apt/methods/gpgv.cc, branch 1.3_pre1

use std::locale::global instead of setlocale

2016-05-28T16:12:02Z

We use a wild mixture of C and C++ ways of generating output, so having a consistent world-view in both styles sounds like a good idea and should help in preventing regressions.

gpgv: show always webportal error on NODATA

2016-05-08T17:46:34Z

gpg doesn't give use a UID on NODATA, which we were "expecting" (but not using for anything), but just an error number. Instead of collecting these as badsigners which will trigger a "invald signature" error with remarks like "NODATA 1" we instead adapt a message similar to the NODATA error of a clearsigned file (which is actually not reached anymore as we split them up, which fails with a NOSPLIT error, which uses the same general error message). In other words: Not a security relevant change, just a user experience improvement as we now point them to the most likely cause of the problem instead of saying "invalid signature" which would point them in the direction of the archive being broken (for everyone) instead. Closes: 823746

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.

gpgv: cleanup statusfd parsing a bit

2016-05-01T08:50:24Z

We parse the messages we receive into two big categories: Most of the messages have a keyid as well as a userid and as they are errors we want to show the userids as well. The other category is also errors, but have no userid (like NO_PUBKEY). Explicitly expressing this in code should make it a bit easier to look at and it also help in dropping additional fields or just the newline at the end consistently. Git-Dch: Ignore

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.

properly check for "all good sigs are weak"

2016-03-21T21:47:17Z

Using erase(pos) is invalid in our case here as pos must be a valid and derefenceable iterator, which isn't the case for an end-iterator (like if we had no good signature). The problem runs deeper still through as VALIDSIG is a keyid while GOODSIG is just a longid so comparing them will always fail. Closes: 818910