Bootstrapping issue with HTTPS downloads

  • Done
  • quality assurance status badge
Details
One participant
  • Ludovic Courtès
Owner
unassigned
Submitted by
Ludovic Courtès
Severity
important
L
L
L
Ludovic Courtès wrote on 22 Feb 2016 22:17
control message for bug #22774
(address . control@debbugs.gnu.org)
8737skmomi.fsf@gnu.org
severity 22774 important
L
L
Ludovic Courtès wrote on 31 Jul 2016 18:28
Re: bug#22774: Bootstrapping issue with HTTPS downloads
(address . 22774@debbugs.gnu.org)
87bn1d6abo.fsf@gnu.org
ludo@gnu.org (Ludovic Courtès) skribis:

Toggle quote (7 lines)
> Fixed-output derivations for HTTPS downloads depend on GnuTLS. However,
> pkg-config, one of GnuTLS’s dependencies, is now available exclusively
> over HTTPS, which creates a bootstrapping issue, as reported by
> Christopher W Carpenter and others:
>
> https://lists.gnu.org/archive/html/guix-devel/2016-02/msg00354.html

This is mitigated by the use of content-addressed mirrors over HTTP, as
in commit 40f788b9f6184436d9cc36a4dd8e7d101cd2f0ba (obviously a stop-gap
measure more than a real fix.)

Ludo’.
L
L
Ludovic Courtès wrote on 29 Oct 2016 01:43
(address . 22774@debbugs.gnu.org)
878tt8vy3y.fsf@gnu.org
ludo@gnu.org (Ludovic Courtès) skribis:

Toggle quote (7 lines)
> Fixed-output derivations for HTTPS downloads depend on GnuTLS. However,
> pkg-config, one of GnuTLS’s dependencies, is now available exclusively
> over HTTPS, which creates a bootstrapping issue, as reported by
> Christopher W Carpenter and others:
>
> https://lists.gnu.org/archive/html/guix-devel/2016-02/msg00354.html

The ‘wip-oob-download’ implements “out-of-band downloads”, whereby
downloads are performed by the daemon on behalf of clients.

This works by adding a “built-in builder” in the daemon (idea stolen
from the Nix daemon): if you specify “builtin:download” as the builder
of your derivation, then guix-daemon invokes ‘guix download’ to download
the thing. The derivation has to be fixed-output, of course.

The branch is not ready yet, notably because we’d need a way to pass
mirror lists to ‘guix download’, as an attribute of the derivation.

Another question is compatibility: what if a recent client creates a
“builtin:download” derivation on an old daemon? The problem is that
currently old daemons do not check the builder of the .drv file until
you call ‘build-derivations’. So I think we’ll need to bump the
protocol version so client code can check whether the daemon is new
enough.

Thoughts?

The good thing is that this should allow us to get rid of the bootstrap
binaries that are currently distributed in the source tarball of Guix
and downloaded upon ‘make’:


This was motivated precisely by the need for an out-of-band download
mechanism for bootstrapping, which we’ll then have within guix-daemon.

Ludo’.
L
L
Ludovic Courtès wrote on 14 Nov 2016 00:02
(address . 22774@debbugs.gnu.org)
87lgwnf0fl.fsf@gnu.org
ludo@gnu.org (Ludovic Courtès) skribis:

Toggle quote (11 lines)
> The ‘wip-oob-download’ implements “out-of-band downloads”, whereby
> downloads are performed by the daemon on behalf of clients.
>
> This works by adding a “built-in builder” in the daemon (idea stolen
> from the Nix daemon): if you specify “builtin:download” as the builder
> of your derivation, then guix-daemon invokes ‘guix download’ to download
> the thing. The derivation has to be fixed-output, of course.
>
> The branch is not ready yet, notably because we’d need a way to pass
> mirror lists to ‘guix download’, as an attribute of the derivation.

Fixed!

Toggle quote (7 lines)
> Another question is compatibility: what if a recent client creates a
> “builtin:download” derivation on an old daemon? The problem is that
> currently old daemons do not check the builder of the .drv file until
> you call ‘build-derivations’. So I think we’ll need to bump the
> protocol version so client code can check whether the daemon is new
> enough.

To address that, I bumped the protocol number in worker-protocol.hh and
added a ‘built-in-builders’ RPC that returns the list of supported
built-in builders (a list of strings.)

That way, clients can check what the daemon supports. For instance,
‘url-fetch’ can return either a “normal” fixed-output derivation or one
that uses “builtin:download”, depending on what the daemon supports.

Feedback welcome.

Ludo’.
L
L
Ludovic Courtès wrote on 16 Nov 2016 18:23
(address . 22774-done@debbugs.gnu.org)
87a8czgwyj.fsf@gnu.org
Hi!

I pushed the whole patch series with the fix as
05ceb8dcaf480a47cddf94ac979070b76df6556c.

The final patch series uses a new internal helper, ‘guix
perform-download’, instead of trying to bend ‘guix download’ to these
specific needs.

Ludo’.
Closed
?
Your comment

This issue is archived.

To comment on this conversation send an email to 22774@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 22774
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch