Re: Finding a “good” OpenPGP key server

[Ludovic Courtès]

Vagrant Cascadian  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’.

Re: Finding a “good” OpenPGP key server

[Ludovic Courtès]

Maxime Devos  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

[zimoun]

Hi,

On mar., 31 mai 2022 at 08:09, Vagrant Cascadian  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

[Vagrant Cascadian]

On 2022-05-30, Ludovic Courtès wrote:
> Maxime Devos  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


signature.asc
Description: PGP signature

Re: Finding a “good” OpenPGP key server

[Maxime Devos]

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.


signature.asc
Description: This is a digitally signed message part

Re: Finding a “good” OpenPGP key server

[Tanguy LE CARROUR]

Hi Ludo’,


Quoting Ludovic Courtès (2022-05-30 17:34:43)
> Maxime Devos  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

[Ludovic Courtès]

Maxime Devos  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

[Maxime Devos]

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


signature.asc
Description: This is a digitally signed message part

Re: Finding a “good” OpenPGP key server

[Ludovic Courtès]

Hi,

Tanguy LE CARROUR  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 ;
 that doesn’t help much for the ‘guix refresh’ use case though.

Ludo’.

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  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

[Philip McGrath]

Hi,

On 4/18/22 16:24, Ludovic Courtès wrote:

Hi,

Tanguy LE CARROUR  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

[Ludovic Courtès]

Hi,

Tanguy LE CARROUR  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

[Tanguy LE CARROUR]

Hi Ludo’,

Thanks for updating the topic! :-)


Quoting Ludovic Courtès (2022-04-18 22:24:00)
> Tanguy LE CARROUR  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