Hello,
I'm currently evaluating using `ssh-keygen -Y verify` to check OS
artifacts (e.g. packages) and I noticed that the `-f
allowed_signers_file` option can be passed only once. A side remark:
technically it can be passed multiple times without a warning but the
last invocation overrides all previous ones. Tested using:
$ ssh-keygen -Y verify -f allowed_signers -f /dev/null -n file -s
statement.txt.sig -I wiktor@xxxxxxxxxxxx < statement.txt
Could not verify signature.
While this works (note the order of -f's):
$ ssh-keygen -Y verify -f /dev/null -f allowed_signers -n file -s
statement.txt.sig -I wiktor@xxxxxxxxxxxx < statement.txt
Good "file" signature for wiktor@xxxxxxxxxxxx with RSA key
SHA256:xb+QgBmoSdveobEdwKqUb3BCk9SLJVxq3Ltu2o/FK7U
This is a little bit limiting since it doesn't allow splitting the
signers file into multiple locations that may be managed independently.
For example: a distro's keys file would be managed by a system package
while additional user/local keys could be in a separate one, managed by
the system administrator / end user.
Of course, this could be workarounded by careful concatenation of files
before passing them to "verify" (inserting newlines between files etc.).
Just for comparison the Stateless OpenPGP CLI spec allows passing
multiple CERTS files [0] directly in the command-line.
A similar problem appears in the "File Hierarchy for the Verification of
OS Artifacts (VOA)" draft specification [1] which suggests putting each
key in a separate file (CC'ing David, who is leading this).
In my opinion allowing multiple "-f" files would cleanly solve all these
issues but I'd like to hear what you think about it and if there are any
(potentially better) alternatives?
Thanks for your time!
Kind regards,
Wiktor
[0]:
https://datatracker.ietf.org/doc/html/draft-dkg-openpgp-stateless-cli#name-verify-verify-detached-sign
[1]:
https://github.com/uapi-group/specifications/pull/134/files#diff-c79d1da1ef2fcfffc28ac7308505535eac0942d086d54a990553374ac81fed00R383
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
