apt/test/integration/test-releasefile-verification, branch 1.2.8Debians commandline package managerhttps://git.kalnischkies.de/apt/atom?h=1.2.82016-03-22T00:58:45Zhandle gpgv's weak-digests ERRSIG2016-03-22T00:58:45ZDavid Kalnischkiesdavid@kalnischkies.de2016-03-22T00:26:29Zurn:sha1:08b7761a251a36fa65cbe022a86c51d7f091a88d
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: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: support spaces in path and TMPDIR2015-12-19T22:04:34ZDavid Kalnischkiesdavid@kalnischkies.de2015-12-15T16:20:26Zurn:sha1:3abb6a6a1e485b3bc899b64b0a1b7dc2db25a9c2
This doesn't allow all tests to run cleanly, but it at least allows to
write tests which could run successfully in such environments.
Git-Dch: Ignore
tests: don't use hardcoded port for http and https2015-09-15T08:16:09ZDavid Kalnischkiesdavid@kalnischkies.de2015-09-14T22:33:12Zurn:sha1:6c0765c096ffb4df14169236c865bbb2b10974ae
This allows running tests in parallel.
Git-Dch: Ignore
tests: try to support spaces in TMPDIR2015-09-14T13:22:19ZDavid Kalnischkiesdavid@kalnischkies.de2015-09-14T00:26:13Zurn:sha1:63c7141275c8c5c0f6e60f5242785e50cabaf2a0
Not all tests work yet, most notable the cdrom tests, but those require
changes in libapt itself to have a proper fix and what we have fixed so
far is good enough progress for now.
Git-Dch: Ignore
fix various typos reported by codespell2015-08-27T09:27:44ZDavid Kalnischkiesdavid@kalnischkies.de2015-08-22T14:22:08Zurn:sha1:3a8776a37af38127fb04565959e8e0e449eb04a4
Reported-By: codespell
Replace --force-yes by various options starting with --allow2015-08-14T10:38:18ZJulian Andres Klodejak@debian.org2015-08-14T09:49:45Zurn:sha1:b381a482eab0fc7b65b63cf0512ef1f97d775e34
This enables more fine grained control over such exceptions.
show or-groups in not-installed recommends and suggests lists2015-08-10T15:27:18ZDavid Kalnischkiesdavid@kalnischkies.de2015-07-13T01:36:59Zurn:sha1:9112f77703c39d46e2e0471c48c8a5e1f93f4abf
Further abstracting our new ShowList allows to use it for containers of
strings as well giving us the option to implement an or-groups display
for the recommends and suggests lists which is a nice trick given that
it also helps with migrating the last remaining other cases of old
ShowList.
implement Signed-By without using gpg for verification2015-08-10T15:25:26ZDavid Kalnischkiesdavid@kalnischkies.de2015-07-07T20:11:20Zurn:sha1:4e03c47de15164f2656d9655edab6fb3570cb2f2
The previous commit returns to the possibility of using just gpgv for
verification proposes. There is one problem through: We can't enforce a
specific keyid without using gpg, but our acquire method can as it
parses gpgv output anyway, so it can deal with good signatures from not
expected signatures and treats them as unknown keys instead.
Git-Dch: Ignore
implement Signed-By option for sources.list2015-08-10T15:25:26ZDavid Kalnischkiesdavid@kalnischkies.de2015-06-24T17:31:22Zurn:sha1:b0d408547734100bf86781615f546487ecf390d9
Limits which key(s) can be used to sign a repository. Not immensely useful
from a security perspective all by itself, but if the user has
additional measures in place to confine a repository (like pinning) an
attacker who gets the key for such a repository is limited to its
potential and can't use the key to sign its attacks for an other (maybe
less limited) repository… (yes, this is as weak as it sounds, but having
the capability might come in handy for implementing other stuff later).