Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=2.9.2 2024-04-09T17:59:52Z 2024-04-09T17:59:52Z Julian Andres Klode julian.klode@canonical.com 2024-04-09T17:56:26Z urn:sha1:81c65f7e86b8f16eaaa91d9c205a594b0ebde159 We temporarily downgraded the errors to warnings to give the launchpad PPAs time to be fixed, but warnings are not safe: Untrusted keys could be hiding on your system, but just not used at the moment. Hence revert this so we get the errors we want. This reverts commit 66998ed3d299bede651ad40368bdb270f5f5b0f9. LP: #2060721 Gbp-Dch: full 2024-02-28T17:22:01Z Julian Andres Klode julian.klode@canonical.com 2024-02-28T16:04:05Z urn:sha1:66998ed3d299bede651ad40368bdb270f5f5b0f9 This will only issue warnings instead of errors while we continue cleaning up our repositories. 2024-02-28T17:22:01Z Julian Andres Klode julian.klode@canonical.com 2024-02-28T15:52:33Z urn:sha1:8a14c18c5b487139948dcb22abd37bffdd9cf5f4 This allows us to render public key algorithms as weak as well. 2024-02-28T17:22:01Z Julian Andres Klode julian.klode@canonical.com 2024-02-28T14:14:43Z urn:sha1:50e3fee26ae843a812b1c9ec8531946931773fd3 The assertion can be overriden using apt::key::assert-pubkey-algo, the default is the most opinionated one. This will inform the user during apt-cdrom add as we do not pass --quiet to user, so adjust test case. Add a simple test case for it to test-method-gpgv. LP: #2055193 2024-02-28T17:21:01Z Julian Andres Klode julian.klode@canonical.com 2024-02-28T13:49:48Z urn:sha1:60d653634f889abe09c0f4d88f2559eab9202635 2024-02-28T17:21:01Z Julian Andres Klode julian.klode@canonical.com 2024-01-18T17:35:35Z urn:sha1:066121ac4de3f1e07e203583a2c5d00a0289f84a 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.