| Age | Commit message (Collapse) | Author |
|---|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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.
|
|
id: '': no such user
./test-bug-611729-mark-as-manual: 59: [: Illegal number:
Regression-of: 68842e1741a5005b1e3f0a07deffd737c65e3294
Gbp-Dch: Ignore
|
|
If sudo was invoked by root, SUDO_UID will be 0, and apt
will not print a Requested-By line.
|
|
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.
|
|
Now that --with-source is supported in show we can go a little further
and add the "syntactic sugar" of supporting deb-files on the commandline
directly to give users an alternative to remembering dpkg -I for deb
files & as a bonus apt also works on changes files.
Most of the code churn is actually to deal with cases probably not too
common in reality like mixing packages and deb-files on the commandline
and getting the right order for these multiple records.
Closes: 883206
|
|
|
|
The syntax is a bit awkward, but it is the same as for a package name
and introducing another syntax wouldn't really help usability, so with
apt install ./foo.deb/experimental you will get the dependencies of foo
satisfied by your default release, but if this wouldn't satisfy the
version requirements the candidate for this dependency is switched to
the version from the experimental release. The same applies for apt
build-dep ./foo.dsc/stable-backports which was the initial request.
|
|
apt install pkg/release follows versioned dependencies in the candidate
switching if the current candidate does not satisfy the dependency,
so for uniformity the same should be supported in build-dep.
|
|
Reported-By: codespell & spellintian
Gbp-Dch: Ignore
|
|
GTest has a bunch of undefined macros which causes the compiler to spit
out warnings for each one on each test file. There isn't much we can do,
so we just disable the warning for the testcases. Other warnings like
sign-promo and sign-compare we can avoid by being more explicit about
our expected integer constants being unsigned.
As we are just changing testcases, there is no user visible change which
would deserve to be noted in the changelog.
Gbp-Dch: Ignore
Reported-By: gcc-8
|
|
Still allow the older one to be used.
Closes: #897149
|
|
json-based hooks for apt cli tools
See merge request apt-team/apt!10
|
|
This allows third-party package managers like snap or flatpak
to hook in and suggest alternatives if packages could not be
found, for example.
This is still highly experimental and the protocol might change
in future versions.
|
|
pu/zstd
See merge request apt-team/apt!8
|
|
|
|
We just enabled https on changelogs.ubuntu.com, let's use it.
|
|
zstd is a compression algorithm developed by facebook. At level 19,
it is about 6% worse in size than xz -6, but decompression is multiple
times faster, saving about 40% install time, especially with eatmydata
on cloud instances.
|
|
Check that Date of Release file is not in the future
See merge request apt-team/apt!3
|
|
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.
|
|
The interesting takeaway here is perhaps that 'chmod +w' is effected by
the umask – obvious in hindsight of course. The usual setup helps with
hiding that applying that recursively on all directories (and files)
isn't correct. Ensuring files will not be stored with the wrong
permissions even if in strange umask contexts is trivial in comparison.
Fixing the test also highlighted that it wasn't bulletproof as apt will
automatically fix the permissions of the directories it works with, so
for this test we actually need to introduce a shortcut in the code.
Reported-By: Ubuntu autopkgtest CI
|
|
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
|
|
|
|
This fixes a test failure on autopkgtest.
|
|
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 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
|
|
Gbp-Dch: Ignore
|
|
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.]
|
|
The format isn't too hard to get right, but it gets funny with multiline
fields (which we don't really have yet) and its just easier to deal with
it once and for all which can be reused for more messages later.
|
|
Commit 89c4c588b275 ("fix from David Kalnischkies for the InRelease gpg
verification code (LP: #784473)") amended verification of cleartext
signatures by a check whether the file to be verified actually starts
with "-----BEGIN PGP SIGNATURE-----\n".
However cleartext signed InRelease files have been found in the wild
which use \r\n as line ending for this armor header line, presumably
generated by a Windows PGP client. Such files are incorrectly deemed
unsigned and result in the following (misleading) error:
Clearsigned file isn't valid, got 'NOSPLIT' (does the network require authentication?)
RFC 4880 specifies in 6.2 Forming ASCII Armor:
That is to say, there is always a line ending preceding the
starting five dashes, and following the ending five dashes. The
header lines, therefore, MUST start at the beginning of a line, and
MUST NOT have text other than whitespace following them on the same
line.
RFC 4880 does not seem to specify whether LF or CRLF is used as line
ending for armor headers, but CR is generally considered whitespace
(e.g. "man perlrecharclass"), hence using CRLF is legal even under
the assumption that LF must be used.
SplitClearSignedFile() is stripping whitespace (including CR) on lineend
already before matching the string, so StartsWithGPGClearTextSignature() is
adapted to use the same ignoring. As the earlier method is responsible
for what apt will end up actually parsing nowadays as signed/unsigned this
change has no implications for security.
Thanks: Lukas Wunner for detailed report & initial patch!
References: 89c4c588b275d098af33f36eeddea6fd75068342
Closes: 884922
|
|
If the cache needs to grow to make room to insert volatile files like
deb files into the cache we were remapping null-pointers making them
non-null-pointers in the process causing trouble later on.
Only the current Releasefile pointer can currently legally be a
nullpointer as volatile files have no release file they belong to, but
for safety the pointer to the current Packages file is equally guarded.
The option APT::Cache-Start can be used to workaround this problem.
Reported-By: Mattia Rizzolo on IRC
|
|
For the failure propagation testing we try to connect to a port which
isn't open – you would think that this has a rather limited set of
failure modes but it turns out that there are various ways this can
fail, so instead of trying to guess all error message we just accept
any.
Reported-By: travis-ci
Gbp-Dch: Ignore
|
|
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.
|
|
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).
|
|
LookupTag is a little helper to deal with rfc822-style strings we use in
apt e.g. to pass acquire messages around for cases in which our usual
rfc822 parser is too heavy. All the fields it had to deal with so far
were single line, but if they aren't it should really produce the right
output and not just return the first line. Error messages are a prime
candidate for becoming multiline as at the moment they are stripped of
potential newlines due to the previous insufficiency of LookupTag.
|
|
The casts are useless, but the reports show some where we can actually
improve the code by replacing them with better alternatives like
converting whatever int type into a string instead of casting to a
specific one which might in the future be too small.
Reported-By: gcc -Wuseless-cast
|
|
If we perform candidate switching in requests like "apt install foo/bar"
we should first check if the dependencies of foo from release bar are
already satisfied by what is already installed before checking if the
candidate (or switched candidate) would.
|
|
If a InRelease file fails to download with a non-404 error
we assumed there is some general problem with repository like
a webportal or your are blocked from access (wrong auth, Tor, …).
Turns out some server like S3 return 403 if a file doesn't exist.
Allowing this in general seems like a step backwards as 403 is a
reasonable response if auth failed, so failing here seems better
than letting those users run into problems.
What we can do is show our insecure warnings through and allow the
failures for insecure repos: If the repo is signed it is easy to add
an InRelease file and if not you are setup for trouble anyhow.
References: cbbf185c3c55effe47f218a07e7b1f324973a8a6
|
|
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.
|
