| Age | Commit message (Collapse) | Author |
|---|
|
Turns out that pkgDepCache and pkgProblemResolver maintain two (semi)
independent sets of protected flags – except that a package if marked
protected in the pkgProblemResolver is automatically also marked in the
pkgDepCache as protected. This way the pkgProblemResolver will have as
protected only the direct user requests while pkgDepCache will
(hopefully) propagate the flag to unavoidable dependencies of these
requests nowadays. The pkgProblemResolver was only checking his own
protected flag though and based on that calls our Mark* methods usually
without checking return, leading to it believing it could e.g. remove
packages it actually can't remove as pkgDepCache will not allow it as it
is marked as protected there. Teaching it to check for the flag in the
pkgDepCache instead avoids it believing in the wrong things eventually
giving up.
The scoring is keeping the behaviour of adding the large score boost
only for the direct user requests though as there is no telling which
other sideeffects this might have if too many packages get too many
points from the get-go.
Second part of fixing #960705, now with pkgProblemResolver output which
looks more like the whole class of problem is resolved rather than a
teeny tiny edgecase it was before.
|
|
The previous commit deals with negative, now we add the positive side of
things as well which makes this a recursive endevour. As we can push the
protected flag forward only if a single solution for a dependency exists
it is easy for trees to not get it, so if resolving becomes difficult it
won't help at all.
|
|
If we propagate protected e.g. due to a user request we should also act
upon (at the moment) satisfied negative dependencies so that the
resolver knows that installing this package later is not an option.
That the problem resolver is trying bad solutions is a bug by
itself which existed before and after and should be worked on.
Closes: #960705
|
|
For positive dependencies this isn't giving much as the dependency
should already be satisfied by such a provider if its protectiveness
would help, but it doesn't hurt to check them first and for negative
dependencies it means that we check those first which are the most
likely to fail to be removed – which is a good idea.
|
|
The important change is adding IsIgnoreable() as it will deal with
self-conflicts and such, but while we are at it lets sprinkle in some
refactoring.
|
|
Reducing the scope of these helpers might allow us to move them
elsewhere and share them or it is a rather pointless exercise,
we will see where it leads us to later on.
Gbp-Dch: Ignore
|
|
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!
|
|
The variable this is read to is named Junk and that it is for usecases
like apt-ftparchive which just looks at the items metadata, so instead
of performing this hunked read for data nobody will process we just tell
our FileFd to skip ahead (Internally it might still loop over the data
depending on which compressor is involved).
|
|
With FileFd::Write we already have a helper for this situation we can
just make use of here instead of hoping for the best or rolling our own
solution here.
|
|
Our testcases had their own implementation of GetTempFile with the
feature of a temporary file with a choosen suffix. Merging this into
GetTempFile lets us drop this duplicate and hence test more our code
rather than testing our helpers for test implementation.
And then hashsums_test had another implementation… and extracttar wasn't
even trying to use a real tempfile… one GetTempFile to rule them all!
That also ensures that these tempfiles are created in a temporary
directory rather than the current directory which is a nice touch and
tries a little harder to clean up those tempfiles.
|
|
Not all filesystems implement this feature in all versions of Linux,
so this open call can fail & we have to fallback to our old method.
|
|
|
|
|
|
|
|
(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
|
|
Closes: #960186
|
|
|
|
References: https://github.com/mquinson/po4a/commit/329f472a378d42c7a33e8110e5091be61480a0fc
|
|
Upstream says it had no effect before, so it seems safe to adapt.
References: https://github.com/mquinson/po4a/commit/ac1e97305b6073ed87fa8cf0a2e32f9b1255d0f1
|
|
Also translating two related strings along the way.
References: https://github.com/Debian/apt/pull/107
|
|
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
|
|
Maintainer scripts that need to use apt-key del might as well
depend on gpg, they don't need the full gnupg suite.
|
|
People are still using apt-key add and friends, despite that not
being guaranteed to work. Let's tell them to stop doing so.
We might still want a list command at a future point, but this
needs deciding, and a blanket ban atm seems like a sensible step
until we figured that out.
|
|
|
|
We did not merge nl with the template when we updated it,
hence we have quite a bit of churn in that commit and this
one.
|
|
Reinstate * wildcards
See merge request apt-team/apt!118
|
|
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
|
|
Refactor MarkInstall fixing various or-group handling issues
See merge request apt-team/apt!117
|
|
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.
|
|
MarkDelete is not recursive as MarkInstall is and we can not conflict
with ourselves anyhow, so we can move the unavoidable deletes before
changing the state of the package in question avoiding the need for the
state update in case of conflicts we can not deal with (e.g. the package
conflicts with an explicit user request).
|
|
Should be easier to move the code bits around then and it helps in
documenting a bit what the blocks do and how they interact (or not).
|
|
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.
|
|
This fixes no bugs per se, but the idea is to delay more costly changes
and check easier things first. It e.g. inhibits the moving of the
autobit until we are sure that this MarkInstall call isn't going to
fail (e.g. because a dependency isn't satisfiable).
|
|
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.
|
|
Reported-By: gcc -Wuseless-cast
Gbp-Dch: Ignore
|
|
Reported-By: clangd
Gbp-Dch: Ignore
|
|
Closes: #956313
|
|
|
|
ubuntu: http: Add non-interactive to user agent if run by systemd
See merge request apt-team/apt!114
|
|
Include that apt is being run from a service in the user
agent, so traffic can be analysed for interactive vs
non-interactive use, and prioritised accordingly.
It looks like this now:
User-Agent: Debian APT-HTTP/1.3 (2.0.1) non-interactive
A previous version included the full service names, but this
raised some privacy concerns.
LP: #1825000
|
|
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
|
|
|
|
|
|
Closes: #955412
|
|
Closes: #955505
|
|
Closes: #955023
|
