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:
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, 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, 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.
It looks to me like address gives us a more stable guarantee -- it's either NULL or an addr-spec, while email might vary between:
the empty string
addr-spec
angle-addr
(maybe the email field could be NULL as well, but i haven't encountered that yet).
This patch prefers to populate the email field of GMimeCertificate from gpgme_user_id_t's address field, when it is present but differs from the email field.
Coverage decreased (-0.003%) to 70.46% when pulling 565bebad5e4ade8cfa6274919b8e4f647f35b129 on dkg:prefer-address-to-email into 6bff5288f9c108160dd56dd20a9c6608aa55f791 on jstedfast:master.
GMimeCertificate's email field is typically populated from the
email
field of the highest-validitygpgme_user_id_t
object.But gpgme offers some confusing commentary on the
gpgme_user_id_t
, in particular: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
andaddress
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, butaddress
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, 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, theaddress
field isalice@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 butaddress
is NULL.It looks to me like
address
gives us a more stable guarantee -- it's either NULL or an addr-spec, whileemail
might vary between:(maybe the
email
field could be NULL as well, but i haven't encountered that yet).This patch prefers to populate the
email
field of GMimeCertificate fromgpgme_user_id_t
'saddress
field, when it is present but differs from theemail
field.