Hi! On Fri, 2013-03-15 at 17:28:31 +0100, David Kalnischkies wrote: > On Thu, Mar 14, 2013 at 7:31 PM, Guillem Jover wrote: > > So (from what I wrote on the initial bug report) SigVerify::RunGPGV() > > would not be able to parse something like: > > > > "-----BEGIN PGP SIGNATURE----- \t \n" > > For the signature, this might to be a problem, for the message > (which I thought you are referring to) I still think §7 is the authority > as it not an amored header (line) but a "cleartext header" (line).
The way I see it, §6.2 describes the general format of an Armored Message, and even refers (implicitly) to §7 for the specifics of "cleartext signatures" and "cleartext signed messages". So the latter is just a particular instance of the former, and all format details described there apply. > Yet, as §7.1 says that "any trailing whitespace […] at the end of > any line is removed when the cleartext signature is generated." > I question even why I should expect to see such a signature. This refers to the "cleartext signature" generation, i.e. that any spaces in the "cleartext message" will get discarded when computing the signature, not that they will get removed from the output file (they could though, as they are irrelevant for signature verification purposes anyway, and §7 is very clear that this framework might not be reversible). And this is pretty easy to test, just sign something like the following text («gpg --clearsign test.txt»), edit test.txt.asc and remove the trailing whitespace, and verify the signature («gpg --verify test.txt.asc»). ,--- test.txt.asc -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Test lines with trailing whitespace -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlFJJHEACgkQuW9ciZ2SjJsTwgCeOCXz/bhD9T+/PThUhI+VjHd3 350An2ysqI+SpYEYg7EtH4+/R66e4lf7 =b7L8 -----END PGP SIGNATURE----- `--- > And given that paragraph §6.2 is referring to formatting ASCII Amor > which a clear-text message is not as §7 is so quick to outline I > question if §6.2 should have relevance in §7 at all without special > invocation by name, but this might destroy everything. As I've written above it describes the general format, and yes also how to ASCII Armor the message part too. The "cleartext signed message" (not the cleartext itself) is still in Armored form, and §7 has this to say: ,--- It is desirable to be able to sign a textual octet stream without ASCII armoring the stream itself, [...] `--- which to me seems like confirmation enough. It even goes on to mention “"Hash" Armor Headers” and “ASCII armored signature(s)” only by reference, which were described before in detail in §6.2, and not in this section. > > And in additiona SourcesWriter::DoPackage() should not be able to > > handle an OpenPGP message starting with stuff like: > > > > "-----BEGIN PGP MESSAGE----- \t \n" > > "Hash: SHA1\n" > > " \n" > > "<SIGNED MESSAGE>\n" > > Beside again invoking §7.1 and repeating that "cleartext header" isn't > mentioned as a possible Amored Header line, §7 also says about > the line following the Hash Armor Header(s): > "Exactly one empty line not included into the message digest," > > For me an empty line is in fact empty and not just a short way of > saying "doesn't contain printable characters". gpgv obviously > has a more relaxed interpretation … See above, the way I interpret it is as just a shorthand for “- A blank (zero-length, or containing only whitespace) line”. The RFC could probably do with some rewording to make that very clear. I'll try to get in contact with the authors to see to this. > >> (I wonder now how someone is supposed to sign a message > >> containing whitespace sourcecode …) > > > > I don't think trailing whitespace is in this context usually (ever?) > > significant anyway? > > https://en.wikipedia.org/wiki/Whitespace_%28programming_language%29 > (the remark was a joke) Ah sorry I missed it. :) In any case, in those situations I guess one can always use Armored Signatures («gpg --armor --sign»). > >> APT code also doesn't support dash-escaped text so far. > > > > Neither does dpkg, but that should be fine because they only accept > > deb822 (?) which only allows message lines starting with fields names > > or spaces, and field names cannot start with a dash. > > I agree in theory, its just that §7.1 says: > "An implementation MAY dash-escape any line" > and an attacker might use this to disable fields, but if my testing is > correct gpgv doesn't allows at least this currently … > (which would be a bug if I am right, but I am not complaining) Both gpgv and gpg allow any (non-dash-escaped) arbitrary line (in the cleartext part of a cleartext signed message) being dash-escaped, even after the fact, because the signature is computed before dash-escaping; just prepend «- » to any signed line, and the message will verify as good. But as I mentioned before this does not matter, because any deb822 parser will (should) choke on those as field names are not allowed to start with «- » and continuation lines should start with a space anyway. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org