apt/test/integration/test-releasefile-verification, branch 1.3_pre1

add insecure (and weak) allow-options for sources.list

2016-06-22T12:05:01Z

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

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

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

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

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

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

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).

gpgv: use EXPKEYSIG instead of KEYEXPIRED

2016-05-01T08:50:24Z

The upstream documentation says about KEYEXPIRED: "This status line is not very useful". Indeed, it doesn't mention which key is expired, and suggests to use the other message which does.

Allow lowering trust level of a hash via config

2016-03-28T12:59:33Z

Introduces APT::Hashes:: with entries Untrusted and Weak which can be set to true to cause the hash to be treated as untrusted and/or weak.

handle gpgv's weak-digests ERRSIG

2016-03-22T00:58:45Z

Our own gpgv method can declare a digest algorithm as untrusted and handles these as worthless signatures. If gpgv comes with inbuilt untrusted (which is called weak in official terminology) which it e.g. does for MD5 in recent versions we should handle it in the same way. To check this we use the most uncommon still fully trusted hash as a configureable one via a hidden config option to toggle through all of the three states a hash can be in.