jstedfast / gmime / 570

70%

push

travis-ci

Prefer gpgme_user_id_t's address field over the email field (#102)

GMimeCertificate's email field is typically populated from the `email` field of the highest-validity `gpgme_user_id_t` object.

But gpgme offers some confusing commentary on the `gpgme_user_id_t`, [in particular](https://gnupg.org/documentation/manuals/gpgme/Key-objects.html#index-gpgme_005fuser_005fid_005ft):

    char *email
      This is the email component of uid, if available.
    char *address;
      The mail address (addr-spec from RFC-5322) of the user ID
      string. This is general the same as the email part of this
      structure but might be slightly different. If no mail address is
      available NULL is stored.

It's hard to say exactly what this difference means.

Experimenting with some certificates and gpgme 1.15.1, it looks to me like the differences between `email` and `address` are:

 - when an OpenPGP User ID *does* contain an e-mail address, the two fields appear to be identical: they are both the same addr-spec.

 - when an OpenPGP User ID does not appear to contain an e-mail address, `email` is set to the empty string, but `address` is set to NULL.

 - when rendering the X.509 Subject DN as a user ID, the email is the the empty string, but the address is set to NULL (this is true regardless of whether the DN contains an 1.2.840.113549.1.9.1 ("emailAddress") component, which I've [suggested might change](https://dev.gnupg.org/T5450), but I'm not convinced anything will happen).

 - when rendering an X.509 SubjectAltName of type rfc822Name, `address` is an addr-spec, but "email" is an angle-addr.  that is, for [Alice's signing cert](https://www.ietf.org/archive/id/draft-ietf-lamps-samples-04.html#name-alices-signature-verificati), the `address` field is `alice@smime.example` but the email field is `<alice@smime.example>`

 - when rendering an X.509 SubjectAltName of any other type, `email` is the empty string but `address` is NULL.

I... (continued)

2 of 2 new or added lines in 1 file covered. (100.0%)

10210 of 14482 relevant lines covered (70.5%)

10485.59 hits per line