manifoldco
Cannot set cred *after* revoking keys
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
I spent a few minutes discussing this with @jbowes in person. Currently, this is intended behaviour, as you shouldn't be able to see keyrings you've been revoked from. Therefore, the real problem is that the server doesn't tell you that someone must encode you into the new ring (which should probably be a part of the torus keypairs generate flow).
However, it raises another interesting problem: what about the single user use-case? Even if the above behaviour existed, I should still be able to overwrite the current value otherwise I'll never be able to recover that segment of the path.
So -- we probably also want the message to be along the lines of:
1 - If you want to keep your data, someone else who has access to this keyring needs to re-add you via the worklog
2 - If you're the only user who has access, or you just want to keep moving forward you can use torus set --force to overwrite the existing keyring.
However, #2 is predicated on the client knowing what the version and previous fields should be.
cc @jbowes
However, #2 is predicated on the client knowing what the version and previous fields should be.
If you are an approved and active user with READ or LIST access via the ACL, we should return the Keyring, Membership, and Claim objects but not the Credentials in a case where you have a revoked membership.
This way the Daemon can look at the claims and memberships to determine if any of their active keys are included in the ring at which point we can return an error telling them to get encoded using the worklog.
This also allows us to support the torus set --force flow, just that the Daemon will have to check if they've been added to the keyring (or have revoked keys). If that's the case, the Daemon can return a nice error telling them to use --force if they really do wish to lose access to the data.