apt/test/integration/test-releasefile-verification, branch 1.3_rc2 Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.3_rc2 2016-08-17T07:52:32Z 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. don't show NO_PUBKEY warning if repo is signed by another key 2016-05-01T08:50:24Z David Kalnischkies david@kalnischkies.de 2016-04-28T22:31:49Z urn:sha1:fb7b11ebb852fa255053ecab605bc9cfe9de0603 Daniel Kahn Gillmor highlights in the bugreport that security isn't improving by having the user import additional keys – especially as importing keys securely is hard. The bugreport was initially about dropping the warning to a notice, but in given the previously mentioned observation and the fact that we weren't printing a warning (or a notice) for expired or revoked keys providing a signature we drop it completely as the code to display a message if this was the only key is in another path – and is considered critical. Closes: 618445 gpgv: handle expired sig as worthless 2016-05-01T08:50:24Z David Kalnischkies david@kalnischkies.de 2016-04-28T20:02:50Z urn:sha1:1af227c2eaad386f0917fc4f36c84fd5999b884e Signatures on data can have an expiration date, too, which we hadn't handled previously explicitly (no problem – gpg still has a non-zero exit code so apt notices the invalid signature) so the error message wasn't as helpful as it could be (aka mentioning the key signing it).