Hi, On Fri, 15 Oct 2021 at 20:54, Ludovic Courtès <ludovic.cour...@inria.fr> wrote:
> --8<---------------cut here---------------start------------->8--- > $ guix build -f /tmp/content-addressed.scm -S --check > La jena derivaĵo estos konstruata: > /gnu/store/nq2jdzbv3nh9b1mglan54dcpfz4l7bli-sed-4.8.tar.gz.drv > building /gnu/store/nq2jdzbv3nh9b1mglan54dcpfz4l7bli-sed-4.8.tar.gz.drv... > > Starting download of > /gnu/store/1mlpazwwa2mi35v7jab5552lm3ssvn6r-sed-4.8.tar.gz > From https://ftpmirror.gnu.org/gnu/zed/sed-4.8.tar.gz... > following redirection to > `https://mirror.cyberbits.eu/gnu/zed/sed-4.8.tar.gz'... > download failed "https://mirror.cyberbits.eu/gnu/zed/sed-4.8.tar.gz" 404 "Not > Found" > > [...] > > Starting download of > /gnu/store/1mlpazwwa2mi35v7jab5552lm3ssvn6r-sed-4.8.tar.gz > From > https://archive.softwareheritage.org/api/1/content/sha256:58e6751c41a7c25bfc6e9363a41786cff3ba5709cf11d5ad903cf7cce31cc3fb/raw/... > downloading from > https://archive.softwareheritage.org/api/1/content/sha256:58e6751c41a7c25bfc6e9363a41786cff3ba5709cf11d5ad903cf7cce31cc3fb/raw/ > ... > > warning: rewriting hashes in > `/gnu/store/mgais6lk92mm8n5kyx70knr11jbwgfhr-sed-4.8.tar.gz'; cross fingers > successfully built > /gnu/store/nq2jdzbv3nh9b1mglan54dcpfz4l7bli-sed-4.8.tar.gz.drv > --8<---------------cut here---------------end--------------->8--- The message can be even more “spottable” than the URL ’archive.softwareheritage.org’ if the vault requires a cooking. One will see «SWH vault: requested bundle cooking, waiting for completion...» or «SWH vault: retrying...». Yeah, it is hidden with the option ’v0’ but it is the user’s responsibility to check, IMHO. > It’s nothing new, it’s what I do when I want to test the download > fallbacks (see also ‘GUIX_DOWNLOAD_FALLBACK_TEST’ in commit > c4a7aa82e25503133a1bd33148d17968c899a5f5). Still, I wonder if it could > somehow be abused to have malicious packages pass review. Yes, it is nothing new. Somehow, it is an issue with any content-addressed system. Here, we need to split the issue depending on the origins: - url-fetch: the attacker has to introduce the tarballs into SWH. There is not so much means, from my understanding: SWH ingests tarballs via loaders, for instance gnu.org or sources.json or debian.org etc. Therefore the attacker has to introduce the malicious code to these platforms. - url-fetch without metadata (as your example), indeed, the reviewer could be abused; mitigated by the fact that “guix lint” spots the potential issue. - url-fetch with metadata: the attacker have to also corrupt Diasarchive-DB. Otherwise, the tarball returned by SWH will not match the checksum. - svn-fetch, hg-fetch, cvs-fetch: no attack possible, yet. - git-fetch: it is the *real* issue. Because it is easy for the attacker to introduce malicious code into SWH (create a repo on GitHub, click Save, done). Then submit a package using it as you did. It is the same case as url-fetch without metadata but easier for the attacker. It is mitigated by “guix lint”. That’s said, if I am an attacker and I would like to corrupt Guix, then I would create a fake project mimicking a complex software. For instance, Gmsh is a complex C++ scientific software. The correct URL is <https://gmsh.info> and the source at <https://gitlab.onelab.info/gmsh/gmsh>. Then, as an attacker, I buy the domain say gmsh.org and put a malicious code there. Last, I send for inclusion a package using this latter URL. The reviewer would be abused. That’s why more eyes, less issues. :-) > Also, just because a URL looks nice and is reachable doesn’t mean the > source is trustworthy either. An attacker could submit a package for an > obscure piece of software that happens to be malware. The difference > here is that the trick above would allow targeting a high-impact > package. I agree. > On the plus side, such an attack would be recorded forever in Git > history. I agree again. :-) > All in all, it’s probably not as worrisome as it first seems. However, > it’s worth keeping in mind when reviewing a package. I agree with a minor comment. From my opinion, not enough patches are going via guix-patches and are pushed directly. For instance, the «Commit policy» section says «For patches that just add a new package, and a simple one, it’s OK to commit, if you’re confident (which means you successfully built it in a chroot setup, and have done a reasonable copyright and license auditing).» And from my point of view, new packages should *always* go via guix-patches, wait 15 days, then push if no remark. It lets the time for the community to chime in. And if not, it just slows down for 2 weeks. Cheers, simon