Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.9.12 2020-02-16T11:46:09Z 2020-02-16T11:46:09Z Julian Andres Klode julian.klode@canonical.com 2020-02-16T10:45:05Z urn:sha1:9cc0e2cab7c83ede99e21c70f248d884b8930983 This experiment did not turn out sensibly, as some servers do not accept credentials when none are expected and fail, so you cannot mirror such a repository. This reverts commit c2b9b0489538fed4770515bd8853a960b13a2618. 2020-01-30T15:58:23Z Julian Andres Klode julian.klode@canonical.com 2019-04-15T07:40:20Z urn:sha1:4f9c58d25ff52fbb69cd3439fc1484bea47e1566 Since we append a concrete kernel version to each pattern, and then anchor the pattern, let's just pick any package starting with a kernel name (linux-, kfreebsd-, gnumach-), and not worry about linux-headers, linux-tools, etc specifically, as they'll be caught by the generic pattern. LP: #1607845 2020-01-16T10:10:47Z Julian Andres Klode julian.klode@canonical.com 2020-01-16T09:53:05Z urn:sha1:ea4b7921b7e3eadb42be1deab5f343dbba8f29df APT 1.9.6 introduced empty groups by making use of groups to deduplicate package names. This is not normally a problem, but here we assumed that every group has at least one package. This caused a problem because automake was providing automake-1.16 while having the source package automake-1.16. So we found the automake-1.16 group, iterated over its empty package list, trying to store the provides (which hence never happened). LP: #1859952 2020-01-15T22:02:32Z Julian Andres Klode jak@debian.org 2020-01-15T22:02:32Z urn:sha1:087c97b7959acb1f9417b0b02be58709666476dc apt(8): Disable regular expressions and fnmatch See merge request apt-team/apt!95 2020-01-15T21:19:17Z Julian Andres Klode julian.klode@canonical.com 2020-01-15T21:01:54Z urn:sha1:21cb4a9e513ccb6f376fbcaf67957c4851cbbe32 This is the first step. Next step will be to add warnings to apt-get and then remove support there as well. 2020-01-15T21:07:25Z Julian Andres Klode julian.klode@canonical.com 2019-12-04T12:58:38Z urn:sha1:a9916c3faa2b8c6fa288599efec65868d050b0ef Commit 93f33052de84e9aeaf19c92291d043dad2665bbd restricted auth.conf entries to only apply to https by default, but this was silent - there was no information why http sources with auth.conf entries suddenly started failing. Add such information, and extend test case to cover it. 2019-12-06T12:48:07Z Julian Andres Klode julian.klode@canonical.com 2019-12-06T12:46:58Z urn:sha1:05d1549fb65b00137b22159761462626d11bfe73 apt satisfy "" caused a segmentation fault because we were iterating over the characters, checking if the next character was the end of the string; when it could also be the current character. Instead, check whether the next character is before the end of the string, rather than identical to the end. 2019-12-02T14:49:07Z Julian Andres Klode jak@debian.org 2019-12-02T14:49:07Z urn:sha1:b59be3af284d13988182d99fcd2ab5948a0f6a83 Pu/patterns phase2 See merge request apt-team/apt!85 2019-12-02T13:27:38Z Julian Andres Klode julian.klode@canonical.com 2019-12-02T10:46:49Z urn:sha1:93f33052de84e9aeaf19c92291d043dad2665bbd This avoids downgrade attacks where an attacker could inject Location: http://private.example/ and then (having access to raw data to private.example, for example, by opening a port there, or sniffing network traffic) read the credentials for the private repository. Closes: #945911 2019-11-27T21:00:43Z David Kalnischkies david@kalnischkies.de 2019-11-27T11:10:31Z urn:sha1:1690c3f87ae45a41e8d3e09bf0b1021c008460b9 While passing the combi Release and Release.gpg to the gpgv method for verification the filename of Release is placed where usually Release.gpg is assumed in the rest of the code. The "usual" cases like passing verification and failing verification ending in an error are taking care of this, but the code path dealing with a failed verification, but ignoring said failure (e.g. due to trusted=yes) was not which results in the wrong file being removed later on (in case the index happens to be unmodified since the last update call) leading us into the abyss of strange failures (fixed in the previous commit) were nothing should have changed. This is not a security issue in this form as the repository needs to fail verification & the user forcing apt to ignore the failure and carry on anyhow. It does show however how complicated the code and its various interconnected paths can become. Reported-By: Val "pinkieval" Lorentz on IRC