Lindsay Haisley writes:
Well the copy sent directly was marked as having an invalid signature as well, so message munging by Sourceforge can probably be ruled out.I don't know. I may try to see how Evolution submits emails to gpg. This may tell us something.
Well, here's a demonstration of how PGP signatures SHOULD be verified. When this came up a while ago, I reviewed the relevant RFC specification, and I find no fault with my implementation of PGP signature creation and verification.
It's a fortunate luck of the draw that the message that you checked did not use quoted-printable MIME encoding, but plain encoding. Which means you can actually slice apart the message and feed the right parts directly to gpg, and verify the sig manually. Here's how, see if you can reproduce the following steps:
Open the raw message file, and save both of the MIME sections in it, as two separate files:
The first MIME section begins as follows: ==== Content-Type: text/plain; format=flowed; delsp=yes; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit Lindsay Haisley writes: ====The first line in the file should be the Content-Type: header, and the file should end with exactly one blank line. There are two blank lines at the end of the first MIME section in the raw email message file:
==== though it's annoying. --=_monster.email-scan.com-6997-1358296100-0029 ====However, according to the relevant MIME specs, the second empty blank line is actually a part of the MIME boundary marker that immediately follows it. This is one of the most common bugs in MIME decoders, they fail to consider the newline sequence immediately before the MIME delimiter string as a logical part of the MIME boundary delimiter, even though this is highlighted and underlined, in honking capital letters (well, almost), in the appropriate RFC.
So, if you did this right, and if you named this file, say, msg1.txt, then you should get the following checksum:
$ md5sum msg1.txt 1307dabdb13c9067a6f699118f1d96a2 msg1.txtThen save the second MIME section, with the signature, as msg1.txt.sig. It's fairly short:
$ cat msg1.txt.sig -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEABECAAYFAlD19CQACgkQx9p3GYHlUOJVeQCaA6SwE8QCrfLRurbkd2Q1EJT5 b5MAn3rJx/7bwk5/XrqLGc0dswLrlc3t =AZlV -----END PGP SIGNATURE----- $The MIME PGP RFC specifies that the signature applies to text that's formatted using the CRLF end-of-line sequence, so convert msg1.txt accordingly:
[mrsam@monster tmp]$ unix2dos <msg1.txt >msg1.txt.out [mrsam@monster tmp]$ mv msg1.txt.out msg1.txt The checksum of the reformatted msg1.txt should now be: $ md5sum msg1.txt 4bea49c17cb71cd6e33ad1f456650f3d msg1.txt Now, you can run gpg manually, to verify the signature: $ gpg msg1.txt.sig gpg: Signature made Tue 15 Jan 2013 07:28:20 PM EST using DSA key ID 81E550E2 gpg: Good signature from "Sam Varshavchik <mr...@courier-mta.com>" That's all, folks.Now, I think I've grown out of my arrogant phase many years ago, but I'm fairly certain that Evolution is screwing up here. I just can't see what I'm doing wrong. Since Evolution invokes gpg to verify the signature, the only possibility here, is that it screws up and feeds the wrong content into pgp to verify. I would venture a guess that Evolution is either:
A) Verifying the sig of text content that ends with LFs, rather than the CRLF newline sequence. This is spelled out in section 5 of RFC 2015:
# When the PGP digital signature is generated: # # (1) The data to be signed must first be converted to its # type/subtype specific canonical form. For text/plain, this # means conversion to an appropriate character set and conversion # of line endings to the canonical <CR><LF> sequence.This is why in my walkthrough, above, you ran unix2dos to convert the text message to the canonical CRLF newline sequence format. Quite an archaic concept, but that's what the spec says.
B) Screwing up the MIME boundary parsing, and Evolution tries to verify the checksum on the message that ends with two empty lines. It does not. It ends with one empty line, and the second newline sequence logically belongs to the MIME boundary delimiter that follows. This is quite explicitly stated on page 19 of RFC 2046:
# The boundary delimiter MUST occur at the beginning of a line, i.e., # following a CRLF, and the initial CRLF is considered to be attached # ============================================= # to the boundary delimiter line rather than part of the preceding # ================================================================ # part. # =====So, what's probably happening is that Evolutions gets one of these wrong. But what I don't understand is that you say that the sig does verify on some messages. But, if Evolution is either misparsing the MIME boundary delimiter string, or failing to convert the text to the canonical CRLF format, then it should be getting the signatures wrong every time.
Maybe Evolution mistakenly trims off all trailing newlines from all messages, so the sig would fail to verify if a signed message ends with a blank line.
This message shouldn't end with a logical blank line. Let's see if Evolution manages to get the signature right, with this one.
pgp0luKleB9cG.pgp
Description: PGP signature
------------------------------------------------------------------------------ Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery and much more. Keep your Java skills current with LearnJavaNow - 200+ hours of step-by-step video tutorials by Java experts. SALE $49.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122612
_______________________________________________ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
