Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=2.9.2 2024-01-09T16:33:58Z 2024-01-09T16:33:58Z Gábor Németh homar@riseup.net 2023-12-15T12:12:05Z urn:sha1:deeda8948be59730659972185e279fbe1b438121 Corrected 'und' -> 'and' in the fake package's description. As a result, the MD5 checksum of this string is changed from 36ef2ec58c83bc4fdbe9fe958dd9c107 to 5022766cbc9bf07d1abea2c41a72646f which in turn reduced the size of the resulting Packages.gz by one. Therefore the accepted answer in the test case is updated too. 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.