Mitigating "dependency confusion" attacks on Guix users

[Ryan Prior <ryanprior@hey.com>]

[-- Attachment #1: Type: text/plain, Size: 1739 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 4087 bytes --]