Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.2.4 2016-02-04T17:13:05Z 2016-02-04T17:13:05Z Julian Andres Klode jak@debian.org 2016-02-04T17:13:05Z urn:sha1:eb5113c486955d9cd66126aa59d3a27e52c52e58 2016-01-27T15:39:52Z David Kalnischkies david@kalnischkies.de 2016-01-27T14:28:17Z urn:sha1:6fc2e03084c7e027c2b9a63c1fe99ff743aae3b6 The Date field in the Release file is useful to avoid allowing an attacker to 'downgrade' a user to earlier Release files (and hence to older states of the archieve with open security bugs). It is also needed to allow a user to define min/max values for the validation of a Release file (with or without the Release file providing a Valid-Until field). APT wasn't formally requiring this field before through and (agrueable not binding and still incomplete) online documentation declares it optional (until now), so we downgrade the error to a warning for now to give repository creators a bit more time to adapt – the bigger ones should have a Date field for years already, so the effected group should be small in any case. It should be noted that earlier apt versions had this as an error already, but only showed it if a Valid-Until field was present (or the user tried to used the configuration items for min/max valid-until). Closes: 809329 2016-01-26T20:09:47Z David Kalnischkies david@kalnischkies.de 2016-01-26T20:09:47Z urn:sha1:07aca07ae73016aa7823e708dda746eec8346989 In 321213f0dcdcdaab04e01663e7a047b261400c9c Andreas Cadhalpun corrected the incorrect overriding of earlier better-fitting results with later (semi-)matches – but that broke the case in which packages are in multiple releases in the same version (and the user has both releases configured). Closes: 812497 2016-01-08T14:40:01Z David Kalnischkies david@kalnischkies.de 2016-01-08T12:08:19Z urn:sha1:896f0ae857b693782658145e16e21a3054dd5280 Some (older) versions of bash seem to be allergic to a method named "aptautotest_grep_^apt" (note the caret). Unlikely that we are going to write autotests for such commands so we could just skip those, but lets instead just use "normal" characters in the names and strip the rest as we already did with the (arguable more common) '-'. 2016-01-08T14:40:01Z David Kalnischkies david@kalnischkies.de 2016-01-07T23:35:39Z urn:sha1:abec2980ef1ff051be14c26097a76b6429b3b7bc This way it works more similar to the compressor binaries, which we can relief in this way from their job in the test framework avoiding the need of adding e.g. liblz4-tool to the test dependencies. 2016-01-08T14:40:01Z David Kalnischkies david@kalnischkies.de 2016-01-07T19:32:09Z urn:sha1:0179cfa83cf0042235eda41db7f35c420781c63e Downloading and storing are two different operations were different compression types can be preferred. For downloading we provide the choice via Acquire::CompressionTypes::Order as there is a choice to be made between download size and speed – and limited by whats available in the repository. Storage on the other hand has all compressions currently supported by apt available and to reduce runtime of tools accessing these files the compression type should be a low-cost format in terms of decompression. apt traditionally stores its indexes uncompressed on disk, but has options to keep them compressed. Now that apt downloads additional files we also deal with files which simply can't be stored uncompressed as they are just too big (like Contents for apt-file). Traditionally they are downloaded in a low-cost format (gz) as repositories do not provide other formats, but there might be even lower-cost formats and for download we could introduce higher-cost in the repositories. Downloading an entire index potentially requires recompression to another format, so an update takes potentially longer – but big files are usually updated via pdiffs which has to de- and re-compress anyhow and does it on the fly anyhow, so there is no extra time needed and in general it seems to be benefitial to invest the time in update to save time later on file access. 2016-01-08T14:40:01Z David Kalnischkies david@kalnischkies.de 2016-01-03T21:39:46Z urn:sha1:912a61312a0463b46d6560756c89146f59daaab6 Less hardcoding should help while introducing new compressors. Git-Dch: Ignore 2015-12-19T22:04:34Z David Kalnischkies david@kalnischkies.de 2015-12-18T12:17:11Z urn:sha1:785cb6fc843f4751ff9c57dcdf375ad061e83f36 The output changes slightly between different versions, which we already dealt with in the main testcase for apt-key, but there are two more which do not test both versions explicitly and so still had gpg1 output to check against as this is the default at the moment. Git-Dch: Ignore 2015-12-19T22:04:34Z David Kalnischkies david@kalnischkies.de 2015-12-17T16:41:11Z urn:sha1:bc8f83a5afd858206efe518c31bbb1ac948a39a3 apt-key creates internally a script (since ~1.1) which it will call to avoid dealing with an array of different options in the code itself, but while writing this script it wraps the values in "", which will cause the shell to evaluate its content upon execution. To make 'use' of this either set a absolute gpg command or TMPDIR to something as interesting as: "/tmp/This is fü\$\$ing cràzy, \$(man man | head -n1 | cut -d' ' -f1)\$!" If such paths can be encountered in reality is a different question… 2015-12-19T22:04:34Z David Kalnischkies david@kalnischkies.de 2015-12-15T16:20:26Z urn:sha1:3abb6a6a1e485b3bc899b64b0a1b7dc2db25a9c2 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