New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

gnome-keysign-sign-key fails to send certifications of User IDs that have no e-mail address #71

Open
dkg opened this Issue Jan 19, 2019 · 3 comments

Comments

Projects
None yet
2 participants
@dkg
Copy link

dkg commented Jan 19, 2019

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 <alice@example.net>
uid 2: Alice Jones (CEO) <boss@example.biz>

then the e-mail that goes to alice@example.net should contain the certification for User IDs 0 and 1, and the e-mail that goes to boss@example.biz 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.
@muelli

This comment has been minimized.

Copy link
Member

muelli commented Jan 19, 2019

If the user indicates that they intend to certify that user ID

Right.
I don't think we can capture that intent yet.

its certification should be attached to any other certification that can be sent -- so the certifications are sent in tandem.

Right. We have the same problem for photo UIDs. I remember having actively decided to not send those because we do not have a way yet to know whether the user wants to have those signed.

Do you think we should unconditionally sign all user IDs? Or only non-photo UIDs? Or exactly one non-email UID?

@dkg

This comment has been minimized.

Copy link
Author

dkg commented Jan 19, 2019

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.

if it's non-interactive, then maybe by default just certify the uids that have a valid-looking e-mail address, but offer a --also-certify-non-email-identities command-line flag.

@muelli

This comment has been minimized.

Copy link
Member

muelli commented Jan 21, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment