| Age | Commit message (Collapse) | Author |
|---|
|
This commit potentially breaks code feeding apt an encoded URI using a
method which does not get URIs send encoded. The webserverconfig
requests in our tests are an example for this – but they only worked
before if the server was expecting a double encoding as that was what
was happening to an encoded URI: so unlikely to work as expected in
practice.
Now with the new methods we can drop this double encoding and rely on
the URI being passed properly (and without modification) between the
layers so that passing in encoded URIs should now work correctly.
|
|
We do not deal a lot with URIs which need encoding, but then we do it is
a pain that we store it decoded in the acquire system as it means we
have to decode and reencode URIs eventually which is potentially giving
us slightly different URIs.
We see that in our own testing framework while setting up redirects as
the config options are effectively double-encoded and decoded to pass
them around successfully as otherwise %2f and / in an URI are treated
the same.
This commit adds the infrastructure for methods to opt into getting URIs
send in encoded form (and returning them to us in encoded form, too) so
that we eventually do not have to touch the URIs which is how it should
be. This means though that we have to deal with methods who do not
support this yet (aka: all at the moment) for which we decode and encode
while communicating with them.
|
|
|
|
Unroll pkgCache::sHash 8 times and break up the dependency between
the iterations by expanding the calculation
H(n) = 33 * H(n-1) + c
8 times rather than performing it 8 times. This seems to yield about
a 0.4% performance improvement.
I tried unrolling 4 and 2 bytes as well, those only having 3 ifs at
the end rather than 1 small loop; but that was actually slower -
potentially the code got to large and the cache went bonkers.
I also tried unrolling 4 times instead of 8, thinking that smaller
code might yield better results overall then, but that was slower as
well.
|
|
XXH3 is faster than both our CRC32c implementation as well
as DJB hash for hash table hashing, so meh, let's switch to
it.
|
|
We now have over 100k package names, my Ubuntu system has 125k
arleady, so increase the hash table size to match, this will cost
us about a MB in cache size, but give a very nice speed up somewhere
around 3%-4% or so.
|
|
The integer overflow was detected by DonKult who added a check like this:
(std::numeric_limits<decltype(Itm.Size)>::max() - (2 * sizeof(Block)))
Which deals with the code as is, but also still is a fairly big limit,
and could become fragile if we change the code. Let's limit our file
sizes to 128 GiB, which should be sufficient for everyone.
Original comment by DonKult:
The code assumes that it can add sizeof(Block)-1 to the size of the item
later on, but if we are close to a 64bit overflow this is not possible.
Fixing this seems too complex compared to just ensuring there is enough
room left given that we will have a lot more problems the moment we will
be acting on files that large as if the item is that large, the (valid)
tar including it probably doesn't fit in 64bit either.
|
|
Like the code in arfile.cc, MemControlExtract also has buffer
overflows, in code allocating memory for parsing control files.
Specify an upper limit of 64 MiB for control files to both protect
against the Size overflowing (we allocate Size + 2 bytes), and
protect a bit against control files consisting only of zeroes.
|
|
Tarballs have long names and long link targets structured by a
special tar header with a GNU extension followed by the actual
content (padded to 512 bytes). Essentially, think of a name as
a special kind of file.
The limit of a file size in a header is 12 bytes, aka 10**12
or 1 TB. While this works OK-ish for file content that we stream
to extractors, we need to copy file names into memory, and this
opens us up to an OOM DoS attack.
Limit the file name size to 1 MiB, as libarchive does, to make
things safer.
|
|
GHSL-2020-169: This first hunk adds a check that we have more files
left to read in the file than the size of the member, ensuring that
(a) the number is not negative, which caused the crash here and (b)
ensures that we similarly avoid other issues with trying to read too
much data.
GHSL-2020-168: Long file names are encoded by a special marker in
the filename and then the real filename is part of what is normally
the data. We did not check that the length of the file name is within
the length of the member, which means that we got a overflow later
when subtracting the length from the member size to get the remaining
member size.
The file createdeb-lp1899193.cc was provided by GitHub Security Lab
and reformatted using apt coding style for inclusion in the test
case, both of these issues have an automated test case in
test/integration/test-ubuntu-bug-1899193-security-issues.
LP: #1899193
|
|
This allows patterns like ~nalpha~nbeta and ~nalpha!~nbeta to
work like they do in APT.
Also add a comment to remind readers that everything in START
should be in short too.
Cc: stable >= 2.0
|
|
The compiler does not know that the size is small and thinks we might
be doing a stack buffer overflow of the vla:
Add APT_ASSUME macro and silence -Wstringop-overflow in HexDigest()
The compiler does not know that the size of a hash is at most 512 bit,
so tell it that it is.
../apt-pkg/contrib/hashes.cc: In function ‘std::string HexDigest(gcry_md_hd_t, int)’:
../apt-pkg/contrib/hashes.cc:415:21: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
415 | Result[(Size)*2] = 0;
| ~~~~~~~~~~~~~~~~~^~~
../apt-pkg/contrib/hashes.cc:414:9: note: at offset [-9223372036854775808, 9223372036854775807] to an object with size at most 4294967295 declared here
414 | char Result[((Size)*2) + 1];
| ^~~~~~
Fix this by adding a simple assertion. This generates an extra two
instructions in the normal code path, so it's not exactly super costly.
|
|
In LP#835625, it was reported that apt did not unpack multi-arch
packages in the correct order, and dpkg did not like that. The fix
also made apt configure packages together, which is not strictly
necessary.
This turned out to cause issues now, because of dependencies on
libc6:i386 that caused immediate configuration of that to not
work.
Work around the issue by not configuring multi-arch: same packages
in lockstep if they have the immediate flag set. This will be the
pseudo-essential set, and given how essential works, we mostly need
the native arch to work correctly anyway.
LP: #1871268
Regression-Of: 30426f4822516bdd26528aa2e6d8d69c1291c8d3
|
|
We are seeing more and more installations fail due to immediate
configuration issues related to libc6. Immediate configuration is
supposed to ensure that an essential package is configured immediately,
just in case some other packages use a part of the essential package
that only works if that package is configured.
This used to be a warning, it was turned into an error in some commit I
can't remember right now, but importantly, the error missed a return,
which means that ordering completed succesfully and packages were being
installed anyway; and after all that happened successfully, we'd print
an error at the end and exit with an error code, which is not super
useful.
Revert the error back to a warning such that the behavior stays the same
but we do not fail (unless we mess up ordering which then gets caught by
a consistency check later on.
Closes: #953260
Closes: #972552
LP: #1871268
|
|
If we have errors pending, always log them with our failure
message to provide more context.
|
|
Closes: #931566
|
|
Support marking all newly installed packages as automatically installed
See merge request apt-team/apt!110
|
|
Remove master/slave terminology
See merge request apt-team/apt!124
|
|
|
|
Fully deprecate apt-key, schedule removal for Q2/2022
See merge request apt-team/apt!119
|
|
It isn't needed to iterate over all results if we will be doing nothing
anyhow as it isn't that common to have that debug option enabled.
|
|
We were traditionally adding points for some dependency types to the
real package, but we should also do it for providers of that package to
help the resolver especially if the real package is for some reason not
tagged for removal yet/anymore.
While at it we ensure that the points are only attributed once for each
package as especially with versioned provides a package can nowadays
provide another many times and would hence acquire a lot of points.
|
|
If the package providing the given solution is tagged already for
removal (or at least for "not installing") we can ignore this solution
as a possibility as it is not one, which means we can avoid exploring
the option and potentially forward the protected flag further if that
helps in reducing the possibilities to a single one.
|
|
Marking a package for removal is fine if we know that we have to remove
that package, but if we are in an alternative branch we might not go
this route in the end and hence have a package pointlessly marked for
removal which isn't questioned later on.
We check if we are allowed to remove that package to avoid working on
the positive dependencies if not, but we mark them for removal only
after all the other dependencies are successfully resolved.
In an ideal world we would let the problemResolver do its job on them,
but the resolver might decide against doing the removal exploring
another option like the next alternative, which might be a good idea,
but is not the behaviour we had before, so that is the best we can do
for now without changing the resolver drastically.
|
|
This will be mapped to Important for the time being.
|
|
M-A:foreign causes Provides to apply to all architectures and as we
wanted to avoid resolver changes for M-A those are done by explicitly
creating these provides instead of forcing the resolvers to learn about
this. The EDSP is a different beast though & we don't need this trick
here especially as it leads to needless (but harmless) duplication.
No sort+unique is done to avoid changing order (not that it should
matter, but just to be sure), but the sets should be small enough to not
make a huge difference either way.
|
|
We usually tell EDSP solvers only about architectures we are configured
to treat as native/foreign, but the system could have packages from
other architectures installed (even if very unlikely) which could
influence the solution (e.g. requiring a removal) so we make sure to
tell them.
|
|
If package is installed via an explicitly given deb file we store the
filename as a provides, so that the frontend can request the filename
and get the usual "Selected foo instead of foo.deb" message.
We do not need to trouble the EDSP solvers with that though as these
provides are not valid in various ways and we have already solved the
link between commandline and package (and version) for them.
Closes: #962741
|
|
Add option '--mark-auto' to 'apt install' that marks all newly installed
packages as automatically installed.
Signed-off-by: Nicolas Schier <nicolas@fjasle.eu>
|
|
Partial directories are created with 0700, but the parent is 0755, while
the error message would report 0700 for both… that isn't right and can
be pretty confusing.
Turns out that the messages aren't marked for translation, so no
unfuzzing is required & we just leave it as untranslated for now.
Especially as the more detailed error strings derived from errno
are translated.
Reported-By: Wakko Warner <wakko@animx.eu.org>
Closes: #962310
|
|
While we process the possible solutions we might modify other solutions
like discarding their candidates and such, so that then we reach them
they might no longer be proper candidates. We also try to drop
duplicates early on to avoid the simple cases of these which
test-explore-or-groups-in-markinstall triggers via its explicit
duplication but could also come via multiple provides.
It only worked previously as were ignoring current versions which
usually is okay expect if they are marked for removal and we want to
reinstate them so the ProblemResolver can decide which one later on.
|
|
Especially if a lot packages have to be removed due to not to explicitly
expressed conflicts the problem resolver can take a few turns to remove
them all. Allowing it to try a little longer if needed seems beneficial
as the worst which can happen is that we now take two times as long to
present an error message to the user.
|
|
For protected packages the "Fixing" done via KillList in the
ProblemResolver will usually not happen as the state change is not
allowed, so the debug message is just confusing and the resolver is
needlessly looping here (which might push it over the edge), so if we
didn't do our thing successfully here we short-circuit a bit to help the
next iteration come to a solution.
|
|
The pkgProblemResolver incorrectly skips protected packages while
considering packages for removal, which was always wrong but is now a
lot more visible as (potentially) far more packages are considered
protected in their state.
Note that the testcase shows that we need more changes to make this
proper.
|
|
We are leaking a d-pointer currently weighting a boolean in size and
MethodConfig is instantiated in small numbers only, so nobody will
actually notice a difference, but proper cleanup is important.
Reported-By: clang LeakSanitizer
References: 04ab37fecaf286f724bef2e0969d2b67ab5ac1b1
|
|
The non-virtual base-destructor causes its derivate classes to leak
tiny bits of memory otherwise. The header is private and not to be
used outside of APT, so we can perform this tiny ABI break as there
is no ABI to break.
Reported-By: valgrind and clang -fsanitize=leak
|
|
As the builtins were used in the feature test also in the default branch
clang fails to compile the test helpfully complaining that you need to
compile with sse4.2 to use that while on gcc it is optimized out as
unused code and produces only a warning for that… removing the code from
the default branch fixes this problem, but we adapt the code some more to
avoid compilers optimizing it out in the future just in case.
|
|
../apt-pkg/init.cc:137:39: warning: adding 'int' to a string does not append to the string [-Wstring-plus-int]
Cnf.CndSet("Dir::State", STATE_DIR + 1);
../apt-pkg/init.cc:137:39: note: use array indexing to silence this warning
We have a few instances of that & it should be reasonably clear that we are not
actually trying to append here, but ignoring or silencing this warning with an
override is far more costly than just using what clang suggests here.
Reported-By: clang
Gbp-Dch: Ignore
|
|
../apt-pkg/edsp.cc:861:23: error: object backing the pointer will be destroyed at the end of the full-expression [-Wdangling-gsl]
const char *arch = _config->Find("APT::Architecture").c_str();
Compilers are probably optimizing it the way the patch does by hand now. Small
string optimisation helps likely as well. Othwise that should have failed left
and right as EDSP is used by experimental and such builders to talk to aspcud.
Reported-By: clang
|
|
|
|
Gbp-Dch: Ignore
|
|
For speed reasons pkgDepCache initializes its state once and then has a
battery of update calls you have to invoke in the right order to update
the various states – all in the name of speed. In debug and/or
simulation mode we can sacrifice this speed for a bit of extra checking
though to verify that we haven't made some critical mistake like #961266.
|
|
It looks like hack and therefore I wanted this to be a very isolated
commit so we can find it & revert it easily if need be, but for now it
seems to work.
The idea is that Status is telling us how the candidate is in relation
to the current installed version which is used to figure out if a
package is "kept back" by the algorithm or not, but by discarding the
candidate version we loose this information.
Ideally we would keep better tabs on what we do to a package and why,
but for now that seems okayish. It will cause the wrong version to be
displayed though as if the package is installed the installed version
becomes the candidate and hence (installed => installed) is displayed.
|
|
If we have a negative dependency to deal with we prefer to install an
upgrade rather than remove the current version. That is why we split the
method rather explicitly in two in 57df273 but there is a case we didn't
react to: If we have seen the candidate before as a "satisfier" of this
negative dependency there is no point in trying to upgrade to it later
on. We keep that info by candidate discard if we can, but even if we
can't we can at least keep that info around locally.
This "fixes" (or would hide) the problem described in 04a020d as well as
you don't have to discard installations you never make.
|
|
For a (partially) installed package like the one MarkInstall operates on
at the moment we want to discard the candidate from, we have to first
remove the package from the internal state keeping to have proper broken
counts and such and only then reset the candidate version which is a
trivial operation in comparison.
Take a look at the testcase: Now, what is the problem? Correct,
git:i386. Didn't see that coming, right? It is M-A:foreign so apt tries
to switch the architecture of git here (which is pointless, it knows
that this won't work, but lets fix that in another commit) will
eventually realize that it can't install it and wants to discard the
candidate of git:i386 first removing the broken indication like it
should, removing the install flag and then reapplies the broken
indication: Expect it doesn't as it wants to do that over the candidate
version which the package no longer had so seemingly nothing is broken.
It is a bit of a hairball to figure out which commit it is exactly that
is wrong here as they are all influencing each other a bit, but >= 2.1
is an acceptable ballpark. Bisect says 57df273 but that is mostly a lie.
Closes: #961266
|
|
References: dcdfb4723a9969b443d1c823d735e192c731df69
|
|
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.
|
