| Age | Commit message (Collapse) | Author |
|---|
|
In the intended usecase where this serves as a hack there is no problem
with double/single quotes being present as we write it to a log file
only, but nowadays our calling of apt-key produces a temporary config
file containing this "setting" as well and suddently quoting is
important as the config file syntax is allergic to it.
So the fix is to ignore all quoting whatsoever in the input and just
quote (with singles) the option values with spaces. That gives us 99% of
the time the correct result and the 1% where the quote is an integral
element of the option … doesn't exist – or has bigger problems than a
log file not containing the quote. Same goes for newlines in values.
LP: #1672710
(cherry picked from commit 2ce15bdeac6ee93faefd4b42b57f035bef80c567)
|
|
This gets rid of warnings about .ucf-dist files
Reported-By: Axel Beckert (on IRC)
(cherry picked from commit 5094697fe4b2459ff6f706a22006d3028369f3fa)
|
|
|
|
We are including sys/statvfs.h, not statvfs.h, so make sure our
dummy in the correct spot.
(cherry picked from commit c050f4fa30ccda637f3e05edddf750b768c8590d)
|
|
-1 is not an allowed value for the file descriptor, the only
allowed non-file-descriptor value is AT_FDCWD. So use that
instead.
AT_SYMLINK_NOFOLLOW has a weird semantic: It checks whether
we have the specified access on the symbolic link. It also
is implemented only by glibc on Linux, so it's inherently
non-portable. We should just drop it.
Thanks: James Clarke for debugging these issues
Reported-by: James Clarke <jrtc27@jrtc27.com>
(cherry picked from commit 25f54c960d7a4ceca7bd3e21f87baf48d6cbc2d3)
|
|
In the case of build-dep and other commands where a file can be
passed we must make sure not to normalize the path name as that
can have odd side effects, or well, cause the operation to do
nothing.
Test for build-dep-file is adjusted to perform the vcard check
once as "vcard" and once as "VCard", thus testing that this
solves the reported bug.
We inline the std::transform() and optimize it a bit to not
write anything in the common case (package names are defined
to be lowercase, the whole transformation is just for names
that should not exist...) to counter the performance hit of
the added find() call (it's about 0.15% more instructions
than with the existing transform, but we save about 0.67%
in writes...).
Closes: #854794
(cherry picked from commit 85ee4036c68d8ecd2c973d413a17aca81380900b)
|
|
Since the introduction of by-hash, two differently named
files might have the same real URL. In our case, the files
icons-64x64.tar.gz and icons-128x128.tar.gz of empty tarballs.
APT would try to merge them and end with weird errors because
it completed the first download and enters the second stage for
decompressing and verifying. After that it would queue a new item
to copy the original file to the location, but that copy item would
be in the wrong stage, causing it to use the hashes for the
decompressed item.
Closes: #838441
(cherry picked from commit 7b78e8bef1fc9de22d826db1db9df25f97d3710c)
|
|
Just copied over from common-licenses. Seems we missed to do
that earlier.
Gbp-Dch: ignore
(cherry picked from commit 84285d17bab32a0ceafe31a5b2be61cc4f520b42)
|
|
This speeds up testing things as root, which is good, because
we usually test as user.
Gbp-Dch: ignore
(cherry picked from commit 17dadc40aefbbdd002b864edd157e4795e54fba3)
|
|
This hopefully cuts down on the test time. Optimally, we'd just have
one build job and parallize, but that requires a tty or something,
probably due to GNU parallel?
Gbp-Dch: ignore
(cherry picked from commit 9b7c71f145e51c2d655ef09fca434d02db08331d)
|
|
This fixes issues with sourceforge where the redirector includes
such a Content-Range in a 302 redirect. Since we do not really know
what file is meant in a redirect, let's just ignore it for all
responses other than 416 and 206.
Maybe we should also get rid of the other errors, and just ignore
the field in those cases as well?
LP: #1657567
(cherry picked from commit 4759a702081297bde66982efed8b2b7fd39ca27c)
|
|
rred can fail for a plentory of reasons, but its failure is usually
recoverable (Ign lines) so it shouldn't leak unrequested debug messages
to an observing user.
Closes: #850759
(cherry picked from commit 2984d7aec37e09b473c7b99f43d20622c25dc99d)
|
|
If apt renames a file to .FAILED it leaves its namespace and is never
touched again – expect since 1.1~exp4 in which "apt clean" will remove
those files. The usefulness of these files rapidly degrades if you don't
keep the update log itself (together with debug output in the best case)
through and on 99% of all system they will be kept around forever just
to collect dust over time and eat up space.
With this commit an update call will remove all FAILED files of previous
runs, so that the FAILED files you have on disk are always only the ones
related to the last apt run stopping apt from hoarding files.
Closes: 846476
(cherry picked from commit 7ca83492e802967f183babf06ab541b1b51f1703)
|
|
The mode wasn't working at all if not used together with --fix-missing
which while likely to come in pairs its legal to use standalone.
Regression-in: eb1f04dda07c2b69549ad9fd793cca0e91841b3e
(cherry picked from commit 3313eaf97c83177433478505c05815ab02f9782b)
|
|
Keeping the Fd of the cache file we have validated around to later load
it into the mmap ensures not only that we load the same file (which
wouldn't really be a problem in practice), but that this file also still
exists and wasn't deleted e.g. by a 'apt clean' call run in parallel.
(cherry picked from commit 06606f073210fe3902fe92d5ff77fa1ab621b972)
|
|
The update command acquires a lock on lists/, but at the end it will
also require the dpkg/lock while building the binary caches. That seems
rather pointless as we are only reading those files, not causing writing
in them. This can also cause problems if a package installation is
running and a background process (like cron) starts an update: If you
are "lucky" enough the update process will pick the dpkg lock in between
apt calls causing the installation process to fail.
(cherry picked from commit 0d9081598afa051409b03dbdbe5025cd7ce59ba4)
|
|
We get the archives/lock for clean – that is enough to ensure that other
apt instances aren't interfering (or are being interfered with). We
don't need to block actions involving dpkg.
(cherry picked from commit 22acd327ac39ffe3bb14b3e1f2d1f21761de13ca)
|
|
Unlikely that anyone is actually running into this, but if we asked to
not generate a cache and avoid it in the first step we shouldn't create
one implicitly anyway by displaying the statistics.
(cherry picked from commit 33f982b90a4f77be18cb82daf8c79e9c5513761c)
|
|
Interpreting a boolean as an int works just fine – it just hasn't the
intended result – it isn't a serious problem through as the disabling of
the usage of this dpkg calling style is just an "optimization"
(cherry picked from commit 4e18c2cee6da39982cc463cafbf27eab5561099f)
|
|
Again no practical difference, but for consistency a boolean option
should really be accessed via a boolean method rather than an int
especially if you happen to try setting the option to "true" …
Gbp-Dch: Ignore
(cherry picked from commit c15ba854b6736696f164e4d2c243a944e2d4006e)
|
|
This can happen e.g. for file: repositories. There is no inherent
problem with setting such values internally, but its bad style,
forbidden in the manpage and could be annoying in the future.
Gbp-Dch: Ignore
(cherry picked from commit 44ecb8c3579e5ae8828f83530e4151a0ff84d5d6)
|
|
The crude way of preparing a message to be a multiline value failed at
generation valid deb822 in case the error message ended with a new line
like the resolving errors from apt do. apt itself can parse these, but
other tools like grep-dctrl choke on it, so be nice and print valid.
Reported-By: Johannes 'josch' Schauer on IRC
(cherry picked from commit 0161280405fe5aa256dc9df6a56106dd3a1a6f38)
|
|
That was the case already for tar-only and diff-only, but in a more
confusing way and without a message while dsc "worked" before resulting
in a dpkg-source error shortly after as tar/diff files aren't available…
(cherry picked from commit 58ebb3017baf46e33a9bb2c1779d6daede27d108)
|
|
(cherry picked from commit 49b91f6903804183dbe1abb12ce1f9803a3dee5f)
|
|
Previouosly apt's bash completion was such that, given
$ mkdir xyzzz
$ touch xyzzy.deb xyzzx.two.deb
you'd get
$ apt install xyzz<tab>
xyzzx.two.deb xyzzz/
$ apt install /tmp/foo/xyzz<tab>
xyzzx.two.deb xyzzz/
this is inconsistent (xyzzx.two.deb is listed but not xyzzy.deb), but
worse than that it offered things that apt would not actually
recognise as candidates for install:
$ sudo apt install xyzzx.two.deb
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package xyzzx.two.deb
E: Couldn't find any package by glob 'xyzzx.two.deb'
E: Couldn't find any package by regex 'xyzzx.two.deb'
With this small (trival, really) change, apt's bash completion will
only offer things apt understands, and won't recquire an aditional
period in the filename to offer it:
$ apt install xyzz<tab>^C
$ # (no completions!)
$ apt install ./xyzz<tab>
xyzzx.two.deb xyzzy.deb xyzzz/
$ apt install /tmp/foo/xyzz
xyzzx.two.deb xyzzy.deb xyzzz/
fixes #28
LP: #1645815
(cherry picked from commit 6761dae5d0c372d132b0df91753120b59e30fd0e)
|
|
The documentation of APT::Periodic::Verbose doesn't match the code,
specifically level 2 should apply some things differently to level 1
but does not because it uses `-le 2` instead of `-lt 2` or `-le 1`.
Closes: 845599
(cherry picked from commit 250687865e2d27dc949b810e59b07161a4c8f762)
|
|
In ad9416611ab83f7799f2dcb4bf7f3ef30e9fe6f8 we fall back to asking the
original mirror (e.g. a redirector) if we do not get the expected
result. This works for the indexes, but patches are a different beast
and much simpler. Adding this fallback code here seems like overkill as
they are usually right along their Index file, so actually forward the
relevant settings to the patch items which fixes pdiff support combined
with a redirector and partial mirrors as in such a situation the pdiff
patches would be 404 and the complete index would be downloaded.
(cherry picked from commit 5832913a49d4f7c75527264a935cc0ce00627f1d)
|
|
(cherry picked from commit 8e7a99564dd57b0dcb7df47b43e71ccefc8e0ebe)
|
|
We try to configure all packages at the end which need to be configured,
but that also applies to packages which weren't completely installed
(e.g. maintainerscript failed) we end up removing in this interaction
instead.
APT doesn't perform this explicit configure in the end as it is using
"dpkg --configure --pending", but it does confuse the progress report
and potentially also hook scripts.
Regression-Of: 9ffbac99e52c91182ed8ff8678a994626b194e69
(cherry picked from commit bb9c5972524ac5c078fa0f0bc5674c7a0fe01fb4)
|
|
dpkg stumbles over these (#844300) and we haven't dropped 'easier'
removes to be implicit and to be scheduled by dpkg by default so far
so we shouldn't push the decision in such cases to dpkg either.
(cherry picked from commit 53f3fc59f4eb37eea57bbde53fb75f2e15af0378)
|
|
Our old idea was to look for the first package which would be "touched"
and take this as the package dpkg is talking about, but that is
incorrect in complicated situations like a package upgraded to/from
multiple M-A:same siblings installed.
As we us the progress report to decide what is still needed we have to
be reasonabily right about the package dpkg is talking about, so we jump
to quite a few loops to get it.
(cherry picked from commit 4b10240cca0dc0a4e82e42959545d2ae7e622d29)
|
|
Given that we use the progress information to skip over actions dpkg has
already done like not purging a package which was already removed and
had no config files or not acting on disappeared packages and such it is
important that apt and dpkg agree on which states the package has to
pass through.
To ensure that we keep tabs on this in the future a warning is added at
the end if apt hasn't seen all the action it was supposed to see. I
can't wait for the first bugreporters to wonder about this…
(cherry picked from commit dabe9e2482180ada77d2adda2b3c03db22059fb8)
|
|
If a package is triggered dpkg frequently issues two messages about it
causing us to make a note about it both times which messes up our
planned dpkg actions view. Adding these actions if we have nothing else
planned fixes this and should still be correct as those planned actions
will deal with the triggering just fine and we avoid strange problems
like a package triggered before its removed…
(cherry picked from commit 066d4a5bab628ef8220971bb5763ff8f3a13de07)
|
|
[Comment from commiter:] I have the feeling that the issue itself is
fixed for a while already as nowadays we have testcases involving a
webserver closing the connection on error (look for "closeOnError") and
no even remotely recent reports about it, but moving the content
clearance above the failure report is a valid change and shouldn't hurt.
Closes: #465572
(cherry picked from commit 324bb34d77a43d1be411c402b2e11f588194439a)
|
|
apt tools do not really support these other variables, but tools apt
calls might, so lets play save and clean those up as needed.
Reported-By: Paul Wise (pabs) on IRC
(cherry picked from commit e2c8c825a5470e33c25d00e07de188d0e03922c8)
|
|
We can't cleanup the environment like e.g. sudo would do as you usually
want the environment to "leak" into these helpers, but some variables
like HOME should really not have still the value of the root user – it
could confuse the helpers (USER) and HOME isn't accessible anyhow.
Closes: 842877
(cherry picked from commit 34b491e735ad47c4805e63f3b83a659b8d10262b)
|
|
A user relying on the deprecated behaviour of apt-get to accept a source
with an unknown pubkey to install a package containing the key expects
that the following 'apt-get update' causes the source to be considered
as trusted, but in case the source hadn't changed in the meantime this
wasn't happening: The source kept being untrusted until the Release file
was changed.
This only effects sources not using InRelease and only apt-get, the apt
binary downright refuses this course of actions, but it is a common way
of adding external sources.
Closes: 838779
(cherry picked from commit 84eec207be35b8c117c430296d4c212b079c00c1)
LP: #1657440
|
|
In effect this is an extension of the 6 years old commit
a8dfff90aa740889eb99d00fde5d70908d9fd88a which uses the autoremover to
remove packages again from the solution which are no longer needed to be
there. Commonly these are dependencies of packages we end up not
installed due to problem resolver decisions. Slightly less common is
the situation we deal with here: a package which we wanted to upgrade
sporting a new dependency, but ended up holding back.
The problem is that all versions of an installed reverse dependencies can
bring back a "garbage" package – we need to do this as there is
nothing inherently wrong in having garbage packages installed or upgrade
them, which itself would have garbage dependencies, so just blindly
killing all new garbage packages would prevent the upgrade (and actually
generate errors). What we should be doing is looking only at the version
we will have on the system, disregarding all old/new reverse dependencies.
Reported-By: Stuart Prescott (themill) on IRC
(cherry picked from commit 952171787a0b865c17d5c9476e272106383ae93a)
|
|
|
|
This prevents CI failures from happening in 1.3 and 1.2 and
might actually be more complete.
Gbp-Dch: ignore
(cherry picked from commit 803dabde5a4345ce83b3d2ffbd475786db9769d9)
|
|
Curl requires URLs to be urlencoded. We are however giving it
undecoded URLs. This causes it go completely nuts if there is
a space in the URI, producing requests like:
GET /a file HTTP/1.1
which the servers then interpret as a GET request for "/a" with
HTTP version "file" or some other non-sense.
This works around the issue by encoding the path component of
the URL. I'm not sure if we should encode other parts of the URL
as well, this one seems to do the trick for the actual issue at
hand.
A more correct fix is to avoid the dequoting and (re-)quoting
of URLs when a redirect occurs / a new request is sent. That's
been on the radar for probably a year or two now, but nobody
bothered implementing that yet.
LP: #1651923
(cherry picked from commit 994515e689dcc5f963f5fed58284831750a5da03)
|
|
|
|
This unit runs unattended-upgrades. If apt itself is part of the
upgrade a restart of the unit will kill unattended-upgrades. This
will lead to an inconsistent dpkg status.
Closes: #841763
Thanks: Alexandre Detiste
(cherry picked from commit e133bb5e81b10bf059b3abeab2d9e41f7206e446)
LP: #1649959
|
|
|
|
This is a follow up to the previous issue where we did not check
if getline() returned -1 due to an end of file or due to an error
like memory allocation, treating both as end of file.
Here we ensure that we also handle buffered writes correctly by
flushing the files before checking for any errors in our error
stack.
Buffered writes themselves were introduced in 1.1.9, but the
function was never called with a buffered file from inside
apt until commit 46c4043d741cb2c1d54e7f5bfaa234f1b7580f6c
which was first released with apt 1.2.10. The function is
public, though, so fixing this is a good idea anyway.
Affected: >= 1.1.9
(cherry picked from commit 6212ee84a517ed68217429022bd45c108ecf9f85)
|
|
This fixes a security issue where signatures of the
InRelease files could be circumvented in a man-in-the-middle
attack, giving attackers the ability to serve any packages
they want to a system, in turn giving them root access.
It turns out that getline() may not only return EINVAL
as stated in the documentation - it might also return
in case of an error when allocating memory.
This fix not only adds a check that reading worked
correctly, it also implicitly checks that all writes
worked by reporting any other error that occurred inside
the loop and was logged by apt.
Affected: >= 0.9.8
Reported-By: Jann Horn <jannh@google.com>
Thanks: Jann Horn, Google Project Zero for reporting the issue
LP: #1647467
(cherry picked from commit 51be550c5c38a2e1ddfc2af50a9fab73ccf78026)
|
|
|
|
Gbp-Dch: ignore
|
|
|
|
We always want to run codecov test, even if there are spurious
failures. We should really work around those failures more, though,
it is starting to annoy me.
|
