Ryan Prior <ryanprior@hey.com> writes:

> 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".

I'm not sure you can escape trusting the collection of channels you're
using. Because channels are code that's expected to interact, I'm not
sure it's easy to target a single package from a specific channel, and
expect that this provides some security. A malicious channel could
simply reach out and modify the state in modules from a different
channel, which would circumvent the protection you're suggesting.