| Age | Commit message (Collapse) | Author |
|---|
|
This new field allows a repository to declare that access to
packages requires authorization. The current implementation will
set the pin to -32768 if no authorization has been provided in
the auth.conf(.d) files.
This implementation is suboptimal in two aspects:
(1) A repository should behave more like NotSource repositories
(2) We only have the host name for the repository, we cannot use
paths yet.
- We can fix those after an ABI break.
The code also adds a check to acquire-item.cc to not use the
specified repository as a download source, mimicking NotSource.
|
|
This allows disabling a repository by pinning it to 'never',
which is internally translated to a value of -32768 (or whatever
the minimum of short is).
This overrides any other pin for that repository. It can be used
to make sure certain sources are never used; for example, in
unattended-upgrades.
To prevent semantic changes to existing files, we substitute
min + 1 for every pin-priority: <min>. This is a temporary
solution, as we are waiting for an ABI break.
To add pins with that value, the special Pin-Priority
"never" may be used for now. It's unclear if that will
persist, or if the interface will change eventually.
|
|
Report keys used to sign file from gpgv method to acquire system
See merge request apt-team/apt!44
|
|
This fixes a security issue that can be exploited to inject arbritrary debs
or other files into a signed repository as followed:
(1) Server sends a redirect to somewhere%0a<headers for the apt method> (where %0a is
\n encoded)
(2) apt method decodes the redirect (because the method encodes the URLs before
sending them out), writting something like
somewhere\n
<headers>
into its output
(3) apt then uses the headers injected for validation purposes.
Regression-Of: c34ea12ad509cb34c954ed574a301c3cbede55ec
LP: #1812353
|
|
Telling the acquire system which keys caused the gpgv method to
succeed allows us for now just a casual check if the gpgv method
really executed catching bugs like CVE-2018-0501, but we will make use
of the information for better features in the following commits.
|
|
In C++17 `register` keyword was removed. Current gcc 8.1.0 produces
following warning if `-std=c++17` flag is used:
warning: ISO C++17 does not allow 'register' storage class specifier
[-Wregister]
GCC almost completely ignores `register` keyword, with rare exception of
`-O0` when additional copy from/to stack may be generated.
For simplicity of the codebase it is better to just remove this
problematic keyword where it is not strictly required.
See: http://en.cppreference.com/w/cpp/language/storage_duration
Signed-off-by: Khem Raj <raj.khem@gmail.com>
|
|
|
|
We called low-level ParseDepends without an architecture each time,
which means each call looked up the native architecture. Store the
native architecture in the class and use that when calling low-level
ParseDepends from the high-level ParseDepends().
This improves performance for a cache build from 2.7 to 2.5 seconds
for me.
Also avoid a call when stripping multiarch, as the native architecture
is passed in.
|
|
|
|
This is more than twice as fast as adler32, but could be made another
50% faster by calculating crcs for 8 byte blocks in "parallel" (without
data dependency) and then combining them. But that's complicated code.
Reference measurements for hashing the cache 100 times:
adler32=2.46s xxhash64=0.64 xxhash32=1.12
crc32c(this)=1.10 crc32c(opt)=0.44s
|
|
Set PATH=/usr/sbin:/usr/bin:/sbin:/bin when running dpkg
See merge request apt-team/apt!38
|
|
This avoids a lot of problems from local installations of
scripting languages and other stuff in /usr/local for which
maintainer scripts are not prepared.
[v3: Inherit PATH during tests, check overrides work]
[v2: Add testing]
|
|
This allows us to install matching auth files for sources.list.d
files, for example; very useful.
This converts aptmethod's authfd from one FileFd to a vector of
pointers to FileFd, as FileFd cannot be copied, and move operators
are hard.
|
|
FileFd could be copied using the default copy constructor,
which does not work, and then causes code to crash.
|
|
Use quoted tagnames in config dumps
See merge request apt-team/apt!32
|
|
Remove old derivatives
See merge request apt-team/apt!31
|
|
Tagnames in configuration can include spaces (and other nasties) e.g. in
repository-specific configuration options due to Origin/Label
potentially containing a space. The configuration file format supports
parsing quoted as well as encoded spaces, but the output generated by
apt-config and other places which might be feedback into apt via
parsing (e.g. before calling apt-key in our gpgv method) do not quote
and hence produce invalid configuration files.
Changing the default to be an encoded tagname ensures that the output of
dump can be used as a config file, but other users might not expect
this so that is technically a backward-breaking change.
|
|
No user visible change expect for some years old changelog entries,
so we don't really need to add a new one for this…
Reported-By: codespell
Gbp-Dch: Ignore
|
|
|
|
This is an inactive derivative according to the census, and all the URLs which
are part of tanglu.org are dead.
|
|
This is an inactive derivative according to the census, and all the URLs which
are part of .ultimediaos.com are dead.
|
|
Support subkeys and multiple keyrings in Signed-By options
See merge request apt-team/apt!27
|
|
Closes: #910941
|
|
Some post-invoke scripts install packages, which fails because
the environment variable is not set. This sets the variable for
all three kinds of scripts {pre,post-}invoke and pre-install-pkgs,
but we will only allow post-invoke at a later time.
Gbp-Dch: full
|
|
pkgCacheFile's destructor unlocks the system, which is confusing
if you did not open the cachefile with WithLock set. Create a private
data instance that holds the value of WithLock.
This regression was introduced in commit b2e465d6d32d2dc884f58b94acb7e35f671a87fe:
Join with aliencode
Author: jgg
Date: 2001-02-20 07:03:16 GMT
Join with aliencode
by replacing a "Lock" member that was only initialized when the lock
was taken by calls to Lock, UnLock; with the latter also taking place
if the former did not occur.
Regression-Of: b2e465d6d32d2dc884f58b94acb7e35f671a87fe
LP: #1794053
|
|
A recent change to use chronos inadvertently replaced the
difference of new usec - old usec with new sec - old usec,
which is obviously wrong.
|
|
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.
|
|
If we limit a file to be signed by a certain key it should usually
accept also being signed by any of this keys subkeys instead of
requiring each subkey to be listed explicitly. If the later is really
wanted we support now also the same syntax as gpg does with appending an
exclamation mark at the end of the fingerprint to force no mapping.
|
|
We are seeing 'processing' messages from dpkg first, so it makes sense
to translate them to "Preparing" messages instead of using "Installing"
and co to override these shortly after with the "Preparing" messages.
The difference isn't all to visible as later messages tend to linger far
longer in the display than the ealier ones, but at least in a listing it
seems more logical.
|
|
The progress reporting relies on parsing the status reports of
dpkg which used to repeat being in the same state multiple times
in the same run, but by fixing #365921 it will stop doing so.
The problem is in theory just with 'config-files' in case we do purge as
this (can) do remove + purge in one step, but we remove this also for
the unpack + configure combination althrough we handle these currently
in two independent dpkg calls.
|
|
Exiting the processing loop as soon as the dpkg process finishes might
leave status-fd lines unprocessed which wasn't much of a problem in the
past as the progress would just be slightly off, but now that we us the
information also for skipping already done tasks and generate warnings
if we didn't see all expected messages we should make sure we seem them
all. We still need to exit "early" if dpkg exited unsuccessfully/crashed
through as the (remaining) status lines we get could be incomplete.
|
|
No user-visible change as it effects mostly code comments and
not a single error message, manpage or similar.
Reported-By: codespell & spellintian
Gbp-Dch: Ignore
|
|
cppcheck reports: (error) Iterator 't' used after element has been erased.
The loop is actually fashioned to deal with this (not in the most
efficient way, but in simplest and speed isn't really a concern here)
IF this codepath had a "break" at the end… so I added one.
Note that the tests aren't failing before (and hopefully after) the
change as the undefined behavior we encounter is too stable.
Thanks: David Binderman for reporting
|
|
APT in 1.6 saw me rewriting the mirror:// transport method, which works
comparable to the decommissioned httpredir.d.o "just" that apt requests
a mirror list and performs all the redirections internally with all the
bells like parallel download and automatic fallback (more details in the
apt-transport-mirror manpage included in the 1.6 release).
The automatic fallback is the problem here: The intend is that if a file
fails to be downloaded (e.g. because the mirror is offline, broken,
out-of-sync, …) instead of erroring out the next mirror in the list is
contacted for a retry of the download.
Internally the acquire process of an InRelease file (works with the
Release/Release.gpg pair, too) happens in steps: 1) download file and 2)
verify file, both handled as URL requests passed around. Due to an
oversight the fallbacks for the first step are still active for the
second step, so that the successful download from another mirror stands
in for the failed verification… *facepalm*
Note that the attacker can not judge by the request arriving for the
InRelease file if the user is using the mirror method or not. If entire
traffic is observed Eve might be able to observe the request for
a mirror list, but that might or might not be telling if following
requests for InRelease files will be based on that list or for another
sources.list entry not using mirror (Users have also the option to have
the mirror list locally (via e.g. mirror+file://) instead of on a remote
host). If the user isn't using mirror:// for this InRelease file apt
will fail very visibly as intended.
(The mirror list needs to include at least two mirrors and to work
reliably the attacker needs to be able to MITM all mirrors in the list.
For remotely accessed mirror lists this is no limitation as the attacker
is in full control of the file in that case)
Fixed by clearing the alternatives after a step completes (and moving a pimpl
class further to the top to make that valid compilable code). mirror://
is at the moment the only method using this code infrastructure (for all
others this set is already empty) and the only method-independent user
so far is the download of deb files, but those are downloaded and
verified in a single step; so there shouldn't be much opportunity for
regression here even through a central code area is changed.
Upgrade instructions: Given all apt-based frontends are affected, even
additional restrictions like signed-by are bypassed and the attack in
progress is hardly visible in the progress reporting of an update
operation (the InRelease file is marked "Ign", but no fallback to
"Release/Release.gpg" is happening) and leaves no trace (expect files
downloaded from the attackers repository of course) the best course of
action might be to change the sources.list to not use the mirror family
of transports ({tor+,…}mirror{,+{http{,s},file,…}}) until a fixed
version of the src:apt packages are installed.
Regression-Of: 355e1aceac1dd05c4c7daf3420b09bd860fd169d,
57fa854e4cdb060e87ca265abd5a83364f9fa681
LP: #1787752
|
|
We forgot to set the variable for the selection changes. Let's
set it for that and some other dpkg calls.
Regression-Of: c2c8b4787b0882234ba2772ec7513afbf97b563a
|
|
The dpkg frontend lock is a lock dpkg tries to acquire
except if the frontend already acquires it.
This fixes a race condition in the install command where the
dpkg lock is not held for a short period of time between
different dpkg invocations.
For this reason we also define an environment variable
DPKG_FRONTEND_LOCKED for dpkg invocations so dpkg knows
not to try to acquire the frontend lock because it's held
by a parent process.
We can set DPKG_FRONTEND_LOCKED only if the frontend lock
really is held; that is, if our lock count is greater than 0
- otherwise an apt client not using the LockInner family of
functions would run dpkg without the frontend lock set, but
with DPKG_FRONTEND_LOCKED set. Such a process has a weaker
guarantee: Because dpkg would not lock the frontend lock
either, the process is prone to the existing races, and,
more importantly, so is a new style process.
Closes: #869546
[fixups: fix error messages, add public IsLocked() method, and
make {Un,}LockInner return an error on !debSystem]
|
|
The random_device fails if not enough entropy is available. We do
not need high-quality entropy here, though, so let's switch to a
seed based on the current time in nanoseconds, XORed with the PID.
|
|
debSystem uses a reference counted lock, so you can acquire it
multiple times in your applications, possibly nested. Nesting
locks causes a fd leak, though, as we only increment the lock
count when we already have locked twice, rather than once, and
hence when we call lock the second time, instead of increasing
the lock count, we open another lock fd.
This fixes the code to check if we have locked at all (> 0).
There is no practical problem here aside from the fd leak, as
closing the new fd releases the lock on the old one due to the
weird semantics of fcntl locks.
|
|
Clock changes while apt is running can result in strange reports
confusing (and amusing) users. Sadly, to keep the ABI for now the
code is a bit more ugly than it would need to be.
|
|
Commit d7c92411dc1f4c6be098d1425f9c1c075e0c2154 introduced a warning for
non-existent files from components not mentioned in Components to hint
users at a mispelling or the disappearance of a component.
The debian-installer subcomponent isn't actively advertised in the
Release file through, so if apt ends up in acquiring a file which
doesn't exist for this component (like Translation files) apt would
produce a warning:
W: Skipping acquire of configured file
'main/debian-installer/i18n/Translation-en' as repository
'http://deb.debian.org/debian buster InRelease' doesn't have the
component 'main/debian-installer' (component misspelt in sources.list?)
We prevent this in the future by checking if any file exists from this
component which results in the warning to be produced still for the
intended cases and silence it on the d-i case.
This could potentially cause the warning not to be produced in cases it
should be if some marginal file remains, but as this message is just a
hint and the setup a bit pathological lets ignore it for now.
There is also the possibility of having no file present as they would
all be 0-length files and being a "hidden" component, but that would be
easy to workaround from the repository side and isn't really actively used
at the moment in the wild.
Closes: #879591
|
|
more volatile: build-dep foo.deb/release & show foo.deb
See merge request apt-team/apt!14
|
|
Don't force the same mirror for by-hash URIs
See merge request apt-team/apt!15
|
|
When running with Debug::pkgAutoRemove=yes, explain why certain packages
are being marked, either because they're marked essential/important or
because they match the blacklist from APT::NeverAutoRemove.
This should help troubleshoot cases where autoremove is not proposing
removal of packages expected to be up for removal.
Tested manually with `apt-get autoremove -o Debug::pkgAutoRemove=yes`.
|
|
Downloading from the same mirror we got a Release file from makes sense
for non-unique URIs as their content changes between mirror states, but
if we ask for an index via by-hash we can be sure that we either get the
file we wanted or a 404 for which we can perform a fallback for which
allows us to pull indexes from different mirror in parallel.
|
|
Individual items shouldn't concern themselves with these alternative
locations, we can deal with this more efficiently within the
infrastructure created for other alternative URIs now avoiding the need
to implement this in each item.
|
|
If we got a file but it produced a hash error, mismatched size or
similar we shouldn't fallback to alternative URIs as they likely result
in the same error. If we can we should instead use another mirror.
We used to be a lot stricter by stopping all trys for this file if we
got a non-404 (or a hash-based) failure, but that is too hard as we
really want to try other mirrors (if we have them) in the hope that they
have the expected and correct files.
|
|
With the advent of compressed files and especially with in-memory
post-processed files the simple assumptions made in IsOk are no longer
true. Worse, they are at best duplicates of checks performed by the
cache generation (and validation) earlier and isn't used in too many
places. It is hence best to simply get right of these calls instead of
trying to fix them.
|
|
It is easier to prepend our fields, but that results in confusion for
things working on the so generated records as they don't start with the
usual "Package" – that shouldn't be a problem in theory, but in practice
e.g. "apt-cache show" shows these records directly to the user who
will probably be more confused by it than tools.
|
|
IP addresses are by definition not a domain so in the best case the
requests will just fail; we can do better than that on our own.
|
|
Prompted-by: Jakub Wilk <jwilk@debian.org>
|
