SCTL is not End2End encryption, instead SCTL is more of an envelope, in which you store secrets until they are needed, and those secrets should only remain available in plain text while the operation that needs them is active.
A feature that I think could be nice for sctl, particularly if you use multiple keys, or if you're a noob and want an easy way to use keys, is basic key management. My idea being that sctl uses a config file (perhaps ~/.sctlcfg) which can hold key state. In it would be something like
keys:
alias: key
or
keys:
- alias: foo
key: bar
The --keys flag could then use the alias as a shorthand instead of a long key name, e.g.
sctl add --key foo
but it shouldn't prevent you from using the key itself
sctl add --key some/long/key
It would require something like a keys subcommand..
sctl
key
add
list
remove
Some additional food for thought is the idea of having a "default" key set, so if no --key flag is set, just use the default. This might be overkill given that its really only useful for when a new .scuttle.json is being created, as the key gets defined in there afterwards.
A feature that I think could be nice for sctl, particularly if you use multiple keys, or if you're a noob and want an easy way to use keys, is basic key management. My idea being that sctl uses a config file (perhaps
~/.sctlcfg) which can hold key state. In it would be something likeor
The
--keysflag could then use the alias as a shorthand instead of a long key name, e.g.but it shouldn't prevent you from using the key itself
It would require something like a
keyssubcommand..Some additional food for thought is the idea of having a "default" key set, so if no
--keyflag is set, just use the default. This might be overkill given that its really only useful for when a new.scuttle.jsonis being created, as the key gets defined in there afterwards.