Attach pubkey when signing

[niklasfemerstrand]

Add the pubkey file[1] as an attachment to signed emails.

[1] "data:asc," + encodeURIComponent(openpgp.keyring.publicKeys[i].armored)

[bogde]

i worked on this and i have just completed the initial implementation. can you review:
bogde@5bedc55

and let me know your thoughts and whether should i make any changes or/and submit a pull request.

thanks.

[niklasfemerstrand]

Merged your commit, removed the $dbg declaration and renamed signature.asc->pubkey.asc

If you could find a quick way to name the attachment with the actual pubkey ID, like "pubkey_XXX.asc" that'd be even prettier, and more user friendly for users quickly filling t heir downloads directory with "pubkey.asc (1)", "pubkey.asc (2)" and so forth. Surely it can be passed as an arg.

I consider the function part to be fixed though, thanks a bunch :-)

[bogde]

what do you want the XXX to be? i can probably use the key id or the user's email address.

maybe we should also have some kind of option "attach public key when signing [yes/no]", although i guess it's better to have fewer settings for the user to take care of. public key can be removed before sending the message anyway.

[bogde]

yeah, just read your message again and noticed the answer to my question. i'm not sure how can i easily get the key id in php (in the handler for the message_compose hook) since the key is stored locally on the user's computer. i made some changes to have something like pubkey_[username].asc. i'll commit it and wait for your thoughts.

[bogde]

i might have found a better way to rename the attachment. i'll let you know as soon as possible.

[niklasfemerstrand]

No stress :-)

[krautsource]

maybe we should also have some kind of option "attach public key when signing [yes/no]"

I'd really like that, but with a default of "no". Unless I'm missing something, the whole point of signing an email is that the receiver can verify the signature with the public key he already has (ideally from a known source and transferred out-of-band).
Signing a message and sending the corresponding public key along with it somehow seems pointless to me, so I'd only do that on the first occasion I'm writing to a recipient so he can verify all future emails I'll be sending his way.

My reasoning is this:
When every message brings a public key along, a crypto-savvy recipient will of course only import the public key from the first email he/she received from that sender and ignore all others. And such a recipient will be cautious when all of a sudden, a new public key comes along (from an attacker).
But think of less crypto-aware users who will get used to receiving a public key with each of your emails... if signature verification with the old public key fails one day (because the message is faked), they might just import the attached, attacker-provided public key because it seems not too unusual to them that there is a public key attached.
So I think sending a public key via email should be done as rarely as possible so people are alert when an attacker sends them his public key.

Just my $0.02, please correct me if mistaken :-)

[bogde]

default no is easier (as proven by the sign/encrypt options) :-)

you are right in your reasoning. in real life people do exchange keys via e-mail though... i guess the key may be used for the other party to send back an encrypted message too. if the other party is careful not to reply to a wrong address, the worst that happens is that the recipient is not able to decrypt the message.

anyway, i actually wanted to say that i found a hack to rename the attachment to pubkey_keyid.asc. see:
bogde@cd497fe

[krautsource]

in real life people do exchange keys via e-mail though

Sure, but I don't see much sense in sending the key with every signed message... that's all :-)

[bogde]

any comments on my "rename public key attachment" above? thanks

[niklasfemerstrand]

Will take a look ASAP

[krautsource]

In the meantime, I had a look at the code and I was wondering what keeps us from leveraging the built-in upload routines of Roundcube, so there is no custom server-side code needed for this at all.

We could build an Ajax request like this one in order to simulate a regular file upload:

// Build the payload
var payload = [  
  '------foobar', 
  'Content-Disposition: form-data; name="_token"', 
  '', 
  rcmail.env.request_token, 
  '------foobar', 
  'Content-Disposition: form-data; name="_attachments[]"; filename="here_goes_the_file_name.asc"', 
  'Content-Type: text/plain', 
  '', 
  'Here be the file contents', 
  '------foobar--'  
];
// Let Roundcube build the URL
var url = rcmail.url('upload', { _id:rcmail.env.compose_id || '', _uploadid: new Date().getTime() })
// Submit the request
$.ajax({
  type: 'post',
  url: url,
  contentType: 'multipart/form-data; boundary=----foobar',
  data: payload.join('\n'),
  success: function(data) {
    // Extract the add2attachment_list statement from the response
    var statement = data.match(/rcmail\.add2attachment_list\(.+?\);/);
    if(statement) {
      // eval() is bad, so maybe better parse the original add2attachment_list statement and build one ourselves...
      eval(statement[0]);
    }
  }
});

Of course it still needs some refinement and proper error handling etc. But basically it works.
Could this be a viable, more light-weight alternative?

[niklasfemerstrand]

I would prefer doing it entirely in JS, concerning as much as possible regarding this plugin actually. But for now let's use bogde's already finished code so we can reach some sort of stable release and then we can improve later.

@bogde: Sorry for slow attention, I haven't forgot about this :-)

[krautsource]

Okay, then how about this: I will...

• finish the JS implementation (not much left to be done actually)
• add an option "Always attach public key to signed or encrypted messages" in the settings screen
• add a button "Attach public key" in the compose window next to or below the "Attach a file" button, for those who don't use above-mentioned option
• use localized texts from the beginning :-)

[hennegwath]

May I ask, how about this?