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 ‘guile-3.0’ variable? 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 build log). I think it would be best to error out if multiple channels provide same-named files. Thoughts? Ludo’. ¹ https://pytorch.org/blog/compromised-nightly-dependency/ ² https://toot.aquilenet.fr/@Parnikkapore@mastodon.social/109636000975651971