Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.3_exp1 2016-05-08T17:46:34Z 2016-05-08T17:46:34Z David Kalnischkies david@kalnischkies.de 2016-05-08T17:46:34Z urn:sha1:2fac0dd5a7a62b67a869cd4c71c9d09159aaa31d 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 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. 2016-05-01T08:50:24Z David Kalnischkies david@kalnischkies.de 2016-04-29T08:08:13Z urn:sha1:5419a6ce20967902102358a07632ae3688788d62 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 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 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). 2016-05-01T08:50:24Z David Kalnischkies david@kalnischkies.de 2016-04-28T17:05:06Z urn:sha1:f13b413a3bb1f03886ba7d8c43b08bd13836a663 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. 2016-04-27T20:55:55Z Patrick Cable pc@pcable.net 2016-04-27T20:55:55Z urn:sha1:8707edd9e4684ed68856cd8eeff15ebd1e8c88ea when using the https transport mechanism, $no_proxy is ignored if apt is getting it's proxy information from $https_proxy (as opposed to Acquire::https::Proxy somewhere in apt config). if the source of proxy information is Acquire::https::Proxy set in apt.conf (or apt.conf.d), then $no_proxy is honored. 2016-04-25T13:35:52Z David Kalnischkies david@kalnischkies.de 2016-04-07T15:48:17Z urn:sha1:742f67eaede80d2f9b3631d8697ebd63b8f95427 We have this situation in cases were parts of the transaction are refused (e.g. in a hashsum mismatch) and rerun the update (e.g. in the hope that we get a mirror which is synced this time). Previously we would ask the server with an if-range and in the best case recieve a 416 in response (less featureful server might end up giving us the entire file again or we get the wrong file this time giving us a hashsum mismatch…), which is a waste of time if we know already by checking the hashsums that we got the complete and correct file. 2016-04-14T14:55:35Z David Kalnischkies david@kalnischkies.de 2016-04-14T14:16:06Z urn:sha1:479f6fa454cd6ee9e1bc4d9ecda856d34584092e With the previous fix for file applied we can again hit repositories which contain uncompressed empty files, which since the introduction of the central store: method wasn't accounted for anymore as we forbid empty compressed files. 2016-04-14T14:15:39Z David Kalnischkies david@kalnischkies.de 2016-04-14T14:01:56Z urn:sha1:e169fa4a85e03b2b03bb1bdba716b96654ae6050 A silly of-by-one error in the stripping of the extension to check for the uncompressed filename broken in an attempt to support all compressions in commit a09f6eb8fc67cd2d836019f448f18580396185e5. Fixing this highlights also mistakes in the handling of the Alt-Filename in libapt which would cause apt to remove the file from the repository (if root has the needed rights – aka the disk isn't readonly or similar)