| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This reverts commit ed94a024e14e0fdbd9ea6cabd07063da441bcc02.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This reverts commit 57a00c50b14a49ed91816e3f4467e0f2e57ee772.
|
|
Closes: 679580
|
|
|
|
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.
|
|
|
|
Allow specifying an alternative path to the InRelease file, so
you can have multiple versions of a repository, for example.
Enabling this option disables fallback to Release and Release.gpg,
so setting it to InRelease can be used to ensure that only that
will be tried.
We add two test cases: One for checking that it works, and another
for checking that the fallback does not happen.
Closes: #886745
|
|
|
|
Same reasoning as with the previous commit for http with the added
benefit of moving the hard to discover and untranslated example config
into a manpage which could be translated.
|
|
We had documentation for the http transport in our "catch-all" apt.conf
manpage, but it seems benefitial to document transports in their own
manpage instead of pushing them all into one.
|
|
The documentation said "spaces", but there is no real reason to be so
strict and only allow spaces to separate values as that only leads to
very long lines if e.g. multiple URIs are specified which are again hard
to deal with from a user PoV which the deb822 format is supposed to
avoid. It also deals with multiple consecutive spaces and strange things
like tabs users will surely end up using in the real world.
The old behviour on encountering folded lines is the generation of URIs
which end up containing all these whitespace characters which tends to
mess really bad with output and further processing.
Closes: 881875
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The CDN service deb.d.o is more reliable than the http
redirector, so switch to it for our examples.
|
|
|
|
|
|
|
|
Yes, we might still add new features to 1.3 or break some more
stuff. Stay tuned!
|
|
|
|
Quite a huge churn of new strings.
|
|
Weak had no dedicated option before and Insecure and Downgrade were both
global options, which given the effect they all have on security is
rather bad. Setting them for individual repositories only isn't great
but at least slightly better and also more consistent with other
settings for repositories.
|
|
|
|
|
|
A frontend like apt-file is only interested in a specific set of files
and selects those easily via "Created-By". If it supports two locations
for those files through it would need to select both and a user would
need to know that implementation detail for sources.list configuration.
The "Identifier" field is hence introduced which by default has the same
value as "Created-By", but can be freely configured – especially it can
be used to give two indexes the same identifier.
|
|
Users have the option since apt >= 1.1 to enforce that a Release file is
signed with specific key(s) either via keyring filename or fingerprints.
This commit adds an entry with the same name and value (except that it
doesn't accept filenames for obvious reasons) to the Release file so
that the repository owner can set a default value for this setting
effecting the *next* Release file, not the current one, which provides a
functionality similar "HTTP Public Key Pinning". The pinning is in
effect as long as the (then old) Release file is considered valid, but
it is also ignored if the Release file has no Valid-Until at all.
|
|
A keyring file can include multiple keys, so its only fair for
transitions and such to support multiple fingerprints as well.
|
|
Git-Dch: Ignore
|
|
|
|
Git-Dch: ignore
|
|
Git-Dch: Ignore
|
|
Never updating this information is wrong, updating it automatically
isn't super correct either, but it seems conventional to have it and
updating it more often than needed seems better than updating it never.
Git-Dch: Ignore
|
|
|
|
In b0d408547734100bf86781615f546487ecf390d9 I accidently removed the
documentation for Trusted and replaced it with Signed-By instead of
adding it.
Git-Dch: Ignore
|
|
This changes the semantics of the option (which is renamed too) to be a
yes/no value with the special additional value "force" as this allows
by-hash to be disabled even if the repository indicates it would be
supported and is more in line with our other yes/no options like pdiff
which disable themselves if no support can be detected.
The feature wasn't documented so far and hasn't reached a (un)stable
release yet, so changing it without trying too hard to keep
compatibility seems okay.
|
|
Git-Dch: Ignore
|
