Bug 3314 - user can't see validity of gpg signatures
Summary: user can't see validity of gpg signatures
Status: RESOLVED FIXED
Alias: None
Product: Claws Mail (GTK 2)
Classification: Unclassified
Component: Plugins/Privacy/PGP (show other bugs)
Version: other
Hardware: PC Linux
: P3 enhancement
Assignee: users
URL:
Depends on:
Blocks:
 
Reported: 2014-10-29 13:34 CET by HW42
Modified: 2014-10-30 22:17 CET (History)
1 user (show)

See Also:


Attachments
Fake key to demonstrate the problem with not showing the validity (deleted)
2014-10-29 17:59 CET, HW42
no flags Details
Good signature made with the fake key. (866 bytes, text/plain)
2014-10-29 18:00 CET, HW42
no flags Details

Description HW42 2014-10-29 13:34:45 CET
Commit fe89b3a7 [0] broke the verification of the trustworthiness of gpg signatures.

Every "correct" (i.e. key X signed this message correctly) is show as good signature.
This is a critical security bug since now the user don't see if the UID of the key which
made this signature is valid. So it's sufficient that someone has imported the key which
has signed the message - but the UID is never verified.

I think the committer was confused about the meaning of owner-trust and signature validity
in the context of gpg.

Owner-trust is a user specific setting for a key which determines how much you trust
signatures made by that key.

Validity say if gpg could verify that the UID of the key is valid. This is done by checking
the signatures of the key in combination with the according owner-trust (see also [1]).

To reproduce simply import a key of which you don't now if it's UID is valid. Now open
a message which is correctly signed this message. This is show as "good signature" and
you have no indication that you don't now that the UID is valid.

This affects versions >= 3.10.0


[0]: http://git.claws-mail.org/?p=claws.git;a=commitdiff;h=fe89b3a7fbcefc21dcf195929c948bd8be603788;hp=b0a0fd75fb84a8bfffebc945faa241b06feb91bf
[1]: https://www.gnupg.org/faq/GnuPG-FAQ.html#what-are-trust-validity-and-ownertrust
Comment 1 Paul 2014-10-29 13:43:09 CET
In fact, no.

That commit did what it said, "fix erroneous 'untrusted' msg based on validity not trust". Previously it reported a "valid" sig as a "trusted" sig. That was mixing up "owner trust" with "uid vailidity". "valid" and "trust" are not interchangeable terms.

Now if you want to see validity and trust, click the button a 2nd time to "view full information"
Comment 2 HW42 2014-10-29 13:55:08 CET
Ok, I maybe formulated the bug message a bit confusing.

But the problem remains. If the signature is correct (i.e. key X singed this
message) the thing which the user really interested in is if the signature is valid (i.e. he trust that the show UID really belongs to key X).

So it is very critical to show the validity in the "Good signature" message.
(Yes the full information shows this correctly.)
Comment 3 Paul 2014-10-29 14:06:24 CET
You can think of the initial display as 'gpg -v' and the full info as 'gpg -v --verify-options show-uid-validity'
Comment 4 HW42 2014-10-29 17:01:08 CET
At least the gpg versions I have tested (1.4.18, 2.0.26, 2.1.0-beta895)
does very clearly show if the validity of the signature can't be
verified (they also use "trusted" here):

[...]
gpg: Good signature from "Some UID <mail@example.org>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
[...]

I think it's very critical to display the validity of the signature
since else you have to click every time to the "full information".
Comment 5 Paul 2014-10-29 17:12:48 CET
(In reply to comment #4)
> At least the gpg versions I have tested (1.4.18, 2.0.26, 2.1.0-beta895)
> does very clearly show if the validity of the signature can't be
> verified (they also use "trusted" here):
> 
> [...]
> gpg: Good signature from "Some UID <mail@example.org>"
> gpg: WARNING: This key is not certified with a trusted signature!
> gpg:          There is no indication that the signature belongs to the owner.
> [...]
> 
> I think it's very critical to display the validity of the signature
> since else you have to click every time to the "full information".

It's not the validity of the signature that you're seeing, it's the validity of the UID. A signature is either good or bad, a UID has validity. The owner has "trust". You are confusing the terms and using them as if they are interchangeable. They are not.

How is this "critical"? If you're verifying a downloaded software package, e.g. the Claws Mail tarballs, or verifying a signature on a message, e.g. the Claws Mail release announcements, would you not trust them? Do you never trust a signature unless you've signed the key?
Comment 6 HW42 2014-10-29 17:58:18 CET
> It's not the validity of the signature that you're seeing, it's the
> validity of the UID. A signature is either good or bad, a UID has
> validity. The owner has "trust". You are confusing the terms and using
> them as if they are interchangeable. They are not.

Yes "good/bad signature" and "validity" and "(owner-)trust" have
different meanings in gpg.

Sorry if my formulation was unclear.

My point is that it is critical to the user to see if the uid of the key
which created a "good signature" is valid.

> How is this "critical"? If you're verifying a downloaded software
> package, e.g. the Claws Mail tarballs, or verifying a signature on a
> message, e.g. the Claws Mail release announcements, would you not trust
> them? Do you never trust a signature unless you've signed the key?

There are two possibilities.

Either I have a keyring which contains only trusted keys. For example
the debian-keyring (here I mean "trusted" in the sense of I trust them
to sign packages. uid's are ignored here).

Or the other possibility is that I know via my Web-of-Trust (i.e. I have
personally signed the key, or somebody I trust (i.e. owner-trust) have
signed it, or you manually verify longer certification chains) that the
uid belongs to the key.

In your "normal" keyring you always import potentially untrusted keys
when you fetch them from a keyserver.

It's critical since else way I could simply upload the attached fake key
to a keyserver (obviuosly without the warning in the uid) and publish a
fake release of claws-mail. When somebody now reads the release message
hey sees "key 0x654CECFF not available" and therefore download it from
the key server. Now claws-mail states "Good signature from Paul ...".
Unless he clicks on the "full information" he has no indication that
something is wrong.
Comment 7 HW42 2014-10-29 17:59:30 CET
Created attachment 1444 [details]
Fake key to demonstrate the problem with not showing the validity
Comment 8 HW42 2014-10-29 18:00:39 CET
Created attachment 1445 [details]
Good signature made with the fake key.
Comment 9 HW42 2014-10-29 18:49:09 CET
> In your "normal" keyring you always import potentially untrusted keys
> when you fetch them from a keyserver.

Here I mean "untrusted" in the sense of "untrusted input" not owner-trust (since everybody can upload arbitrary key to the keyservers.
Comment 10 Paul 2014-10-29 19:41:23 CET
The content of attachment 1444 [details] has been deleted by
    Paul <paul@claws-mail.org>
without providing any reason.

The token used to delete this attachment was generated at 2014-10-29 19:41:16 CET.
Comment 11 Paul 2014-10-29 19:44:39 CET
(In reply to comment #7)
> Created attachment 1444 [details]
> Fake key to demonstrate the problem with not showing the validity

Not necessary, I understand your words.
Comment 12 Paul 2014-10-30 19:26:58 CET
I've now implemented this feature request.
Just for your information, on looking back at this and the commit, fe89b3a7, you referenced, I recalled why I removed that. It was because it was broken. The switch was on gpg_err_code(sig->validity) and the case options are against gpgme_validity_t, which is a validity of a trust item or key, not a sig. Therefore you never got an accurate answer, as it was taking a err code from one thing and matching to an enum from another thing.
Comment 13 HW42 2014-10-30 22:17:56 CET
> I've now implemented this feature request.

Thank you.

> Just for your information, on looking back at this and the commit,
> fe89b3a7, you referenced, I recalled why I removed that. It was because
> it was broken. The switch was on gpg_err_code(sig->validity) and the
> case options are against gpgme_validity_t, which is a validity of a
> trust item or key, not a sig. Therefore you never got an accurate
> answer, as it was taking a err code from one thing and matching to an
> enum from another thing.

I know it worked correctly for the case of "full" validity and for
"unknown" validity. But due to the type mismatch this was obviously just
luck.

Since the "Good signature"-message can still be misleading for somebody
not so familiar with the terms used by gpg what do you think of simply
show the validity like in the full information view?

Note You need to log in before you can comment on or make changes to this bug.