summaryrefslogtreecommitdiff
path: root/test/integration/test-cve-2013-1051-InRelease-parsing
AgeCommit message (Collapse)Author
2016-12-31warn if clearsigned file has ignored content partsDavid Kalnischkies
Clearsigned files like InRelease, .dsc, .changes and co can potentially include unsigned or additional messages blocks ignored by gpg in verification, but a potential source of trouble in our own parsing attempts – and an unneeded risk as the usecases for the clearsigned files we deal with do not reasonably include unsigned parts (like emails or some such). This commit changes the silent ignoring to warnings for now to get an impression on how widespread unintended unsigned parts are, but eventually we want to turn these into hard errors.
2015-12-19tests: support spaces in path and TMPDIRDavid Kalnischkies
This doesn't allow all tests to run cleanly, but it at least allows to write tests which could run successfully in such environments. Git-Dch: Ignore
2015-11-19tests: use quiet level 0 by default in testsDavid Kalnischkies
Git-Dch: Ignore
2015-11-04support arch:all data e.g. in separate Packages fileDavid Kalnischkies
Based on a discussion with Niels Thykier who asked for Contents-all this implements apt trying for all architecture dependent files to get a file for the architecture all, which is treated internally now as an official architecture which is always around (like native). This way arch:all data can be shared instead of duplicated for each architecture requiring the user to download the same information again and again. There is one problem however: In Debian there is already a binary-all/ Packages file, but the binary-any files still include arch:all packages, so that downloading this file now would be a waste of time, bandwidth and diskspace. We therefore need a way to decide if it makes sense to download the all file for Packages in Debian or not. The obvious answer would be a special flag in the Release file indicating this, which would need to default to 'no' and every reasonable repository would override it to 'yes' in a few years time, but the flag would be there "forever". Looking closer at a Release file we see the field "Architectures", which doesn't include 'all' at the moment. With the idea outlined above that 'all' is a "proper" architecture now, we interpret this field as being authoritative in declaring which architectures are supported by this repository. If it says 'all', apt will try to get all, if not it will be skipped. This gives us another interesting feature: If I configure a source to download armel and mips, but it declares it supports only armel apt will now print a notice saying as much. Previously this was a very cryptic failure. If on the other hand the repository supports mips, too, but for some reason doesn't ship mips packages at the moment, this 'missing' file is silently ignored (= that is the same as the repository including an empty file). The Architectures field isn't mandatory through, so if it isn't there, we assume that every architecture is supported by this repository, which skips the arch:all if not listed in the release file.
2015-09-15tests: don't use hardcoded port for http and httpsDavid Kalnischkies
This allows running tests in parallel. Git-Dch: Ignore
2015-08-10Fix test case breakage from the new policy implementationJulian Andres Klode
Everything's working now.
2015-06-11show URI.Path in all acquire item descriptionsDavid Kalnischkies
It is a rather strange sight that index items use SiteOnly which strips the Path, while e.g. deb files are downloaded with NoUserPassword which does not. Important to note here is that for the file transport Path is pretty important as there is no Host which would be displayed by Site, which always resulted in "interesting" unspecific errors for "file:". Adding a 'middle' ground between the two which does show the Path but potentially modifies it (it strips a pending / at the end if existing) solves this "file:" issue, syncs the output and in the end helps to identify which file is meant exactly in progress output and co as a single site can have multiple repositories in different paths.
2015-06-09do not request files if we expect an IMS hitDavid Kalnischkies
If we have a file on disk and the hashes are the same in the new Release file and the old one we have on disk we know that if we ask the server for the file, we will at best get an IMS hit – at worse the server doesn't support this and sends us the (unchanged) file and we have to run all our checks on it again for nothing. So, we can save ourselves (and the servers) some unneeded requests if we figure this out on our own.
2015-03-16test exitcode as well as string equalityDavid Kalnischkies
We use test{success,failure} now all over the place in the framework, so its only consequencial to do this in the situations in which we test for a specific output as well. Git-Dch: Ignore
2014-10-07fix test-cve-2013-1051-InRelease-parsing (fails now in the method)Michael Vogt
2013-08-12add chronic-like testsuccess/testfailure helpersDavid Kalnischkies
For many commands the output isn't stable (like then dpkg is called) but the exitcode is, so this helper enhances the common && msgpass || msgfail by generating automatically a msgtest and showing the output of the command in case of failure instead of discarding it unconditionally, the later being chronic-like behaviour Git-Dch: Ignore
2013-06-24simple fork and pidfile aptwebserverDavid Kalnischkies
Forking only after being ready to accept clients avoids running races with the tests which sometimes failed on the first 'apt-get update' (or similar) with the previous background-start and hope for the best… The commit fixes also some oversight output-order changes in regards to Description-md5 and (I-M-S) race conditions in various tests. Git-Dch: Ignore
2013-06-09tests: add expected port for cve-2013-105 testcaseDavid Kalnischkies
Git-Dch: Ignore
2013-03-18rename testcase to mention CVE number, make the code more consistent withDavid Kalnischkies
the rest and add some more tests (by fixing commented ones)