Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=main 2024-11-22T12:40:10Z 2024-11-22T12:40:10Z David Kalnischkies david@kalnischkies.de 2022-05-09T09:42:48Z urn:sha1:7adf8c1fa8d519b8b57292763eb7703e7d3cc580 Ideally copy and file mirrors would support by-hash as well, but its harder to setup and maintain especially if you want to cache an online mirror who has by-hash enabled. We can avoid unneeded roundtrips (in the best case) and entire cache misses (in the usual worst case) by "just" telling methods that the URI we passed it has the requested file perhaps also in other paths. This is done in pseudo-relative paths as we would otherwise need to teach redirection code to rewrite those URIs as well. A method like http can easily ignore this value and await explicit instructions to look at that file, but inspecting the path in local sources via file or copy is (comparatively) free, so we just do it immediately. If that ends up being the wrong version of the file as by-hash would have protected us from we are in this feature branch now falling back to other mirrors which are like the ones online and in support of by-hash. 2024-11-22T12:40:10Z David Kalnischkies david@kalnischkies.de 2022-04-28T14:44:13Z urn:sha1:afc7b0dbf1114f3d723ff0e1ab9d0796cd799970 In practice most of them will, but making the acquire process hang in response if they don't seems like an overly excessive response if we can just support it gracefully to reply with an error (or actually succeed in the unlikely event this URI is actually correct). 2021-09-13T14:08:52Z David Kalnischkies david@kalnischkies.de 2021-09-12T14:08:52Z urn:sha1:2b0369a5d1673d9e40f2af4db7677b040a26ee58 We allow file (and other file-based methods) URIs to either be given as file:///path or as file:/path, but in various places of the acquire system we perform string comparisons on URIs which do not handle this expecting the canonical representation produced by our URI code. That used to be hidden by us quoting and dequoting the URIs in the system, but as we don't do this anymore we have to be a bit more careful on input. Ideally we would do less of these comparisons, but for now lets be content with inserting a canonicalisation early on to prevent hangs in the acquire system. 2021-03-07T01:55:07Z David Kalnischkies david@kalnischkies.de 2021-03-06T15:11:34Z urn:sha1:2a81f98b124d8fe551b160df55db1d3bf79a77c1 The mirror method can distribute requests for files based on various metadata bits, but some – the main index files – weren't actually passing those on to the methods as advertised in the manpage. This is hidden both by mirror usually falling back to other sources which will eventually hit the right one and that if the repository does not support by-hash apt will automatically stick to the mirror which was used for the Release file. 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-02-19T14:56:09Z David Kalnischkies david@kalnischkies.de 2018-02-02T18:14:09Z urn:sha1:b3e7a16265e7c6c3b6892b9ec8a787d692ced6e6 The interesting takeaway here is perhaps that 'chmod +w' is effected by the umask – obvious in hindsight of course. The usual setup helps with hiding that applying that recursively on all directories (and files) isn't correct. Ensuring files will not be stored with the wrong permissions even if in strange umask contexts is trivial in comparison. Fixing the test also highlighted that it wasn't bulletproof as apt will automatically fix the permissions of the directories it works with, so for this test we actually need to introduce a shortcut in the code. Reported-By: Ubuntu autopkgtest CI 2018-02-19T13:41:31Z Julian Andres Klode julian.klode@canonical.com 2018-02-19T13:41:31Z urn:sha1:bda3bce0197fe64819626f9ab116f72f80ce63c5 This fixes a test failure on autopkgtest. 2018-01-19T20:55:39Z David Kalnischkies david@kalnischkies.de 2018-01-19T01:20:40Z urn:sha1:38d444af2632219ab399dabadaaefaa4dcdd6ebf apt 1.6~alpha6 introduced aux requests to revamp the implementation of a-t-mirror. This already included the potential of running as non-root, but the detection wasn't complete resulting in errors or could produce spurious warnings along the way if the directory didn't exist yet. References: ef9677831f62a1554a888ebc7b162517d7881116 Closes: 887624 2018-01-03T18:42:45Z David Kalnischkies david@kalnischkies.de 2017-11-18T13:21:14Z urn:sha1:8aadb98849ba2555f4596042c888da451d965dfd Gbp-Dch: Ignore