Re: Guix & signed archive export/import

[Ludovic Courtès]

Hi, Niels,

Thanks for the quick feedback!

address@hidden (Niels Möller) skribis:

> address@hidden (Ludovic Courtès) writes:

[...]

>> libspki/lsh supports password-protected keys, with a specific sexp
>> format, whereas libgcrypt doesn't.
>
> About this format, one known problem (if it is a problem), is that the
> entire key is encrypted. It would sometimes be better to have an
> expression which includes the public key in the clear, together with an
> encrypted private key. And I think this code is in lsh, not libspki.

OK.  I was just mentioning this example in passing; it’s not really
important for our purposes at this point.

>> So now the daemon has a SPKI-style access-control list (ACL), which
>> lists the public keys whose imports are allowed.  The ACL is stored in
>> "canonical s-expression" format, via Libgcrypt, as envisioned by SPKI
>> [0] and as implemented by lsh [1].
>
> If the files are to be human editable, which I think makes some sense
> for an ACL list, it might be better to use the advanced syntax. The way
> I do that in lsh, I don't want a parser for the advanced syntax in lsh
> or lshd. Instead, when reading the file, I spawn an sexp-conv process to
> convert it to canonical form.

OK.  Both the ACL and signatures are stored in advanced syntax here,
which Libgcrypt can parse and emit.  For the ACL it’s obviously more
convenient; for signatures, it’s just that I find it clearer, and the
few bytes that’d be saved using the canonical encoding are not worth it
IMO.

> And ideally, you shouldn't need a large acl list, but a single entry
> with the key belonging to the machine's owner or sysadm. The sysadm then
> delegates authorization to one or more "distro" keys, which can delegate
> further to the keys of each build machine. Each delegation is an spki
> certificate.

Sure, but again, all we have is a small subset of SPKI, and no
delegations.  So the idea was to do have an interface like
‘lsh-authorize’ to explicitly add an entry to the ACL.

>> Namely, /etc/guix/acl looks like this:
> [...]
>>     (tag (guix import))))
>
> Can you add any additional restrictions to that tag, saying that a
> certain key may sign only a subset of packages? I have thought a little
> about that, and I really don't know what's the best way is to specify a
> subset. Some possibilities,
>
>   * Authorization for a single package, say
>
>       (tag (guix import (package emacs)))
>
>     Here, there's no limit on what the package the signer calls "emacs"
>     might contain, so that's not terribly useful.
>
>   * Authorization of packages from a certain source, say
>
>       (tag (guix import (from http://ftp.gnu.org)))
>
>   * Authorization to install into a particular subtree of the local file
>     system, say
>
>       (tag (guix import (dir /usr/local/emacs/)))
>
> The tricky thing here is to define the syntax and semantics of the tags
> so that one can do useful delegations using the spki tag intersection
> machinery.

Currently I don’t see how such tags could be used, and they may be hard
to define.

In Guix, all package binaries are collected in the “store”, a big
directory with one sub-directory per package.  It is normally populated
either by building things locally, or by downloading “substitutes”
(pre-built binaries) from another machine, such as the hydra.gnu.org
build farm.

hydra.gnu.org will sign binaries it produces with its key, but these
binaries could also be distributed from other places.  For instance, in
the longer term we want to encourage use of a distributed store, or at
least to allow the use of a diverse set of HTTP servers that distribute
binaries.

The idea here is that, if you trust hydra.gnu.org or Niels’s machine to
distribute genuine binaries, then you add them to your ACL with the
(guix import) tag, which allows you to import substitutes from them.

> And maybe making best use of delegations would require more fine-grained
> operating system capabilities, so one could use restrictions in the spki
> tag also to limit what the package can do once it is running. But it
> might be reasonably easy for packages which contain some deamon which is
> going to run as its own uid anyway; then spki authorization could map to
> group membership of that uid.

This is going way beyond what’s discussed here though.  :-)

>> In addition to the actual signature, archive signatures embed the signed
>> hash and the signer's public key, like this:
>>
>>   (signature 
>>    (data 
>>     (flags pkcs1)
>>     (hash sha256 
>> #2749F0EA9F26C6C7BE746A9CFF8FA4C2F2A02B000070DBA78429E9A11F87C6EB#))
>>    (sig-val 
>>     (rsa 
>>      (s 
>> #477143FFA2DF163036599985425A331CAF4FF7FA22083A64BA08BEA0DB3BA95472A56B1EAF5E122716FACC81E8D72FEFF0985DDA162EB22FE5579B27D333B774C89425151198DA7A094E264F18755EEA1F278592555C531ADC9DE86C7BFFB4869C70150DD93D07BC032E830F9314CD7EE204DE3ED74DCBB96F63C7D0CDCCD72A#)))
>>    (public-key 
>>     (rsa 
>>      (n 
>> #00C1F764069F54FFE93A126B02328903E984E4AE3AF6DF402B5B6B3907911B88C385F1BA76A002EC9DEA109A5228EF0E62EE31A06D1A5861CAB474F6C857AC66EB65A1905F25BBA1869579E73A3B7FED13AF5A1667326F88CDFC2FF24B03C14FD1384AA7E73CA89572880B606E3A974E15347963FC7B6378574936A47580DBCB45#)
>>      (e #010001#))))
>
> I don't quite remember, but is this expression standard spki or not?

Well, <http://www.ietf.org/rfc/rfc2693.txt> doesn’t say anything about
that; <http://theworld.com/~cme/spki.txt> has some examples, which are
slightly different, but it does not formally define the sexp format for
signatures.

The ‘data’ and ‘sig-val’ things seem to originate in Libgcrypt; the
‘public-key’ format is also from Libgcrypt, and slightly different from
what appears in the SPKI documents.

I think “we” (i.e., Werner and you ;-)) could discuss the
standardization of these 3 items, and then ‘signature’ should be easier.

WDYT?

Thanks,
Ludo’.