pius fails to sign User IDs that have no e-mail address #109
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:
then the e-mail that goes to
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, as well as how it treats User Attributes (attached photos), fwiw -- i've raised an issue about how pius deals with User Attributes in #110)
The text was updated successfully, but these errors were encountered:
That would be a security issue for sure. If I have a key like:
And I use your proposed algorithm, the user now validates that this individual is Bill Clinton. Now, granted, one should look down the list of all UIDs before signing, but I think this behavior would be super misleading.
It is an interesting question on how to handle this though. I'm thinking something like an extra prompt. Something like:
We could do the same thing for photo UIDs...
Another solution is to save the unsent sig to a separate directory (suggested in
As for the interactive approach, you could also give the option to post directly to the key server.
Regarding the security issue, the user should ultimately be in control. But indeed the UI shouldn't make it easy to accidentally sign a dodgy key. I think it's quite common for UID's without email to contain strictly a full name that's often an exact match of a prefix of another UID. If pius encounters that trivial case it would be safe to do what the OP suggests automatically without nagging the user. Note that the user is going to skip the whole key if there's a stark difference in names.
Maybe this is persnickety but I should also mention the error message says "No email for Bob, cannot send key." While it's a correct statement, the key is not the significant thing that's being sent and could confuse novices. I would phrase it as "cannot send signature" or "cannot send signed key".
I agree that there are some security issues involved here, thanks for calling (at least one of) them out, @jaymzh !
I like @libBletchley 's idea about pius being clever about noticing when the human name matches a certificate that you're planning to sign already, and just doing the right thing there.
so that would leave what to do about handling a non-matching e-mail address-less User ID, and how to be sure that the user is ok with signing it. One approach would be to ask the user to type in the name they intend to certify (or hit enter to not certify it at all). Users who know what they want can just copy-and-paste the relevant line, and users who don't know what they want can just hit enter to ignore.