andrewg wrote:
> Speaking for the current SKS keyserver operators, it *is* currently
> working. There are occasional glitches when vandals find a way around
> our flooding protections, but we are constantly improving these. (I
> realise I'm tempting fate by say
On 2025-01-30 11:29, Michael Richardson wrote:
I think that that the place where we actually need to differ from the
past is
actually the flood-fill between key servers. I think that's probably
not
going to work.
Speaking for the current SKS keyserver operators, it *is* currently
wo
I was awake a bunch last night, and I was pondering the six points that Seth
made. I am more and more concerned with having key servers have access to
revocation (certificates), and I have no understanding how this will work with
key server to key server communication. It seems to me that there
e key that relate it to
the data subject? Potentially, yes. Though an important detail to note is that
for the keyserver to remove UID information from a pubic key, that key must be
revoked. And it can be reasonably expected that most or all references to the
now-revoked public key would be removed
> Thank you for this post.
> It's not particularly GNUPG specific, maybe this belongs on open...@ietf.org.
Thanks, I'll give it a look!
> Re Steps 3,4,5:
>
> * The keyserver sends the resultant hash to Alice via email using the email
> address given on her public k
Thank you for this post.
It's not particularly GNUPG specific, maybe this belongs on open...@ietf.org.
Maybe your gist should become an Internet-Draft.
Re Steps 3,4,5:
* The keyserver sends the resultant hash to Alice via email using the email
address given on her public key's UI
S
network transitioned away from the sks-keyserver software (which was unable to
handle deletion requests or poisoned keys) to the more modern hockeypuck
software (see https://hockeypuck.io <https://hockeypuck.io/>). In the meantime,
keys.openpgp.org <http://keys.openpgp.org/> was set up a
at rectifying the design of the keyserver
network. I've written a detailed outline in a GitHub Gist, which I'll link
below. But to give a brief summary, I break down the requirements of a modern
keyserver network into six main criteria, including the storage and
distribution of public
st hagrid, although I haven’t tested it.
> I have seen https://github.com/SKS-Keyserver/sks-keyserver but still
> have to check it out if it really suites my needs.
SKS-keyserver is very similar to hockeypuck (hockeypuck was first developed as
an SKS-keyserver replacement). It does have the
start with, but you can export a single key to a file with the suffix “.gpg” and it should suffice. and at least hagrid is noteven /intended/ to be "self hosted".I’m pretty sure you can self-host hagrid, although I haven’t tested it.I have seen https://github.com/SKS-Keyserver/sks-key
On 07.07.23 12:21, Werner Koch wrote:
> https://www.gnupg.org/blog/20201018-gnupg-and-ldap.html
Thanks, I will have a look into it.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users
On Fri, 7 Jul 2023 10:59, Bernd Naumann said:
> For a test setup / proof of concent / lab, I'm looking for a pretty
> simple keyserver implementation.
Use an LDAP server; this is the most flexible and best supported way to
store keys.
https://www.gnupg.org/blog/20201018-gnupg-an
Hi *,
For a test setup / proof of concent / lab, I'm looking for a pretty
simple keyserver implementation.
I don't need any form of validation, web ui, etc.
At least I want to be able to disable send mail validation, federation,
web server, and what not.
I just want to be able t
Hi,
I am using Debian 10. My key was verified... I think you are right. At
that time (~3yrs back) I more worried about spam from publishing it on
the keyserver.
I'm pretty sure that is what it is. I didn't verify my email. Since I
was using the same machine to know more about gpg, i
On 10/02/2022 13:23, Raja Saha wrote:
I created the subkey, output it to a file and imported it to gpg on
working dir. Then I sent the key to the keyserver, gpg --send-keys
*. After that when I searched the keyserver by my email it, there
was no key. When I searched by my key
e the export command to set the dir, but instead
toggled the names of the ~/.gnupg dir to shift between the two dirs in
gpg.
I created the subkey, output it to a file and imported it to gpg on
working dir. Then I sent the key to the keyserver, gpg --send-keys
*. After that when I searche
On Tue, 27 Jul 2021 11:12, root said:
> I am new to GnuPG and this is a great tool in programming. I am not sure how
> to
> use gpg commands directly in C/C++ codes though. I thought gpgme is
> providing the
> interface to use gpg ?
Yes, please use GPGME or the GPGME C++ bindings
Salam-Shalom
ly line in dirmngr.conf (except for comments) is:
>> keyserver hkps://keys.openpgp.org
OK, I could figure it out, finally:
Beyond Linux From Scratch (BLFS) do not use ntbTLS for TLS, they use gnuTLS.
But in connection with an update of gnupg I had installed ntbTLS in my
former syst
On Sat, 2021-07-31 at 19:56 +0200, Rainer Fiebig wrote:
> Am 31.07.21 um 17:40 schrieb Werner Koch:
> > On Thu, 29 Jul 2021 18:36, Andrew Gallagher said:
> >
> > > If you built gnupg from its default configuration, it does not
> > > automatically look in /etc/ssl/certs for CA certificates. You may
> > Try "gnutls-cli keys.openpgp.org". If it does not get into "Simple
> > Client Mode" as expected, it means p11-kit trust store may be
> > disrupted.
> > Try "make-ca -f -g" to rebuild it.
> >
> > And check if your p11-kit was built
Simple
> Client Mode" as expected, it means p11-kit trust store may be disrupted.
> Try "make-ca -f -g" to rebuild it.
>
> And check if your p11-kit was built with
> -Dtrust_paths=/etc/pki/anchors as the BLFS book says. If not sure,
> rebuild it. (I can also r
Am 31.07.21 um 21:00 schrieb Xi Ruoyao:
> On Sat, 2021-07-31 at 19:56 +0200, Rainer Fiebig wrote:
>> Am 31.07.21 um 17:40 schrieb Werner Koch:
>>> On Thu, 29 Jul 2021 18:36, Andrew Gallagher said:
>>>
If you built gnupg from its default configuration, it does not
automatically look in /et
Am 31.07.21 um 17:40 schrieb Werner Koch:
> On Thu, 29 Jul 2021 18:36, Andrew Gallagher said:
>
>> If you built gnupg from its default configuration, it does not
>> automatically look in /etc/ssl/certs for CA certificates. You may want
>
> On Unix and unless gnupg was build with --with-default-tr
On Thu, 29 Jul 2021 18:36, Andrew Gallagher said:
> If you built gnupg from its default configuration, it does not
> automatically look in /etc/ssl/certs for CA certificates. You may want
On Unix and unless gnupg was build with --with-default-trust-store-file
the following collections of certific
5C084DEBE9B26995E310250568
gpg: data source: https://keys.openpgp.org:443
(1) Łukasz Langa (GPG langa.pl)
Łukasz Langa
Łukasz Langa
4096 bit RSA key B26995E310250568, erzeugt: 2015-05-11
Keys 1-1 of 1 for "E3FF2839C048B25C084DEBE9B26995E310250568". Ei
Am 29.07.21 um 19:36 schrieb Andrew Gallagher:
> On 29/07/2021 17:52, Rainer Fiebig wrote:
>>
>> ~> openssl x509 -text > After"
>> Not After : Sep 30 14:01:15 2021 GMT
>
> So the file exists, and appears to have the correct contents (the
> difference in checksum is probably whitespace
On 29/07/2021 17:52, Rainer Fiebig wrote:
~> openssl x509 -text
So the file exists, and appears to have the correct contents (the
difference in checksum is probably whitespace or commentary, I wouldn't
worry about it).
I'm going to refer back to my earlier statement: "It looks like dirmngr
Am 29.07.21 um 18:45 schrieb Andrew Gallagher:
> On 29/07/2021 17:33, Rainer Fiebig wrote:
>> Thanks. File exists but has a different checksum:
>>
>> /etc/ssl/certs> sha256sum DST_Root_CA_X3.pem
>> 4b3ecda4db3f417f23f5dfa84eb4d59d6cc2959446ebaf89c7df5866d31e9980
>> DST_Root_CA_X3.pem
>
> Ah, I won
On 29/07/2021 17:33, Rainer Fiebig wrote:
Thanks. File exists but has a different checksum:
/etc/ssl/certs> sha256sum DST_Root_CA_X3.pem
4b3ecda4db3f417f23f5dfa84eb4d59d6cc2959446ebaf89c7df5866d31e9980
DST_Root_CA_X3.pem
Ah, I wonder is the expiry date different. Can you incant the following
Am 29.07.21 um 18:16 schrieb Andrew Gallagher:
> On 29/07/2021 08:41, Rainer Fiebig via Gnupg-users wrote:
>> Am 28.07.21 um 21:38 schrieb Ingo Klöcker:
>>> On Mittwoch, 28. Juli 2021 18:38:07 CEST Rainer Fiebig via Gnupg-users
> wrote:
>>>
>>> Does
On 29/07/2021 08:41, Rainer Fiebig via Gnupg-users wrote:
Am 28.07.21 um 21:38 schrieb Ingo Klöcker:
On Mittwoch, 28. Juli 2021 18:38:07 CEST Rainer Fiebig via Gnupg-users
wrote:
>>
Does 'gpg --keyserver hkps://pgpkeys.eu --search-keys ...' work for you?
No, same ou
>>
>> Correct.
>>
>>> keys.openpgp.org uses LetsEncrypt as their TLS CA. Can you connect to
>>> other keyservers that also use LetsEncrypt? For example, pgpkeys.eu uses
>>> the same intermediate certificate (LetsEncrypt R3) as keys.openpgp.org.
>&
eir TLS CA. Can you connect to
> > other keyservers that also use LetsEncrypt? For example, pgpkeys.eu uses
> > the same intermediate certificate (LetsEncrypt R3) as keys.openpgp.org.
>
> This works:
>
> ~> gpg --keyserver pgpkeys.eu --search-keys
> E3FF2839C048B25C084DEBE9B
es as "Missing
> publisher certificate in the chain", is that correct?
>
Correct.
> keys.openpgp.org uses LetsEncrypt as their TLS CA. Can you connect to
> other keyservers that also use LetsEncrypt? For example, pgpkeys.eu uses
> the same intermediate cer
On 28/07/2021 15:19, Rainer Fiebig via Gnupg-users wrote:
2021-07-28 16:06:50 dirmngr[4135.6] Fehler beim Verbinden mit
'https://keys.openpgp.org:443': Fehlendes Herausgeberzertifikat in der Kette
2021-07-28 16:06:50 dirmngr[4135.6] command 'KS_SEARCH' failed:
Fehlendes Herausgeberzertifikat in d
ly line in dirmngr.conf (except for comments) is:
>> keyserver hkps://keys.openpgp.org
>
> note that this particular keyserver has decided to be incompatible with
> the current OpenPGP standard, by ommitting a valid user id, unless
> it was "validated".
> (It says
Hi Rainer,
Am Mittwoch 28 Juli 2021 11:22:18 schrieb Rainer Fiebig via Gnupg-users:
> Hi! I'm having a problem when searching for keys on keyservers when
> using "gpg --search-keys".
>
> The only line in dirmngr.conf (except for comments) is:
> keyserver hkps://ke
Hi! I'm having a problem when searching for keys on keyservers when
using "gpg --search-keys".
The only line in dirmngr.conf (except for comments) is:
keyserver hkps://keys.openpgp.org
gnupg version is 2.2.29 but I also see this with 2.2.27.
Locale is German but "Kein &quo
be
> used for any crypto operations like signing, encrypting, etc. because the
> public key data has _not_ been imported. The keys have just been listed. This
> is very similar to listing the keys on a keyserver without actually
> retrieving
> the public keys from the keyserver.
>
been imported. The keys have just been listed. This
is very similar to listing the keys on a keyserver without actually retrieving
the public keys from the keyserver.
> Alternatively, if I do gpgme_op_keylist_start() using an email address with
> GPGME_KEYLIST_MODE_EXTERN, the key->can_en
Hi, all
I've posted this question on stackoverflow.com a few days ago, and I am still
waiting for someone to comment.
https://stackoverflow.com/questions/68490051/key-retrieved-from-keyserver-keys-openpgp-org-cant-be-used-gpgme
Long story short, when the public key is downloaded to my PC
Am 25.06.21 um 00:14 schrieb Brandon Anderson via Gnupg-users:
>
>> The keyserver situation seems a bit difficult currently, maybe
>> https://keys.openpgp.org/ is the best (easiest) workaround for now.
>>
>> But WKD is really worth looking at!
>>
>
> My un
stions would be appreciated.
Hey Alex,
From what I can tell a lot of the keyservers are being shutdown. Take a
look at the message on the SKS site (the SSL cert is expired)
https://sks-keyservers.net/.
The keyserver *pools* at sks-keyservers.net are no longer maintained for
legal
The keyserver situation seems a bit difficult currently, maybe
https://keys.openpgp.org/ is the best (easiest) workaround for now.
But WKD is really worth looking at!
My understanding is the Ubuntu Key-server is staying up, I could be
wrong, but https://keyserver.ubuntu.com/ seems to be
ciated.
One alternative could be https://keys.openpgp.org/
This keyserver has one big advantage, when you upload a key there, this
server verifies the email address associated with that key is valid and
you have actual access to this email address. Fake keys have no chance
there.
Now, it also has on
Starting on the morning of June 21 between ~6am and 9am PDT, one of
our CI jobs which fetches gpg keys with:
gpg --keyserver hkp://pool.sks-keyservers.net
<http://pool.sks-keyservers.net> --recv-keys ...
started failing because of what looks like a failure to resolve
the poo
Starting on the morning of June 21 between ~6am and 9am PDT, one of our CI
jobs which fetches gpg keys with:
gpg --keyserver hkp://pool.sks-keyservers.net --recv-keys ...
started failing because of what looks like a failure to resolve the
pool name.
FWIW the following also fails in the
g you a great Sunday.
Best regards,
christian
On 07.03.21, 11:12, "Andrew Gallagher via Gnupg-users"
wrote:
Hi, Christian
>
> And, actually, we deployed our own (hkp://keyserver.dcc.sib.swiss:80)
keyserver, which I am trying to access. But can't for som
Hi Christian,
Am Sa den 6. Mär 2021 um 8:44 schrieb Christian Ribeaud:
> Desperately searching for hours now???
> I am NOT able to run following command:
>
> gpg --keyserver hkp://keyserver.dcc.sib.swiss:80 --keyserver-options
> no-self-sigs-only,no-import-clean --search-ke
Hi, Christian
>
> And, actually, we deployed our own (hkp://keyserver.dcc.sib.swiss:80)
keyserver, which I am trying to access. But can't for some reason I do
not understand.
I can connect to that server from here, but it appear to contain only 85
keys. Did you import a dump, or
Stefan,
Thanks for your answer.
Up to you, which one should I take for testing? There is a lot of red here…
And, actually, we deployed our own (hkp://keyserver.dcc.sib.swiss:80)
keyserver, which I am trying to access. But can't for some reason I do not
understand.
This instance is wo
Good morning,
Desperately searching for hours now…
I am NOT able to run following command:
gpg --keyserver hkp://keyserver.dcc.sib.swiss:80 --keyserver-options
no-self-sigs-only,no-import-clean --search-keys
Always getting following output:
gpg: error searching keyserver: No keyserver
On Mon, Dec 14, 2020 at 5:24 PM Casey Marshall via Gnupg-users
wrote:
>> [...]
> The fix to this issue was to have Hockeypuck remove all packets lacking a
> currently-valid self-signature from responses. This removes fake packets
> (like the uat example) as well as expired identities. The self-
>
> Date: Fri, 11 Dec 2020 17:56:24 +
> From: Stefan Claas
> To: Casey Marshall via Gnupg-users ,
> sks-de...@nongnu.org, Casey Marshall
> Subject: Re: [Keyserver] Hockeypuck 2.1.0 released
> Message-ID:
> <
> cac6fiz6epr-eud0azmcvz7m4c9hxga1isfg
consider that an authenticated request to delete a key may not
> actually remove the key from the keyserver? Instead the the primary key
> should be kept and the server prepared to receive and merge even
> unauthenticated revocation certificates. This is important in case of a
&
update their own key once it has been inflated beyond the key
Finally after more than 20 years waiting for someone to implement such a
feature. Yeah. Where can I find the specs?
Did you consider that an authenticated request to delete a key may not
actually remove the key from the keyserver?
> On 11 Dec 2020, at 05:11, Casey Marshall via Gnupg-users
> wrote:
>
> Peers across these more divergent cohorts may still peer at a lower
> frequency, so key material accepted by both may still propagate.
But the problem with divergence isn’t loss of efficiency - divergent servers
don’t gr
>
> Date: Thu, 10 Dec 2020 19:59:46 +
> From: Andrew Gallagher
> To: SKS Development and Deployment discussion ,
> GnuPG Users
> Subject: Re: [Keyserver] Hockeypuck 2.1.0 released
> Message-ID:
> Content-Type: text/plain; charset="utf-8"; Forma
es that may be useful to mitigate
spamming/flooding/DoS [1] attacks on GnuPG and keyservers. See the
release link for details, but here's the highlights:
* Configurable key length and packet size limits, with sensible
defaults to limit keyserver resource consumption (1MB and 8K
s the highlights:
- Configurable key length and packet size limits, with sensible defaults
to limit keyserver resource consumption (1MB and 8K respectively).
- Configurable blacklist of primary key fingerprints.
- Authenticated key management. This adds a couple of extra endpoints
which allo
?q=Mageia-7.1-x86_64.iso
>
> were it says you can import the key to verify the iso.
>
> But kleopatra stays without reaction (no matter how many pools I join) and
>
> entropia@roadrunner:~> gpg --keyserver pool.sks-keyservers.net --recv-keys
> EDCA7A90
> gpg: using c
entropia@roadrunner:~> gpg --keyserver pool.sks-keyservers.net --recv-keys
EDCA7A90
Now I remember time ago there was an issue of keyservers abused and the
structure
was halted.
What is the current status and how can one download a signature as of today?
Manually or with a "keyserverpage&q
If it is a technical challenge and Kristian as head (pool maintainer),
why does he not ask publicity
the hockeypuck author, dkg and the sequoia-team, for help?
As an example, if I would be Kristian I would do so, set-up with my
pool gang a hockeypuck
test-net (bootstrapped with a handful of pub ke
> On 24 Oct 2020, at 10:41, Stefan Claas via Gnupg-users
> wrote:
>
> there can
> be no consensus achieved between privacy loving EU citizens and (US
> based) SKS operators
Most SKS operators are (were?) based outside the US. This is primarily a
technical challenge, not a political one.
A
an solve the issues
>
> To me
> it makes sense to preserve a decentalised network of public keyservers [1].
>
> In my post
> Preserving non-central and privacy with a "permission recording keyserver"
> [Reiter 2019-07 a]
> https://lists.gnupg.org/pipermail/
On 23/10/2020 13:23, Andrew Gallagher wrote:
> * Hints could take the form of fake preferred-keyserver subpackets, in a
> similar manner to fake "fpr:DEADBEEF" user-id packets that have been
> previously discussed to support UID-less key refresh on legacy systems
> (could
On 23/10/2020 10:14, Bernhard Reiter wrote:
> So yes, I also believe that improvements to hockeypuck or a fresh
> implementation could step by step get the public keyserver network up again.
I've thought about this quite a bit after my previous attempts to
reconcile recon wit
Am Samstag 19 September 2020 23:34:32 schrieb Stefan Claas:
> I stand by my points that hockeypuck can solve the issues
To me
it makes sense to preserve a decentalised network of public keyservers [1].
In my post
Preserving non-central and privacy with a "permission recording k
Hi
On Sunday 20 September 2020 at 11:29:07 PM, in
, Mark wrote:-
> I'm the one that asked the original question in
> regards to GPG4Win. I
> know with the latest version the default is
> "hkp://keys.gnupg.net"
Thanks, Mark.
hkp://keys.gnupg.net is an alias for hkps://hkps.pool.sks-keyservers.
gt; your post that hkps.pool.sks-keyservers.net "is now returning zero results".
> I had noticed the GnuPG manual says the default keyserver is
> hkps.pool.sks-keyservers.net. I was under the impression the default had been
> changed to the Hagrid keyserver at keys.ope
stion that occurred to me when I read in
your post that hkps.pool.sks-keyservers.net "is now returning zero results". I
had noticed the GnuPG manual says the default keyserver is
hkps.pool.sks-keyservers.net. I was under the impression the default had been
changed to the Hagrid keyserver
Hi Andrew,
On Sat, 19 Sep 2020 21:38:22 +0200,
Andrew Gallagher wrote:
> Hagrid “solves” the vandalism problem by abandoning
> decentralisation.
This is not strictly true.
When we think about updating keys, there are two types of information
that can be updated:
- Identity Information (User I
Andrew Gallagher wrote:
>
> > On 19 Sep 2020, at 21:06, Stefan Claas wrote:
> >
> > *With all due respect*, the problems you mention with the SKS protocol is
> > IMHO absolutely solvable with hockeypuck if the
> > author implements the same Mailvelope or Hagrid confirmation process for
> > i
Stefan Claas wrote in
<20200919201736.2...@300baud.de>:
|Robert J. Hansen wrote:
|>> It is true the attacks were what brought it down, but the amount \
|>> of effort was not a "sustained
|>> attack" by any measure. The invested resources are somewhere around \
|>> "couple hours and $0.00"
> On 19 Sep 2020, at 21:06, Stefan Claas wrote:
>
> *With all due respect*, the problems you mention with the SKS protocol is
> IMHO absolutely solvable with hockeypuck if the author
> implements the same Mailvelope or Hagrid confirmation process for its users
If you have not yet read the mega
Andrew Gallagher wrote:
>
> > On 19 Sep 2020, at 20:05, Stefan Claas wrote:
> >
> > Well, there is IMHO a good replacement for SKS available, called
> > hockeypuck and it is written in modern Golang.
>
> This is beside the point. SKS is both a protocol and an implementation.
> Hockeypuck is
sults.
>
>
> The GnuPG manual's description [0] of the Dirmngr option "--keyserver name"
> still ends with "If no keyserver is explicitly configured, dirmngr will use
> the built-in default of hkps://hkps.pool.sks-keyservers.net." Is this still
> true, or w
> On 19 Sep 2020, at 20:05, Stefan Claas wrote:
>
> Well, there is IMHO a good replacement for SKS available, called
> hockeypuck and it is written in modern Golang.
This is beside the point. SKS is both a protocol and an implementation.
Hockeypuck is a reimplementation of the same protocol an
Steffen Nurpmeso wrote:
> Stefan Claas wrote in
> <20200919201736.2...@300baud.de>:
> |Robert J. Hansen wrote:
> |>> It is true the attacks were what brought it down, but the amount \
> |>> of effort was not a "sustained
> |>> attack" by any measure. The invested resources are somewhere
Robert J. Hansen wrote:
> > It is true the attacks were what brought it down, but the amount of effort
> > was not a "sustained
> > attack" by any measure. The invested resources are somewhere around "couple
> > hours and $0.00".
>
> I'm not sure that's true.
[...]
I think it does not matter
> It is true the attacks were what brought it down, but the amount of effort
> was not a "sustained
> attack" by any measure. The invested resources are somewhere around "couple
> hours and $0.00".
I'm not sure that's true.
The keyserver poisoning at
Hi
On Friday 18 September 2020 at 4:32:55 PM, in
, Phil
Pennock via Gnupg-users wrote:-
> keys.gnupg.net is a CNAME for
> hkps.pool.sks-keyservers.net -- which is
> now returning zero results.
The GnuPG manual's description [0] of the Dirmngr option "--keyserver name"
rt was
not a "sustained
attack" by any measure. The invested resources are somewhere around "couple
hours and $0.00".
- V
[single server]: https://sks-keyservers.net/status/ (hkps column)
[1.1.6]:
https://github.com/SKS-Keyserver/sk
On 2020-09-18 at 15:04 +0200, accounts-gn...@holbrook.no wrote:
> Is it possible to define multiple sources of keys with WKD, for example
> with a dns TXT record? The use-case would be if the main server is down,
> alternative places to get it.
The SRV record approach had to be dropped because the
kps.pool.sks-keyservers.net -- which is
> now returning zero results.
>
> The pool of is Very Unhealthy. The entire keyserver
> system had Known Issues but worked well enough that the volunteers who
> ran it could keep it alive and improving, until it came under sustained
> attac
Hello,
>Is it possible to define multiple sources of keys with WKD, for example
>with a dns TXT record?
Well, yes, actually. This can be done with both X509 certificates (where it is
called SMIMEA) and gpg keys. Obtaining a key basically involves quering the
appropriate TYPE in the DNS record (
;m also interested if there is a better choice.
keys.gnupg.net is a CNAME for hkps.pool.sks-keyservers.net -- which is
now returning zero results.
The pool of SKS keyservers is Very Unhealthy. The entire keyserver
system had Known Issues but worked well enough that the volunteers who
ran it c
On 2020-09-18 at 10:08 +0200, Franck Routier (perso) wrote:
> Le jeudi 17 septembre 2020 à 18:13 -0400, Phil Pennock via Gnupg-users
> a écrit :
> > If publishing keys, I do recommend setting up WKD for your
> > domain, which helps a little.
>
> What is the status of WKD now, and is it to superse
2020 1:57 PM, Martin wrote:
> Hi list
>
> Which keyserver do you recommend these days?
>
> I have hkps://keys.openpgp.org in gpg.conf - but it seems that there
> are missing a lot of public keys on this server.
>
>
>
> ___
> Gn
I wasn't aware of WKD, thanks for the heads up.
Is it possible to define multiple sources of keys with WKD, for example
with a dns TXT record? The use-case would be if the main server is down,
alternative places to get it.
On Fri, Sep 18, 2020 at 12:55:45PM +0200, Vincent Breitmoser via Gnupg-us
> What is the status of WKD now, and is it to superseed centralized key
> servers ?
Not for folks who have their email address at the domain of an email provider,
or an organization that doesn't support WKD. So statistically, everyone but
a rounding error.
That said, for folks who run their own
Le jeudi 17 septembre 2020 à 18:13 -0400, Phil Pennock via Gnupg-users
a écrit :
> If publishing keys, I do recommend setting up WKD for your
> domain, which helps a little.
What is the status of WKD now, and is it to superseed centralized key
servers ?
Franck
_
On 2020-09-17 at 22:57 +0200, Martin wrote:
> Which keyserver do you recommend these days?
For what purpose?
For receiving updates to previously known keys, of people who care
enough about their keys to distribute their keys across multiple
keyservers instead of just going "I pushed i
Martin wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hi list
>
> Which keyserver do you recommend these days?
>
> I have hkps://keys.openpgp.org in gpg.conf - but it seems that there
> are missing a lot of public keys on this server.
Hi,
goo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi list
Which keyserver do you recommend these days?
I have hkps://keys.openpgp.org in gpg.conf - but it seems that there
are missing a lot of public keys on this server.
- --
Best regards,
Martin
-BEGIN PGP SIGNATURE
On Mon, 6 Jul 2020 09:11, Jerry said:
> gpg2 --refresh-keys
> gpg: enabled debug flags: memstat
> gpg: refreshing 168 keys from hkp://pool.sks-keyservers.net
> gpg: keyserver refresh failed: No keyserver available
Please add in the error case always the --verbose option which ma
Jerry wrote:
> I have not been able to refresh the keys on my system. I have run the
> following command with the error as shown.
>
> gpg2 --refresh-keys
> gpg: enabled debug flags: memstat
> gpg: refreshing 168 keys from hkp://pool.sks-keyservers.net
> gpg: keyserv
-keyservers.net
gpg: keyserver refresh failed: No keyserver available
gpg: keydb: handles=1 locks=0 parse=168 get=168
gpg:build=0 update=0 insert=0 delete=0
gpg:reset=0 found=168 not=1 cache=0 not=0
gpg: kid_not_found_cache: count=0 peak=0 flushes=0
gpg: sig_cache: total=0 cached=0
Thanks I will update it and make sure both Kleopatra and Enigmail are
using the same one so they are "on the same page"
On 5/15/2020 11:55 PM, Michał Górny wrote:
> On Fri, 2020-05-15 at 16:52 -0700, Mark wrote:
>> I know this may be a subjective question but what is the best
On Fri, 2020-05-15 at 16:52 -0700, Mark wrote:
> I know this may be a subjective question but what is the best keyserver
> to use? I use GPG4Win with the Enigmail plugin for Thunderbird. The
> keyservers listed in Enigmail are:
>
> vks://keys.openpgp.org, hkps://hkps.pool.sks
1 - 100 of 843 matches
Mail list logo
