apt/test/integration/test-releasefile-verification, branch 1.1.7Debians commandline package managerhttps://git.kalnischkies.de/apt/atom?h=1.1.72015-12-19T22:04:34Ztests: 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).
show URI.Path in all acquire item descriptions2015-06-11T08:56:31ZDavid Kalnischkiesdavid@kalnischkies.de2015-06-11T08:56:31Zurn:sha1:1da3b7b8e15b642135b54684e70a0c271471f07a
It is a rather strange sight that index items use SiteOnly which strips
the Path, while e.g. deb files are downloaded with NoUserPassword which
does not. Important to note here is that for the file transport Path is
pretty important as there is no Host which would be displayed by Site,
which always resulted in "interesting" unspecific errors for "file:".
Adding a 'middle' ground between the two which does show the Path but
potentially modifies it (it strips a pending / at the end if existing)
solves this "file:" issue, syncs the output and in the end helps to
identify which file is meant exactly in progress output and co as a
single site can have multiple repositories in different paths.
treat older Release files than we already have as an IMSHit2015-05-18T20:15:06ZDavid Kalnischkiesdavid@kalnischkies.de2015-05-18T20:15:06Zurn:sha1:6bf93605fdb8e858d3f0a79a124c1d39f760094d
Valid-Until protects us from long-living downgrade attacks, but not all
repositories have it and an attacker could still use older but still
valid files to downgrade us. While this makes it sounds like a security
improvement now, its a bit theoretical at best as an attacker with
capabilities to pull this off could just as well always keep us days
(but in the valid period) behind and always knows which state we have,
as we tell him with the If-Modified-Since header. This is also why this
is 'silently' ignored and treated as an IMSHit rather than screamed at
the user as this can at best be an annoyance for attackers.
An error here would 'regularily' be encountered by users by out-of-sync
mirrors serving a single run (e.g. load balancer) or in two consecutive
runs on the other hand, so it would just help teaching people ignore it.
That said, most of the code churn is caused by enforcing this additional
requirement. Crisscross from InRelease to Release.gpg is e.g. very
unlikely in practice, but if we would ignore it an attacker could
sidestep it this way.