Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.8.0 2019-02-01T14:40:06Z 2019-02-01T14:40:06Z Julian Andres Klode jak@debian.org 2019-02-01T14:40:06Z urn:sha1:d5dcc2e9d3008b57c3fae0bcb5b1c2a197f5430c Fail if InRelease or Release.gpg contain unsigned lines See merge request apt-team/apt!45 2019-02-01T13:51:56Z David Kalnischkies david@kalnischkies.de 2019-02-01T13:51:56Z urn:sha1:5caa8cac3bc0ffa8b5360f3e5d5c84e710eb394b Implementing a parser with recursion isn't the best idea, but in practice we should get away with it for the time being to avoid needless codechurn. Closes: #920317 #921037 2019-01-28T19:45:02Z David Kalnischkies david@kalnischkies.de 2019-01-28T19:45:02Z urn:sha1:9b840b59cc80a072e14b8adc9d76669a7a50ab87 We support dash-encoding even if we don't really work with files who would need it as implementations are free to encode every line, but otherwise a line starting with a dash must either be a header we parse explicitly or the file is refused. This is against the RFC which says clients should warn on such files, but given that we aren't expecting any files with dash-started lines to begin with this looks a lot like a we should not continue to touch the file as it smells like an attempt to confuse different parsers by "hiding" headers in-between others. The other slightly more reasonable explanation would be an armor header key starting with a dash, but no existing key does that and it seems unlikely that this could ever happen. Also, it is recommended that clients warn about unknown keys, so new appearance is limited. 2019-01-23T18:10:47Z David Kalnischkies david@kalnischkies.de 2019-01-23T16:47:49Z urn:sha1:3734cceb44b02ca4d5ee3c6f5cbfe1e12f17cffb The warnings were introduced 2 years ago without any reports from the wild about them actually appearing for anyone, so now seems to be an as good time as any to switch them to errors. This allows rewritting the code by failing earlier instead of trying to keep going which makes the diff a bit hard to follow but should help simplifying reasoning about it. References: 6376dfb8dfb99b9d182c2fb13aa34b2ac89805e3 2018-08-14T17:44:28Z David Kalnischkies david@kalnischkies.de 2018-06-28T16:23:36Z urn:sha1:9a521ed76019fc7bdad1bf09c063bd3550536ef0 Completely pointless as it makes no difference for apt, but copying the file to other projects becomes a lot easier. Gbp-Dch: Ignore 2018-05-04T22:34:27Z David Kalnischkies david@kalnischkies.de 2018-05-04T17:56:41Z urn:sha1:b12bdeaf8acd050c5526ecc05526db70df5fd485 Reported-By: codespell & spellintian Gbp-Dch: Ignore 2018-05-04T16:42:37Z David Kalnischkies david@kalnischkies.de 2018-05-04T16:24:57Z urn:sha1:1d77c915005f7630949e2ce706055ee3235009b6 GTest has a bunch of undefined macros which causes the compiler to spit out warnings for each one on each test file. There isn't much we can do, so we just disable the warning for the testcases. Other warnings like sign-promo and sign-compare we can avoid by being more explicit about our expected integer constants being unsigned. As we are just changing testcases, there is no user visible change which would deserve to be noted in the changelog. Gbp-Dch: Ignore Reported-By: gcc-8 2018-05-04T15:35:49Z Julian Andres Klode julian.klode@canonical.com 2018-05-04T14:07:12Z urn:sha1:39d9e217a22901892647499ee695ba472a111d25 Still allow the older one to be used. Closes: #897149 2018-03-12T07:56:59Z Julian Andres Klode julian.klode@canonical.com 2018-03-08T08:33:39Z urn:sha1:4de4200ec2717e777bbf99ed82d1b4344f078ec2 zstd is a compression algorithm developed by facebook. At level 19, it is about 6% worse in size than xz -6, but decompression is multiple times faster, saving about 40% install time, especially with eatmydata on cloud instances. 2018-01-02T22:39:30Z David Kalnischkies david@kalnischkies.de 2018-01-02T14:14:58Z urn:sha1:dcc0759fea4bf65d5477678e287880927d2cc9be 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 & initial patch! References: 89c4c588b275d098af33f36eeddea6fd75068342 Closes: 884922