apt/test/integration/framework, branch 1.6_beta1Debians commandline package managerhttps://git.kalnischkies.de/apt/atom?h=1.6_beta12018-02-19T15:06:06ZMerge branch 'pu/not-valid-before' into 'master'2018-02-19T15:06:06ZJulian Andres Klodejak@debian.org2018-02-19T15:06:06Zurn:sha1:928ecff984be22632c27a69e072741e74491292c
Check that Date of Release file is not in the future
See merge request apt-team/apt!3Check that Date of Release file is not in the future2018-02-19T15:05:01ZJulian Andres Klodejulian.klode@canonical.com2018-01-29T15:15:41Zurn:sha1:9e5899cac1a6367e3769af52a724821880e538f6
By restricting the Date field to be in the past, an attacker cannot
just create a repository from the future that would be accepted as
a valid update for a repository.
This check can be disabled by Acquire::Check-Date set to false. This
will also disable Check-Valid-Until and any future date related checking,
if any - the option means: "my computers date cannot be trusted."
Modify the tests to allow repositories to be up to 10 hours in the
future, so we can keep using hours there to simulate time changes.
tests: set debhelper compat 10 and R³ by default2018-02-19T14:56:09ZDavid Kalnischkiesdavid@kalnischkies.de2018-01-27T01:15:35Zurn:sha1:7aaf9b2c63aa8bdd87de4c19dcf1742c686a1cc2
The testpackages hardly need debhelper at all, so any version would do,
and they build without root rights by definition, but declaring it
explicitly can't hurt and in the case of debhelper it would be sad if
our testcases break one day because the old compat level is removed.
Gbp-Dch: Ignore
allow the apt/lists/auxfiles/ directory to be missing2018-01-19T20:55:39ZDavid Kalnischkiesdavid@kalnischkies.de2018-01-19T01:20:40Zurn:sha1:38d444af2632219ab399dabadaaefaa4dcdd6ebf
apt 1.6~alpha6 introduced aux requests to revamp the implementation of
a-t-mirror. This already included the potential of running as non-root,
but the detection wasn't complete resulting in errors or could produce
spurious warnings along the way if the directory didn't exist yet.
References: ef9677831f62a1554a888ebc7b162517d7881116
Closes: 887624
allow a method to request auxiliary files2018-01-03T17:55:41ZDavid Kalnischkiesdavid@kalnischkies.de2017-08-12T14:21:13Zurn:sha1:ef9677831f62a1554a888ebc7b162517d7881116
If a method needs a file to operate like e.g. mirror needs to get a list
of mirrors before it can redirect the the actual requests to them. That
could easily be solved by moving the logic into libapt directly, but by
allowing a method to request other methods to do something we can keep
this logic contained in the method and allow e.g. also methods which
perform binary patching or similar things.
Previously they would need to implement their own acquire system inside
the existing one which in all likelyhood will not support the same
features and methods nor operate with similar security compared to what
we have already running 'above' the requesting method. That said, to
avoid methods producing conflicts with "proper" files we are downloading
a new directory is introduced to keep the auxiliary files in.
[The message magic number 351 is a tribute to the german Grundgesetz
article 35 paragraph 1 which defines that all authorities of the
state(s) help each other on request.]
implement fallback to alternative URIs for all items2017-12-13T22:56:29ZDavid Kalnischkiesdavid@kalnischkies.de2017-10-27T17:09:45Zurn:sha1:355e1aceac1dd05c4c7daf3420b09bd860fd169d
For deb files we always supported falling back from one server to the
other if one failed to download the deb, but that was hardwired in the
handling of this specific item. Moving this alongside the retry
infrastructure we can implement it for all items and allow methods to
use this as well by providing additional URIs in a redirect.
implement Acquire::Retries support for all items2017-12-13T22:56:29ZDavid Kalnischkiesdavid@kalnischkies.de2017-10-25T23:09:48Zurn:sha1:dff555d40bb9776b5b809e06527e46b15e78736c
Moving the Retry-implementation from individual items to the worker
implementation not only gives every file retry capability instead of
just a selected few but also avoids needing to implement it in each item
(incorrectly).
tests: Improve handling profiling messages on CI2017-11-22T20:35:51ZJulian Andres Klodejak@debian.org2017-11-19T15:11:33Zurn:sha1:b85851e510bdf13cef770981f76a403bc20b12da
We did not strip away profiling messages when we were diffing
from stdin (-). Just always write temporary files and strip from
them.
We also had a problem when stripping ...profiling: from a line
and the next line starts with profiling. Split the sed into two
calls so we first remove complete profiling: lines before fixing
the ...profiling: cases.
ignore unsupported key formats in apt-key2017-10-05T15:30:25ZDavid Kalnischkiesdavid@kalnischkies.de2017-08-01T13:22:09Zurn:sha1:012932793ba0ea9398a9acd80593bed8e77cfbfc
gpg2 generates keyboxes by default and users end up putting either those
or armored files into the trusted.gpg.d directory which apt tools
neither expect nor can really work with without fortifying backward
compatibility (at least under the ".gpg" extension).
A (short) discussion about how to deal with keyboxes happened in
https://lists.debian.org/deity/2017/07/msg00083.html
As the last message in that thread is this changeset lets go ahead
with it and see how it turns out.
The idea is here simply that we check the first octal of a gpg file to
have one of three accepted values. Testing on my machines has always
produced just one of these, but running into those values on invalid
files is reasonabily unlikely to not worry too much.
Closes: #876508
test: Workaround gpgv warning2017-09-09T12:00:48ZJulian Andres Klodejak@debian.org2017-09-09T12:00:11Zurn:sha1:4d4459a5548e82224aac778833625358c0801681
gpgv: WARNING: This key is not suitable for signing in --compliance=gnupg mode