[Top][All Lists]

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

Channel introductions

From: zimoun
Subject: Channel introductions
Date: Thu, 4 Jun 2020 20:30:38 +0200

Hi Ludo,

I move the discussion to guix-devel to avoid to pollute the bug thread
[1] already long enough. :-)

Well thank you for the explanations.  There is still something I do
not understand.  I am sorry to be slow but as I am pushing the
adoption of Guix in my lab, it is hard to explain ("sell") when I have
not well understood myself. :-)

You said:

> Nothing special, I guess: each channel would be authenticated (or not,
> if it’s an unsigned channel).  I think it’s completely orthogonal.


> >      ;; Tell 'guix pull' to use my own repo.
> >      (list (channel
> >              (name 'guix)
> >              (url "";)
> >              (branch "super-hacks")))
> Yeah, we have to keep it working.  So I guess in that case it would just
> emit a warning saying this channel is not authenticated, and that’s it.


> >> No, when publishing a fork of an authenticated channel, you’ll have to
> >> publish its introduction alongside its URL.

and so, I do not understand what happens if:

 a- the channel is unsigned
 b- the channel is signed and I want to add something to it

> >  1- an authenticated fork of an authenticated channel
> >  2- an authenticated fork of an unauthenticated channel
> >  3- an unauthenticated fork of an authenticated channel
> >  4- an unauthenticated fork of an unauthenticated channel
> >
> > "authenticated channel" means a channel using all the authentication 
> > machinery.
> > "authenticated fork" means add a "channel introduction" and so become
> > a "authenticate channel" then.
> I’m sorry, I don’t follow the terminology.

Well, I am sorry if I have not understood.  From my understanding,
today there is unsigned channels (called above unauthenticated
channels) and tomorrow some channel will be signed (called above
authenticated channel).  Then adding materials to these 2 kind of
channels can be done in 2 ways: signed or unsigned (called above,
authenticated fork and unauthenticated fork, respectively).
Therefore, this leads to 4 situations:

 1- add signed material to a signed channel
 2- introduce authentication to an unsigned channel
 3- add unsigned material to a signed channel
 4- add unsigned material to unsigned channel

Therefore, my question is what happens?  Today, I can fork any channel
and publish this fork without enter in the security dance.  Well, I
want to continue to be able to fork any channel and publish the fork
without enter in the security dance and based on your answers, I do
not understand if it will still be possible.

I understand that there is incompatible requirements but I miss what
will be the framework of channels with this trusted "guix pull".

Could '--allow-downgrades' bypass the authentication mechanism?  Since
it is the name (more descriptive than) for '--allow-anything'. ;-)
(at least with Git histories)

> > 1- the correct way
> > 2- bootstrap the trust
> > 3- and 4- quick and dirty "Scientific" workflows where the security is
> > not a concern.
> Funny how “scientific” has become synonymous with “quick-and-dirty”
> these days…

Even if 'quick-and-dirty' is often a point of view. ;-)

However, the point is that security is not a main concern for
"scientific" workflow.  The main argument of Applied Maths or
Biologists people I know is first: easy-to-use and robust.  And
security is in general not-easy and error-prone.  Anyway.

> Yet, these two issues must also be addressed in Guix, like in any other
> distro.


> I hope that makes sense.

Yes it makes sense.
I disagree on "get the latest" but who cares. :-)

Sorry again to be slow.

All the best,


reply via email to

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