Hi Guix! I've been digesting this piece, published hours ago, describing dependency confusion attacks that revealed severe vulnerabilities at many major organizations: https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610

Guix users already have a few mitigations against this sort of attack. Most importantly, no substitute servers or channels are installed by default which allow arbitrary uploads by community contributors. That feature of the affected public registries (npm, pypi, rubygems) is so convenient, but contributes to this kind of attack. This is a great motivation for people to move to Guix from those other package systems.

However, I'm still thinking about how to attack Guix users. Somebody who adds an internal channel for their own packages could still be vulnerable to a dependency confusion attack via a compromised or manipulated Guix maintainer. The target of the attack could install packages they believed would be provided by their internal channel but actually get another package provided upstream.

The degree of vulnerability increases further with each channel used, with each channel maintainer becoming another potential vector of compromise. How can we make this kind of attack even more difficult?

What comes to my mind is that we should encourage (require?) people to specify the channel name a package belongs to, if it's not the "guix" channel. So instead of referring to "python-beautifulsoup4" (ambiguous: is this from my channel or upstream Guix?) we say that "python-beautifulsoup4" always means that package from the "guix" channel and a version provided by my channel called "internal" needs to be called for explicitly, like "@internal/python-beautifulsoup4".

Cheers,
Ryan