Page MenuHome GnuPG

gpg --verify suggests entire file was verified, even if file contains auxiliary data
Closed, ResolvedPublic

Description

"gpg --verify <filename>" returns a binary answer: has a valid signature,
doesn't have a valid signature. This is described in the man page as "Assume
that the first argument is a signed file or a detached signature and verify
it without generating any output."

This works well for detached signatures or for files that contain only a
clearsigned message and nothing else. The problem comes in when somewhere in
a file a valid block of clearsigned text is present, but this block is
preceded or followed by auxiliary data. Running "gpg --verify" on that file
results in an assertion that "the file" has a "valid signature" while in
fact only a part of the file was verified with no way of knowing which.

As it turned out, implementors have been assuming that running
"gpg --verify" on a file yields enough information to further process
that file as if all data in it were correctly signed. It has been
argued that running "gpg --verify" in its current form on a clearsigned
file is useless as it only tells you that that "something somewhere in
that file has a valid signature".

(There is currently a working way to verify and extract only the signed
data, which is by using --status-fd and parsing its output.)

Details

Related Objects

Event Timeline

thijs set External Link to http://bugs.debian.org/704645.
thijs added a subscriber: thijs.

This is an application problem. For example KMail renders the signed parts in a
frame with a different color so to visible explain what has been signed. Mutt
has a similar feature. We can't do anything about this in gpg than to emit
certain status lines and to output the signed data.

This is long known problem with signatures and not even the worst. MUAs
introduced ways to mitigate the problems 2 decades ago. The best working
solutions is to use PGP/MIME for mail and detached signatures for other data.

Yes. I think we're in agreement that MIME and detached signatures are the best way.

However, the functionality in gpg to check cleartext messages is there. If gpg
is confronted with a cleartext file containing auxilliary data, wouldn't it
better refrain from giving a positive return code when checking that file?

I'm reading in your response that you're not eager to change the behaviour of
--verify in this regard, right?

If that's the case, perhaps you can consider this patch to add a note to the
documentation, making it clear what is expected when using --verify on inline
signed files with auxiliary data. Afterall, we've seen several places where
--verify was used insecurely in the wild, so some warning may be in order.

werner claimed this task.
werner removed a project: Restricted Project.