(Disclaimer: I am not arguing that we don't need to fix this – we are working on it – the following just outlines why I think that it is a "bug" in gpgv and/or other implementations that we have to fix to use them …)
On Thu, Mar 14, 2013 at 7:31 PM, Guillem Jover <guil...@debian.org> wrote: > I think you might have been confused by the nomenclature, and my lack > of more explicit detail, perhaps? Or I missunderstood your comment. Yeah, I messed up the naming a bit … guilty as pledged. > 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). 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. 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. > 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 … >> (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) >> 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) Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
