apt/test/integration/test-releasefile-verification, branch 1.4.2 Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.4.2 2017-01-19T14:59:38Z fix various typos reported by spellintian 2017-01-19T14:59:38Z David Kalnischkies david@kalnischkies.de 2017-01-19T14:14:19Z urn:sha1:93cff633a830e222693fc0f3d78e6e534d1126ee Most of them in (old) code comments. The two instances of user visible string changes the po files of the manpages are fixed up as well. Gbp-Dch: Ignore Reported-By: spellintian show apt-key warnings in apt update 2016-08-25T13:22:28Z David Kalnischkies david@kalnischkies.de 2016-08-25T13:22:28Z urn:sha1:29c590951f812d9e9c4f17706e34f2c3315fb1f6 In 105503b4b470c124bc0c271bd8a50e25ecbe9133 we got a warning implemented for unreadable files which greatly improves the behavior of apt update already as everything will work as long as we don't need the keys included in these files. The behavior if they are needed is still strange through as update will fail claiming missing keys and a manual test (which the user will likely perform as root) will be successful. Passing the new warning generated by apt-key through to apt is a bit strange from an interface point of view, but basically duplicating the warning code in multiple places doesn't feel right either. That means we have no translation for the message through as apt-key has no i18n yet. It also means that if the user has a bunch of sources each of them will generate a warning for each unreadable file which could result in quite a few duplicated warnings, but "too many" is better than none. Closes: 834973 add the gpg-classic variant to the gpgv/gnupg or-group 2016-08-17T07:52:32Z David Kalnischkies david@kalnischkies.de 2016-08-16T13:46:19Z urn:sha1:19fdf93d7363261227811a62157063081b9f1a5d We need to support partial upgrades anyhow, so we have to deal with the different versions and your tests try to ensure that we do, so we shouldn't make any explicit higher requirements. don't sent Range requests if we know its not accepted 2016-08-16T16:49:37Z David Kalnischkies david@kalnischkies.de 2016-08-11T16:24:35Z urn:sha1:d94b1d80d8326334d17f6a43061368e783b8e0aa If the server told us in a previous request that it isn't supporting Ranges with bytes via an Accept-Ranges header missing bytes, we don't try to formulate requests using Ranges. (error) va_list 'args' was opened but not closed by va_end() 2016-07-27T20:42:24Z David Kalnischkies david@kalnischkies.de 2016-07-27T20:21:58Z urn:sha1:196d590a99e309764e07c9dc23ea98897eebf53a Reported-By: cppcheck Gbp-Dch: Ignore add insecure (and weak) allow-options for sources.list 2016-06-22T12:05:01Z David Kalnischkies david@kalnischkies.de 2016-06-20T18:50:43Z urn:sha1:d03b947b0ce4f87d7d5cc48d4d274ab3bd0b289a Weak had no dedicated option before and Insecure and Downgrade were both global options, which given the effect they all have on security is rather bad. Setting them for individual repositories only isn't great but at least slightly better and also more consistent with other settings for repositories. tests: disable generation of Release.gpg by default 2016-05-04T10:12:33Z David Kalnischkies david@kalnischkies.de 2016-05-04T09:45:35Z urn:sha1:5a23c56d6852a27d45c2ae227b43060f7beac051 Most tests just need a signed repository and don't care if it signed by an InRelease file or a Release.gpg file, so we can save some time by just generating one of them by default. Sounds like not much, but quickly adds up to a few seconds with the amount of tests we have accumulated by now. Git-Dch: Ignore tests: allow to disable generation of InRelease/Release.gpg file 2016-05-04T10:12:27Z David Kalnischkies david@kalnischkies.de 2016-05-04T09:10:08Z urn:sha1:761a5ad2ec07f097b05c32427bd0ebddfd587987 If the test just signs release files to throw away one of them to test the other, we can just as well save the time and not create it. Git-Dch: Ignore support Signed-By in Release files as a sort of HPKP 2016-05-01T08:50:24Z David Kalnischkies david@kalnischkies.de 2016-04-29T14:48:16Z urn:sha1:89901946f936446f439b95f1a9a85ac942ac2c92 Users have the option since apt >= 1.1 to enforce that a Release file is signed with specific key(s) either via keyring filename or fingerprints. This commit adds an entry with the same name and value (except that it doesn't accept filenames for obvious reasons) to the Release file so that the repository owner can set a default value for this setting effecting the *next* Release file, not the current one, which provides a functionality similar "HTTP Public Key Pinning". The pinning is in effect as long as the (then old) Release file is considered valid, but it is also ignored if the Release file has no Valid-Until at all. support multiple fingerprints in signed-by 2016-05-01T08:50:24Z David Kalnischkies david@kalnischkies.de 2016-04-29T08:16:42Z urn:sha1:46e00c9062d09a642973e83a334483db1f310397 A keyring file can include multiple keys, so its only fair for transitions and such to support multiple fingerprints as well.