Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=2.7.12 2024-02-20T12:49:04Z 2024-02-20T12:49:04Z Julian Andres Klode julian.klode@canonical.com 2024-02-20T12:43:08Z urn:sha1:40a75722c43ae24cb9a99d6730a3b25b65819c49 This was automated with sed and git-clang-format, and then I had to fix up the top of policy.cc by hand as git-clang-format accidentally indented it by two spaces. 2022-10-31T10:18:13Z Julian Andres Klode julian.klode@canonical.com 2022-10-31T10:17:04Z urn:sha1:c2cb1e42189c5fe3481386cb83a6b03bfe583d1f During development there was an if (0) there for debugging purposes that unfortunately stayed in and caused files to accumulate. LP: #1995247 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-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-02-04T10:00:00Z David Kalnischkies david@kalnischkies.de 2020-06-28T18:52:09Z urn:sha1:96dc40b19623621a9cc2c5541fb3adbbceb553b1 varg API is a nightmare as the symbols seems different on ever other arch, but more importantly SendMessage does a few checks on the content of the message and it is all outputted via C++ iostreams and not mixed in FILE* which is handy for overriding the streams. 2020-12-18T18:31:19Z David Kalnischkies david@kalnischkies.de 2020-07-09T22:02:25Z urn:sha1:97d6c3b2d05fe0d965657197adf56cc78f9edf81 Every method opts in to getting the encoded URI passed along while keeping compat in case we are operated by an older acquire system. Effectively this is just a change for the http-based methods as the others just decode the URI as they work with files directly. 2020-08-04T10:12:11Z Julian Andres Klode julian.klode@canonical.com 2020-07-14T14:19:08Z urn:sha1:9cb5a81168307e15f209173ad9286835bff2df65 2020-01-07T21:51:41Z Julian Andres Klode julian.klode@canonical.com 2020-01-07T21:37:36Z urn:sha1:df4b92bd1df204e7fb0d22e73e143d205d74aea6