guix-devel
[Top][All Lists]
Advanced

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

Re: Guix beyond 1.0: let’s have a roadmap!


From: Ludovic Courtès
Subject: Re: Guix beyond 1.0: let’s have a roadmap!
Date: Sun, 07 Jul 2019 16:09:24 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux)

Hi,

"Alex Griffin" <address@hidden> skribis:

> On Mon, Jul 1, 2019, at 10:06 AM, Ludovic Courtès wrote:
>> > ** TODO run-time configuration system for services, similar to OpenWrt's 
>> > UCI
>> 
>> What does it mean?  (I don’t know UCI.)
>
> UCI is a configuration language and tool layered on top of the underlying 
> packages. It gives a single machine-readable configuration format to 
> everything, and then uses it to generate the real config files used by 
> services. It's the thing that lets you change your router settings from the 
> OpenWrt web interface or command line.
>
> It's a lot like Guix system declarations, except service configuration 
> happens at runtime. I guess the thing I really want though is a web interface.

Giovanni Biscuolo <address@hidden> skribis:

> UCI [1] short description: «small utility written in C (a shell
> script-wrapper is available as well) and is intended to centralize the
> whole configuration of a device running OpenWrt.»
>
> How UCI works [2]:
> «Applications are made UCI-compatible by simply writing the original
> configuration file (which is read by the program) according to the
> chosen settings in the corresponding UCI file. This is done upon running
> the initialization scripts in /etc/init.d/. See Init scripts for more
> information. Thus, when starting a daemon with such a UCI-compatible
> initialization script, you should be aware that the program's original
> configuration file gets overwritten.»

Interesting!  Perhaps there are lessons to be learned from OpenWRT’s
experience building UCI and its web interface?  And also from Augeas.

>> > ** TODO support automatic GPG/signify signature verification of origin 
>> > objects
>> 
>> For users or for packagers?
>
> For packagers. If a package ships with a cryptographic signature, we could 
> commit it with the package and have Guix double check our source integrity. 
> This would be especially helpful with `guix refresh`, because I suspect not 
> everybody is as diligent about integrity checking when Guix just generates a 
> working hash for you.

Note: s/integrity/authenticity/

‘guix refresh’ automatically checks OpenPGP signatures when they exist.

However, that authenticity check is necessarily out-of-band: there’s
nothing we can commit in Guix proper regarding that check.  The good
thing is that we have complete history of all the changes made to Guix,
so anyone can at any time authenticate the source code that Guix refers
to.

Perhaps what we could do is provide users with a tool to authenticate
the source code of specific packages, pretty much like ‘guix refresh’
does.

What’s more important, though, is authenticating checkouts of Guix
itself since it’s at the root of everything:
<https://issues.guix.gnu.org/issue/22883>.

Thanks,
Ludo’.



reply via email to

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