apt/apt-pkg/contrib, branch 2.1.4Debians commandline package managerhttps://git.kalnischkies.de/apt/atom?h=2.1.42020-05-18T13:55:36ZSkip reading data from tar members if nobody will look at it2020-05-18T13:55:36ZDavid Kalnischkiesdavid@kalnischkies.de2020-05-15T11:29:36Zurn:sha1:19790db8900bc9baac29cf58600152997a8ecef8
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).
Properly handle interrupted write() call in ExtractTar2020-05-18T13:55:36ZDavid Kalnischkiesdavid@kalnischkies.de2020-05-13T21:01:38Zurn:sha1:5534bb3ad346ef4435e6fd0fe326771a4bde16a1
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.
Allow prefix to be a complete filename for GetTempFile2020-05-18T13:55:36ZDavid Kalnischkiesdavid@kalnischkies.de2020-05-18T09:55:54Zurn:sha1:c470d92366d7c3c239a689f0a10d6d0d9daafbff
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.
Prefer use of O_TMPFILE in GetTempFile if available2020-05-18T13:55:36ZDavid Kalnischkiesdavid@kalnischkies.de2020-05-13T06:42:02Zurn:sha1:37cc8dcda9e97e0b9420d37bb886081fa629847d
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.
SECURITY UPDATE: Fix out of bounds read in .ar and .tar implementation (CVE-2020-3810)2020-05-12T16:55:55ZJulian Andres Klodejulian.klode@canonical.com2020-05-12T09:49:09Zurn:sha1:dceb1e49e4b8e4dadaf056be34088b415939cda6
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
Add color highlighting to E:/W:/N: prefixes2020-03-24T09:24:39ZJulian Andres Klodejulian.klode@canonical.com2020-03-10T21:26:52Zurn:sha1:768f0031930a994ecfab84ecd6478852275a98c3
This matches the definitions used by dpkg.
Closes: #953527
error: Extract operator<< into error.cc (de-inline it)2020-03-10T21:29:46ZJulian Andres Klodejulian.klode@canonical.com2020-03-10T21:24:20Zurn:sha1:b0e2c9de13ff1df2f0f1cba2ceed88c710efea3a
Extract the code, and reformat it with clang-format so we can
modify it.
Show absolute time while waiting for lock instead of %, rework message2020-03-06T12:14:37ZJulian Andres Klodejulian.klode@canonical.com2020-03-06T12:10:04Zurn:sha1:1b81f6bd13bb31e59da3f53cfdc7caab43abf887
Showing a percentage for a timeout is pretty non-standard. Rework the
progress class so it can show an absolute progress (currently hardcoded
to use seconds as a unit). If there is a timeout (aka if it's not the
maximum long long unsigned -1llu), then show the timeout, otherwise
just count up seconds, e.g.
Waiting for cache lock: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 33842 (apt)... 1/120s
or
Waiting for cache lock: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 33842 (apt)... 1s
Also improve the error message to use "Waiting for cache lock: %s" instead of "... (%s)", as having
multiple sentences inside parenthesis is super weird, as is having two closing parens.
We pass the information via _config, as that's reasonably easy and avoids
ABI hackage. It also provides an interesting debugging tool for other
kinds of progress.
GetLock: No strerror if it's just another process holding the lock2020-03-06T12:07:55ZJulian Andres Klodejulian.klode@canonical.com2020-03-06T12:07:55Zurn:sha1:68a83a64cd424385b613f58e23c03e262d840b91
This improves the locking message, getting rid of useless details. If
we have a process holding the lock, we got that because the lock is
being hold by it, so there's no point telling the people the reason
for not getting the lock is the EAGAIN error and displaying its
strerrror().
apt-pkg: default visibility to hidden2020-02-26T19:34:54ZJulian Andres Klodejulian.klode@canonical.com2019-08-13T17:15:19Zurn:sha1:db678df196ccd8f9f6fb336706cf5701d1e53aa6