On Thu, 10 Dec 2020 11:07, Casey Marshall said:
>- Authenticated key management. This adds a couple of extra endpoints
>which allow a key owner to replace and delete their key, authenticated by
>signing the armored key in the request. This allows a key owner to still
>update their
On Mon, 27 May 2019 13:30, kristian.fiskerstr...@sumptuouscapital.com
said:
> requiring load-balanced setup with minimum of 3 nodes on modern hardware
> (e.g a node today requires a minimum of 8 GiB of RAM to be responsive
> during merge of certain keys). The propagation time between the servers
On Sun, 26 May 2019 22:39, gnupg-de...@spodhuis.org said:
> With the various problems of SKS today, I tentatively suggest that not
> defaulting to the HKPS pool and choosing a different target for the
> keys.gnupg.net CNAME might be beneficial.
FWIW, keys.gnupg.net is since gnupg 2.2.7 not a
On Sat, 25 May 2019 14:53, i...@zeromail.org said:
> ilf:
>> Now I would like to know: Did any keyserver admin(s) receive any
>> (serious) GDPR-related complaint? Or even an official complaint by a
>> data protection authority? Or even a penalty like a fine?
You mean from the left over 5 servers
On Wed, 7 Nov 2018 11:50, andr...@andrewg.com said:
> significantly affecting legitimate use. It may stop people uploading
> warez but it can’t prevent cheap vandalism.
Free storage to upload arbitrary data is easily available (e.g. p2p,
free mail accounts). Having a searchable index to that
On Tue, 6 Nov 2018 17:27, a...@datenreisen.de said:
> I do roughly recal that such a verification process has been discussed for
> the SKS keyservers at one of the pgp-summit before, but i wonder what
> happened to the idea. However, if it that is “good enough” to be compliant
This requires
On Tue, 6 Nov 2018 17:57, v...@pep-project.org said:
> I'm not of the opinion that key servers are a good idea at all. It's
> a pity that people still follow this wrong idea.
Keyservers are used for several purposes:
1. Search for keys based on the fingerprint ("gpg --recv-key FPR")
2. Search
On Fri, 9 May 2014 02:14, cl...@jhcloos.com said:
Now that sks-keyservers.net6. is signed, it would be useful to add
TLSA RRs at:
Sure. However, I would really like to get a new beta out and not keep
on adding useful features without having a a working and beta released
code base.
Hi,
thanks for the comments. To get things straight, let me summarize my
understanding:
For plain HTTP:
- No change to the current code
or
- Resolve the name while following CNAME records to get a list of IP
addresses. Then connect any server at its IP address but use the
On Wed, 7 May 2014 18:17, kristian.fiskerstr...@sumptuouscapital.com
said:
(i) as tmphost is derived from getnameinfo, the PTR record will be
used. A concrete example would be sks.karotte.org that resolve to
176.9.51.79 which has a PTR of alita.karotte.org. However no keyserver
is configured
Hi,
I can't remember whether I announced it, but since some weeks
keys.gnupg.net is a CNAME to pool.sks-keyservers.net
and
http-keys.gnupg.net is a CNAME to ha.pool.sks-keyservers.net
The reason for this change is that it is useless to spend a lot of work
in maintaining such a second
On Fri, 3 Jul 2009 20:49, jhar...@widomaker.com said:
Unfortunately, this corrupted key is even on the non-SKS keyservers...
Sorry, about the false alarm.
I was pretty sure that I noticed that kind of corruption on several keys
and thus figured that it is a keyserver problem. However at
On Mon, 23 Mar 2009 21:17, d...@fifthhorseman.net said:
Who controls keys.gnupg.net? Werner? Do you have plans to do any
filtering like this? It seems like it would be useful to have a pool
that rejects hosts that at least admit to running versions with
significant known bugs.
13 matches
Mail list logo
