| Age | Commit message (Collapse) | Author |
|---|
|
We exit early from installing dependencies of a package only if it is
not a user request to avoid polluting the state with installs which
might not be needed (or detrimental even) for alternative choices.
We do continue with installing dependencies though if it is a user
request as it will improve error reporting for apt and can even help
aptitude not hang itself so much as we trim the problem space down for
its resolver dealing with all the easy things.
Similar things can be said about the testcase I have short-circuit
previously… keep going test, do what you should do to report errors!
|
|
|
|
(CVE-2020-3810)
When normalizing ar member names by removing trailing whitespace
and slashes, an out-out-bound read can be caused if the ar member
name consists only of such characters, because the code did not
stop at 0, but would wrap around and continue reading from the
stack, without any limit.
Add a check to abort if we reached the first character in the
name, effectively rejecting the use of names consisting just
of slashes and spaces.
Furthermore, certain error cases in arfile.cc and extracttar.cc have
included member names in the output that were not checked at all and
might hence not be nul terminated, leading to further out of bound reads.
Fixes Debian/apt#111
LP: #1878177
|
|
apt marks packages coming from the commandline among others
as protected to ensure the various resolver parts do not fiddle
with the state of these packages. aptitude (and potentially others)
do not so the state is modified (to a Keep which for uninstalled means
it is not going to be installed) due to being uninstallable before
the call fails – basically reverting at least some state changes the
call made before it realized it has to fail, which is usually a good
idea, except if users expect you to not do it.
They do set the FromUser option though which has beside controlling
autobit also gained the notion of "the user is always right" over time
and can be used for this one here as well preventing the state revert.
References: 0de399391372450d0162b5a09bfca554b2d27c3d
Reported-By: Jessica Clarke <jrtc27@debian.org> on IRC
|
|
Previously (and still in cacheset), patterns where only allowed to
start with ? or ~, which ignores the fact that a pattern might just
as well start with a negation, such a !~nfoo.
Also, we ignored the --regex flag if it looked like this, which
was somewhat bad.
Let's change this all:
* If --regex is given, arguments are always interpreted as regex
* If it is a valid package wildcard (name or * characters), then
it will be interpreted as a wildcard - this set of characters is
free from meaningful overlap with patterns.
* Otherwise, the argument is interpreted as a pattern.
For a future version, we need to adapt parsing for cacheset and
list to use a common parser, to avoid differences in their
interpretation. Likely, this code will go into the pattern parser,
such that it generates a pattern given a valid fnmatch argument
for example.
|
|
Reinstate * wildcards as they are safe to use, but do not allow any
other special characters such as ? or [].
Notably, ? would overlap with patterns, and [] might overlap with
future pattern extensions (alternative bracketing style), it's also
hard to explain.
Closes: #953531
LP: #1872200
|
|
Strange things happen if while resolving the dependencies of a package
said dependencies want to remove the package. The allow-scores test e.g.
removed the preferred alternative in favor of the last one now that they
were exclusive. In our or-group for Recommends we would "just" not
statisfy the Recommends and for Depends we engage the ProblemResolver…
|
|
In normal upgrade scenarios this is no problem as the orgroup member
will be marked for upgrade already, but on a not fully upgraded system
(or while you operate on a different target release) we would go with our
usual "first come first serve" approach which might lead us to install
another provider who comes earlier – bad if the providers conflict.
|
|
If a package is protected and has a dependency satisfied only by a single
package (or conflicts with a package) this package must be part of the
solution and so we can help later actions not exploring dead ends by
propagating the protected flag to these "pseudo-protected" packages.
An (obscure) bug this can help prevent (to some extend) is shown in
test-apt-never-markauto-sections by not causing irreversible autobit
transfers.
As a sideeffect it seems also to help our crude ShowBroken to display
slightly more helpful messages involving the packages which are actually
in conflict.
|
|
We do pretty much the same in IsInstallOk, but here we have already set
the state, so we have to unroll the state as well to sort-of replicate
the state we were in before this MarkInstall failed.
|
|
MarkInstall only looks at the first alternative in an or-group which has
a fighting chance of being satisfiable (= the package itself satisfies
the dependency, if it is installable itself is not considered).
This is "hidden" for Depends by the problem resolver who will try
another member of the or-group later, but Recommends are not a problem
for it, so for them the alternatives are never further explored.
Exploring the or-group in MarkInstall seems like the better choice for
both types as that frees the problem resolver to deal with the hard
things like package conflicts.
|
|
We reseted the candidate for installed packages back to the version
which is installed if one of the (critical) dependencies of it is not
statisfiable, but we can do the same for non-installed packages by
discarding the candidate which beside slightly helping the resolver also
improves error messages generated by apt as a sideeffect.
|
|
Recent GnuTLS 3.6.11 -> 3.6.13 update in Ubuntu broke our
test certificate, it's signed with SHA1. Regenerate with
SHA2.
openssl req -newkey rsa:2048 -x509 -sha256 -days 36500 -nodes -out apt.crt -keyout apt.key -subj "/CN=localhost/O=APT Testcases GmbH/ST=Some-State/C=DE"
cat apt.key apt.crt > test/integration/apt.pem
|
|
While merging apt-pkg and apt-inst libraries the codepath of handling
deb files in apt-pkg was adapted to use the 'old' code from apt-inst
instead of fork&exec of dpkg-deb -I. The information we get this way
forms the main part of the package stanza, but we add a few
semi-optional fields to the stanza to make it look and work more
like a stanza we got from a repository.
Just be careful with the area where these two parts touch as if,
hypothetically, we would stip all newlines around the parts,
but forget to add a newline between them later, the two lines around
the merge would stick a bit too close together forming one which could
result in fun parsing errors if this merged line was previously e.g. a
well-formed Depends line and has now extra fluff attached.
This codepath has a history with too many newlines (#802553) though,
so how likely is it really that it will some day lack one you may ask.
References: 6089a4b17c61ef30b2efc00e270b0907f51f352a
|
|
Packages from third-party sources do not always follow the established
patterns of more properly maintained archives. In that case it was a
driver package for a scanner&printer device which has only a minimum of
info attached, but also minimal non-installed packages do not include
sections, so we really shouldn't assume their availability.
|
|
This experiment did not turn out sensibly, as some servers do not
accept credentials when none are expected and fail, so you cannot
mirror such a repository.
This reverts commit c2b9b0489538fed4770515bd8853a960b13a2618.
|
|
Since we append a concrete kernel version to each pattern, and then
anchor the pattern, let's just pick any package starting with a
kernel name (linux-, kfreebsd-, gnumach-), and not worry about
linux-headers, linux-tools, etc specifically, as they'll be caught
by the generic pattern.
LP: #1607845
|
|
APT 1.9.6 introduced empty groups by making use of groups to
deduplicate package names. This is not normally a problem, but
here we assumed that every group has at least one package.
This caused a problem because automake was providing automake-1.16
while having the source package automake-1.16. So we found the
automake-1.16 group, iterated over its empty package list, trying
to store the provides (which hence never happened).
LP: #1859952
|
|
apt(8): Disable regular expressions and fnmatch
See merge request apt-team/apt!95
|
|
This is the first step. Next step will be to add warnings to
apt-get and then remove support there as well.
|
|
Commit 93f33052de84e9aeaf19c92291d043dad2665bbd restricted auth.conf
entries to only apply to https by default, but this was silent - there
was no information why http sources with auth.conf entries suddenly
started failing. Add such information, and extend test case to cover
it.
|
|
apt satisfy "" caused a segmentation fault because we were iterating
over the characters, checking if the next character was the end of
the string; when it could also be the current character.
Instead, check whether the next character is before the end of
the string, rather than identical to the end.
|
|
Pu/patterns phase2
See merge request apt-team/apt!85
|
|
This avoids downgrade attacks where an attacker could inject
Location: http://private.example/
and then (having access to raw data to private.example, for example,
by opening a port there, or sniffing network traffic) read the credentials
for the private repository.
Closes: #945911
|
|
While passing the combi Release and Release.gpg to the gpgv method for
verification the filename of Release is placed where usually Release.gpg
is assumed in the rest of the code. The "usual" cases like passing
verification and failing verification ending in an error are taking care
of this, but the code path dealing with a failed verification, but
ignoring said failure (e.g. due to trusted=yes) was not which results in
the wrong file being removed later on (in case the index happens to be
unmodified since the last update call) leading us into the abyss of
strange failures (fixed in the previous commit) were nothing should have
changed.
This is not a security issue in this form as the repository needs to fail
verification & the user forcing apt to ignore the failure and carry on
anyhow. It does show however how complicated the code and its various
interconnected paths can become.
Reported-By: Val "pinkieval" Lorentz on IRC
|
|
If we have no old Release file, but old indices we can't compare
hashsums with the new Release file and hence must request the indices
again and have to react to IMS hits if they didn't change.
We used to symlink the old index file to the partial directory, but that
usually meant that we linked an uncompressed file to a compressed file,
which not all uncompressors can deal with transparently resulting in
strange failures.
We could do without the symlink, but that would require changes in the
codepaths dealing with failure as they would rename the file to FAILED.
|
|
Skipped tests do not age very well as changes to the infrastructure go
by unnoticied. In this case we are fetching Translation files now
differently meaning only if mentioned in Release file, which broke this
test. As it makes use of LC_ALL and utf8 locales it can't really be
reenabled, but it might be able to serve as an example for others and
hence at least deserves being fixed.
Gbp-Dch: Ignore
|
|
|
|
|
|
This is pure syntactic sugar - ?narrow does not exist in the
abstract syntax.
|
|
|
|
|
|
|
|
|
|
|
|
When multiple translations of package descriptions are available,
perform search in all of them. It allows using search patterns in
any of the configured languages.
Previously, only the first available translation was searched. As
the result, patterns in e.g. English never matched packages which
had their descriptions translated into local language.
Closes: #490000
|
|
We recently made info an alias for show, but we did not change the
command-line parser to work around it.
LP: #1843812
|
|
Using --force-depends causes dpkg to continue removing packages
a package depends upon even if that package fails to be removed,
because dpkg turns off all sanity checks. So we gotta tell dpkg
to stop immediately if there's an error removing stuff.
Closes: #935910
LP: #1844634
|
|
This matches any package that does not have versions.
|
|
The ?exact-name pattern matches the name exactly, there is
no substring matching going on, or any regular expression
or fnmatch magic.
|
|
This matches all packages where at least one of the versions
is marked essential; or well, whenver apt considers a package
essential.
|
|
This matches all packages that have broken dependencies in the
installed version or the version selected for install.
|
|
These two are mutually exclusive states of installed-ness. And
?installed package is fully unpacked and configured; a ?config-files
package only has config files left.
|
|
These match packages that have no version in a repository, or
where an upgrade is available. Notably,
?and(?obsolete,?upgradable) == ?false
because an upgradable package is by definition not obsolete.
|
|
These patterns allow you to identify automatically installed
packages, as well as automatically installed packages that are
no longer reachable from the manually installed ones.
|
|
This implements the basic logic patterns:
?and ?false ?not ?or ?true
and the basic package patterns:
?architecture ?name ?x-name-fnmatch
|
|
This adds a transformation from parse tree into a CacheFilter and
connects it with cachesets and the apt list command.
|
|
Unfortunately for us, apt update with Acquire::Queue-Mode=access
does not always crash on a real system, so run the whole thing
in valgrind.
|
|
In commit 79b1a8298, QueueName() was changed, amongst other things,
to exit early when the queue mode was single access, as single
access does not need any fancy queue name. The exit became too
early though, as Config was not initialized anymore, but the
caller was relying on it.
Fix QueueName() to always initialize Config and in Enqueue()
initialize Config with a nullptr, so if this regresses it's
guaranteed to fail harder. Also add a test case - this is
very simple, but the first and only test case for access
queue mode.
Regression-Of: 79b1a82983e737e74359bc306d9edb357c5bdd46
LP: #1839714
|
|
Also in old changelogs, but nothing really user visible
like error messages or alike so barely noteworthy.
Reported-By: codespell
Gbp-Dch: Ignore
|
