bug-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#60782: Channels and dependency confusion


From: Ludovic Courtès
Subject: bug#60782: Channels and dependency confusion
Date: Mon, 16 Jan 2023 10:00:01 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)

Hello,

Simon Tournier <zimon.toutoune@gmail.com> skribis:

> On ven., 13 janv. 2023 at 14:48, Ludovic Courtès <ludovic.courtes@inria.fr> 
> wrote:
>
>> 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.
>
> The PyPI attack used to comprised PyTorch exploits that the PyPI index
> takes precedence and sadly PyPI is not curated.
>
>     https://github.com/pypa/pip/issues/8606
>
> Well, the assumption for a similar attack using Guix channels is that
> the user first adds the channel to their channel list.  Therefore, they
> trust what they consider able to be trust. ;-)

Right, users would have to explicitly add the offending channel to their
channel list in the first place.  (And there are many other ways channel
code could mess up with one’s machine.)

>> 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.
>
> Yes, it could be a counter-measure.  Aside the security risk, it even
> appears to me sane to error because this collision leads to an undefined
> behaviour.  And such undefined behaviour should be removed; they are
> never a good thing.

+1!

Ludo’.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]