apt/test/integration/framework, branch 2.7.14

Typos in integration tests

2024-01-09T16:33:58Z

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.

Compare SHA256 to check if versions are really the same

2023-08-02T10:04:32Z

If we know both SHA256, and they're different, the packages are. This approach stores the SHA256 only at runtime, avoiding the overhead of storing it on-disk, because when we update repositories we update all of them anyhow. Note that pkgCacheGenerator is hidden, so we can just modify its ABI, hooray. Closes: #931175 LP: #2029268

Do not store trusted=yes Release file unconditionally

2023-03-04T12:07:00Z

A source marked with trusted=yes can still fail verification of the Release file, mostly for Date related issues, like being too new or too old, which have other options to force them in. The update code was not using the Release file (which was a InRelease file but failed verification – which was overridden by trusted=yes) as intended, but it marked it for storage, so that this "bad" Release file would end up being moved into lists/, which is bad as the indexes it refers to aren't updated while the next update run assumes that the indexes are in the state the Release file claims them to be in. Fixed simply by making the storage conditional on the usage as intended, which also resolves a second issue: The verification can also detect that a Release file we got is older than what we already have to avoid down- grade attacks. The more likely explanation is a slightly outdated mirror in a rotation/CDN through, so this gets the silent treatment to avoid scaring users by handling it as if we had got the same Release file we already have stored locally, removing the freshly received older file in the process alongside setting some variables. Those variables were already modified in the trusted=yes case though resulting in the stored Release file being removed instead. Not modifying the variables too early resolves this problem as well. Both seem to exist since at least 2015 as traces are visible in 448c38bdcd already, which shuffled lots of code around including the bad ones, but as we are in trusted=yes land, security is of no concern here, this "just" leads to failed pinning, hashsum mismatches and other strange problems in follow-up calls depending on how out of sync the Release file (if its still present) is with the rest of the trusted data. Reported-By: Dima Kogan on IRC Tested-By: Dima Kogan

Allow apt to run if no dpkg/status file exists

2022-09-02T14:55:45Z

Not having a dpkg/status file used to be a hard error which from a boostrap perspective is suspect as in the beginning, there is no status so you would need to touch it into existence. We make a difference between factual non-existence and inaccessibility to catch mistakes in which the file is not readable for some reason, the testcase test-bug-254770-segfault-if-cache-not-buildable is an example of this. Note that apt has already figured out at this point that this is a Debian-like system which should have a dpkg/status file. This change does not effect the auto-detection and is not supposed to.

Avoid dealing with a fake dpkg stanza in the tests

2022-09-02T14:55:45Z

We needed a fake dpkg in our status file for dpkg --assert-multi-arch to work in the past, but recent dpkg versions do not require this anymore, so we can remove this somewhat surprising hackery in favour of better hidden hackery we only use if we work with an older dpkg (e.g. on current Debian stable).

Link interactive helpers against system libapt for autopkgtest

2022-05-07T08:45:44Z

Building the library just so we can build the helpers against it is not only wasteful but as we are supposed to test the system we can use that as an additional simple smoke test before the real testing starts.

Merge branch 'fix/file-https-proxy' into 'main'

2021-10-18T13:37:09Z

Fix file:/// vs file:/ hang & https-proxy for http See merge request apt-team/apt!187

Merge branch 'feature/barbarianarchs' into 'main'

2021-10-18T13:36:00Z

Streamline access to barbarian architecture functionality See merge request apt-team/apt!184

Read and work with canonical file-URIs from sources.lists

2021-09-13T14:08:52Z

We allow file (and other file-based methods) URIs to either be given as file:///path or as file:/path, but in various places of the acquire system we perform string comparisons on URIs which do not handle this expecting the canonical representation produced by our URI code. That used to be hidden by us quoting and dequoting the URIs in the system, but as we don't do this anymore we have to be a bit more careful on input. Ideally we would do less of these comparisons, but for now lets be content with inserting a canonicalisation early on to prevent hangs in the acquire system.

Move apt specific test setup into its own function

2021-09-04T13:35:15Z

APTs ad hoc testing framework for integration tests is not intending to be a general propose framework, but it is relatively easy to abuse it for other projects anyhow with some refactoring even if that is neither recommend nor officially supported. Gbp-Dch: Ignore