For reasons of internal capacity and infrastructure re-engineering, we
are shutting down keyserver.pch.net. We do want to continue to
participate in the keyserver community, and hope to bring our service
back online again in the next few months.
Thanks to all our peers, and fellow keyserver
On 2/6/19 8:28 PM, Robert J. Hansen wrote:
> What we don't have is *consensus* -- not only among ourselves, but in
> the larger community.
The current discussions we're having (e.g during OpenPGP email summit in
brussels in october and lately on FOSDEM last weekend) is eventually not
storing UIDs
On 2019/02/06 23:51, Robert J. Hansen wrote:
> No. Keyserver reconciliation is 90% of the problem. Fixing this would
> make it impossible for older keyservers to reconcile with a next-gen design.
I have had a long think about this problem, and I reckon that the
biggest bar to progress is the
On 2019/02/07 11:01, Martin Dobrev wrote:
> My idea for blacklists is in a sense similar - during recon process
> consolidate hashes from the blacklists with whatever is in the live
> database and report this to peers. This way it won't trigger continuous
> *recon/fetch/drop due to blacklist*
On 2019/02/07 05:35, Gabor Kiss wrote:
> And all these programs can talk each to other due to RFC 821 (1982).
Well, yes. A good protocol is everything. The implementation is
relatively easy. Ensuring that the protocol doesn't result in a cascade
failure is the Really Hard Problem. We're still
Todd Fleisher dijo [Wed, Feb 06, 2019 at 08:24:38PM -0800]:
> FYI - that site generates an untrusted ssl certificate warning and
> after acknowledging that I get an error that the site couldn't be
> found on dreamboat.
You are right, I will now check with Dreamhost why this is
happening. Try the
On 07/02/2019 08:02, robots.txt fan wrote:
> On Thursday, February 7, 2019 12:37 AM, Andrew Gallagher
> wrote:
>> Because you can reject a key, but then what happens is it just keeps trying
>> to come back. Pretty soon there are so many rejected keys floating around
>> that the network stops
Robert,
No doubt it's risky to implement things that there is no consensus on. But
the device I'm writing this on was invented by *not a consensus*, and a
consensus to design it would not have emerged on this list nor elsewhere.
The risk may be lowered:
1) on behalf of our company I'm excited
On Thursday, February 7, 2019 12:37 AM, Andrew Gallagher
wrote:
> Because you can reject a key, but then what happens is it just keeps trying
> to come back. Pretty soon there are so many rejected keys floating around
> that the network stops reconciling. Also, what happens if I reject certain
