From: ludo@gnu.org (Ludovic Courtès)
To: Mark H Weaver <mhw@netris.org>
Cc: Alex Kost <alezost@gmail.com>, 22990@debbugs.gnu.org
Subject: bug#22990: Grafts leads to inefficient substitute info retrieval
Date: Tue, 15 Mar 2016 22:50:05 +0100 [thread overview]
Message-ID: <87twk7qulu.fsf@gnu.org> (raw)
In-Reply-To: <8737rrmv8s.fsf@netris.org> (Mark H. Weaver's message of "Tue, 15 Mar 2016 14:49:55 -0400")
Mark H Weaver <mhw@netris.org> skribis:
> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Alex Kost <alezost@gmail.com> skribis:
>>
>>> Ludovic Courtès (2016-03-11 19:52 +0300) wrote:
>>>
>>>> As of right now (v0.9.0-2007-g66a30a3), ‘graft-derivation’ works either by:
>>>>
>>>> 1. Fetching substitute info about the things being built so that it
>>>> can determine its references, which in turns allows it to determine
>>>> whether they need to be grafted.
>>>>
>>>> 2. Building stuff, as a last resort, so that it can determine its
>>>> references.
>>>
>>> I noticed that #1 is happening even with --no-substitutes option. Is it
>>> intended?
>>
>> Not really, but I see this is because ‘substitutable-path-info’ (called
>> from ‘references/substitutes’, called from ‘graft-derivation’) works
>> regardless of whether substitutes are enabled:
>>
>> scheme@(guile-user)> ,use(guix)
>> scheme@(guile-user)> (define s (open-connection))
>> scheme@(guile-user)> (set-build-options s #:use-substitutes? #f)
>> $2 = #t
>> scheme@(guile-user)> (valid-path? s "/gnu/store/qf2lm7jpiiyygxz8zq0r1ca1fazv6smn-mutt-1.5.24")
>> $3 = #f
>> scheme@(guile-user)> (substitutable-path-info s '("/gnu/store/qf2lm7jpiiyygxz8zq0r1ca1fazv6smn-mutt-1.5.24"))
>> $4 = (#<<substitutable> path: "/gnu/store/qf2lm7jpiiyygxz8zq0r1ca1fazv6smn-mutt-1.5.24" deriver: "/gnu/store/jcl9c3w463xa2g963q5a60rrd97y1g28-mutt-1.5.24.drv" refs: ("/gnu/store/3gmzl5jpk700hqyr8p3kfg0vgcnw8d97-libassuan-2.4.2" "/gnu/store/b02lmk67jq1vcflk2m2bwzc8gmwmndqp-ncurses-6.0" "/gnu/store/d3xdc2w87yw3raafwb9q34gxx4xqci8k-cyrus-sasl-2.1.26" "/gnu/store/pkasxagsa4z4viscfpl6sjszmdmwncl1-gcc-4.9.3-lib" "/gnu/store/qf2lm7jpiiyygxz8zq0r1ca1fazv6smn-mutt-1.5.24" "/gnu/store/qvx4q6lbwi4s3cwr8wqaa7kcva0a5c4b-openssl-1.0.2f" "/gnu/store/sb40mddkia0brc814xkbnhxccfm32q3a-gpgme-1.6.0" "/gnu/store/sgzfawy95pfn7nsw3xvmca58llm5zzbc-glibc-2.22" "/gnu/store/x2p2biyybcb2wac77qz9468asc5fm48i-perl-5.22.1" "/gnu/store/x8dmdlrn5qn0wrbcnngj55y3ab73h0pp-bash-4.3.42" "/gnu/store/zpxg45dq67psrn4wmfk4l635h0si8q63-libgpg-error-1.21") dl-size: 0 nar-size: 6661016>)
>
> Is the information from the substitute server authenticated by checking
> hydra's signature against the list of keys in /etc/guix/acls?
Yes.
>> However, substitutes are not downloaded, so in this regard
>> --no-substitutes is honored.
>
> It depends on the intent of --no-substitutes. If the intent is to avoid
> trusting the substitute server, then by relying on the accuracy of the
> runtime dependency data from Hydra, we are failing to honor that intent.
>
> That said, I think it's okay to document that --no-substitutes alone is
> not sufficient to avoid trusting a substitute server, and that the
> proper way to accomplish that is to make sure its key is not in
> /etc/guix/acls.
The sysadmin gets to choose which principals are trusted; unprivileged
users can only shrink this set.
The weird thing is that in this case, passing --substitute-urls='' on
the client side would effectively disable substitutes entirely.
> What do you think?
We could augment the doc for --no-substitutes, I guess we should first
document that grafting relies on server-provided info.
Ludo’.
next prev parent reply other threads:[~2016-03-15 21:51 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-11 16:52 bug#22990: Grafts leads to inefficient substitute info retrieval Ludovic Courtès
2016-03-12 9:23 ` Alex Kost
2016-03-13 12:11 ` Ludovic Courtès
2016-03-15 18:49 ` Mark H Weaver
2016-03-15 21:50 ` Ludovic Courtès [this message]
2016-03-15 8:24 ` Ludovic Courtès
2017-01-08 21:44 ` Ludovic Courtès
2017-01-09 22:55 ` Ludovic Courtès
2017-01-11 9:54 ` Ludovic Courtès
2017-01-11 10:51 ` David Craven
2017-01-11 21:19 ` Ludovic Courtès
2020-03-29 13:41 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87twk7qulu.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=22990@debbugs.gnu.org \
--cc=alezost@gmail.com \
--cc=mhw@netris.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.