Skip to content

sq verify should not mix signed content with signature status output

yesterday i was able to verify a signed message with sq verify which is pretty cool...

$ sq verify --public-key-file /tmp/public.key /tmp/signed-message.asc
Compressed using ZIP
Good signature from B5FB 9E3E 3661 A436
1 good signature.
Hey Antoine,

No problem! Thanks for helping with this!

Could you create two accounts for that have ssh access with [REDACTED]?

Thanks!

... well I think this is verified... How can I be sure? Could this not be a message that simply contains Good signature from...?

I think there are multiple problems here:

  1. signed content is mixed with the signature status. this kind of problem has been a plague of the GnuPG interface and I think should be a total no-no here as well

  2. signature status output doesn't seem to be machine readable. i suspect people might be attracted by sequoia as a simpler and more intuitive commandline than GnuPG and will try to parse that output, with potentially catastrophic results. i know that Sequoia is designed to be a (presumably) sound ABI but because those commandline programs exist, they will be used.

  3. the signing key seems to be only a long key ID and not a fingerprint. I haven't double-checked the actual packet in this signature to see if there's a Issuer Fingerprint subpacket, but I sure hope that sq properly parses and shows those instead of long keyids by default

Note that gpg --verify "solves" this problem by forcing the user to send the output to a file with the --output flag. I am not sure I like that interface as, by default, it shows no output at all so users might thing the message is empty. But it at least enforces a sane separation of concerns.

I am not sure how this should be done, but the current approach seems slightly dangerous, at least.

Thanks for your work!