<feed xmlns='http://www.w3.org/2005/Atom'>
<title>apt/test/libapt/openmaybeclearsignedfile_test.cc, branch 1.6_alpha6</title>
<subtitle>Debians commandline package manager</subtitle>
<id>https://git.kalnischkies.de/apt/atom?h=1.6_alpha6</id>
<link rel='self' href='https://git.kalnischkies.de/apt/atom?h=1.6_alpha6'/>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/'/>
<updated>2018-01-02T22:39:30Z</updated>
<entry>
<title>Support cleartext signed InRelease files with CRLF line endings</title>
<updated>2018-01-02T22:39:30Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2018-01-02T14:14:58Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=dcc0759fea4bf65d5477678e287880927d2cc9be'/>
<id>urn:sha1:dcc0759fea4bf65d5477678e287880927d2cc9be</id>
<content type='text'>
Commit 89c4c588b275 ("fix from David Kalnischkies for the InRelease gpg
verification code (LP: #784473)") amended verification of cleartext
signatures by a check whether the file to be verified actually starts
with "-----BEGIN PGP SIGNATURE-----\n".

However cleartext signed InRelease files have been found in the wild
which use \r\n as line ending for this armor header line, presumably
generated by a Windows PGP client.  Such files are incorrectly deemed
unsigned and result in the following (misleading) error:

    Clearsigned file isn't valid, got 'NOSPLIT' (does the network require authentication?)

RFC 4880 specifies in 6.2 Forming ASCII Armor:

    That is to say, there is always a line ending preceding the
    starting five dashes, and following the ending five dashes.  The
    header lines, therefore, MUST start at the beginning of a line, and
    MUST NOT have text other than whitespace following them on the same
    line.

RFC 4880 does not seem to specify whether LF or CRLF is used as line
ending for armor headers, but CR is generally considered whitespace
(e.g. "man perlrecharclass"), hence using CRLF is legal even under
the assumption that LF must be used.

SplitClearSignedFile() is stripping whitespace (including CR) on lineend
already before matching the string, so StartsWithGPGClearTextSignature() is
adapted to use the same ignoring. As the earlier method is responsible
for what apt will end up actually parsing nowadays as signed/unsigned this
change has no implications for security.

Thanks: Lukas Wunner for detailed report &amp; initial patch!
References: 89c4c588b275d098af33f36eeddea6fd75068342
Closes: 884922
</content>
</entry>
<entry>
<title>warn if clearsigned file has ignored content parts</title>
<updated>2016-12-31T01:29:19Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-12-16T18:50:48Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=6376dfb8dfb99b9d182c2fb13aa34b2ac89805e3'/>
<id>urn:sha1:6376dfb8dfb99b9d182c2fb13aa34b2ac89805e3</id>
<content type='text'>
Clearsigned files like InRelease, .dsc, .changes and co can potentially
include unsigned or additional messages blocks ignored by gpg in
verification, but a potential source of trouble in our own parsing
attempts – and an unneeded risk as the usecases for the clearsigned
files we deal with do not reasonably include unsigned parts (like emails
or some such).

This commit changes the silent ignoring to warnings for now to get an
impression on how widespread unintended unsigned parts are, but
eventually we want to turn these into hard errors.
</content>
</entry>
</feed>
