Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.6_beta1 2018-02-26T12:15:26Z 2018-02-26T12:15:26Z Julian Andres Klode julian.klode@canonical.com 2018-02-26T12:15:26Z urn:sha1:5206249ea92fccf9e812a2d373cbd2f16c623059 2018-02-23T14:37:53Z Julian Andres Klode julian.klode@canonical.com 2018-02-23T14:37:53Z urn:sha1:923ba67464960940a19b24a341e896a9338161fb LP: #1698159 2018-02-19T15:06:06Z Julian Andres Klode jak@debian.org 2018-02-19T15:06:06Z urn:sha1:928ecff984be22632c27a69e072741e74491292c Check that Date of Release file is not in the future See merge request apt-team/apt!3 2018-02-19T15:05:01Z Julian Andres Klode julian.klode@canonical.com 2018-01-29T15:15:41Z urn:sha1:9e5899cac1a6367e3769af52a724821880e538f6 By restricting the Date field to be in the past, an attacker cannot just create a repository from the future that would be accepted as a valid update for a repository. This check can be disabled by Acquire::Check-Date set to false. This will also disable Check-Valid-Until and any future date related checking, if any - the option means: "my computers date cannot be trusted." Modify the tests to allow repositories to be up to 10 hours in the future, so we can keep using hours there to simulate time changes. 2018-02-19T14:57:43Z David Kalnischkies david@kalnischkies.de 2018-02-07T00:45:03Z urn:sha1:13c85c9cec9e071e90ea190a74cbaabe7c51024c This is an optional dependency for the test, but the skipping of the test is very noisy and checking that an unchanged aptitude isn't downright exploding with our libapt isn't a bad idea either. Gbp-Dch: Ignore 2018-02-19T14:57:38Z Chris Leick c.leick@vollbio.de 2018-02-03T15:53:56Z urn:sha1:cc6bab259025b159f1e7c925f29bf07b2c8501ac 2018-02-19T14:56:09Z David Kalnischkies david@kalnischkies.de 2018-02-02T18:14:09Z urn:sha1:b3e7a16265e7c6c3b6892b9ec8a787d692ced6e6 The interesting takeaway here is perhaps that 'chmod +w' is effected by the umask – obvious in hindsight of course. The usual setup helps with hiding that applying that recursively on all directories (and files) isn't correct. Ensuring files will not be stored with the wrong permissions even if in strange umask contexts is trivial in comparison. Fixing the test also highlighted that it wasn't bulletproof as apt will automatically fix the permissions of the directories it works with, so for this test we actually need to introduce a shortcut in the code. Reported-By: Ubuntu autopkgtest CI 2018-02-19T14:56:09Z David Kalnischkies david@kalnischkies.de 2018-01-27T01:15:35Z urn:sha1:7aaf9b2c63aa8bdd87de4c19dcf1742c686a1cc2 The testpackages hardly need debhelper at all, so any version would do, and they build without root rights by definition, but declaring it explicitly can't hurt and in the case of debhelper it would be sad if our testcases break one day because the old compat level is removed. Gbp-Dch: Ignore 2018-02-19T14:56:09Z David Kalnischkies david@kalnischkies.de 2018-01-27T01:11:20Z urn:sha1:6e2877548b114729b69b817b872419edde732d0f This setting was lost in the transition to cmake. The private library has no public users and hence the default visibility of symbols changed early to hidden – something which should eventually be done for the public libraries as well, but one step at the time. 2018-02-19T14:56:09Z David Kalnischkies david@kalnischkies.de 2018-01-05T22:47:45Z urn:sha1:d90eb8132961aa481b94e63246a0ed23fc36d182 It is sad that we can't wrap the cdrom method tighter at the moment, but due to its ability to mount drives into arbitrary places via an external suid binary we can't really do a lot better at the moment. What we can do is set the options in the configuration space through as it is standard in the other methods instead of doing it in main() which is assumed to be more boilerplatey than actually doing something. Gbp-Dch: Ignore