Unread messages should be deleted after a week

• move the ci service to cli/internal
• create ci command (ks ci [command])
• rename push-ci to ci send (ks ci send)
• move the setup (service selection, keys prompts, etc) to ks ci setup
• service provider specifics (key prompts, etc) should be handled by the service implementation for that provider (eg github)
• ks ci reset, ks ci clean
• assess : should ks ci send send all (prod and staging) environments or only the active one (or the one specified by --env ?
• split message in slot

• keystone.yaml - YAML configuration file. See structure below
• .keystone - Keystone folder holding the cache (files + .env) and a file pointing to the current environment. See structure below.
• if not already present, add the folder .keystone to .gitignore

keystone.yaml

---
projectId: djkfhkqjhgjhdgsjhgdsf
env:
- key: ALGOLIA_TOKEN
  strict: true
- SENTRY
files:
- config/credentials.json
- config/cert.ca
options:
  strict: true

.keystone/

.keystone/
  |- environment // holds the current environment name
  |-  cache/ 
       |- .env // cache for all the environment variables
       |- [...other files] are secrets files to cache

WARNING: cgroup v2 is not fully supported yet, proceeding with partial confinement

Get remote modifications:

$ ks fetch

sync .keystone folder

• send current env hash
  • 204 No content (no message, and user sens last hash 🐱 )
  • 200 Env hash / last message for me
    • if 200 and no message, ask someone to forge hash message for me.

Load keystone env, before start your program:

$ eval(ks source)

• create digest output by current system (load env vars, show warings)
• if missing files :
  • write file
• if existing files, but same:
  • do nothing
• if existing files, and different:
  • show warnings

Add a new file

$ ks file add config/myfile

• execute ks fetch
• retrieve all public keys from current project env
• for each one, prepare message

To handle multiple repositories situations, it is necessary that multiple ci services be setup.
Therefore, ks ci setup is a goner, replaced by:

• ks ci add: to add a service
• ks ci rm: to remove a service
• ks ci: to list currently configured services

On top of that, ks ci send should send the current environment to all configured services. Maybe a switch could allow to send to only one service (or a defined list of services), but is there a case for it ?

Push secrets from the command line. This avoid keystone to store the secrets for a long time on its server.

• Integration with Github
• Integration with Gitlab

Push one secret as a message, if message is too large split it

A user should be able to sign with its github account

Secrets are stored in .keystone/<env>/.env file.
And files are store in .keystone/<env>/<file-path>.

Conflict if file-path is .env

https://docusaurus.io/ seems like a good option

A user should be able to use its Gitlab account to connect.

• Use themis for all encryption jobs, see https://www.cossacklabs.com/themis/ and Secure Message
• Create a TTL strategy to remove message from the inbox after a time defined by default or by the user (Cloud tasks)

Currenty key pairs are bound to the third-party account used to login. It unfortunately bounds an account to only one device.

To allow a user to use Keystone smoothly on multiple devices, a user could have more one key pair, and not have it bound to a third party service.

• in DB, rework the relation, so that User has many PublicKey (or use an embedded array ?);
• upon login, if, there is no key pair in config, generate one and add the public key the that relation;
• when sending messages, send for all the public keys; when fetching, fetch for the public key in the .config; Rework the DB relation to all this (maybe);
• Store device name in .config and add it to relation in db;
• in cli, a set of new commands (those are suggestions) : ks keys, to list keys; ks keys revoke [key index], to revoke a key;
• Store in auth_token an uuid for the device, if revoked, the device can't interact with the project;
• Can choose device name;
• Send mail when new device registered to user and admins.

Due to the production context (Google Cloud Run) requests can take several seconds (2 to 3) because the server has to be "cold started".

It would be interesting to have some kind of a loader displayed if a requests takes more than a second to complete.
The loader should not be used in ks source, tho

See: https://golang.org/pkg/log/

Has timestamp and file name facilities.

with this output

$ ks file
Failed to render template files list (template: files list:3:29: executing "files list" at <8>
: wrong type for value; expected string; got keystonefile.FileKey)

ks secret and ks file should also show files in cache (with a color). So that the user may be informed some secrets they might need is already available

There is currently no way to "destroy" a project. Should not there be a ks destroy ? Or ks delete-project (so that’s harder to type and we are sure the user actually meant it when they type that) ?

Get remote modifications:

$ ks fetch

sync .keystone folder

• send current env hash
  • 204 No content (no message, and user sens last hash 🐱 )
  • 200 Env hash / last message for me
    • if 200 and no message, ask someone to forge hash message for me.

Current behaviour stops the init command if the project’s keystone.yml exists. This allows for cases where the project seems initialized but the missing directories and file (like the current environments) lead to an unusable CLI.

No matter the other files, init should create the missing ones.

We set values for each environment for secret.
But if we want to stop process (with ctrl+c), cli doesn't kill process. Same as "enter" press.

Requirements

• Invitee needs a keystone account (in order to have pub keys to use)

Flow:

• Invitee provide a token/code to the project owner
• the project owner uses the code to add him to the project
• the project owner can send an email with the instructions to create an account and generate a code

Samuel could send new secret being a new member and not having any secret in cache.

When no environment has been checkout, the command ks status reports undefined. It should state that the user need to checkout an environment.

See screenshot below:

• Endpoint to retrieve the project users and their pub keys to send secure messages
• Backup command to export and import Keystone user conf on another computer

Given the following project structure:

root
├── .ksconfig
└── src
    └── index.js

Calling ks env checkout default from root/src will fail.
ks should walk up the directory strucuture to find the closest .ksconfig in the tree

There is going to be a need for a request for fetching a user public key. Since this operation will have to be done on every message fetch, shouldn’t we cache those public keys ?

Then lands the question of cache invalidation of course…

What should a developer, a devops or an admin/owner should be allowed to do on the dev, ci, stagingand prod environments.

Otherwise, other user will think new secrets have been added

The NPM install doesn't work but the binary installer does.

We should ask windows users to download the binary, launch the installer and set their path to the program located in Program Files

setx /M PATH "%PATH%;C:\Something\bin"

To handle updates, we could detect the user system and ask them to download the latest binary if any instead of asking them to run the npm -g i @keystone/clicommand.

rm should not remove secret from the cache, just in keystone.yml
purge should remove secret from cache

JWT Token expiration is currently not handled at all, leading to confusing errors such as 'Project doesn't exist', even though it is known to exist.

There is currently no way to set the content of a file for a single environment. The current only solution would be to ks file add it but the content of the file will be asked for all the environment, as the --env flag as no effect on ks file add.

One option would be to mimic ks secret set with a ks file set that would set the content for the current environment, automatically enabling the --env switch.

An other is to make file add sensible to --env switch, requiring some rework of how this flag is currently handled : it would affect all commands where the --env works.

A third and rather wild one, would be to have a deamon monitoring keystoned files and send messages to members when cache content is modified. But I’m afraid that would require a lotta work.

When a file is deleted locally, the user can run 'ks push' to remove it from storage

What I did

I listed secrets with ks secret and saw that there already was a MANDRILL_API_KEY but was unused (not in the keystone.yml.

I wanted to use it, so I went for ks secret add MANDRILL_API_KEY, but was welcome by a first error stating ks secret add requires two positional arguments.
So I went for ks secret add MANDRILL_API_KEY "", but then, this happened :

keystone develop [$]
❯ ks secret add MANDRILL_API_KEY ""
{MANDRILL_API_KEY false map[dev:*** prod:** staging:***] false}
The secret already exist. Values are:
dev: ***
prod: ***
staging: ***
✗ Do you want to override the values:

 ERROR

I was asked whether I wanted to overwrite the existing values and said no.

What I expected

I expected several things to go differently :

• ks secret add to accept one argument and use prompts for the secret value, or simply ask me to use the existing values, and add the secret to the keystone.yml
• ks secret add <secret name> <secret value> to add the secret to the keystone.yml and say SUCCESS when I say "no" to "Do you want to overwrite the exiting values?"

1. new table roles: name(string), description(string)
2. new table environment_types: name(string)
3. new relation between roles and environment_types: rights: enum(admin, read, write, none)
4. new link from environments to environment_types
5. define seed (which roles can do what on which environments)
6. project_members links projects, users and roles
7. environments references projects (belongs to)
8. environments have a versionID

API
new route /roles

CLI
new command : ks role -> list roles
maybe later has CRUD ops

ks member add -> help lists roles
for each members prompts the role
ks member add --role developer

ks member set-role developer