Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.7.0_rc1 2018-09-11T11:08:58Z 2018-09-11T11:08:58Z David Kalnischkies david@kalnischkies.de 2018-09-10T19:34:11Z urn:sha1:329c8d5e149465003ea9007661a7af1099c75c43 We are seeing 'processing' messages from dpkg first, so it makes sense to translate them to "Preparing" messages instead of using "Installing" and co to override these shortly after with the "Preparing" messages. The difference isn't all to visible as later messages tend to linger far longer in the display than the ealier ones, but at least in a listing it seems more logical. 2018-09-11T11:08:58Z David Kalnischkies david@kalnischkies.de 2018-09-10T16:43:34Z urn:sha1:f484906eff85c8c9eadc13ce817d8857abdd08e8 The progress reporting relies on parsing the status reports of dpkg which used to repeat being in the same state multiple times in the same run, but by fixing #365921 it will stop doing so. The problem is in theory just with 'config-files' in case we do purge as this (can) do remove + purge in one step, but we remove this also for the unpack + configure combination althrough we handle these currently in two independent dpkg calls. 2018-09-11T11:08:58Z David Kalnischkies david@kalnischkies.de 2018-09-09T17:45:42Z urn:sha1:2295de2c97e6d1290a86e0b160885212411510a5 Exiting the processing loop as soon as the dpkg process finishes might leave status-fd lines unprocessed which wasn't much of a problem in the past as the progress would just be slightly off, but now that we us the information also for skipping already done tasks and generate warnings if we didn't see all expected messages we should make sure we seem them all. We still need to exit "early" if dpkg exited unsuccessfully/crashed through as the (remaining) status lines we get could be incomplete. 2018-08-29T15:51:43Z David Kalnischkies david@kalnischkies.de 2018-08-29T15:01:25Z urn:sha1:c4862d49bbc30c37f4fca966ac515692e26d93be No user-visible change as it effects mostly code comments and not a single error message, manpage or similar. Reported-By: codespell & spellintian Gbp-Dch: Ignore 2018-08-29T15:50:31Z David Kalnischkies david@kalnischkies.de 2018-08-22T07:54:07Z urn:sha1:55585d0f93de1a0e60858e594b1b3b46f4a0831f cppcheck reports: (error) Iterator 't' used after element has been erased. The loop is actually fashioned to deal with this (not in the most efficient way, but in simplest and speed isn't really a concern here) IF this codepath had a "break" at the end… so I added one. Note that the tests aren't failing before (and hopefully after) the change as the undefined behavior we encounter is too stable. Thanks: David Binderman for reporting 2018-08-20T16:29:16Z David Kalnischkies david@kalnischkies.de 2018-08-18T15:32:04Z urn:sha1:29658a3a74af49e2a24e17bdebb20e1612aac3ec APT in 1.6 saw me rewriting the mirror:// transport method, which works comparable to the decommissioned httpredir.d.o "just" that apt requests a mirror list and performs all the redirections internally with all the bells like parallel download and automatic fallback (more details in the apt-transport-mirror manpage included in the 1.6 release). The automatic fallback is the problem here: The intend is that if a file fails to be downloaded (e.g. because the mirror is offline, broken, out-of-sync, …) instead of erroring out the next mirror in the list is contacted for a retry of the download. Internally the acquire process of an InRelease file (works with the Release/Release.gpg pair, too) happens in steps: 1) download file and 2) verify file, both handled as URL requests passed around. Due to an oversight the fallbacks for the first step are still active for the second step, so that the successful download from another mirror stands in for the failed verification… *facepalm* Note that the attacker can not judge by the request arriving for the InRelease file if the user is using the mirror method or not. If entire traffic is observed Eve might be able to observe the request for a mirror list, but that might or might not be telling if following requests for InRelease files will be based on that list or for another sources.list entry not using mirror (Users have also the option to have the mirror list locally (via e.g. mirror+file://) instead of on a remote host). If the user isn't using mirror:// for this InRelease file apt will fail very visibly as intended. (The mirror list needs to include at least two mirrors and to work reliably the attacker needs to be able to MITM all mirrors in the list. For remotely accessed mirror lists this is no limitation as the attacker is in full control of the file in that case) Fixed by clearing the alternatives after a step completes (and moving a pimpl class further to the top to make that valid compilable code). mirror:// is at the moment the only method using this code infrastructure (for all others this set is already empty) and the only method-independent user so far is the download of deb files, but those are downloaded and verified in a single step; so there shouldn't be much opportunity for regression here even through a central code area is changed. Upgrade instructions: Given all apt-based frontends are affected, even additional restrictions like signed-by are bypassed and the attack in progress is hardly visible in the progress reporting of an update operation (the InRelease file is marked "Ign", but no fallback to "Release/Release.gpg" is happening) and leaves no trace (expect files downloaded from the attackers repository of course) the best course of action might be to change the sources.list to not use the mirror family of transports ({tor+,…}mirror{,+{http{,s},file,…}}) until a fixed version of the src:apt packages are installed. Regression-Of: 355e1aceac1dd05c4c7daf3420b09bd860fd169d, 57fa854e4cdb060e87ca265abd5a83364f9fa681 LP: #1787752 2018-08-08T13:20:44Z Julian Andres Klode julian.klode@canonical.com 2018-08-08T13:19:20Z urn:sha1:55489885b51b02b7f74e601a393ecaefd1f71f9c We forgot to set the variable for the selection changes. Let's set it for that and some other dpkg calls. Regression-Of: c2c8b4787b0882234ba2772ec7513afbf97b563a 2018-08-07T13:07:52Z Julian Andres Klode jak@debian.org 2017-01-29T12:05:18Z urn:sha1:c2c8b4787b0882234ba2772ec7513afbf97b563a The dpkg frontend lock is a lock dpkg tries to acquire except if the frontend already acquires it. This fixes a race condition in the install command where the dpkg lock is not held for a short period of time between different dpkg invocations. For this reason we also define an environment variable DPKG_FRONTEND_LOCKED for dpkg invocations so dpkg knows not to try to acquire the frontend lock because it's held by a parent process. We can set DPKG_FRONTEND_LOCKED only if the frontend lock really is held; that is, if our lock count is greater than 0 - otherwise an apt client not using the LockInner family of functions would run dpkg without the frontend lock set, but with DPKG_FRONTEND_LOCKED set. Such a process has a weaker guarantee: Because dpkg would not lock the frontend lock either, the process is prone to the existing races, and, more importantly, so is a new style process. Closes: #869546 [fixups: fix error messages, add public IsLocked() method, and make {Un,}LockInner return an error on !debSystem] 2018-07-06T08:40:28Z Julian Andres Klode julian.klode@canonical.com 2018-07-05T15:45:40Z urn:sha1:420009e46ce7c0d97a2dc5e216ffce48dd7c0846 The random_device fails if not enough entropy is available. We do not need high-quality entropy here, though, so let's switch to a seed based on the current time in nanoseconds, XORed with the PID. 2018-06-13T21:36:08Z Julian Andres Klode julian.klode@canonical.com 2018-06-13T16:45:12Z urn:sha1:79f012bd09ae99d4c9d63dc0ac960376b5338b32 debSystem uses a reference counted lock, so you can acquire it multiple times in your applications, possibly nested. Nesting locks causes a fd leak, though, as we only increment the lock count when we already have locked twice, rather than once, and hence when we call lock the second time, instead of increasing the lock count, we open another lock fd. This fixes the code to check if we have locked at all (> 0). There is no practical problem here aside from the fd leak, as closing the new fd releases the lock on the old one due to the weird semantics of fcntl locks.