Right now, if you change your preferences you must restart the daemon manually. Instead, the Daemon should detect or be told that the preferences have changed and update itself appropriately.

If someone loses their passphrase, we have no way for them to recover or reset it.

The passphrase is not stored anywhere, and is used to derive the key to encrypt their master key, which is in turn used to encrypt their org specific keys. In other words, once you lose your passphrase, you've lost access to everything else.

We need a method for a user to recover their master key, and re-encrypt it with a new phassphrase.

Existing setup

A user's passphrase is via scrypt to 256 bytes. The first 192 bytes are used to encrypt the master key via triplesec. The next 32 bytes are used for hmac authentication against the server during logic. The final 32 bytes are used for v2 login (implementation in progress), which uses eddsa for authentication.

New setup

We need to:

• allow a user to authenticate with their passphrase as is done now
• allow a user to authenticate with a backup paper key, which has restricted access
  • it can retrieve the master key
  • it can change the master key
  • it can change the passphrase based eddsa login details
• store the master key in a way that is accessible by both the passphrase and the paper key

If both the passphrase and the paper key allow access to the master key, then if a user loses their passphrase, they can authenticate against the server using their paper key, download the master key, and re-upload the master key, encrypted for their paper key and their new passphrase (which they would also upload).

Shared encryption of the master key

Under the new scheme, the user's passphrase will be stretched and split as such:

An account with a paper key will use an entirely different method for decrypting the master key. Since both the torus client will have to know how to do this, and the server will know which accounts are configured this way, we can reset the bytes used and stretch less.

The paper key will likewise be stretched to 64 bytes, and split in the same way.

The master key will be encrypted via triplesec as before, but we will generate the passphrase via ecdhe (see curve25519.ScalarMult) using the curve25519 portions of both the passphrase and the paper key. there is no need to manually stretch the ecdhe output before feeding into triplesec, as triplesec will scrypt itself.

Creating the paper key

New accounts will generate and display the paper key during signup.
Existing accounts will need to upgrade. We can do this in the client by detecting that the server has told us we're on the old login flow during login.

The paper key itself should be a mneumonic sentence, generated via https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki or similar.

The profile recover command

torus profile recover (or torus recover?) will prompt for your email and your paperkey, then allow you to enter a new passphrase. It will handle re-encrypting the master key with your new passphrase/existing paper key

For stuff uploaded to get.torus.sh, we should set the s3 content-type and cache-control headers. This should happen when the file is uploaded.

Confirm prompts should support a default yes or no.

The default option should be uppercased in the [y/n] text in the prompt.

Hey guys, I think it would be cool if you could move around the choice selector with vim bindings (hjkl), this is what I initially tried to do and thought your product was broken.

We want to be able to help users onboard into the application by showing them contextual help based on commands that they have ran. Things like:

• Showing the command to create an object inside an empty state
  • i.e torus envs list says "No environments found" but also indicates to use torus envs create
• Show a command which would likely be used next after an action
• i.e torus teams create suggests creating a policy to attach to that team.

This will be governed by the core.hints pref (enabling users to toggle it on an off).

We would surface the feature during signup with a Y/n prompt asking if they would like to enable them (defaulting to yes).

We haven't documented the new worklog resolve command, we should do that!

Problem

Configuration files are still core to many deployment flows and many developers prefer them.

Our challenge is to offer an experience that enables you to store secrets with torus while integrating seamlessly into your pre-existing deployment pipeline.

To do that, we can offer people the ability to derive configuration files at deployment time accepting the fact that these files must be kept "safe" (as they move outside the confines of the Torus ecosystem).

Proposal

We're proposing a torus template command that operates exactly like torus run and torus view allow users to specify the service, environment, etc., through flags but also require a template file (e.g. torus template -e production -s api config.json.template).

Torus would then use the given template to generate a config file and print it to stdout. Optionally, if --file is provided then we will write the output to the given file path.

For simplicity and approachability, I think the best option for a templating engine would be something like handlebars which has a decent go library.

If an expected variable is not present, the template command will fail.

Command Help

NAME:
   torus template - Generate a configuration file using secrets for the given project, service, and environment. By default, the result is written to stdout.

USAGE:
   torus template [template-file] [output file] [command options]

CATEGORY:
   SECRETS

OPTIONS:
   --org ORG, -o ORG                 Use this organization.
   --project PROJECT, -p PROJECT     Use this project.
   --environment ENV, -e ENV         Use this environment.
   --service SERVICE, -s SERVICE     Use this service. (default: default)
   --user USER, -u USER              Use this user.
   --machine MACHINE, -m MACHINE     Use this machine.
   --instance INSTANCE, -i INSTANCE  Use this instance. (default: 1)

Example Usage

$ cat service.json.template
{
  "port": {{ port }},
  "sendgrid_token": {{ sendgrid_token }}
}

$ torus template -e production -s api service.json.template
{
  "port": 3211,
  "sendgrid_token": "wwerwerwerwrwrwre"
}

$ torus template -e production -s auth service.json.template auth.json

# For complex config files, we can offer an iterable (config) for looping over the available configuration.
$ cat complex.env.template
{
  "port": {{ config.port }},
  "sendgrid_token": "{{ config.sendgrid_token }}"
}

Todo

• Implement new --format flag with torus view
• Implement torus template command as spec'd above

Running torus system wide for machine usage is quite different than for a single user, as seen in #59

We need to enforce a different permission model.

For a user, everything should be accessible by that user and only that user. For a machine, the machine's token should be accessible only by root/the init process.

Logs should be viewable by system admins, and the torus socket/pid file should be accessible by some semi-trusted set of processes (ie a group).

This is mostly supported now, but configuring it is not ideal.

This issue will cover the changes we can make to make configuring torus as a system daemon for machine use nice and easy.

Placeholder for discussion about these facets of the style guide.

Talking points

• Select lists
  • With and without "new item" input
• Text input
• Password inputs
• Confirmation (Y/N/abort)
• Args, command option and flag usage

Once a user has run the release-all build step, we don't actually know where the generated artifacts live.

It'd be good for the makefile to produce that url. Secondly, the "staging" or "release" bucket used for non-production releases should be indexable so we can browse our release candidates.

This should be publicly available.

We've had a lot of questions regarding windows, it'd be great if we could add proper support. The largest change will probably be handling the Daemon socket which currently uses a Unix file socket.

There is other work as well, to acclimatize the environment to a windows user. We'll also need a decent strategy for ensuring the CLI tool continues to work on Windows through CI.

From the original pr (#170):

• Get a nice interface in place for the session/auth stuff (XXX included in changes)
• Share api clients between frontend and daemon (#174, #175, #176)
• (Maybe) Replace envelope/primitive split with a flattened primitive only struct that will serialize and deserialize properly
• Interfaces and embedded shared structs all over the place

These were left off to reduce the size of the PR. The shared api clients point would be the most nice to have immediately.

There are a few types of "secrets" that don't fit within the concept of a project (e.g. code repository) as their life cycles exist outside of a single application (e.g. AWS_SECRET_KEY or similar).

Ideally, these secrets can be stored inside torus, however, we need to answer a few questions.

• Do these secrets belong to the org or the user? For example, if I set my AWS_SECRET_KEY, is that accessible to the org or does the data belong to me?
• How are these secrets (which don't belong to a specific project) affect those that are set within a project or service (i.e. how does path specificity fit?)
• What would it look like to set a personal or global secret?
• How would you view and explore these secrets in relation to the other secrets stored inside torus?

All feedback, thoughts, ideas are welcome :)

• Have no machines created
• torus machines list
• Receive message "Machine roles not found."

This is confusing because it's no so much that the roles aren't found, but there are no machines.

The early exit happens here, but we should probably do the machines lookup prior to that.

I got an error message "Unauthorized: You are unauthorized to perform this action." when trying to log in multiple times, which was only fixed by logging out and trying to log back in, meaning Torus never logged my account out overnight.

• The underlying command framework supports dynamic tab completion
  • Though has this bug which we should see solved first, before implementing
  • app.EnableBashCompletion = true in main.go
• Need to figure out how this integrates with distribution channels
  • Will it automatically add the bash completion during install? How do disable it?
  • How do we make manual install easy?

First step would be tab completion of commands.

Second step, once we've begun caching locally, would be tab completing object names.

When correcting keyring memberships, the worklog should know about when a user's keypair was revoked and replaced with a new one. This should trigger:

• adding the new keypair into the existing active keyrings (so the user has access)
• in the secrets worklog handler - rotating the existing keyring versions (happens already)

For testing, it's probably time we add a hidden keypairs revoke command.

$> torus panic
Take a deep breath. You don't have to panic.

Did you lose your paper key, or has someone else seen it [y/n]? n
Did someone else get access to your passphrase [y/n]? y

Ok. It's going to be fine. First, you'll have to pick a new passphrase.
Then, I'll remove your account's access to secrets in any orgs you belong to,
just in case someone bad does have your old passphrase and tries to use it.

Next, I'll let the other members of the orgs know that they need to re-add your
access to the secrets. They'll just need to confirm that it's ok; it won't be much
work for them at all.

Finally, I'll track all of the secrets you used to have access to, and help you and
your friends change the values, in case someone bad did access them.

Let's get started.

Enter your new passphrase:

On the hierarchy of fixing oopses, torus panic is the final stop:

• torus profile update: change your password just because
• torus profile recover: (#144) Create a new password using your backup paper key, when you've just forgotten it.
• torus panic: You've lost your physical paper key, or you suspect someone has stolen your passphrase. Revoke all of your existing access, regenerate your compromised parts, and track secret rotation.

Is it not yet possible to delete projects or services? torus project delete (etc) does nothing, and the help only shows list and create actions.

I didn't realize there was a hierarchy of projects containing services, so now I have a few extra projects lying around that should really be services.

I'm stuck here:

> $ torus link                                                                                                                                                                                                                                
✔ Create a new organization: awesome-organization
✔ Create a new project: cool-secrets

Org creation failed, please try again.

We should support ubuntu 16.10. This may require signing the repos: #73

As part of our efforts to bolster onboarding we should offer tutorials for common workflows.
For instance, the quickstart would be made available as a tutorial.

We would ask the user during signup (after verification) if they would like to see a tutorial, and then would let them page through the steps.

The user could then re-access the tutorials through a category of commands specifically for this type of experience. Maybe it's just one command with subcommands, or maybe it's a category with a number of top level tutorials.. unsure what would be best.

They would be simple predefined output that walks a user through a concept and series of commands.

Hit this error when updating my email and password. It should probably just advise me I've been logged out?

You will be required to re-verify your email address before taking any further actions within Torus.
✔ Do you wish to continue? [Y/n] y
Login failed.
Unauthorized: You are unauthorized to perform this action.

As an admin, I should be able to tell who is missing keys, perhaps this should be an unresolvable item in the worklog?

The purpose is to allow an admin or other team member to help diagnose/guide the user in getting their organization back into a ✅ state.

Currently, torus worklog list only shows keypairs if you are missing keypairs, not another user in the org.

thoughts @jbowes ?

To reduce fragmentation in our CLI and to improve some of the interactions we use, we are going to produce a style guide.

This issue will act as a central hub for all things style guide, which will start with discussion around each major area of input/output.

• Tables and lists
• Success, failure, and error states
• Whitespace and layout
• Input prompts
• Rich formatting

Was asked an interesting question today:

How do I see which policies affect me?

The short answer today is:

With a lot of effort

To understand your position in the ACLs you'd need to:

• torus teams list
• torus teams members <team> for each team
• torus policies list
• torus policies view <policy> for each policy attached to each team
• Then decipher in your head how the policies resolve.

I propose that we add a command which will show the current access status:
torus policies access for example.

This would look at the authenticated user/machine, and then dump the complete resolved policy so that you can easily understand the position you're in.

I am storing a secret which consists of a decimal number, e.g. '5346.2346578' and when I store it and retrieve it back Torus changes it to scientific notation e.g. '5346.234+e6'.

Placeholder for discussion about these facets of the style guide.

Talking points

• Newlines after command input
• Tabwriter spacing
• General newline usage
• Table column spacing

Hey,

I just noticed this project is named the same as a project that's in a relatively similar space (distributed storage, not necessarily secrets): https://github.com/coreos/torus

We should begin Signing the binary distributions posted to https://get.torus.sh, so their origin can be verified

On route to overhauling the UX and standardizing output we need to decide what shape our tables and lists take in various situations (empty, one column, multiple column, multi-line table, etc)

Talking points

• What do our tables look like?
  • Do we use headers? What do they look like?
• Are lists just tables with one column?
  • Do one column tables have headers?
• How do we handle lists with asterisks (technically two column)
• How do we handle list data which is multi-line (such as worklog)
  • Git log inspired format?
• What is our default approach to sorting?
• Do we offer filtering?
  • Graceful degradation (no rich formatting, removing headers etc) for scripts
  • Rely on system tools as much as possible (awk, grep)
• How do we denote different table row states?
  • Critical vs non-critical?
  • Automate-able vs manual

The website url is linked in the readme.
It would be nice to have a mention of site url in headline (and readme too)

Placeholder for discussion about these facets of the style guide.

Talking points

• Use of color
• Use for formatting (bold, italic, underline)
• Emoji or icon usage
• Graceful degradation for scripting
• Prefs for disabling/enabling

If you change your email using torus profile update, it would be handy for us to also prompt for the verification code (a la signup) making it very clear that you can't perform any more actions without verifying your account.

Unlike torus set, unset, view, and ls we do not validate that the path used in an ACL through allow or deny exists -- making it very easy for a user to set a rule against an unknown project, environment, or service.

Is it possible to host your solution on premise?

When viewing credentials, if the value is unset in a different keyring version than it was set (ie a newer one), the set value is still displayed.

We need to standardize how we display the subject of an invite through the invite process.

Since an invite begins as having only an email address, it makes sense to focus on that:

• pending: [email protected]
• accepted: username <[email protected]>
• approved: username <[email protected]>

These should be updated for the invites commands, and for worklog.

The systemd based machine use case ships in our rpm, but not yet in the deb. Add it there, too.

I tried out the hidden keypair revoke command to test the set -> revoke -> generate -> set flow, and couldn't do it!

Ians-MacBook-Pro-2:~ ianlivingstone$ torus set sdfdsf sfsdf
Credentials retrieved
Keypairs retrieved
Encrypting key retrieved
Credential encrypted
Completed Operation

Credential sdfdsf has been set at /anewguy/sdf/dev-anewguy/default/*/*/sdfdsf
Ians-MacBook-Pro-2:~ ianlivingstone$ torus keypairs revoke
Keypairs retrieved
Encryption keys revoked
Encryption key revocation uploaded
Signing keys revoked
Signing key revocation uploaded
Keypairs revoked.
Ians-MacBook-Pro-2:~ ianlivingstone$ torus keypairs generate
Generating signing and encryption keypairs for org: anewguy
Keypairs generated
Signing keys signed
Signing keys uploaded
Encryption keys signed
Keypair generation successful.
Ians-MacBook-Pro-2:~ ianlivingstone$ torus set sdfdsf sfsdff
Credentials retrieved
Keypairs retrieved
Encrypting key retrieved
Credential encrypted
Could not set credential.
Bad Request: resource exists

Is it possible to have torus-cli use a proxy?
My ALL_PROXY, http_proxy, https_proxy, HTTP_PROXY and HTTPS_PROXY environment variables are all set which looks be what Go uses by default:
http://stackoverflow.com/questions/14661511/setting-up-proxy-for-http-client

If a token expires, or becomes invalid, the daemon does not destroy the session -- instead it will continue to attempt to use its currently stored session until the daemon is restarted or a user explicitly logs out through the CLI.

We should detect this scenario and destroy the session if a 401 is returned.

We should never use keys that are revoked when adding to a keyring:

• find the non-revoked version of a keypair for a user when adding them to a keyring, and use that
• teach the worklog to re-encode keyring membership with a non-revoked version, when a revoked one is found. This should be auto-resolvable.

This will be hard to test without having revoked keys, so:

• add torus keypairs generate --forceto force a revocation/recreation of a set of keypairs.

It would be very cool if i could do:
torus view /org/proj/env/default/1
In addition to flags.

Talking points

• Complex error messages
  • Error message plus description
• Successful states contain output or not?
  • In a lot of system tools no output is the success state
  • Most of our commands now provide a confirmation message
• Invalid usage? validation failure?

I started playing around with the new ** support with ACL, I owuld have expected the following to work:

$ torus allow crudl /newv2onluorg/api/production/** devops
Invalid path expression.
Invalid service.

However, the following does work:

$ torus allow crudl /newv2onluorg/api/production/**/* devops
Policy generated and attached to the devops team.

Effect:    allow
Action(s): create, read, update, delete, list
Resource:  /newv2onluorg/api/production/*/*/*/*

Necessary permissions (read, list) have also been granted.

However, if you leave off the trailing slash you get:

$ torus allow crudl /newv2onluorg/api/production/**/ devops
Policy generated and attached to the devops team.

Effect:    allow
Action(s): create, read, update, delete, list
Resource:  /newv2onluorg/api/production/*/*/*/

Necessary permissions (read, list) have also been granted.

Which I believe is an invalid path?