On Donnerstag, 9. Juni 2022 22:29:52 CEST Jan Eden via Gnupg-users wrote:
> Sorry, the output of gpgconf referred to a changed configuration. This
> is what happens for me with GnuPG 2.3.4:
>
> value for `keyserver` in gpg.conf → keyserver used with `--refresh-key`
> hkp://keys.gnupg.net → hkp://p
On 2022-06-09 22:13, Jan Eden via Gnupg-users wrote:
>
> On 2022-06-09 21:40, Ingo Klöcker wrote:
> > On Donnerstag, 9. Juni 2022 17:38:04 CEST Mark via Gnupg-users wrote:
> > > I just looked at what Kleopatra has it set for and it has it set for
> > > hkp://keys.gnupg.net as well. I'm guessing th
On 2022-06-09 21:40, Ingo Klöcker wrote:
> On Donnerstag, 9. Juni 2022 17:38:04 CEST Mark via Gnupg-users wrote:
> > I just looked at what Kleopatra has it set for and it has it set for
> > hkp://keys.gnupg.net as well. I'm guessing that is no longer the best
> > choice?
>
> Kleopatra 3.1.21.2204
On Donnerstag, 9. Juni 2022 17:38:04 CEST Mark via Gnupg-users wrote:
> I just looked at what Kleopatra has it set for and it has it set for
> hkp://keys.gnupg.net as well. I'm guessing that is no longer the best
> choice?
Kleopatra 3.1.21.220401 uses whatever `gpgconf --list-options dirmngr` retu
I just looked at what Kleopatra has it set for and it has it set for
hkp://keys.gnupg.net as well. I'm guessing that is no longer the best
choice?
On 6/9/2022 5:01 AM, Andrew Gallagher via Gnupg-users wrote:
On 09/06/2022 12:20, Jan Eden wrote:
I had configured hkp://keys.gnupg.net in gpg.conf
On 09/06/2022 12:20, Jan Eden wrote:
> I had configured hkp://keys.gnupg.net in gpg.conf (no separate
> dirmngr.conf). Switching to keys.openpgp.org had the desired effect:
keys.gnupg.net has not existed for a few years now, but for backwards
compatibility gnupg silently maps it to the hardcoded d
On 2022-06-09 12:08, Andrew Gallagher wrote:
> On 09/06/2022 11:50, Jan Eden wrote:
> > jan ~ % gpg --refresh-key 0xFB73E21AF1163937
> > gpg: refreshing 1 key from hkp://pgp.surf.nl
> > gpg: key FB73E21AF1163937: "Andrew Gallagher " not
> > changed
> > gpg: Total number processed: 1
> > gpg:
On 09/06/2022 11:50, Jan Eden wrote:
> jan ~ % gpg --refresh-key 0xFB73E21AF1163937
> gpg: refreshing 1 key from hkp://pgp.surf.nl
> gpg: key FB73E21AF1163937: "Andrew Gallagher " not
> changed
> gpg: Total number processed: 1
> gpg: unchanged: 1
You're using the pgp.surf.nl keyserve
On 2022-06-09 10:40, Werner Koch wrote:
> On Thu, 9 Jun 2022 08:11, Jan Eden said:
>
> > Now I corrected the mistake, and all is well.
>
> I don't think this is your mistake. We need to do something about it.
> Tracked at https://dev.gnupg.org/T6023
>
> BTW, to ignore local keys and update fro
On 2022-06-09 11:37, Andrew Gallagher wrote:
> On 09/06/2022 07:11, Jan Eden wrote:
> > PS. The key used to sign your message seems to be expired.
>
> That could be because you already had my key in your keyring and it
> wasn't recently (i.e. in the last 18 months) refreshed. What does it say
> i
On 09/06/2022 07:11, Jan Eden wrote:
> PS. The key used to sign your message seems to be expired.
That could be because you already had my key in your keyring and it
wasn't recently (i.e. in the last 18 months) refreshed. What does it say
if you incant the following?
```
gpg --refresh-key 0xFB73E
On Thu, 9 Jun 2022 08:11, Jan Eden said:
> Now I corrected the mistake, and all is well.
I don't think this is your mistake. We need to do something about it.
Tracked at https://dev.gnupg.org/T6023
BTW, to ignore local keys and update from WKD (or whatever has been
configured) you can use --lo
On Fri, 3 Jun 2022 18:05, Frank said:
> And I am currently eyeing at the 'ELF visibility' check in the
> configure script.
That is pretty old code from 2007. I do not remember any details; it is
possible that this is based on Uli Drepper's original paper. it was
originally implemented for Libg
13 matches
Mail list logo
