Ref T13043. Adds CLI support for revoking SSH keys. Also retargets UI language from "Deactivate" to "Revoke" to make it more clear that this is a one-way operation. This operation is already correctly implemented as a "Revoke" operation.
Details
Details
- Reviewers
amckinley - Maniphest Tasks
- T13043: Improve authentication revocation behaviors
- Commits
- rPfa1ecb7f6612: Add a `bin/auth revoke` revoker for SSH keys
Used bin/auth revoke --type ssh to revoke keys, verified they became revoked (with proper transactions) in the UI. Revoked keys from the web UI flow.
Diff Detail
Diff Detail
- Repository
- rP Phabricator
- Branch
- revoke3
- Lint
Lint Passed - Unit
Tests Passed - Build Status
Buildable 19094 Build 25769: Run Core Tests Build 25768: arc lint + arc unit
Event Timeline
Comment Actions
Is there a reason that this flow updates the SSH keys to mark them as revoked, instead of deleting the rows entirely like the other new revokers?
Comment Actions
When we delete a conduit token, session, or temporary token, there's no way for users to "put it back": it's permanently useless and any attacker who stole a copy of it is out of luck. For example, you can't go into the Conduit API Tokens interface and add a specific token you happen to have on hand: you can only generate a new random one.
With passwords and SSH keys, users can put them back: they can pick "hunter2" as their password again even though Cloudflare put it into public cache, or upload the same SSH public key with the private key on the laptop they left at a bar.
In all cases our goal is to permanently invalidate the relevant credentials (i.e., revoke, not just delete) but for anything where the secret is a random thing we generate rather than something the user provides us, deleting is good enough and tends to be a lot simpler.