GNU bug report logs -
#51822
[PATCH] gnupg: Honor GnuPG's configuration for the key server.
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 51822 in the body.
You can then email your comments to 51822 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
guix-patches <at> gnu.org
:
bug#51822
; Package
guix-patches
.
(Sun, 14 Nov 2021 03:00:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
guix-patches <at> gnu.org
.
(Sun, 14 Nov 2021 03:00:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
The previous default "pool.sks-keyservers.net" doesn't seem to work anymore;
besides, users know best.
* guix/gnupg.scm (%openpgp-key-server): Default to #f, meaning not provided.
(gnupg-receive-keys): Make SERVER and KEYRING keyword arguments. Adjust doc.
Provide the '--keyserver' argument only when %openpgp-key-server is not #f.
(gnupg-verify*): Do not set a default value for SERVER. Adjust accordingly.
---
guix/gnupg.scm | 31 ++++++++++++++++++-------------
1 file changed, 18 insertions(+), 13 deletions(-)
diff --git a/guix/gnupg.scm b/guix/gnupg.scm
index 5fae24b325..2ec77c6a71 100644
--- a/guix/gnupg.scm
+++ b/guix/gnupg.scm
@@ -2,6 +2,7 @@
;;; Copyright © 2010, 2011, 2013, 2014, 2016, 2018, 2019 Ludovic Courtès <ludo <at> gnu.org>
;;; Copyright © 2013 Nikita Karetnikov <nikita <at> karetnikov.org>
;;; Copyright © 2020 Tobias Geerinckx-Rice <me <at> tobias.gr>
+;;; Copyright © 2021 Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
;;;
;;; This file is part of GNU Guix.
;;;
@@ -56,9 +57,9 @@ (define current-keyring
"/gpg/trustedkeys.kbx")))
(define %openpgp-key-server
- ;; The default key server. Note that keys.gnupg.net appears to be
- ;; unreliable.
- (make-parameter "pool.sks-keyservers.net"))
+ ;; The default key server. It defaults to #f, which causes GnuPG to use the
+ ;; one it is configured with.
+ (make-parameter #f))
;; Regexps for status lines. See file `doc/DETAILS' in GnuPG.
@@ -182,22 +183,26 @@ (define (gnupg-status-missing-key? status)
(_ #f)))
status))
-(define* (gnupg-receive-keys fingerprint/key-id server
- #:optional (keyring (current-keyring)))
- "Download FINGERPRINT/KEY-ID from SERVER, a key server, and add it to
-KEYRING."
+(define* (gnupg-receive-keys fingerprint/key-id
+ #:key server (keyring (current-keyring)))
+ "Download FINGERPRINT/KEY-ID from SERVER if specified, otherwise from
+GnuPG's default/configure on. The key is added to KEYRING."
(unless (file-exists? keyring)
(mkdir-p (dirname keyring))
- (call-with-output-file keyring (const #t))) ;create an empty keybox
+ (call-with-output-file keyring (const #t))) ;create an empty keybox
- (zero? (system* (%gpg-command) "--keyserver" server
- "--no-default-keyring" "--keyring" keyring
- "--recv-keys" fingerprint/key-id)))
+ (zero? (apply system*
+ `(,(%gpg-command)
+ ,@(if server
+ (list "--keyserver" server)
+ '())
+ "--no-default-keyring" "--keyring" ,keyring
+ "--recv-keys" ,fingerprint/key-id))))
(define* (gnupg-verify* sig file
#:key
(key-download 'interactive)
- (server (%openpgp-key-server))
+ server
(keyring (current-keyring)))
"Like `gnupg-verify', but try downloading the public key if it's missing.
Return two values: 'valid-signature and a fingerprint/name pair upon success,
@@ -215,7 +220,7 @@ (define* (gnupg-verify* sig file
(let ((missing (gnupg-status-missing-key? status)))
(define (download-and-try-again)
;; Download the missing key and try again.
- (if (gnupg-receive-keys missing server keyring)
+ (if (gnupg-receive-keys missing #:server server #:keyring keyring)
(match (gnupg-status-good-signature?
(gnupg-verify sig file keyring))
(#f
--
2.33.1
Information forwarded
to
guix-patches <at> gnu.org
:
bug#51822
; Package
guix-patches
.
(Mon, 15 Nov 2021 10:33:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 51822 <at> debbugs.gnu.org (full text, mbox):
Hi Maxim,
On Sun, 14 Nov 2021 at 04:00, Maxim Cournoyer <maxim.cournoyer <at> gmail.com> wrote:
> The previous default "pool.sks-keyservers.net" doesn't seem to work anymore;
Does this mean some "guix time-machine" could be broken?
Cheers,
simon
Information forwarded
to
guix-patches <at> gnu.org
:
bug#51822
; Package
guix-patches
.
(Thu, 18 Nov 2021 13:02:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 51822 <at> debbugs.gnu.org (full text, mbox):
Hi Simon,
zimoun <zimon.toutoune <at> gmail.com> writes:
> Hi Maxim,
>
> On Sun, 14 Nov 2021 at 04:00, Maxim Cournoyer <maxim.cournoyer <at> gmail.com> wrote:
>
>> The previous default "pool.sks-keyservers.net" doesn't seem to work anymore;
>
> Does this mean some "guix time-machine" could be broken?
I don't think so, else I fail to see the relationship.
Thanks,
Maxim
Information forwarded
to
guix-patches <at> gnu.org
:
bug#51822
; Package
guix-patches
.
(Thu, 18 Nov 2021 13:36:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 51822 <at> debbugs.gnu.org (full text, mbox):
Hi Maxim,
On Thu, 18 Nov 2021 at 14:01, Maxim Cournoyer <maxim.cournoyer <at> gmail.com> wrote:
> zimoun <zimon.toutoune <at> gmail.com> writes:
> > On Sun, 14 Nov 2021 at 04:00, Maxim Cournoyer <maxim.cournoyer <at> gmail.com> wrote:
> >
> >> The previous default "pool.sks-keyservers.net" doesn't seem to work anymore;
> >
> > Does this mean some "guix time-machine" could be broken?
>
> I don't think so, else I fail to see the relationship.
If a server was used for doing something by Guix at version A, then
this server is now down, is the something still now doable using this
old version A of Guix? Where this old version A is reachable by "guix
time-machine".
Maybe it does not make sense and it is not relevant.
Cheers,
simon
Information forwarded
to
guix-patches <at> gnu.org
:
bug#51822
; Package
guix-patches
.
(Thu, 18 Nov 2021 14:22:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 51822 <at> debbugs.gnu.org (full text, mbox):
Hi Simon,
zimoun <zimon.toutoune <at> gmail.com> writes:
> Hi Maxim,
>
> On Thu, 18 Nov 2021 at 14:01, Maxim Cournoyer <maxim.cournoyer <at> gmail.com> wrote:
>> zimoun <zimon.toutoune <at> gmail.com> writes:
>> > On Sun, 14 Nov 2021 at 04:00, Maxim Cournoyer <maxim.cournoyer <at> gmail.com> wrote:
>> >
>> >> The previous default "pool.sks-keyservers.net" doesn't seem to work anymore;
>> >
>> > Does this mean some "guix time-machine" could be broken?
>>
>> I don't think so, else I fail to see the relationship.
>
> If a server was used for doing something by Guix at version A, then
> this server is now down, is the something still now doable using this
> old version A of Guix? Where this old version A is reachable by "guix
> time-machine".
>
> Maybe it does not make sense and it is not relevant.
The default server that was hard-coded in Guix (or in GnuPG) in the past
would still not work *now*, even using an older Guix commit :-).
So I do not think it is relevant.
Thanks,
Maxim
Information forwarded
to
guix-patches <at> gnu.org
:
bug#51822
; Package
guix-patches
.
(Thu, 18 Nov 2021 14:30:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 51822 <at> debbugs.gnu.org (full text, mbox):
Re,
On Thu, 18 Nov 2021 at 15:21, Maxim Cournoyer <maxim.cournoyer <at> gmail.com> wrote:
> > If a server was used for doing something by Guix at version A, then
> > this server is now down, is the something still now doable using this
> > old version A of Guix? Where this old version A is reachable by "guix
> > time-machine".
> >
> > Maybe it does not make sense and it is not relevant.
>
> The default server that was hard-coded in Guix (or in GnuPG) in the past
> would still not work *now*, even using an older Guix commit :-).
Yeah, for sure. My question is: because this server is not working
*now* and hard-coded on previous version, is "guix time-machine" still
working for all the subcommands? Or is it broken as collateral damage
of server down + hard coded? :-)
Cheers,
simon
Information forwarded
to
guix-patches <at> gnu.org
:
bug#51822
; Package
guix-patches
.
(Thu, 18 Nov 2021 15:58:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 51822 <at> debbugs.gnu.org (full text, mbox):
Hi,
zimoun <zimon.toutoune <at> gmail.com> writes:
> Re,
>
> On Thu, 18 Nov 2021 at 15:21, Maxim Cournoyer <maxim.cournoyer <at> gmail.com> wrote:
>
>> > If a server was used for doing something by Guix at version A, then
>> > this server is now down, is the something still now doable using this
>> > old version A of Guix? Where this old version A is reachable by "guix
>> > time-machine".
>> >
>> > Maybe it does not make sense and it is not relevant.
>>
>> The default server that was hard-coded in Guix (or in GnuPG) in the past
>> would still not work *now*, even using an older Guix commit :-).
>
> Yeah, for sure. My question is: because this server is not working
> *now* and hard-coded on previous version, is "guix time-machine" still
> working for all the subcommands? Or is it broken as collateral damage
> of server down + hard coded? :-)
guix time-machine is not broken as a whole, but the 'guix refresh
--update' commands that makes use of the (guix gnupg) module would for
sure in whichever commit of Guix, unless pool.sks-keyservers.net is
revived. As a workaround, the --key-server option can be set to
hkp://keyserver.ubuntu.com (what became the default in recent GnuPG
releases).
Thanks,
Maxim
Information forwarded
to
guix-patches <at> gnu.org
:
bug#51822
; Package
guix-patches
.
(Thu, 18 Nov 2021 16:21:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 51822 <at> debbugs.gnu.org (full text, mbox):
Re,
On Thu, 18 Nov 2021 at 16:57, Maxim Cournoyer <maxim.cournoyer <at> gmail.com> wrote:
> guix time-machine is not broken as a whole, but the 'guix refresh
> --update' commands that makes use of the (guix gnupg) module would for
> sure in whichever commit of Guix, unless pool.sks-keyservers.net is
> revived. As a workaround, the --key-server option can be set to
> hkp://keyserver.ubuntu.com (what became the default in recent GnuPG
> releases).
Thanks for explaining. Perfect if there is a (almost) straightforward
workaround. :-)
LGTM!
Cheers,
simon
Reply sent
to
Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
:
You have taken responsibility.
(Thu, 18 Nov 2021 20:06:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
:
bug acknowledged by developer.
(Thu, 18 Nov 2021 20:06:02 GMT)
Full text and
rfc822 format available.
Message #31 received at 51822-done <at> debbugs.gnu.org (full text, mbox):
Hello,
zimoun <zimon.toutoune <at> gmail.com> writes:
> Re,
>
> On Thu, 18 Nov 2021 at 16:57, Maxim Cournoyer <maxim.cournoyer <at> gmail.com> wrote:
>
>> guix time-machine is not broken as a whole, but the 'guix refresh
>> --update' commands that makes use of the (guix gnupg) module would for
>> sure in whichever commit of Guix, unless pool.sks-keyservers.net is
>> revived. As a workaround, the --key-server option can be set to
>> hkp://keyserver.ubuntu.com (what became the default in recent GnuPG
>> releases).
>
> Thanks for explaining. Perfect if there is a (almost) straightforward
> workaround. :-)
>
> LGTM!
Alright, thanks for the review! Submitted as 4c91332cce.
Thanks,
Closing.
Maxim
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Fri, 17 Dec 2021 12:24:09 GMT)
Full text and
rfc822 format available.
This bug report was last modified 2 years and 93 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.