Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.6_beta1 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:48Z David Kalnischkies david@kalnischkies.de 2017-12-13T20:51:52Z urn:sha1:0b5e329a8ba2461ccb7017d3adfc972f9dccd830 We have no speed problem with handling floats/doubles in our progress handling, but that shouldn't prevent us from cleaning up the handling slightly to avoid unclean casting to ints. Reported-By: gcc -Wdouble-promotion -Wold-style-cast 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-12-13T22:53:34Z David Kalnischkies david@kalnischkies.de 2017-12-13T12:26:38Z urn:sha1:957381a0d26ec11a172ebfc64f892d1b31f0c193 gcc was warning about ignored type qualifiers for all of them due to the last 'const', so dropping that and converting to static_cast in the process removes the here harmless warning to avoid hidden real issues in them later on. Reported-By: gcc Gbp-Dch: Ignore 2017-12-13T22:53:26Z David Kalnischkies david@kalnischkies.de 2017-12-13T11:51:26Z urn:sha1:5d5ca1aac76448cdfd16972090d246c44671dce6 gcc has problems understanding this construct and additionally thinks it would produce multiple lines and stuff, so to keep using it isn't really worth it for the few instances we have: We can just write the long form there which works better. Reported-By: gcc Gbp-Dch: Ignore 2017-12-13T22:53:02Z David Kalnischkies david@kalnischkies.de 2017-12-13T11:17:25Z urn:sha1:bb3a0325bf6b5c6c7cd076ba8a44d9d3eba0902b Reported-By: gcc -Wsign-promo 2017-10-22T17:10:57Z Julian Andres Klode jak@debian.org 2017-10-22T17:02:53Z urn:sha1:0934b6b023b46cd0e2e5fa55a23a054b2feeb618 The previous change moved running the proxy detection program from the method to the main process, so it runs as root and not as _apt. This brings it back into the sandbox. Gbp-Dch: ignore 2017-08-24T14:56:52Z Julian Andres Klode jak@debian.org 2017-08-24T14:55:15Z urn:sha1:0e4ac8334d02ea256f750ad61689f28ff1ebdf6c As a follow up to the last commit, let's replace APT_CONST with APT_PURE everywhere to clean stuff up. 2017-08-24T14:56:48Z Julian Andres Klode jak@debian.org 2017-08-24T14:50:12Z urn:sha1:03590fb98226bfdf3147eb78effc3fa7987709bb Functions marked with the const attribute may not inspect any global memory. This includes targets of pointers or references passed as arguments. A pure function however is free to inspect memory, but may not have any side effects. The function StringSplit() was marked as const, but took two references to strings. When the second one was passed as a literal as in StringSplit(name, "::") the compiler cleverly figured out that we only inspect the address of "::" (since StringSplit is const) and thus optimized away the "::" content. While patching out individual broken uses of APT_CONST would be possible, this is already the second case, and there might be more, so let's redefine APT_CONST to use the pure attribute, so we don't end up with the same situation again in some time.