guix-science
[Top][All Lists]
Advanced

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

Re: Help! I messed up guix-past


From: zimoun
Subject: Re: Help! I messed up guix-past
Date: Mon, 12 Sep 2022 18:00:36 +0200

Hi,

On sam., 10 sept. 2022 at 16:39, Ricardo Wurmus <rekado@elephly.net> wrote:

>> From my point of view, authentication of guix-past adds more burden than
>> it solves concrete issues of real problem.
>>
>> I suggest to just drop the authentication for this channel.
>
> I disagree.

Well, if we disagree here then it is rare enough to be notified.  Or
maybe we miscommunicate. :-)


> Channels are an easy way to get a lot of people to run hostile code.
> Authentication ensures that the authors of Guix Past don’t sneak in bad
> code that is then evaluated by Guix — no matter if you install packages
> from Guix Past or not.

I was meaning ’signed commit’ as authentication.

I do not see how signed commits prevent hostile code; because this
hostile code must be pushed to the Gitlab instance in the first place.

Signed commit acts as “double-authentication” for authenticating the
person responsible of the commit.  The attacker needs to control two
“channels“ of “communication”: the remote Git server and the local GPG
thing.

I agree signed commits is necessary for Guix itself or else but I am not
convinced of its interest for guix-past.

As shown elsewhere in the thread, just a channel configuration where the
introduction is not noticed and then “guix pull” is happy.

And I am not convinced that the regular scientists really take care
about these subtleties of GPG.  Obviously, that’s not an argument. ;-)

I restate that signed commits (authentication) add more burden for the
channel guix-past than it solves concrete issues.

Maybe we do not share the same point of view of this topic. :-)

Cheers,
simon



reply via email to

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