| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Provide snapshot support for offical Debian and Ubuntu archives.
There are two ways to enable snapshots for sources:
1. Add Snapshot: yes to your sources file ([snapshot=yes]). This
will allow you to specify a snapshot to use when updating or
installing using the --snapshot,-S option.
2. Add Snapshot: ID to your sources files to request a specific
snapshot for this source.
Snapshots are discovered using Label and Origin fields in the Release
file of the main source, hence you need to have updated the source at
least once before you can use snapshots.
The Release file may also declare a snapshots server to use, similar
to Changelogs, it can contain a Snapshots field with the values:
1. `Snapshots: https://example.com/@SNAPSHOTID@` where `@SNAPSHOTID@`
is a placeholder that is replaced with the requested snapshot id
2. `Snapshots: no` to disable snapshot support for this source.
Requesting snapshots for this source will result in a failure
to load the source.
The implementation adds a SHADOWED option to deb source entries,
and marks the main entry as SHADOWED when a snapshot has been
requested, which will cause it to be updated, but not included
in the generated cache.
The concern here was that we need to keep generating the shadowed
entries because the cleanup in `apt update` deletes any files not
queued for download, so we gotta keep downloading the main source.
This design is not entirely optimal, but avoids the pitfalls of
having to reimplement list cleanup.
Gaps:
- Ubuntu Pro repositories and PPAs are not yet supported.
|
| | |
|
| |
|
|
|
|
| |
This changes a lot of lines technically, but its easy enough to unfuzzy
the translations as most of the mentions are examples to be copied
literally in translations (sadly po4a isn't clever enough for this).
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Extend the Signed-By field to handle embedded public key blocks,
this allows shipping self-contained .sources files, making it
substantially easier to provide third party repositories.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
A user can specify multiple fingerprints for a while now, so its seems
counter-intuitive to support only one keyring, especially if this isn't
really checked or enforced and while unlikely mixtures of both should
work properly, too, instead of a kinda random behaviour.
|
| |
|
|
|
| |
Reported-By: codespell & spellintian
Gbp-Dch: Ignore
|
| |
|
|
| |
Closes: 679580
|
| | |
|
| |
|
|
| |
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
|