You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
some keys, like 25FC1614B8F87B52FF2F99B962AF4031C82E0039, have a user ID that has no e-mail address.
If the user indicates that they intend to certify that user ID, its certification should be attached to any other certification that can be sent -- so the certifications are sent in tandem.
So for example, if an OpenPGP certificate looks like:
uid 0: Alice Jones
uid 1: Alice Jones <firstname.lastname@example.org>
uid 2: Alice Jones (CEO) <email@example.com>
then the e-mail that goes to firstname.lastname@example.org should contain the certification for User IDs 0 and 1, and the e-mail that goes to email@example.com should contain the certification for User IDs 0 and 2.
That way, if the recipient gets any of the e-mails, they can see a certification over the user ID that has no e-mail address.
(this is how caff treats this kind of User ID)
Currently, gnome-keysign-sign-key produces this warning/error message when encountering such a User ID, and the certification is lost:
ERROR:keysign.util:email_file: We are seeing an empty 'to': u''
xdg-email: unexpected argument ''
Try 'xdg-email --help' for more information.
The text was updated successfully, but these errors were encountered:
it depends on how interactive you want gnome-keysign-sign-key to be. if it's allowed to be interactive, then prompting for each uid and uat (including the ones with e-mail addresses) is reasonable.
Hrm. So gnome-keysign-sign-key is more of an auxiliary tool rather than the main user interface. We can think of making it more interactive. But the approach with the flag sounds reasonable. Although then we'd expect the user to inspect the key openpgp data before handing it off for signing. That assumption may be fair.