RFC: Command line ideas

[maxgoedjen]

Hey everyone – it's been a semi-common request for a command line interface for Secretive, so I want to put out a few ideas I've been kicking around. This is still sort of in the ideation phase where I may or may not implement this, but here's some concerns/ideas I've had so far:

Concerns

Malicious applications interfacing with Secretive

Apps shelling out to secretive command and creating/deleting secrets, etc. Exfiltration of secrets is still not possible in this model.

Accidental creation of large amounts of secrets

A script could trivially have a for loop that creates a massive amount of secrets. I'm not confident how the SEP will deal with this – it might be fine, but it also could break the OS in pretty weird ways.

Just generally confusing

People may think that they're supposed to interact with the command line app instead of the SSH agent to perform signing commands, etc.

Proposed Model

Off by default, only enabled through protected means

The command line would not be enabled by default. Requests to the the secretive command line interface would return with an error code if invoked without enabling. The app could be enabled either within the main Secretive app, or possibly through a sudo command invocation to the CLI. The "enabled" state would be stored as a keychain entry (which only Secretive is allowed to write to, by the design of the keychain) so that apps could not indirectly enable this with a defaults write command or similar.

Design intent

This tool would be, at least initially, focused on a sort of "bootstrap a system" model – operations would primarily be focused on allowing this use case, vs being a full peer to the existing Secretive app.

Operations

• list List existing keys. Not sure what the right format here is for output (feedback appreciated here).
• create Create keys. To avoid the "accidental creation" concern, I'm inclined to add a limit on the maximum number of keys that can be created when using the command line (possibly overridable with a --ignore-safety-limits type argument.
• get-configuration Output configuration state – basically outputting the path to the agent/similar stuff, so that the caller could use that to configure a shell.
• MAYBE: delete. I may entertain the possibility of a delete operation, but IMO (again, feedback appreciated) this is probably not terribly useful in most of the use cases I've considered so far.

[martinpaljak]

• A lot of "modern" apps emit JSON as machine+human-readable format, so this could be considered with list (as an option not default, for easier (?) parsing instead of grep/sed/awk/tr/whatnot).
• Personally, while having safeguards is nice, I don't see a real threat in "malicious scripts creating too many keys as a DoS attack" scenario. I see so many other things that would be screwed before being concerned about it. Put a warning that "hammer can break bones, you sure you want to pick it from the toolbox?" but don't require to click through stupid warnings a la EU cookie banners on every use afterwards
• ditto for delete - ask for authorization (bio/password via UI prompt) but do allow to script/invoke it. UI confirmation implies it would not be possible to silently delete/destroy

[martinpaljak]

#545 might add some wishes to CLI-enabled use

[samhclark]

Something neat would be if the command line could control locking/unlocking a secret for ones that usually require auth every time.

An example workflow is with Homebrew. If you have multiple private taps that you connect to over git+ssh (like I do at work), then Homebrew doesn't work out of the box because it makes all the git+ssh connections in parallel. (See: Homebrew/brew#13469)

You can work around this with a series of commands. You can auth the connection with ssh -T git@example.com then go to the notification that popped up and tell Secretive to keep that key unlocked for the next 1 minute. Then you can run brew update and it'll succeed.

It would be really convenient to wrap that up in a little script like this

$ secretive unlock FINGERPRINT
FINGERPRINT will remain unlocked for 1 minute
$ ssh -T git@example.com
$ brew update
$ secretive lock FINGERPRINT  # to lock it again sooner, if able

[maxgoedjen]

Yeah that's a neat idea. I think it'd still do an interactive auth prompt but if that's okay I think it's probably doable.

[samhclark]

Yeah, right now it's two interactive prompts. One for ssh -T git@example.com and a second one after clicking "Leave unlocked." So even two prompts is fine, that leaves me with the same interaction I have now, except I don't have to deal with my mouse and I can script it all.

[maxgoedjen]

The double prompt is only a design thing (just to prevent a scenario like "user authorizes key use, walks away, another person hits 'leave unlocked'") – if it's initiated explicitly it could be one. If I end up building that I'll likely add a similar one click explicit unlock to the UI too.