apt/test/integration, branch 2.9.24

Remove superseded warning about trusted.gpg fallback

2025-01-21T11:16:34Z

This warning has been superseded by the missing sources.list notice (which will also become a warning shortly) Adjust the sqv exit to avoid introducing a new spurious "No good signature" that we did not reach before. moo

Warn about missing Signed-By in .list format

2025-01-21T11:16:34Z

Warn about the missing field there and suggest the transition to deb822 .sources files if we found any non-deb822 source without signed-by.

Grep for more evil in test as a signature can contain evil

2025-01-17T01:09:05Z

The test was failing for me as the PGP signature contained "GeviljGB" which is clearly not the evil we are looking for. Sadly, reproducing this is hard, but random failures of the test suite are annoying, so lets grep for a bit longer strings that can't happen in the signature block to avoid this particular problem.

Write Pre-Depends with a dash again in EDSP

2025-01-17T00:27:48Z

For some reason ~ that I don't know and can't come up with on the spot ~ we output the Pre-Depends field as PreDepends in the translated user-visible output and I accidentally copied that over to the untranslated variant that replaced the embedded copy (with a dash) in the EDSP generator. Code-copies and implementation details littered all over the place are apparently sometimes a good bug-free thing, too… Regression-of: 6828ae2c2f9268c8187f0fa91b3c464ed84a8476 Closes: #1093254

t/i/test-method-gpgv-legacy-keyring: Switch to http, extend

2025-01-14T09:01:51Z

Add some more test cases where only one of the sources is bad; and switch to htp to make the order more reliable.

Drop SourceListWarnings::NonFreeFirmware messages

2025-01-05T22:16:09Z

They were implemented to help a tiny bit in notifying users even if they didn't read the Release notes (or didn't realize it would apply to them) that they likely have to change their sources.list entries, but that transition is now over for a while, so everyone who should have seen it has hopefully reacted to it and so all this code now does is waste space, time and idly waiting for false positives.

Resolve autopkgtest failures caused by dpkg >= 1.22.12

2025-01-05T21:46:03Z

Streamlining the rules around the Section field and especially what happens if its isn't present are a good idea in general, but for testing proposes we want a package without a section ~ something dpkg and co do not want us to have for good reasons (outside of tests). While a real nosection package would interact with more of our code, for this test we don't really need a real one and so we can adopt to the new reality of encountering such packages only if they are already installed instead of trying to build a sectionless package by hand. The other failure is a simple and trivial string change around the formatting of the version number in dpkg error message about file overrides, which we can resolve by just not looking at the version to sidestep dealing with the formatting difference. References: https://lists.debian.org/debian-dpkg/2024/12/msg00010.html Closes: #1092090

test: Check "${METHODSDIR}/sqv" not "/usr/bin/sqv"

2025-01-01T21:27:31Z

This is the correct check to find out whether we have built with sqv support.

sqv: Avoid propagating errors between files

2025-01-01T13:23:35Z

We inadvertently did not discard pending errors when the fallback to Dir::Etc::trusted succeeded, do so. Also add some quick safety checks to make sure we enter the verification in a good state, and that if somehow errors are pending after a verification we return false. Closes: #1091679

methods: Add new sqv method

2024-12-22T22:51:22Z

The new sqv method uses sequoia's sqv tool to verify files. The tool's interface is quite simple: It returns 0 on success, and prints one line per good signer with the fingerprint. sqv has a configurable crypto policy. We have defined apt-specific override mechanisms for sequoia's standard policy, allowing both users, distributions, and apt package to provide overrides for Sequoia's default policy in meaningful ways. The sqv method will be built and be the standard method for verifying OpenPGP signatures provided that `sqv` is in the PATH during building. It is not built if there was no sqv at build time, so you need a rebuild to enable sqv later on. On the flip side, the gpgv method is always built, but it does need to be always built: If APT::Key::GPGVCommand is set, we need to fallback to it - this is important to support existing users of that interface such as mmdebstrap. Also we want to fall back to it when /usr/bin/sqv disappears - for example in our CI :D A couple of concessions have been made for test suite purposes: - Failure to split a clearsigned file only shows the summary, as the gpgv method also only showed it, and no details why it failed. - We write "Got GOODSIG " in debug mode to mimic the gpgv code to keep the test suite happy. - In various places in the test suite we assert minimal output from sqv, but sqv's human output is not intended to be stable. This will incur additional work when it breaks. However we do not _parse_ the output, so actual operation of apt is unaffected. A couple of things are suboptimal here: - We are still doing clearsigned splitting ourselves. sqv only has support for detached signatures right now, whereas sqopv has support for clearsigned files as well (but sqopv does not provide any reasons for why signature verification fails or means to set a policy). - Deprecation of algorithms happens on a timebomb basis in sequoia. We have no means to give users warnings ahead of time if their configuration is outdated. We have implemented various bits that probably should be going away: - Fallback to trusted.gpg This is just annoying... - Support for fingerprints in Signed-By (no subkey matching though) The extra work here is arguably less compared to gpgv. - Check the keyring for correctness. With Signed-By everywhere, we should just error out rather than skip broken keyrings. Moo