Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.6_alpha7 2018-01-02T22:39:30Z 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 2017-12-13T22:56:29Z David Kalnischkies david@kalnischkies.de 2017-07-17T08:52:09Z urn:sha1:07cd99066c30e70a9f41851c80e7c51f4e507163 LookupTag is a little helper to deal with rfc822-style strings we use in apt e.g. to pass acquire messages around for cases in which our usual rfc822 parser is too heavy. All the fields it had to deal with so far were single line, but if they aren't it should really produce the right output and not just return the first line. Error messages are a prime candidate for becoming multiline as at the moment they are stripped of potential newlines due to the previous insufficiency of LookupTag. 2017-12-13T22:53:41Z David Kalnischkies david@kalnischkies.de 2017-12-13T20:39:16Z urn:sha1:1adcf56bec7d2127d83aa423916639740fe8e586 The casts are useless, but the reports show some where we can actually improve the code by replacing them with better alternatives like converting whatever int type into a string instead of casting to a specific one which might in the future be too small. Reported-By: gcc -Wuseless-cast 2017-08-12T14:03:26Z Julian Andres Klode jak@debian.org 2017-08-12T14:02:45Z urn:sha1:79c0a12d5c2d4fd8e6bfcf3a632a452239c07fe0 This caused a build failure in the test suite. 2017-07-26T17:09:04Z David Kalnischkies david@kalnischkies.de 2017-07-07T14:24:21Z urn:sha1:ea408c560ed85bb4ef7cf8f72f8463653501332c We have support for an netrc-like auth.conf file since 0.7.25 (closing 518473), but it was never documented in apt that it even exists and netrc seems to have fallen out of usage as a manpage for it no longer exists making the feature even more arcane. On top of that the code was a bit of a mess (as it is written in c-style) and as a result the matching of machine tokens to URIs also a bit strange by checking for less specific matches (= without path) first. We now do a single pass over the stanzas. In practice early adopters of the undocumented implementation will not really notice the differences and the 'new' behaviour is simpler to document and more usual for an apt user. Closes: #811181 2017-07-26T17:09:04Z David Kalnischkies david@kalnischkies.de 2017-07-15T12:12:50Z urn:sha1:3317ad864c997f4897756c0a2989c4199e9cda62 Using different ways of opening files means we have different behaviour and error messages for them, so by the same for all we can have more uniformity for users and apt developers alike. 2017-07-12T11:57:51Z Julian Andres Klode jak@debian.org 2017-07-12T11:40:41Z urn:sha1:87274d0f22e1dfd99b2e5200e2fe75c1b804eac3 This makes it easier to see which headers includes what. The changes were done by running git grep -l '#\s*include' \ | grep -E '.(cc|h)$' \ | xargs sed -i -E 's/(^\s*)#(\s*)include/\1#\2 include/' To modify all include lines by adding a space, and then running ./git-clang-format.sh. 2017-06-26T21:31:15Z David Kalnischkies david@kalnischkies.de 2017-03-14T10:35:41Z urn:sha1:f78fb67f4b6a5673e497ba1aeb19568581173909 Gbp-Dch: Ignore 2017-03-19T13:32:59Z David Kalnischkies david@kalnischkies.de 2017-03-19T12:53:33Z urn:sha1:2ce15bdeac6ee93faefd4b42b57f035bef80c567 In the intended usecase where this serves as a hack there is no problem with double/single quotes being present as we write it to a log file only, but nowadays our calling of apt-key produces a temporary config file containing this "setting" as well and suddently quoting is important as the config file syntax is allergic to it. So the fix is to ignore all quoting whatsoever in the input and just quote (with singles) the option values with spaces. That gives us 99% of the time the correct result and the 1% where the quote is an integral element of the option … doesn't exist – or has bigger problems than a log file not containing the quote. Same goes for newlines in values. LP: #1672710 2017-01-17T13:33:02Z Julian Andres Klode jak@debian.org 2017-01-17T13:33:02Z urn:sha1:b59a8c6e29015c4d19c4b39a63b328af7d87d1ee This will avoid people from thinking that they have to do nothing when they change the set of files. Gbp-Dch: ignore