Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.6_alpha7 2018-01-17T10:52:38Z 2018-01-17T10:52:38Z Julian Andres Klode julian.klode@canonical.com 2018-01-16T15:53:46Z urn:sha1:698f9e3f9877be2aa181d6e40d3dc5c41ea318b7 Allow specifying an alternative path to the InRelease file, so you can have multiple versions of a repository, for example. Enabling this option disables fallback to Release and Release.gpg, so setting it to InRelease can be used to ensure that only that will be tried. We add two test cases: One for checking that it works, and another for checking that the fallback does not happen. Closes: #886745 2018-01-03T18:42:45Z David Kalnischkies david@kalnischkies.de 2017-11-18T13:21:14Z urn:sha1:8aadb98849ba2555f4596042c888da451d965dfd Gbp-Dch: Ignore 2018-01-03T17:55:41Z David Kalnischkies david@kalnischkies.de 2017-08-12T14:21:13Z urn:sha1:ef9677831f62a1554a888ebc7b162517d7881116 If a method needs a file to operate like e.g. mirror needs to get a list of mirrors before it can redirect the the actual requests to them. That could easily be solved by moving the logic into libapt directly, but by allowing a method to request other methods to do something we can keep this logic contained in the method and allow e.g. also methods which perform binary patching or similar things. Previously they would need to implement their own acquire system inside the existing one which in all likelyhood will not support the same features and methods nor operate with similar security compared to what we have already running 'above' the requesting method. That said, to avoid methods producing conflicts with "proper" files we are downloading a new directory is introduced to keep the auxiliary files in. [The message magic number 351 is a tribute to the german Grundgesetz article 35 paragraph 1 which defines that all authorities of the state(s) help each other on request.] 2018-01-03T17:55:41Z David Kalnischkies david@kalnischkies.de 2017-08-09T21:26:19Z urn:sha1:02567e3084d2faec92e8bf248e89fda6452e634b The format isn't too hard to get right, but it gets funny with multiline fields (which we don't really have yet) and its just easier to deal with it once and for all which can be reused for more messages later. 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-24T09:31:29Z David Kalnischkies david@kalnischkies.de 2017-12-24T09:31:29Z urn:sha1:5ba048a475cfd728906875327ddceed4614a1c9d If the cache needs to grow to make room to insert volatile files like deb files into the cache we were remapping null-pointers making them non-null-pointers in the process causing trouble later on. Only the current Releasefile pointer can currently legally be a nullpointer as volatile files have no release file they belong to, but for safety the pointer to the current Packages file is equally guarded. The option APT::Cache-Start can be used to workaround this problem. Reported-By: Mattia Rizzolo on IRC 2017-12-14T20:55:26Z David Kalnischkies david@kalnischkies.de 2017-12-14T20:05:50Z urn:sha1:8876bf372f8bf5bc12767a2531587f004e38dc74 For the failure propagation testing we try to connect to a port which isn't open – you would think that this has a rather limited set of failure modes but it turns out that there are various ways this can fail, so instead of trying to guess all error message we just accept any. Reported-By: travis-ci Gbp-Dch: Ignore 2017-12-13T22:56:29Z David Kalnischkies david@kalnischkies.de 2017-10-27T17:09:45Z urn:sha1:355e1aceac1dd05c4c7daf3420b09bd860fd169d For deb files we always supported falling back from one server to the other if one failed to download the deb, but that was hardwired in the handling of this specific item. Moving this alongside the retry infrastructure we can implement it for all items and allow methods to use this as well by providing additional URIs in a redirect. 2017-12-13T22:56:29Z David Kalnischkies david@kalnischkies.de 2017-10-25T23:09:48Z urn:sha1:dff555d40bb9776b5b809e06527e46b15e78736c Moving the Retry-implementation from individual items to the worker implementation not only gives every file retry capability instead of just a selected few but also avoids needing to implement it in each item (incorrectly). 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.