Error updating gnurl

Error updating gnurl

[Tanguy LE CARROUR]

As mentionned on GNUnet mailing list [1][], gnurl is affected by security issues.

[1]: https://lists.gnu.org/archive/html/gnunet-developers/2022-04/msg00021.html

It might not affect GNUnet, but I tried to update the package in Guix anyway, and…
I failed! ^_^'

```console
$ ./pre-inst-env guix refresh -u gnurl

Starting download of /tmp/guix-file.NqJa4t
From https://ftpmirror.gnu.org/gnu/gnunet/gnurl-7.72.0.tar.gz...
following redirection to `https://mirrors.ocf.berkeley.edu/gnu/gnunet/gnurl-7.72.0.tar.gz'...
 …2.0.tar.gz  3.3MiB                  3.1MiB/s 00:01 [##################] 100.0%

Starting download of /tmp/guix-file.VXn0IS
From https://ftpmirror.gnu.org/gnu/gnunet/gnurl-7.72.0.tar.gz.sig...
following redirection to `https://mirrors.ocf.berkeley.edu/gnu/gnunet/gnurl-7.72.0.tar.gz.sig'...
 …0.tar.gz.sig  833B                  654KiB/s 00:00 [##################] 100.0%
gpgv: Signature made Wed 16 Sep 2020 22:30:16 CEST
gpgv:                using RSA key 6115012DEA3026F62A98A556D6B570842F7E7F8D
gpgv: Can't check signature: No public key
Would you like to add this key to keyring '/home/tanguy/.config/guix/upstream/trustedkeys.kbx'?
yes
gpg: keyserver receive failed: No data
guix refresh: warning: missing public key 6115012DEA3026F62A98A556D6B570842F7E7F8D for 'mirror://gnu/gnunet/gnurl-7.72.0.tar.gz'
guix refresh: warning: gnurl: version 7.72.0 could not be downloaded and authenticated; not updating
```

Have I done something wrong?!

Regards,

-- 
Tanguy

Finding a “good” OpenPGP key server

[Ludovic Courtès]

Hi,

Tanguy LE CARROUR <tanguy@bioneland.org> skribis:

> $ ./pre-inst-env guix refresh -u gnurl
>
> Starting download of /tmp/guix-file.NqJa4t
> From https://ftpmirror.gnu.org/gnu/gnunet/gnurl-7.72.0.tar.gz...
> following redirection to `https://mirrors.ocf.berkeley.edu/gnu/gnunet/gnurl-7.72.0.tar.gz'...
>  …2.0.tar.gz  3.3MiB                  3.1MiB/s 00:01 [##################] 100.0%
>
> Starting download of /tmp/guix-file.VXn0IS
> From https://ftpmirror.gnu.org/gnu/gnunet/gnurl-7.72.0.tar.gz.sig...
> following redirection to `https://mirrors.ocf.berkeley.edu/gnu/gnunet/gnurl-7.72.0.tar.gz.sig'...
>  …0.tar.gz.sig  833B                  654KiB/s 00:00 [##################] 100.0%
> gpgv: Signature made Wed 16 Sep 2020 22:30:16 CEST
> gpgv:                using RSA key 6115012DEA3026F62A98A556D6B570842F7E7F8D
> gpgv: Can't check signature: No public key
> Would you like to add this key to keyring '/home/tanguy/.config/guix/upstream/trustedkeys.kbx'?
> yes
> gpg: keyserver receive failed: No data

This indicates that ‘guix refresh’ failed to download the relevant GPG
key from the default key server, the one that appears in
~/.gnupg/dirmngr.conf (if it exists).

That’s unfortunately often the case these days.  :-/ This key appears to
be on keys.openpgp.org, but it lacks a “user ID” packet and so gpg
ignores it (for no good reason):

--8<---------------cut here---------------start------------->8---
$ gpg --no-default-keyring --keyring /home/ludo/.config/guix/upstream/trustedkeys.kbx --keyserver keys.openpgp.org --recv-keys 6115012DEA3026F62A98A556D6B570842F7E7F8D
gpg: key D6B570842F7E7F8D: no user ID
gpg: Total number processed: 1
$ gpg --no-default-keyring --keyring /home/ludo/.config/guix/upstream/trustedkeys.kbx --list-keys 6115012DEA3026F62A98A556D6B570842F7E7F8D
gpg: error reading key: No public key
--8<---------------cut here---------------end--------------->8---

I’m not sure what a good solution is (other than looking for the key
manually on Savannah or on some random key server).

Ludo’.

Re: Finding a “good” OpenPGP key server

[Tanguy LE CARROUR]

Hi Ludo’,

Thanks for updating the topic! :-)


Quoting Ludovic Courtès (2022-04-18 22:24:00)
> Tanguy LE CARROUR <tanguy@bioneland.org> skribis:
> 
> > $ ./pre-inst-env guix refresh -u gnurl
> >
> > Starting download of /tmp/guix-file.NqJa4t
> > From https://ftpmirror.gnu.org/gnu/gnunet/gnurl-7.72.0.tar.gz...
> > following redirection to `https://mirrors.ocf.berkeley.edu/gnu/gnunet/gnurl-7.72.0.tar.gz'...
> >  …2.0.tar.gz  3.3MiB                  3.1MiB/s 00:01 [##################] 100.0%
> >
> > Starting download of /tmp/guix-file.VXn0IS
> > From https://ftpmirror.gnu.org/gnu/gnunet/gnurl-7.72.0.tar.gz.sig...
> > following redirection to `https://mirrors.ocf.berkeley.edu/gnu/gnunet/gnurl-7.72.0.tar.gz.sig'...
> >  …0.tar.gz.sig  833B                  654KiB/s 00:00 [##################] 100.0%
> > gpgv: Signature made Wed 16 Sep 2020 22:30:16 CEST
> > gpgv:                using RSA key 6115012DEA3026F62A98A556D6B570842F7E7F8D
> > gpgv: Can't check signature: No public key
> > Would you like to add this key to keyring '/home/tanguy/.config/guix/upstream/trustedkeys.kbx'?
> > yes
> > gpg: keyserver receive failed: No data
> 
> This indicates that ‘guix refresh’ failed to download the relevant GPG
> key from the default key server, the one that appears in
> ~/.gnupg/dirmngr.conf (if it exists).
> 
> That’s unfortunately often the case these days.  :-/ This key appears to
> be on keys.openpgp.org, but it lacks a “user ID” packet and so gpg
> ignores it (for no good reason):
> 
> --8<---------------cut here---------------start------------->8---
> $ gpg --no-default-keyring --keyring /home/ludo/.config/guix/upstream/trustedkeys.kbx --keyserver keys.openpgp.org --recv-keys 6115012DEA3026F62A98A556D6B570842F7E7F8D
> gpg: key D6B570842F7E7F8D: no user ID
> gpg: Total number processed: 1
> $ gpg --no-default-keyring --keyring /home/ludo/.config/guix/upstream/trustedkeys.kbx --list-keys 6115012DEA3026F62A98A556D6B570842F7E7F8D
> gpg: error reading key: No public key
> --8<---------------cut here---------------end--------------->8---
> 
> I’m not sure what a good solution is (other than looking for the key
> manually on Savannah or on some random key server).

Sorry it took me so long to answer!

Actually, Nikita answered this question on a thread on GNUnet's mailing list:

https://lists.gnu.org/archive/html/gnunet-developers/2022-04/msg00030.html

The end of the discussion is off list. The key used to
sign the package is deprecated and not to be used any more/any where.

The proper solution should come from GNUnet, but maybe, we could bypass
the key verification in Guix. Or, I could clone the repo, claim
ownership and sign a new package myself. But that doesn't look like a
good/fair solution to me! Thoughts?!

Regards,

-- 
Tanguy

Re: Finding a “good” OpenPGP key server

[Ludovic Courtès]

Hi,

Tanguy LE CARROUR <tanguy@bioneland.org> skribis:

> Actually, Nikita answered this question on a thread on GNUnet's mailing list:
>
> https://lists.gnu.org/archive/html/gnunet-developers/2022-04/msg00030.html
>
> The end of the discussion is off list. The key used to
> sign the package is deprecated and not to be used any more/any where.

Hmm, so how’s one supposed to authenticate it?

> The proper solution should come from GNUnet, but maybe, we could bypass
> the key verification in Guix. Or, I could clone the repo, claim
> ownership and sign a new package myself. But that doesn't look like a
> good/fair solution to me! Thoughts?!

Sure, if you can update to what you think is genuinely the latest
version, please go ahead.

Thanks,
Ludo’.

Re: Finding a “good” OpenPGP key server

[Philip McGrath]

Hi,

On 4/18/22 16:24, Ludovic Courtès wrote:
> Hi,
> 
> Tanguy LE CARROUR <tanguy@bioneland.org> skribis:
> 
>> gpgv: Signature made Wed 16 Sep 2020 22:30:16 CEST
>> gpgv:                using RSA key 6115012DEA3026F62A98A556D6B570842F7E7F8D
>> gpgv: Can't check signature: No public key
>> Would you like to add this key to keyring '/home/tanguy/.config/guix/upstream/trustedkeys.kbx'?
>> yes
>> gpg: keyserver receive failed: No data
> 
> This indicates that ‘guix refresh’ failed to download the relevant GPG
> key from the default key server, the one that appears in
> ~/.gnupg/dirmngr.conf (if it exists).
> 
> That’s unfortunately often the case these days.  :-/ This key appears to
> be on keys.openpgp.org, but it lacks a “user ID” packet and so gpg
> ignores it (for no good reason):
> 
> --8<---------------cut here---------------start------------->8---
> $ gpg --no-default-keyring --keyring /home/ludo/.config/guix/upstream/trustedkeys.kbx --keyserver keys.openpgp.org --recv-keys 6115012DEA3026F62A98A556D6B570842F7E7F8D
> gpg: key D6B570842F7E7F8D: no user ID
> gpg: Total number processed: 1
> $ gpg --no-default-keyring --keyring /home/ludo/.config/guix/upstream/trustedkeys.kbx --list-keys 6115012DEA3026F62A98A556D6B570842F7E7F8D
> gpg: error reading key: No public key
> --8<---------------cut here---------------end--------------->8---
> 
> I’m not sure what a good solution is (other than looking for the key
> manually on Savannah or on some random key server).
> 

Many distributions of GnuPG include a patch to handle keys without “user 
ID” packets.[1] In fact, it may well be *most* distributions: Debian, 
Fedora, Nix, OpenSUSE[2], and at least one commonly-recommended 
installation option for Mac. Debian packagers have argued [3]:

> I think GnuPG's inability to receive these
> kinds of cryptographic updates to OpenPGP certificates that it knows
> about is at core a security risk (it makes it more likely that users
> will use a revoked key; or will be unable to use any key at all, and
> will send plaintext).

Unfortunately, the upstream GnuPG maintainer has rejected the patch, I 
guess because strict conformance to the OpenPGP standards requires user 
ids.[4]

I am by no means an expert on PGP or GPG issues, but I'd be in favor of 
Guix adopting this patch.

-Philip

[1]: https://keys.openpgp.org/about/faq#older-gnupg
[2]: https://build.opensuse.org/package/show/openSUSE:Factory/gpg2
[3]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930665#10
[4]: https://dev.gnupg.org/T4393#133689

Re: Finding a “good” OpenPGP key server

[Tanguy LE CARROUR]

Hi Philip,


Quoting Philip McGrath (2022-04-29 21:11:41)
> On 4/18/22 16:24, Ludovic Courtès wrote:
> > Hi,
> > 
> > Tanguy LE CARROUR <tanguy@bioneland.org> skribis:
> > 
> >> gpgv: Signature made Wed 16 Sep 2020 22:30:16 CEST
> >> gpgv:                using RSA key 6115012DEA3026F62A98A556D6B570842F7E7F8D
> >> gpgv: Can't check signature: No public key
> >> Would you like to add this key to keyring '/home/tanguy/.config/guix/upstream/trustedkeys.kbx'?
> >> yes
> >> gpg: keyserver receive failed: No data
> > 
> > This indicates that ‘guix refresh’ failed to download the relevant GPG
> > key from the default key server, the one that appears in
> > ~/.gnupg/dirmngr.conf (if it exists).
> > 
> > That’s unfortunately often the case these days.  :-/ This key appears to
> > be on keys.openpgp.org, but it lacks a “user ID” packet and so gpg
> > ignores it (for no good reason):
> > 
> > --8<---------------cut here---------------start------------->8---
> > $ gpg --no-default-keyring --keyring /home/ludo/.config/guix/upstream/trustedkeys.kbx --keyserver keys.openpgp.org --recv-keys 6115012DEA3026F62A98A556D6B570842F7E7F8D
> > gpg: key D6B570842F7E7F8D: no user ID
> > gpg: Total number processed: 1
> > $ gpg --no-default-keyring --keyring /home/ludo/.config/guix/upstream/trustedkeys.kbx --list-keys 6115012DEA3026F62A98A556D6B570842F7E7F8D
> > gpg: error reading key: No public key
> > --8<---------------cut here---------------end--------------->8---
> > 
> > I’m not sure what a good solution is (other than looking for the key
> > manually on Savannah or on some random key server).
> > 
> 
> Many distributions of GnuPG include a patch to handle keys without “user 
> ID” packets.[1] In fact, it may well be *most* distributions: Debian, 
> Fedora, Nix, OpenSUSE[2], and at least one commonly-recommended 
> installation option for Mac. Debian packagers have argued [3]:
> 
> > I think GnuPG's inability to receive these
> > kinds of cryptographic updates to OpenPGP certificates that it knows
> > about is at core a security risk (it makes it more likely that users
> > will use a revoked key; or will be unable to use any key at all, and
> > will send plaintext).
> 
> Unfortunately, the upstream GnuPG maintainer has rejected the patch, I 
> guess because strict conformance to the OpenPGP standards requires user 
> ids.[4]
> 
> I am by no means an expert on PGP or GPG issues, but I'd be in favor of 
> Guix adopting this patch.
> 
> -Philip
> 
> [1]: https://keys.openpgp.org/about/faq#older-gnupg
> [2]: https://build.opensuse.org/package/show/openSUSE:Factory/gpg2
> [3]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930665#10
> [4]: https://dev.gnupg.org/T4393#133689

Oh… thank you so much for your answer! Looks like the proper way to go!
I'll try to update GnuPG package definition to integrate one or several
of those patches.
Or maybe we should first figure out it this is the right thing to do?!

Guix, thoughts!?

Regards,

-- 
Tanguy

Re: Finding a “good” OpenPGP key server

[Ludovic Courtès]

Hi,

Tanguy LE CARROUR <tanguy@bioneland.org> skribis:

> Oh… thank you so much for your answer! Looks like the proper way to go!
> I'll try to update GnuPG package definition to integrate one or several
> of those patches.
> Or maybe we should first figure out it this is the right thing to do?!
>
> Guix, thoughts!?

I have mixed feelings about applying the patch, dunno.

While discussing this on the Fediverse, I learned two things:

  1. keyserver.ubuntu.com is a reliable key server that includes user
     IDs, so it’s a good choice for ‘guix refresh’ and similar uses;

  2. keys.openpgp.org publishes users IDs if you explicitly consent to
     do so via the web interface at <https://keys.openpgp.org/upload>;
     that doesn’t help much for the ‘guix refresh’ use case though.

Ludo’.

Re: Finding a “good” OpenPGP key server

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 1233 bytes --]

Ludovic Courtès schreef op ma 18-04-2022 om 22:24 [+0200]:
> [... guix refresh -u stuff failing due to not finding the key ...]
> I’m not sure what a good solution is (other than looking for the key
> manually on Savannah or on some random key server).

Alternatively, why use key servers at all?  WDYT of something like

(package
  (name "gnurl")
  [...]
  (properties
    ;; Keys that are considered ‘trustworthy’ for signing releases
    ;; of gnurl.
    `((permitted-pgp-signing-keys "CABB A99E ..." "DEAD BEEF ...")
      ;; Locations of PGP key (possibly with some of them pointing to
      ;; the same key)
      (pgp-key-locations
        ,(savannah-pgp-key USER-ID) ... ; most signers are on savannah.gnu.org
        ,(local-file "[...]/someone.pub") ; not easily available from the Web               
        "https://rando/key.pub"
        "ipfs://.../..." "gnunet://...")))) ; download key via P2P networks

The first part (permitted-pgp-signing-keys) has been suggested previously and
seems mostly orthogonal, but the second part is new.  It would reduce
the dependency on central infrastructure.  We could consider key servers
to be ‘merely’ another fallback.

Greetings,
Maxime

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: Finding a “good” OpenPGP key server

[Ludovic Courtès]

Maxime Devos <maximedevos@telenet.be> skribis:

> Ludovic Courtès schreef op ma 18-04-2022 om 22:24 [+0200]:
>> [... guix refresh -u stuff failing due to not finding the key ...]
>> I’m not sure what a good solution is (other than looking for the key
>> manually on Savannah or on some random key server).
>
> Alternatively, why use key servers at all?  WDYT of something like
>
> (package
>   (name "gnurl")
>   [...]
>   (properties
>     ;; Keys that are considered ‘trustworthy’ for signing releases
>     ;; of gnurl.
>     `((permitted-pgp-signing-keys "CABB A99E ..." "DEAD BEEF ...")
>       ;; Locations of PGP key (possibly with some of them pointing to
>       ;; the same key)
>       (pgp-key-locations
>         ,(savannah-pgp-key USER-ID) ... ; most signers are on savannah.gnu.org
>         ,(local-file "[...]/someone.pub") ; not easily available from the Web               
>         "https://rando/key.pub"
>         "ipfs://.../..." "gnunet://...")))) ; download key via P2P networks
>
> The first part (permitted-pgp-signing-keys) has been suggested previously and
> seems mostly orthogonal, but the second part is new.  It would reduce
> the dependency on central infrastructure.  We could consider key servers
> to be ‘merely’ another fallback.

We could also have our own key server.  Just like ‘guix lint -c
archival’ triggers SWH archival, we could have a tool that triggers key
download on the server so that crypto material never vanishes.

Food for thought…

Ludo’.

Re: Finding a “good” OpenPGP key server

[Tanguy LE CARROUR]

Hi Ludo’,


Quoting Ludovic Courtès (2022-05-30 17:34:43)
> Maxime Devos <maximedevos@telenet.be> skribis:
> 
> > Ludovic Courtès schreef op ma 18-04-2022 om 22:24 [+0200]:
> >> [... guix refresh -u stuff failing due to not finding the key ...]
> >> I’m not sure what a good solution is (other than looking for the key
> >> manually on Savannah or on some random key server).
> >
> > Alternatively, why use key servers at all?  WDYT of something like
> >
> > (package
> >   (name "gnurl")
> >   [...]
> >   (properties
> >     ;; Keys that are considered ‘trustworthy’ for signing releases
> >     ;; of gnurl.
> >     `((permitted-pgp-signing-keys "CABB A99E ..." "DEAD BEEF ...")
> >       ;; Locations of PGP key (possibly with some of them pointing to
> >       ;; the same key)
> >       (pgp-key-locations
> >         ,(savannah-pgp-key USER-ID) ... ; most signers are on savannah.gnu.org
> >         ,(local-file "[...]/someone.pub") ; not easily available from the Web               
> >         "https://rando/key.pub"
> >         "ipfs://.../..." "gnunet://...")))) ; download key via P2P networks
> >
> > The first part (permitted-pgp-signing-keys) has been suggested previously and
> > seems mostly orthogonal, but the second part is new.  It would reduce
> > the dependency on central infrastructure.  We could consider key servers
> > to be ‘merely’ another fallback.
> 
> We could also have our own key server.  Just like ‘guix lint -c
> archival’ triggers SWH archival, we could have a tool that triggers key
> download on the server so that crypto material never vanishes.

That would be a solution, I guess. But what would be the cost of setting
it up and maintaining it?
Is gnurl the only package with this problem or is it something that happens often?!

Regards,

-- 
Tanguy

Re: Finding a “good” OpenPGP key server

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 2078 bytes --]

Ludovic Courtès schreef op ma 30-05-2022 om 17:34 [+0200]:
> > (package
> >    (name "gnurl")
> >    [...]
> >    (properties
> >      ;; Keys that are considered ‘trustworthy’ for signing releases
> >      ;; of gnurl.
> >      `((permitted-pgp-signing-keys "CABB A99E ..." "DEAD BEEF ...")
> >        ;; Locations of PGP key (possibly with some of them pointing
> > to
> >        ;; the same key)
> >        (pgp-key-locations
> >          ,(savannah-pgp-key USER-ID) ... ; most signers are on
> > savannah.gnu.org
> >          ,(local-file "[...]/someone.pub") ; not easily available
> > from the Web               
> >          "https://rando/key.pub"
> >          "ipfs://.../..." "gnunet://...")))) ; download key via P2P
> > networks
> > 
> > The first part (permitted-pgp-signing-keys) has been suggested
> > previously and
> > seems mostly orthogonal, but the second part is new.  It would
> > reduce
> > the dependency on central infrastructure.  We could consider key
> > servers
> > to be ‘merely’ another fallback.
> 
> We could also have our own key server.  Just like ‘guix lint -c
> archival’ triggers SWH archival, we could have a tool that triggers
> key download on the server so that crypto material never vanishes.

Is archival important here though?  If the crypto material vanishes,
presumably that means the corresponding author stopped updating the
source code, so it won't be useful anymore (except for after-the-fact
verification?).

What benefit would a Guix key server bring us?

I guess my suggestion is to skip any intermediate infrastructure and
let the Guix repo itself be the key ‘server’ (when using local-file
(*)) or download directly from the site where the key is located.

(*) if space is concern, there are some GPG options that can be used
for stripping out the photo ids and the various signatures by other
people and keep only the bits actually required by Guix.

Greetings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: Finding a “good” OpenPGP key server

[Vagrant Cascadian]

[-- Attachment #1: Type: text/plain, Size: 2080 bytes --]

On 2022-05-30, Ludovic Courtès wrote:
> Maxime Devos <maximedevos@telenet.be> skribis:
>
>> Ludovic Courtès schreef op ma 18-04-2022 om 22:24 [+0200]:
>>> [... guix refresh -u stuff failing due to not finding the key ...]
>>> I’m not sure what a good solution is (other than looking for the key
>>> manually on Savannah or on some random key server).
>>
>> Alternatively, why use key servers at all?  WDYT of something like
>>
>> (package
>>   (name "gnurl")
>>   [...]
>>   (properties
>>     ;; Keys that are considered ‘trustworthy’ for signing releases
>>     ;; of gnurl.
>>     `((permitted-pgp-signing-keys "CABB A99E ..." "DEAD BEEF ...")
>>       ;; Locations of PGP key (possibly with some of them pointing to
>>       ;; the same key)
>>       (pgp-key-locations
>>         ,(savannah-pgp-key USER-ID) ... ; most signers are on savannah.gnu.org
>>         ,(local-file "[...]/someone.pub") ; not easily available from the Web               
>>         "https://rando/key.pub"
>>         "ipfs://.../..." "gnunet://...")))) ; download key via P2P networks
>>
>> The first part (permitted-pgp-signing-keys) has been suggested previously and
>> seems mostly orthogonal, but the second part is new.  It would reduce
>> the dependency on central infrastructure.  We could consider key servers
>> to be ‘merely’ another fallback.
>
> We could also have our own key server.  Just like ‘guix lint -c
> archival’ triggers SWH archival, we could have a tool that triggers key
> download on the server so that crypto material never vanishes.

Or keep some keyrings in a git repo, if we want to keep the keys
somewhat restricted to committers... a major problem of the public
keyserver network is/was the ability for anyone to update or add any key
for anybody.

We've already got the keyring branch in guix.git, maybe adding an
upstream-keys branch wouldn't be madness? Or a separate git
repository. And then you could get it archived at software heritage or
archive.org or whatever trivially.


live well,
  vagrant

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

Re: Finding a “good” OpenPGP key server

[zimoun]

Hi,

On mar., 31 mai 2022 at 08:09, Vagrant Cascadian <vagrant@debian.org> wrote:

> Or keep some keyrings in a git repo, if we want to keep the keys
> somewhat restricted to committers... a major problem of the public
> keyserver network is/was the ability for anyone to update or add any key
> for anybody.
>
> We've already got the keyring branch in guix.git, maybe adding an
> upstream-keys branch wouldn't be madness? Or a separate git
> repository. And then you could get it archived at software heritage or
> archive.org or whatever trivially.

I have not closely followed all the thread.  Just to mention that the
upstream-keys branch or separate Git repository using Software Heritage
or archive.org as backup require some tests for complete robustness.

I have in mind some examples where it is not “trivial” to get back from
SWH; because their cooking vault is slow, because the repo is big or
complex, etc.

That’s said, I agree that Git seems the easiest for preserving keyrings.


Cheers,
simon

Re: Finding a “good” OpenPGP key server

[Ludovic Courtès]

Maxime Devos <maximedevos@telenet.be> skribis:

> Ludovic Courtès schreef op ma 30-05-2022 om 17:34 [+0200]:

[...]

>> We could also have our own key server.  Just like ‘guix lint -c
>> archival’ triggers SWH archival, we could have a tool that triggers
>> key download on the server so that crypto material never vanishes.
>
> Is archival important here though?  If the crypto material vanishes,
> presumably that means the corresponding author stopped updating the
> source code, so it won't be useful anymore (except for after-the-fact
> verification?).

If you want to be able to authenticate software, even after the fact,
then key material needs to be available (that’s why the commit
authentication framework lets you store keys in the repo).

> What benefit would a Guix key server bring us?

It would allow us to archive signing keys of all the software packages
ever added to Guix.

I can picture a new ambitious project that we could call:
OpenPGP Key Heritage.

> I guess my suggestion is to skip any intermediate infrastructure and
> let the Guix repo itself be the key ‘server’ (when using local-file
> (*)) or download directly from the site where the key is located.
>
> (*) if space is concern, there are some GPG options that can be used
> for stripping out the photo ids and the various signatures by other
> people and keep only the bits actually required by Guix.

Let’s assume 10K packages are signed, and that the signing key changes
once per year.  After 5 years, we’d have accumulated 50K OpenPGP
certificates in the repo.  Even if they are stripped (no user ID, no
photo, etc.), that’s still non-negligible.

So yes, I’d rather have it out-of-band.  :-)

Ludo’.

Re: Finding a “good” OpenPGP key server

[Ludovic Courtès]

Vagrant Cascadian <vagrant@debian.org> skribis:

> We've already got the keyring branch in guix.git, maybe adding an
> upstream-keys branch wouldn't be madness? Or a separate git
> repository. And then you could get it archived at software heritage or
> archive.org or whatever trivially.

Yes, that sounds reasonable to me.

Ludo’.