LLudovic Courtès wrote on 13 Jan 14:48 +0100
(address . firstname.lastname@example.org)
In the light of the “dependency confusion” attack on PyTorch¹, one might
wonder how such a thing could affect Guix. The threat model is quite
different though because the ‘guix’ channel is peer-reviewed and curated
whereas PyPI isn’t.
Yet, one way to “translate” the attack to Guix is by looking at module
name clashes, as was suggested on Mastodon².
For example, I’m the author of a channel; my packages refer to (@ (gnu
packages guile) guile-3.0), which I expect to be the “genuine” Guile
provided by the ‘guix’ channel. What happens if the user pulls in an
additional channel that also provides (gnu packages guile) with that
Nothing, because the ‘guix’ channel always comes first in the module
search path (see ‘%package-module-path’ in (gnu packages)). Good.
Now same scenario, but with references to another channel, for example
(@ (past packages boost) boost-1.68) provided by Guix-Past.
This time, if the user pulls in an additional channel that also provides
(@ (past packages boost) boost-1.68), we do not know which one is going
to take precedence. It may go unnoticed though, because
‘channel-instances->derivation’ calls ‘profile-derivation’, which uses
‘build-profile’, which calls ‘union-build’ with the default file
collision policy, which is to warn (the warning only appears in the
I think it would be best to error out if multiple channels provide