GNU bug report logs -
#67072
[PATCH 0/4] Helping diagnose substitute setup issues
Previous Next
Reported by: Ludovic Courtès <ludo <at> gnu.org>
Date: Sat, 11 Nov 2023 11:05:01 UTC
Severity: normal
Tags: patch
Done: Ludovic Courtès <ludo <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
Hi,
On Sat, 11 Nov 2023 at 12:06, Ludovic Courtès <ludo <at> gnu.org> wrote:
> + #:use-module (guix pki)
Looking at what it drags, I notice:
--8<---------------cut here---------------start------------->8---
(define* (authorized-key? key #:optional (acl (current-acl)))
"Return #t if KEY (a canonical sexp) is an authorized public key for archive
imports according to ACL."
;; Note: ACL is kept in native sexp form to make 'authorized-key?' faster,
;; by not having to convert it with 'canonical-sexp->sexp' on each call.
;; TODO: We could use a better data type for ACLs.
(let ((key (canonical-sexp->sexp key)))
(match acl
(('acl
('entry subject-keys
('tag ('guix 'import)))
...)
(not (not (member key subject-keys))))
(_
(error "invalid access-control list" acl)))))
--8<---------------cut here---------------end--------------->8---
I know it is irrelevant with the patch at hand. Maybe not. :-)
1. Why this ’(not (not’ ?
2. When testing the patch, I have not done --sysconfdir=/etc and it
was not able to find the correct ACL. Somehow…
> +(define (check-narinfo-authorization narinfo)
> + "Print a warning when NARINFO is not signed by an authorized key."
> + (unless (valid-narinfo? narinfo)
…I entered in this part – hence the look up (guix pki) ;-). Well, my
mistake is hard to reproduce outside of Guix development tree but
’valid-narinfo?’ returns false for more cases than just
unauthorized-key. Therefore, the hint could be misleading.
Since we are discussing about an helper, I would run ’signature-case’
here in check-narinfo. For example, if the case is 'unauthorized-key,
then I would check is %acl-file exists. Maybe display the full
%acl-file explaining that the key is not in, etc.
Moreover, running “guix challenge coreutils” does not warn about
anything; when I was expected the same warning as “guix weather”.
Last, once sysconfig fixed, I get:
--8<---------------cut here---------------start------------->8---
guix weather: warning: could not determine current substitute URLs; using defaults
computing 1 package derivations for x86_64-linux...
looking for 2 store items on https://ci.guix.gnu.org...
guix weather: error: open-file: Permission denied: "/etc/guix/acl"
--8<---------------cut here---------------end--------------->8---
Hum? Maybe I am doing something wrong… The file /etc/guix/acl has the
permission:
-rw------- 1 root root 528 acl
Is it incorrect? Well, if all are allowed to read (chmod a+r) then
there is not error. And it displays the warning:
--8<---------------cut here---------------start------------->8---
guix weather: warning: could not determine current substitute URLs; using defaults
--8<---------------cut here---------------end--------------->8---
And that’s because the daemon is not supporting the operation. This
warning appears to me misleading: personally I think that I am
misconfigured something when that’s not the case. Instead, I would
display:
warning: using defaults substitute URLs
Cheers,
simon
This bug report was last modified 1 year and 166 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.