| Age | Commit message (Collapse) | Author |
|---|
|
It is an uphill battle to "reset" the environment to a clean state
without making it needlessly hard to use 'good' environment variables,
so we just try a little harder here without really trying for
completeness.
Gbp-Dch: Ignore
|
|
Reported-By: Guillem Jover <guillem@debian.org>
Gbp-Dch: Ignore
|
|
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
|
|
Closes: #907481
|
|
|
|
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
|
|
|
|
gpgs DETAILS documentation file declares that GOODSIG could report keyid
or fingerprint since gpg2, but for the time being it is still keyid
only. Who knows if that will ever change as that feels like an interface
break with dangerous security implications, but lets be better safe than
sorry especially as the code dealing with signed-by keyids is prepared
for this already. This code is rewritten still to have them all use the
same code for this type of problem.
|
|
The 1.7 series rework of show started in
bf53f39c9a0221b670ffff74053ed36fc502d5a0 resolved the issue already,
but its always a good idea to at least bring the tests along so
that we hopeful do not regress in the future with another rewrite.
Tests: #905527
Gbp-Dch: Ignore
|
|
Reviewed-by: Mo Zhou <cdluminate@gmail.com>
Closes: #903695
|
|
If multiple threads act on requests (like if connection comes from a
webbrowser) a thread might request the supported compressors while
another thread is still working on creating the list to be stored in the
static cache variable.
As the price to pay for atomic and co seems to high for the fringe
usecase of manual usage of aptwebserver the patch just makes a call to
generate the list while still single threaded.
Gbp-Dch: Ignore
|
|
Completely pointless as it makes no difference for apt,
but copying the file to other projects becomes a lot easier.
Gbp-Dch: Ignore
|
|
|
|
We forgot to set the variable for the selection changes. Let's
set it for that and some other dpkg calls.
Regression-Of: c2c8b4787b0882234ba2772ec7513afbf97b563a
|
|
Add support for dpkg frontend lock
See merge request apt-team/apt!11
|
|
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]
|
|
Add trailing newline to output of edit-sources.
See merge request apt-team/apt!22
|
|
|
|
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.
|
|
Makes the console output cleaner.
|
|
Handle JSON hooks that just close the file/exit and fix some other errors
See merge request apt-team/apt!21
|
|
JSON hooks might disappear and the common idiom to work around hooks
disappearing is to check for the hook in the shell snippet that is
in the apt.conf file and if it does not exist, do nothing. This caused
APT to fail however, expecting it to acknowledge the handshake.
Ignoring ECONNRESET on handshakes solves the problem.
The error case, and the other error cases also did not stop execution
of the hook, causing more errors to pile up. Fix this by directly going
to the closing part of the code.
LP: #1776218
|
|
|
|
This should avoid test failures on ubuntu:bionic
|
|
Installer packages need us to be online, or they are blocking
shutdowns in the worst case :(
LP: #1723761
|
|
This ensures that we don't hang waiting for debconf.
|
|
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.
|
|
Closes: #900602
|
|
Closes: #900589
|
|
Fix/usesteadyclockforprogress
See merge request apt-team/apt!19
|
|
We want to kill everything using our temporary directory.
LP: #1773992
|
|
Using the time of day for this is slightly wrong just like it is for
progress, just less visible.
|
|
The Stats method isn't called anywhere, was partly commented out before,
but we keep updating the time for it – lets avoid this pointless busywork.
Gbp-Dch: Ignore
|
|
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
|
|
Hardcoding the IPv4 address 127.0.0.1 stops stunnel4 from also binding
on IPv6 as well which not only binds on another port but confuses our
crude port extraction by splitting on ':' with ::1.
Gbp-Dch: Ignore
|
|
Pu/timeout bad addr fixes
See merge request apt-team/apt!18
|
|
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
|
|
120s is an insanely high default time out, lower it to 30s
to make things a bit nicer.
|
|
Correctly register timed out IP addresses from a timed out
select() call as a bad address so we do not try it again.
LP: #1766542
|
|
Increase debug verbosity in `apt-get autoremove`
See merge request apt-team/apt!9
|
|
Run `apt-get autoremove -o Debug::pkgAutoRemove=yes` and confirm the
logged reason for packages to be kept is correct.
Only check for specific debug lines containing 'MarkPackage:' in order
to prevent new debug logging to break the test case.
|
|
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`.
|
|
id: '': no such user
./test-bug-611729-mark-as-manual: 59: [: Illegal number:
Regression-of: 68842e1741a5005b1e3f0a07deffd737c65e3294
Gbp-Dch: Ignore
|
|
Closes: #898886
|
|
Closes: 898797
|
|
Closes: 892792
|
|
Update .gitignore
See merge request apt-team/apt!16
|
