On Wed, Feb 10, 2021 at 07:51:23AM +0000, Christopher Baines wrote:
> 
> 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.

perhaps with module-set! ? Is that the one that lets you redefine a
package in a different module, from, say, your os-config?

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted