Questions on code signing
wk at gnupg.org
Tue Aug 27 11:30:06 CEST 2019
On Tue, 27 Aug 2019 00:18, gnupg-users at gnupg.org said:
> (1) If a file is signed but the signature is incorrect, 'gpg2 -d'
> returns a non-zero status code, so the remote script knows not to
Right but as stated somewhere in the docs, you should never ever rely on
the status code fomr the binary. Well, except for the gpgv tool which
we developed just for the purpose to verify signatures. You can't use
it however with encrypted+signed data.
> like gpg2 will not catch that case. Is there an option I can give in
> addition to -d that REQUIRES the file to be signed? I realize you can
No, you need to check that there is a valid signature by checking the
--status-fd messages. It is a bit tricky to get this right because
there is a variety of things which can be found in the input to gpg.
Using detached signatures makes things much easier because you really
known what has been signed. You still need to check the status-fd
You may also use the GPGME library (or the gpgme-json wrapper) to make
things easier. GPGME takes care of also nitty-gritty you would need to
> (2) If a file is signed and the remote script has the signer's public
> key, then a --verify operation will succeed. The trouble is, what if
> the file is signed by some signature in the remote script's keyring
> other than the expected code signing key? Is there an option that can
> be given to --verify (or along with -d, if there's a solution to (1))
> that can specify the exact signing key (or keys) required? I tried
Your script or progrtam should check which key was used for signing. Or
you make sure that your local keyring only has that very key. Watch out
for this --status-fd token:
The args are:
- [ <primary-key-fpr> ]
This status indicates that the signature is cryptographically
valid. This is similar to GOODSIG, EXPSIG, EXPKEYSIG, or REVKEYSIG
(depending on the date and the state of the signature and signing
key) but has the fingerprint as the argument. Multiple status
lines (VALIDSIG and the other appropriate *SIG status) are emitted
for a valid signature. All arguments here are on one long line.
sig-timestamp is the signature creation time in seconds after the
epoch. expire-timestamp is the signature expiration time in
seconds after the epoch (zero means "does not
expire"). sig-version, pubkey-algo, hash-algo, and sig-class (a
2-byte hex value) are all straight from the signature packet.
PRIMARY-KEY-FPR is the fingerprint of the primary key or identical
to the first argument. This is useful to get back to the primary
key without running gpg again for this purpose.
The primary-key-fpr parameter is used for OpenPGP and not
available for CMS signatures. The sig-version as well as the sig
class is not defined for CMS and currently set to 0 and 00.
Note, that *-TIMESTAMP may either be a number of seconds since
Epoch or an ISO 8601 string which can be detected by the presence
of the letter 'T'.
This can be easily parsed with awk(1) or other tools.
> (3) If a file is both encrypted and signed, is there a way to merely
> verify the signature other than to include a detached signature? Right
> now, using --verify on a single file that was encrypted/signed with
> -es just gives "gpg: verify signatures failed: Unexpected error." Is
> there a way around that, so I don't need to use a detached signature?
You can extra the signature from the encrypted+signed data:
gpg --unwrap -d -o SIG <ENC+SIG
and then run
gpgv -o SIGNEDFILE SIG && echo verified!
--unwrap is not documented and has the minor problem that it also keeps the
compression layer. However, gpgv groks that compression layer and works
as with a standard signature. The signature is on SIGNEDFILE which gpgv
outputs for you.
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 227 bytes
Desc: not available
More information about the Gnupg-users