| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
The rest of our code uses return-code errors and it isn't that nice to
crash the rred method on bad patches anyway, so we move to properly
reporting errors in our usual way which incidently also helps writing
a fuzzer for it.
This is not really security relevant though as the patches passed hash
verification while they were downloaded, so an attacker has to overtake a
trusted repository first which gives plenty better options of attack.
|
|
|
|
|
|
|
|
|
| |
The undefined behaviour sanitizer complains with:
runtime error: addition of unsigned offset to 0x… overflowed to 0x…
Compilers and runtime do the right thing in any case and it is a
codepath that can (and ideally should) be avoided for speed reasons
alone, but fixing it can't hurt (too much).
|
|
|
|
|
|
|
| |
Our configuration files are not security relevant, but having a parser
which avoids crashing on them even if they are seriously messed up is
not a bad idea anyway. It is also a good opportunity to brush up the
code a bit avoiding a few small string copies with our string_view.
|
|
|
|
|
|
|
| |
strtoul(l) surprises us with parsing negative values which should not
exist in the places we use to parse them, so we can just downright
refuse them rather than trying to work with them by having them promoted
to huge positive values.
|
|
|
|
|
|
| |
It isn't super likely that we will encounter such big words in the real
world, but we can return arbitrary length, so lets just do that as that
also means we don't have to work with a second buffer.
|
|
|
|
|
|
| |
This has no attack surface though as the loop is to end very soon anyhow
and the method only used while reading CD-ROM mountpoints which seems
like a very unlikely attack vector…
|
|
|
|
|
|
|
| |
For \xff and friends with the highest bit set and hence being a negative
value on signed char systems the wrong encoding is produced as we run
into undefined behaviour accessing negative array indexes.
We can avoid this problem simply by using an unsigned data type.
|
|
|
|
|
|
|
|
| |
If the Configuration code calling this was any indication, it is hard to
use – and even that monster still caused heap-buffer-overflow errors,
so instead of trying to fix it, lets just use methods which are far
easier to use. The question why this is done at all remains, but is left
for another day as an exercise for the reader.
|
|
|
|
|
| |
References: 2497198e9599a6a8d4d0ad08627bcfc7ea49c644
Gbp-Dch: Ignore
|
|
|
|
|
|
| |
We were printing an error and hence have non-zero exit code either way,
but API wise it makes sense to have this properly reported back to the
caller to propagate it down the chain e.g. while parsing #include stanzas.
|
|
|
|
|
| |
We do this once (usually), so the leak is tremendously big, but it is
detected as a leak by the fuzzer and trips it up.
|
|
|
|
|
| |
References: 1460eebf2abe913df964e031eff081a57f043697
Gbp-Dch: Ignore
|
|
|
|
|
|
|
|
|
|
|
| |
Explicitly opening a tar member is a bit harder than it needs to be as
you have to remove the compressor extension so that it can be guessed
here gain potentially choosing the wrong member.
Doesn't really matter for deb packages of course as the member count is
pretty low and strongly defined, but testing is easier this way.
It also finally fixes an incorrectly formatted error message.
|
|
|
|
|
|
|
|
|
|
|
|
| |
The buffers we feed in and read out are usually a couple kilobytes big
so allowing lzma to use an unlimited amount of memory is easy & okay,
but not needed and confuses memory checkers as it will cause lzma to
malloc a huge chunk of memory (which it will never use).
So lets just use a "big enough" value instead.
In exchange we simplify the decoder calling as we were already using the
auto-variant for xz, so we can just avoid the if-else and let liblzma
decide what it decodes.
|
|\
| |
| |
| |
| | |
Include all translations when building the cache
See merge request apt-team/apt!156
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We do download all translations we ever downloaded, but we don't add all
of those to the cache, meaning that if we run update with LANG=C, it
might still download your de_DE translation, but it won't insert it into
the cache, causing your de_DE user to not get translated messages.
LP: #1907850
|
|\ \
| | |
| | |
| | |
| | | |
vendor: Adjust Debian -security codename
See merge request apt-team/apt!155
|
|/ /
| |
| |
| | |
Signed-off-by: Wolfgang Schweer <wschweer@arcor.de>
|
|\ \
| | |
| | |
| | |
| | | |
Fix apt-acquire-additional-files entity's location.
See merge request apt-team/apt!154
|
|/ / |
|
|\ \
| | |
| | |
| | |
| | | |
fix passing readonly /dev/null fd as stdout/stderr
See merge request apt-team/apt!153
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The read-only /dev/null was duplicated to stdout and stderr, causing writes to those descriptors to fail:
[pid 260] openat(AT_FDCWD, "/dev/null", O_RDONLY) = 7
[pid 260] dup2(7, 0) = 0
[pid 260] close(5) = 0
[pid 260] dup2(6, 1) = 1
[pid 260] dup2(7, 2) = 2
[pid 260] write(2, "Chrooting into ", 15) = -1 EBADF (Bad file descriptor)
[pid 260] chroot("/chroot/") = 0
|
|/
|
|
| |
Closes: #979848
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Assigning the result of AllocateInMap directly to Ver->d caused Ver->d
to be resolved first, and hence if Ver was remapped during the
AllocateInMap, we were trying to assign to the old value.
Closes: #980037
|
| |
|
|\
| |
| |
| |
| | |
Misc fixes
See merge request apt-team/apt!152
|
| |
| |
| |
| |
| |
| |
| | |
We interpreted "cannot detect chroot" as "not a chroot", but it's
arguably the better idea to detect it as a chroot, to avoid new behavior
from phased updations in situations where it's unclear (no /proc mounted
or stuff).
|
|/
|
|
|
| |
In case we did not find any kernels to protect, the regular expression
will be empty, and trying to substr(1) it will fail.
|
|
|
|
| |
Closes: #979725
|
| |
|
|
|
|
|
|
|
| |
No idea why we don't have manual page syntax check (what prepare-release
post-build does) in CI. Should fix that eventually.
Gbp-Dch: ignore
|
|\
| |
| |
| |
| | |
Pu/small fixes
See merge request apt-team/apt!151
|
| |
| |
| |
| | |
Gbp-Dch: ignore
|
| |
| |
| |
| | |
Gbp-Dch: ignore
|
|\ \
| |/
|/|
| |
| | |
Implement update --error-on=any
See merge request apt-team/apt!150
|
|/
|
|
|
|
|
|
|
|
|
| |
People have been asking for a feature to error out on transient network
errors for a while, this gives them one while keeping the door open for
other modes we need, such as --error-on=no-success which we need to
determine when to retry the daily update job.
Closes: #594813
(and a whole bunch of duplicates...)
|
|\
| |
| |
| |
| | |
Add support for Phased-Update-Percentage
See merge request apt-team/apt!129
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If we have different binNMU versions on different architectures,
we don't want madness to ensue.
This is a change from how update-manager does things, as Ubuntu does not
have binNMUs, but I believe it's the right thing to do for a generic
solution.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds support for Phased-Update-Percentage by pinning
upgrades that are not to be installed down to 1.
The output of policy has been changed to add the level of
phasing, and documentation has been improved to document
how phased updates work.
The patch detects if it is running in a chroot, and if so, always
includes phased updates, restoring classic apt behavior to avoid
behavioral changes on buildd chroots.
Various options are added to control this all:
* APT::Get::{Always,Never}-Include-Phased-Updates and their legacy
update-manager equivalents to always or never include phased updates
* APT::Machine-ID can be set to a UUID string to have all machines in a
fleet phase the same
* Dir::Etc::Machine-ID is weird in that it's default is sort of like
../machine-id, but not really, as ../machine-id would look up
$PWD/../machine-id and not relative to Dir::Etc; but it allows you to
override the path to machine-id (as opposed to the value)
* Dir::Bin::ischroot is the path to the ischroot(1) binary which is used
to detect whether we are running in a chroot.
|
|\
| |
| |
| |
| | |
Only autoremove kernels in apt(8); respect --no-auto-remove
See merge request apt-team/apt!149
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Automatically removing kernels in apt-get could be unexpected, so limit
it to apt for now. To handle --no-auto-remove correctly, rewrite the
hack that makes apt ignore APT::Get::AutomaticRemove options from config
files such that it unsets the option.
This then means we can do FindB("APT::Get::AutomaticRemove", true) as the
default for APT::Get::AutomaticRemove::Kernels and get the behavior we
want: If you set --no-auto-remove, it is respected as that FindB returns
false; if you don't set it, it will be true.
|
|\ \
| |/
|/|
| |
| | |
Make immediate configuration optional
See merge request apt-team/apt!148
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The benefits of immediate configuration are that Essential packages
will be configured immediately, so if they are wrongly not working
without being configured they won't fail later packages.
However, we've reached the point where dependencies on the essential set
are too complex for immediate configuration to always work, causing
installations to error out at the end, despite having succeeded, because
we did not correctly return the error here and did not check for pending
errors before running dpkg.
Given that we check and configure any packages at the end that have not
been configured yet, or fail if we can't configure them; making
immediate configuration optional is the best way forward - it orders as
it does now, but then does not spuriously fail after having successfully
installed everything.
Closes: #973305, #188161, #211075, #649588
LP: #1871268
|
|\|
| |
| |
| |
| | |
Bump codenames to bullseye/hirsute and adjust -security codename
See merge request apt-team/apt!147
|
| |
| |
| |
| | |
Closes: #969932
|
|\ \
| |/
|/|
| |
| | |
?depends patterns and friends
See merge request apt-team/apt!146
|
| |
| |
| |
| | |
This was easy.
|
| | |
|