[PATCH] crypto: signature verification reports valid User IDs

[PATCH] crypto: signature verification reports valid User IDs

When i'm trying to understand a message signature, i care that i know
who it came from (the "validity" of the identity associated with the
key), *not* whether i'm willing to accept the keyholder's other
identity assertions (the "trust" associated with the certificate).

We've been reporting User ID information based on the "trust"
associated with the certificate, because GMime didn't clearly expose
the validity of the User IDs.

Re: [PATCH] crypto: signature verification reports valid User IDs

On Wed 2017-11-29 23:20:35 -0500, Daniel Kahn Gillmor wrote:

> When i'm trying to understand a message signature, i care that i know
> who it came from (the "validity" of the identity associated with the
> key), *not* whether i'm willing to accept the keyholder's other
> identity assertions (the "trust" associated with the certificate).
>
> We've been reporting User ID information based on the "trust"
> associated with the certificate, because GMime didn't clearly expose
> the validity of the User IDs.
>
> This change relies on fixes made in GMime 3.0.3 and later which
> include https://github.com/jstedfast/gmime/pull/18.

Without this patch, the notmuch test suite currently fails when built
against gmime 3 on debian testing, because gmime 3 on debian testing
now correctly returns key IDs for _get_key_id().

This patch corrects the misbehavior of previous versions of notmuch, and
restores the ability to display correct validity of the keys in
question.

Since we already have util/gmime-extra.c to deal with differences
between gmime-3.0 and 2.6, and since this code is purely gmime related
(not using any notmuch data or types), it makes sense to me put this
(split) there. I guess we might use a different prefix for stuff we add,
although iirc we didn't bother for zlib-extra.c

Re: [PATCH] crypto: signature verification reports valid User IDs

> Daniel Kahn Gillmor <[hidden email]> writes:
>
>> @@ -478,9 +478,10 @@ fi
>> # we need to have a version >= 2.6.5 to avoid a crypto bug. We need
>> # 2.6.7 for permissive "From " header handling.
>> GMIME_MINVER=2.6.7
>> +GMIME3_MINVER=3.0.3
>
> Does this change mean notmuch won't build at all for people with gmime-3
> < 3.0.3? I understand that's not a problem in Debian, but what about in
> general?

iiuc, if you've only got gmime-3 version < 3.0.3, then you will not be
able to build notmuch. however, if you have that *and* you have a
version of gmime-2.6, configure will just use gmime 2.6.

If you only have gmime-2.4, or a version of gmime 2.6 before 2.6.7, then
you are SOL.

I think that's an acceptable situation, though. We're not taking away
too many options from users.

Also, when built against 3.0.0, 3.0.1, or 3.0.2, the identification
information shown during signed messages is strictly *wrong* -- it shows
the assigned ownertrust of a certificate where it should show the
validity. This is not only wrong, but it's actively dangerous, because
it encourages users to mark keys with elevated ownertrust "just to turn
them green". This is the equivalent of encouraging users to add
arbitrary root CAs to their list of trusted X.509 anchors. Not
something a MUA should be doing.

>> +
>> +static const char*
>> +_get_certificate_valid_userid (GMimeCertificate *cert)
>> +{
>
> Since we already have util/gmime-extra.c to deal with differences
> between gmime-3.0 and 2.6, and since this code is purely gmime related
> (not using any notmuch data or types), it makes sense to me put this
> (split) there. I guess we might use a different prefix for stuff we add,
> although iirc we didn't bother for zlib-extra.c

The (very slight) disadvantage of putting this code in
util/gmime-extra.c is that it will no longer be static, but will instead
be exposed across compilation units. That said, i don't think that's
actually a big deal, and i understand why you want it in
util/gmime-extra.c. So i'll send a new revision of this patch shortly.

[PATCH v2] crypto: signature verification reports valid User IDs

When i'm trying to understand a message signature, i care that i know
who it came from (the "validity" of the identity associated with the
key), *not* whether i'm willing to accept the keyholder's other
identity assertions (the "trust" associated with the certificate).

We've been reporting User ID information based on the "trust"
associated with the certificate, because GMime didn't clearly expose
the validity of the User IDs.

[PATCH v3] crypto: signature verification reports valid User IDs

When i'm trying to understand a message signature, i care that i know
who it came from (the "validity" of the identity associated with the
key), *not* whether i'm willing to accept the keyholder's other
identity assertions (the "trust" associated with the certificate).

We've been reporting User ID information based on the "trust"
associated with the certificate, because GMime didn't clearly expose
the validity of the User IDs.

Re: [PATCH v3] crypto: signature verification reports valid User IDs

> When i'm trying to understand a message signature, i care that i know
> who it came from (the "validity" of the identity associated with the
> key), *not* whether i'm willing to accept the keyholder's other
> identity assertions (the "trust" associated with the certificate).
>
pushed to release and master
_______________________________________________
notmuch mailing list
[hidden email]https://notmuchmail.org/mailman/listinfo/notmuch