apt/apt-pkg/contrib, branch 2.1.19Debians commandline package managerhttps://git.kalnischkies.de/apt/atom?h=2.1.192021-02-04T10:00:00ZReplace PrintStatus with SendMessage usage2021-02-04T10:00:00ZDavid Kalnischkiesdavid@kalnischkies.de2020-06-28T18:52:09Zurn:sha1:96dc40b19623621a9cc2c5541fb3adbbceb553b1
varg API is a nightmare as the symbols seems different on ever other
arch, but more importantly SendMessage does a few checks on the content
of the message and it is all outputted via C++ iostreams and not mixed
in FILE* which is handy for overriding the streams.
Avoid undefined pointer arithmetic while growing mmap2021-02-04T10:00:00ZDavid Kalnischkiesdavid@kalnischkies.de2020-06-08T15:07:43Zurn:sha1:f7e6eaf84bebac565f462e2ce48f30808cc771eb
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).
Avoid overstepping bounds in config file parsing2021-02-03T16:43:13ZDavid Kalnischkiesdavid@kalnischkies.de2021-02-03T16:40:05Zurn:sha1:c4da2ff42da55ffc38c77a9170dc151216d75962
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.
Forbid negative values in unsigned StrToNum explicitly2021-02-03T16:36:46ZDavid Kalnischkiesdavid@kalnischkies.de2020-05-13T07:07:19Zurn:sha1:e0743a85c5f5f2f83d91c305450e8ba192194cd8
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.
Remove Word size limit from ParseQuote and CWord2021-02-03T16:36:45ZDavid Kalnischkiesdavid@kalnischkies.de2020-12-03T10:12:45Zurn:sha1:6630c3e5b6af77205b043208ef15720cf270075c
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.
Don't parse \x and \0 past the end in DeEscapeString2021-02-03T16:36:45ZDavid Kalnischkiesdavid@kalnischkies.de2020-12-03T09:44:27Zurn:sha1:ed192f410da36aedf5e54bb3f967e6613ab4bb51
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…
Fix incorrect base64 encoding due to int promotion2021-02-03T16:36:45ZDavid Kalnischkiesdavid@kalnischkies.de2020-12-03T09:41:43Zurn:sha1:10f13938bbf1474451fadcd62e1c31c4b5f5b3d7
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.
Retire and deprecate _strtabexpand2021-02-03T16:36:45ZDavid Kalnischkiesdavid@kalnischkies.de2020-12-03T09:29:54Zurn:sha1:03790b071d6a97374a03af36eda5698a143300b0
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.
Fail ConfigDir reading if directory listing failed2021-02-03T16:36:45ZDavid Kalnischkiesdavid@kalnischkies.de2020-12-03T09:19:21Zurn:sha1:bb553c3884f811792a1d8021ea8396cbe1ec0b23
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.
Use 500 MB memory limit for xz/lzma decoding2021-02-02T18:56:45ZDavid Kalnischkiesdavid@kalnischkies.de2020-12-02T14:46:34Zurn:sha1:b4b5e9bf97970e0efc4a994de96066a92e3a9b8f
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.