UX: print warning if substitute server is not authorized

  • Open
  • quality assurance status badge
Details
2 participants
  • Chris Marusich
  • Ricardo Wurmus
Owner
unassigned
Submitted by
Ricardo Wurmus
Severity
normal

Debbugs page

R
R
Ricardo Wurmus wrote on 17 Jan 2018 04:17
(address . bug-guix@gnu.org)
idjpo681xyo.fsf@bimsb-sys02.mdc-berlin.net
Suppose I add example.com as a substitute server by passing
“--substitute-urls=https://example.com” to the daemon or the Guix
command line. I haven’t authorized the signing key, so Guix won’t
accept any of the substitutes from example.com.

Currently, Guix does not make it obvious to the user that a requested
substitute server is ignored because its key is not authorized. We
should print a clear warning in this case.

(guix scripts authenticate) already includes “validate-signature”, which
aborts with an error if the key is not authorized, but we don’t seem to
use it.

--
Ricardo
C
C
Chris Marusich wrote on 21 Jan 2018 23:08
(name . Ricardo Wurmus)(address . ricardo.wurmus@mdc-berlin.de)(address . 30143@debbugs.gnu.org)
87a7x6xte0.fsf@gmail.com
Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de> writes:

Toggle quote (13 lines)
> Suppose I add example.com as a substitute server by passing
> “--substitute-urls=https://example.com” to the daemon or the Guix
> command line. I haven’t authorized the signing key, so Guix won’t
> accept any of the substitutes from example.com.
>
> Currently, Guix does not make it obvious to the user that a requested
> substitute server is ignored because its key is not authorized. We
> should print a clear warning in this case.
>
> (guix scripts authenticate) already includes “validate-signature”, which
> aborts with an error if the key is not authorized, but we don’t seem to
> use it.

What if example.com serves substitutes that are signed by another
server, such as hydra.gnu.org? No matter where a substitute comes from,
if it was signed with an authorized key and its signature checks out,
then it's OK to use, right?

--
Chris
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAlpljfcACgkQ3UCaFdgi
Rp36txAA2IV+AfvqRPXhFjA9bwlhUzk3ly9D/GE6OH5yddJUFcvnCbcgpgdEwYLk
kEXRv8Q73JpK8qYG1mlzlgqV2JO7cznjERN4r86ApU2nCmIRdldXH3dPveW4k+Sj
twHQ4D1+49JH06usnIGmjdmuVoRxwltkCO89l6W3NYlZHl6PUDdZMfKo1reVI9F4
zC+f5Jt0MqJDJirP2C+F3/p3oOew/u/NmmuEl0Ii4pKoEL2M8sNU+4FxJkKPEwvI
C7a5bMaaPWJK2pbnBKZj/l49viRX6v7EyfxnB7fDQY4K7T0vwC/VS8MPa8gTZnir
NcGJU4p+K5k6Zo2TQsQoIgIJ126ZODDTov8L/6auZoaNUGGT09kGYAIDMzrbkVQ3
vs3cSkvkYxDQYSEX79indELjH3eEbfo4CWIRpo9ppWfFa4OJi9HlL1S3L0iLdVpq
0v7a0gIaRuoL3aeInnMCsPLfCw7Ts4NlPX6atoKiwJEeLWI6Y1+9B5RhDa3nt3ZU
ZHvMabv3ruJ2UeyACPYS6tsZQIAKuWCYgQzRXQ3RJqhdL1wdoenFqPrdf1YdfxB9
7b1UlIrfuExnZzYjuqipq5vAi9QjSJBghfcYIykZmTWaRyFAdPRVBTAYlzTCpzRb
bgmwklMtuJRD7w7/79PTzuzGp1q+m6QmCllDHhEwwkfNGp+QgFI=
=idpO
-----END PGP SIGNATURE-----

R
R
Ricardo Wurmus wrote on 22 Jan 2018 22:50
(name . Chris Marusich)(address . cmmarusich@gmail.com)(address . 30143@debbugs.gnu.org)
87shaxyspx.fsf@mdc-berlin.de
Chris Marusich <cmmarusich@gmail.com> writes:

Toggle quote (20 lines)
> Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de> writes:
>
>> Suppose I add example.com as a substitute server by passing
>> “--substitute-urls=https://example.com” to the daemon or the Guix
>> command line. I haven’t authorized the signing key, so Guix won’t
>> accept any of the substitutes from example.com.
>>
>> Currently, Guix does not make it obvious to the user that a requested
>> substitute server is ignored because its key is not authorized. We
>> should print a clear warning in this case.
>>
>> (guix scripts authenticate) already includes “validate-signature”, which
>> aborts with an error if the key is not authorized, but we don’t seem to
>> use it.
>
> What if example.com serves substitutes that are signed by another
> server, such as hydra.gnu.org? No matter where a substitute comes from,
> if it was signed with an authorized key and its signature checks out,
> then it's OK to use, right?

Correct.

--
Ricardo
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 30143@patchwise.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 30143
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