Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.3_exp3 2016-06-15T11:38:51Z 2016-06-15T11:38:51Z David Kalnischkies david@kalnischkies.de 2016-06-15T10:45:07Z urn:sha1:99968cf75b46210bded1662d34c4c2b0ef07be04 Most servers who close the connection do not send a content-length as this is redundant information usually, but some might and while testing with our server and with 'aptwebserver::response-header::Connection' set to 'close' I noticed that http hangs after a redirect in such cases, so if we have the information, just use it instead of discarding it. 2016-06-02T11:35:28Z David Kalnischkies david@kalnischkies.de 2016-06-02T10:44:58Z urn:sha1:62600666d21aacea63cece3b4ec64f0ffb40168b In 8b79c94af7f7cf2e5e5342294bc6e5a908cacabf changing to usage of C++ way of setting the locale causes us to be terminated in case of usage of an ungenerated locale as LC_ALL (or similar) – but we don't want to fail here, we just want to carry on as before with setlocale which we call in that case just for good measure. 2016-05-28T16:12:02Z David Kalnischkies david@kalnischkies.de 2016-05-28T11:22:38Z urn:sha1:8b79c94af7f7cf2e5e5342294bc6e5a908cacabf 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. 2016-05-27T17:14:38Z David Kalnischkies david@kalnischkies.de 2016-05-27T16:10:39Z urn:sha1:b58e2c7c56b1416a343e81f9f80cb1f02c128e25 Setting the C++ locale via std::locale::global(std::locale("")); which would otherwise default to the default C locale (aka: unaffected by setlocale) effects the formatting of numeric types in IO streams, which for output for humans is perfectly sensible, but breaks our many text interfaces used and parsed by us and others without expecting the numbers to be formatted. Closes: #825396 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.