apt/test/integration/framework, branch 1.3_exp1Debians commandline package managerhttps://git.kalnischkies.de/apt/atom?h=1.3_exp12016-05-08T17:46:34Zgpgv: show always webportal error on NODATA2016-05-08T17:46:34ZDavid Kalnischkiesdavid@kalnischkies.de2016-05-08T17:46:34Zurn: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
tests: disable generation of Release.gpg by default2016-05-04T10:12:33ZDavid Kalnischkiesdavid@kalnischkies.de2016-05-04T09:45:35Zurn: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 file2016-05-04T10:12:27ZDavid Kalnischkiesdavid@kalnischkies.de2016-05-04T09:10:08Zurn: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
don't show NO_PUBKEY warning if repo is signed by another key2016-05-01T08:50:24ZDavid Kalnischkiesdavid@kalnischkies.de2016-04-28T22:31:49Zurn: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 worthless2016-05-01T08:50:24ZDavid Kalnischkiesdavid@kalnischkies.de2016-04-28T20:02:50Zurn: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).
show more details for "Hash Sum mismatch" errors2016-04-25T13:35:52ZDavid Kalnischkiesdavid@kalnischkies.de2016-03-12T19:29:04Zurn:sha1:0340069cc4709a18ba117090763d9f263de999a9
Users tend to report these errors with just this error message… not very
actionable and hard to figure out if this is a temporary or 'permanent'
mirror-sync issue or even the occasional apt bug.
Showing the involved hashsums and modification times should help in
triaging these kind of bugs – and eventually we will have less of them
via by-hash.
The subheaders aren't marked for translation for now as they are
technical glibberish and probably easier to deal with if not translated.
After all, our iconic "Hash Sum mismatch" is translated at least.
These additions were proposed in #817240 by Peter Palfrader.
don't ask server if we have entire file in partial/2016-04-25T13:35:52ZDavid Kalnischkiesdavid@kalnischkies.de2016-04-07T15:48:17Zurn: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.
silently skip acquire of empty index files2016-04-14T19:56:01ZDavid Kalnischkiesdavid@kalnischkies.de2016-04-14T15:32:17Zurn:sha1:b2fd852459a6b9234255644730f48f071ccad64d
There is just no point in taking the time to acquire empty files –
especially as it will be tiny non-empty compressed files usually.
properly check for "all good sigs are weak"2016-03-21T21:47:17ZDavid Kalnischkiesdavid@kalnischkies.de2016-03-21T17:47:10Zurn:sha1:8fa99570816d3a644a9c4386c6a8f2ca21480329
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
tests: reenable basic auth test and add @ in username2016-03-19T08:48:44ZDavid Kalnischkiesdavid@kalnischkies.de2016-03-18T10:37:31Zurn:sha1:28b2efcb190edd97b802ac9055eaf417f141f724
On launchpad #1558484 a user reports that @ in the authentication tokens
parsing of sources.list isn't working in an older (precise) version. It
isn't the recommended way of specifying passwords and co (auth.conf is),
but we can at least test for regressions (and in this case test at all…
who was that "clever" boy disabling a test with exit……… oh, nevermind.
Git-Dch: Ignore