Hi. I'm facing a strange behaviour on latest RC version.
I've enabled Enigma plugin and I'm able to create my key pairs, sign and encrypt messages.
The strange thing is I couldn't verify signed messages at all, even if decryption in perfectly working.
I've debugged GPG class (vendor/pear-pear.php.net/Crypt_GPG/Crypt/GPG.php) to verify what he was doing and why sign validation always fails.
Within _SIGN() method, I've added following lines to log what he was going to sign:
_$rc = rcmail::get_instance();_ _$rc->console('---------------------------------');_ _$rc->console('SIGN INPUT');_ _$rc->console($input);_ _$rc->console('---------------------------------');_
Same thing within _VERIFY() method, to log what is going to verify:
_$rc = rcmail::get_instance();_ _$rc->console('---------------------------------');_ _$rc->console('VERIFY INPUT');_ _$rc->console($input);_ _$rc->console('---------------------------------');_ _$rc->console('VERIFY SIGNATURE');_ _$rc->console($signature);_ _$rc->console('---------------------------------');_
Here is my full output for the sequence:
* user send a new signed email to himself
* user goes to inbox and open signed e-mail
I've noticed that the signed message has an extra newline between main headers and body (take a look at the highlited rows) so I thing that's why sign verification fails (content doesn't match with original message).
_[27-Jul-2016 15:10:38 +0200]: <cmnloql4> ---------------------------------_ _[27-Jul-2016 15:10:38 +0200]: <cmnloql4> SIGN INPUT_ _[27-JUL-2016 15:10:38 +0200]: <CMNLOQL4> CONTENT-TYPE: MULTIPART/ALTERNATIVE;_ _ BOUNDARY="=_944CBD90B0D51928FF049222817A4B03"_
_--=_944CBD90B0D51928FF049222817A4B03_ _Content-Transfer-Encoding: 7bit_ _Content-Type: text/plain; charset=US-ASCII_
_This is an HTML content..._ _--=_944cbd90b0d51928ff049222817a4b03_ _Content-Transfer-Encoding: quoted-printable_ _Content-Type: text/html; charset=UTF-8_
_<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=_ _=3DUTF-8" /></head><body style=3D'font-size: 10pt; font-family: Verdana,Gen=_ _eva,sans-serif'>_ _<p>This is an HTML content...</p>_ _</body></html>_
_--=_944cbd90b0d51928ff049222817a4b03--_
_[27-Jul-2016 15:10:38 +0200]: <cmnloql4> ---------------------------------_ _[27-Jul-2016 15:10:45 +0200]: <cmnloql4> ---------------------------------_ _[27-Jul-2016 15:10:45 +0200]: <cmnloql4> VERIFY INPUT_ _[27-JUL-2016 15:10:45 +0200]: <CMNLOQL4> CONTENT-TYPE: MULTIPART/ALTERNATIVE;_ _ BOUNDARY="=_944CBD90B0D51928FF049222817A4B03"_
_--=_944CBD90B0D51928FF049222817A4B03_ _Content-Transfer-Encoding: 7bit_ _Content-Type: text/plain; charset=US-ASCII_
_This is an HTML content..._ _--=_944cbd90b0d51928ff049222817a4b03_ _Content-Transfer-Encoding: quoted-printable_ _Content-Type: text/html; charset=UTF-8_
_<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=_ _=3DUTF-8" /></head><body style=3D'font-size: 10pt; font-family: Verdana,Gen=_ _eva,sans-serif'>_ _<p>This is an HTML content...</p>_ _</body></html>_
_--=_944cbd90b0d51928ff049222817a4b03--_
_[27-Jul-2016 15:10:45 +0200]: <cmnloql4> ---------------------------------_ _[27-Jul-2016 15:10:45 +0200]: <cmnloql4> VERIFY SIGNATURE_ _[27-Jul-2016 15:10:45 +0200]: <cmnloql4> -----BEGIN PGP SIGNATURE-----_ _Version: GnuPG v1_
_iQEcBAEBAgAGBQJXmLLOAAoJEB1v3mO3A8Wpz6QH/015jrt7YkfGT8pE1nyjpHHe_ _JoCEmugkpmEgJ6wjTgU1SHQos5l1mKqFhsrzpdNghO11yqB/NxOjxOpqSkE9c9c1_ _dXr/H53cLfqPULMD5dqGBFua180BUdLAQ0Nvyll7kD8Y/irU5ccrwA1e3Cb9RYp0_ _sGplLYcD7pPKthCGQfFzPslL9Fj82MBJigm46cKa7pqYhJDNkM4q4zsqtNXcTUqB_ _HcFhEL3+Q21bAbie+B8hDw2SUYGEZORf+sLUrW1oQLLG5ld6XZywCDDKdpq6F+ET_ _OzVaXta8cMIg5dwP/10VALlqYavlzjY/0h7lBmEgm5W/ehs7XuReur45LsS1KJg=_ _=Q6j9_ _-----END PGP SIGNATURE-----_
_[27-Jul-2016 15:10:45 +0200]: <cmnloql4> --------------------------------_
Anyone is facing the same issue?
Maybe it's not an Enigma related issue but a Roundcube behaviour because it happes even on not signed e-mails (but in this case it doesn't bother at all).
Any help would be really appreciate.
Thanks.
Stefano
On 07/27/2016 04:11 PM, sgironella@schema31.it wrote:
I’ve noticed that the signed message has an extra newline between main headers and body (take a look at the highlited rows) so I thing that’s why sign verification fails (content doesn’t match with original message).
Works for me, but I have an idea that it could be some IMAP response parsing issue or IMAP server issue. Could you provide imap_debug log for the moment when you open the message?
And this is the relevant part of the code, in case you'd like to work on this by yourself.
https://github.com/roundcube/roundcubemail/blob/release-1.2/plugins/enigma/l...
Enabled IMAP and SMTP debug (see attachments) and tested against a DBMail internal mail server and an external one (GMail to simplify test repeatability).
Attached files are related to the GMail session.
As you can see, IMAP response differs on main mime part headers structure, so i think that's the reason for sign verification failure.
Any idea on how to fix this?
Thanks!
Stefano
SMTP log
....... cut .......
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--=_12a667e67cfa1dc2752a3a26a0315da3 CONTENT-TYPE: MULTIPART/MIXED; BOUNDARY="=_6252574EB3EF7A89798CDB7924177AF2"
....... cut .......
IMAP log (response)
....... cut .......
[28-Jul-2016 10:23:17 +0200]: <ml905lhg> [17EE] C: A0008 UID FETCH 9460 (BODY.PEEK[1.MIME]) [28-Jul-2016 10:23:17 +0200]: <ml905lhg> [17EE] S: * 31 FETCH (UID 9460 BODY[1.MIME] {80} [28-JUL-2016 10:23:17 +0200]: <ML905LHG> [17EE] S: CONTENT-TYPE: MULTIPART/MIXED; BOUNDARY="=_6252574EB3EF7A89798CDB7924177AF2" [28-Jul-2016 10:23:17 +0200]: <ml905lhg> [17EE] S: [28-Jul-2016 10:23:17 +0200]: <ml905lhg> [17EE] S: ) [28-Jul-2016 10:23:17 +0200]: <ml905lhg> [17EE] S: A0008 OK Success [28-Jul-2016 10:23:17 +0200]: <ml905lhg> [17EE] C: A0009 UID FETCH 9460 (BODY.PEEK[1])
....... cut .......
Parsed IMAP response
....... cut .......
CONTENT-TYPE: MULTIPART/MIXED; BOUNDARY="=_6252574EB3EF7A89798CDB7924177AF2"
....... cut .......
Il 2016-07-28 08:34 A.L.E.C ha scritto:
On 07/27/2016 04:11 PM, sgironella@schema31.it wrote:
I've noticed that the signed message has an extra newline between main headers and body (take a look at the highlited rows) so I thing that's why sign verification fails (content doesn't match with original message).
Works for me, but I have an idea that it could be some IMAP response parsing issue or IMAP server issue. Could you provide imap_debug log for the moment when you open the message?
And this is the relevant part of the code, in case you'd like to work on this by yourself.
https://github.com/roundcube/roundcubemail/blob/release-1.2/plugins/enigma/l...
On 07/28/2016 10:54 AM, sgironella@schema31.it wrote:
Enabled IMAP and SMTP debug (see attachments) and tested against a DBMail internal mail server and an external one (GMail to simplify test repeatability).
Attached files are related to the GMail session.
As you can see, IMAP response differs on main mime part headers structure, so i think that's the reason for sign verification failure.
I created a ticket for this issue https://github.com/roundcube/roundcubemail/issues/5371
I don't see a simple workaround now, we'd need to get the whole signed message body and parse it instead of fetching headers and body of the first part separately. I'll take a look at this over the weekend.
Hello Alec,
just as a confirm of your hypothesis, if you look at the raw source of the message within Roundcube (Action -> show source) it's layout is different from the one that gets thrown at gpg.
This is the very same mail:
RAW SOURCE:
[....]
Message-ID: 5d3b75e68692f4a51fa1d361fdc6d1f1@brancatelli.it X-Sender: andrea@brancatelli.it User-Agent: Roundcube Webmail/1.2.1
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--=_ad16315c31f34b75fe12de9a5f6ff9c3 Content-Type: multipart/mixed; boundary="=_0c2026a878accfb67f4729bf2f2a522d"
--=_0c2026a878accfb67f4729bf2f2a522d Content-Type: multipart/alternative; boundary="=_4f6a45d8f3d31b8528676bb2b9630c46"
--=_4f6a45d8f3d31b8528676bb2b9630c46 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII
[...]
CONSOLE LOG:
[...]
[28-Jul-2016 15:19:22 +0200]: <s4r01i4d>
[28-Jul-2016 15:19:22 +0200]: <s4r01i4d> VERIFY INPUT [28-Jul-2016 15:19:22 +0200]: <s4r01i4d> CONTENT-TYPE: MULTIPART/MIXED; BOUNDARY="=_0C2026A878ACCFB67F4729BF2F2A522D"^M ^M --=_0c2026a878accfb67f4729bf2f2a522d^M Content-Type: multipart/alternative;^M boundary="=_4f6a45d8f3d31b8528676bb2b9630c46"^M ^M --=_4f6a45d8f3d31b8528676bb2b9630c46^M Content-Transfer-Encoding: 7bit^M Content-Type: text/plain; charset=US-ASCII^M ^M Mail firmata mandata tramite potassio.^M --=_4f6a45d8f3d31b8528676bb2b9630c46^M Content-Transfer-Encoding: quoted-printable^M Content-Type: text/html; charset=UTF-8^M
[...]
Andrea Brancatelli Schema31 S.p.a. Responsabile IT
ROMA - BO - FI - PA ITALY Tel: +39.06.98.358.472 Cell: +39.331.2488468 Fax: +39.055.71.880.466 Società del Gruppo SC31 ITALIA
Il 2016-07-28 11:28 A.L.E.C ha scritto:
On 07/28/2016 10:54 AM, sgironella@schema31.it wrote:
Enabled IMAP and SMTP debug (see attachments) and tested against a DBMail internal mail server and an external one (GMail to simplify test repeatability).
Attached files are related to the GMail session.
As you can see, IMAP response differs on main mime part headers structure, so i think that's the reason for sign verification failure.
I created a ticket for this issue https://github.com/roundcube/roundcubemail/issues/5371
I don't see a simple workaround now, we'd need to get the whole signed message body and parse it instead of fetching headers and body of the first part separately. I'll take a look at this over the weekend.
-
A.L.E.C -
Andrea Brancatelli -
sgironella＠schema31.it