Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=2.4.2 2022-03-07T12:04:23Z 2022-03-07T12:04:23Z Julian Andres Klode jak@debian.org 2022-03-07T12:03:24Z urn:sha1:55452afa1e8eb3b252f76e455b49df5883e0b811 Change the logic to use "Valid" instead of "Good" to determine whether we need to fallback and if fallback was successful. That means that if you have an expired key in trusted.gpg.d, and a non-expired in trusted.gpg, verification will now fail directly with the expired key in trusted.gpg.d and not try to fallback. Likewise, if the key in trusted.gpg is expired, this will now also be reported correctly again, instead of producing an error message that the key could not be found. 2022-03-07T10:53:27Z Julian Andres Klode jak@debian.org 2022-03-07T10:53:27Z urn:sha1:ee427f308600a4a3a6f67a4a7835e1172605ba06 If a repository is signed with multiple keys, apt 2.4.0 would ignore the fallback result if some keys were still missing, causing signature verification to fail. Rework the logic such that when checking if fallback was "succesful", missing keys are ignored - it only matters if we managed to verify one key now, whether good or bad. Likewise, simplify the logic when to do the fallback: If there was a bad signature in trusted.gpg.d, do NOT fallback at all - this is a minor security issue, as a key in trusted.gpg.d could fail silently with a bad signature, and then a key in trusted.gpg might allow the signature to succeed (as trusted.gpg.d key is then missing). Only fallback if we are missing a good signature, and there are keys we have not yet checked. 2022-02-22T17:25:06Z Julian Andres Klode jak@debian.org 2022-01-07T11:43:32Z urn:sha1:56adf743b02b80a9acc9a2e480bfd15acb94f755 With apt-key going away, people need to manage key files, rather than keys, so they need to know if any keys are in the legacy keyring. 2021-11-27T10:22:38Z Ville Skyttä ville.skytta@iki.fi 2021-11-03T22:08:07Z urn:sha1:01eed4234440d82fc52c8186cf4268517bcd28bc 2021-11-23T19:19:23Z Cameron Katri me@cameronkatri.com 2021-11-23T19:19:23Z urn:sha1:6f35750118a06e9d11e6aa7ab29f4ef01b75898b Darwin systems define TRUE and FALSE as preprocessor macros for use with bool. This conflicts with the enum values causing the compilation to fail. 2021-10-18T14:12:54Z Julian Andres Klode julian.klode@canonical.com 2021-06-09T11:22:38Z urn:sha1:3f07f5345ec79702c3c769047452041b2c12953f Extend the Signed-By field to handle embedded public key blocks, this allows shipping self-contained .sources files, making it substantially easier to provide third party repositories. 2021-10-18T13:42:56Z Julian Andres Klode jak@debian.org 2021-10-18T13:42:56Z urn:sha1:ad7bae309a827592aa228af9470c1aa7abdd189e basehttp: Turn HaveContent into a TriState See merge request apt-team/apt!179 2021-10-18T13:37:47Z Julian Andres Klode jak@debian.org 2021-10-18T13:37:47Z urn:sha1:efa3528de4277a3d5195c5ce875e7ee960726239 Add AllowRange option to disable HTTP Range usage See merge request apt-team/apt!188 2021-09-16T20:40:00Z David Kalnischkies david@kalnischkies.de 2021-09-16T17:48:33Z urn:sha1:d013f8957c0d464e0059cc107ca79d887cf9f8aa Debian buster (oldstable) ships 6.1 while bullseye (stable) ships 6.5 and so the later is 'fixed'. Upstream declares 6.0 still as supported. It might be still a while we encounter "bad" versions in the wild, so if we can detect and work around the issue at runtime automatically we can save some users from running into "persistent" partial files. References: https://varnish-cache.org/docs/6.4/whats-new/changes-6.4.html#changes-in-behavior 2021-09-16T20:38:46Z David Kalnischkies david@kalnischkies.de 2021-09-16T17:33:24Z urn:sha1:61c1d7d3658fdcd4b32f8b071cef7941120f8abc apt makes heavy usage of HTTP1.1 features including Range and If-Range. Sadly it is not obvious if the involved server(s) (and proxies) actually support them all. The Acquire::http::AllowRange option defaults to true as before, but now a user can disable Range usage if it is known that the involved server is not dealing with such requests correctly.