On Fri 2019-02-08 20:44:33 +, Andrew Gallagher wrote:
> Parse the syslogs of an old style SKS server, fetch any updated
> packets, filter them and submit to the new server.
ah yes, the SMOP (it's a "Simple Matter of Programming") argument :)
> Sync from the old network to the new one only
> On 8 Feb 2019, at 19:02, Daniel Kahn Gillmor wrote:
>
> Figuring out how to do the partial-sync for a limited time sounds
> difficult to me, and i wonder whether it might be better/faster/cheaper
> to just deploy such an update-only network, and don't bother with the
> partial sync.
Parse
On Thu 2019-02-07 23:15:18 +0100, Kristian Fiskerstrand wrote:
> 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 at all on the keyservers, but require the user to do key
> discovery
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
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
> It is no use to wait a great consensus.
Without exception, I have never met someone who was reluctant to
volunteer someone else's time. I think this is unfortunate. I'd rather
we were as reluctant to urge other people to commit their time and
effort to a project as we are to commit our own.
> There are a handful of people with the background and skills to write a
> next-generation keyserver. I looked into it a dozen years ago and wrote
> up a whitepaper on it. I know Phil Pennock has put a lot of thought
> into it. Andrew, likewise. There are easily five or six people on this
>
> Is it possible to develop a keyserver thar uses the same interface as
> the current one?
Sort of.
> Meaning that GnuPG-Clients don't need to change
Yes.
> and current keyservers can recon with the new keyservers (since they
> are not all upgraded simultaniously)?
No. Keyserver
Hi
On 06/02/2019 19:28, Robert J. Hansen wrote:
>> If only it were open-source software and individuals with the extra time
>> and talent to work on those design flaws were able to do so. Wouldn't
>> that be a great world to live in?
> Wouldn't it be great if people were to think before snarking?
> On 6 Feb 2019, at 23:15, robots.txt fan wrote:
>
> To answer my first question, I guess that it is possible to implement a
> keyserver with the same interface for GPG users that can still recon with
> older servers. The older servers might try to send them keys that are on the
> blacklist
On Wed, 6 Feb 2019, 20:28 Robert J. Hansen
> It's a lack of community consensus on what a redesign should look like.
>
And, might I add, the desire for our efforts not to be ruined by others
"proving a point" rather than actors actually seeking malicious intent.
I've abandoned my keyserver, and
On 2/6/2019 11:26 AM, Andrew Gallagher wrote:
> On 06/02/2019 13:11, Steffen Kaiser wrote:
>> Is it meant litterally? The current SKS project is end of life and,
>> effectively, we have to look into another direction? Other software, new
>> fork with rewrite?
> I said "effectively", not
On 06/02/2019 13:11, Steffen Kaiser wrote:
> Is it meant litterally? The current SKS project is end of life and,
> effectively, we have to look into another direction? Other software, new
> fork with rewrite?
I said "effectively", not literally. And I was in a grumpy mood that
day. But I stand by
Hi,
Isn't Mozilla Thunderbird in a similar state? I'm still happily using it
*because* it has reached a point where further updates are rarely needed.
Best regards
Tobias Frei
On Wed, Feb 6, 2019, 14:22 Steffen Kaiser wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> I picked up
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I picked up this sentence here on the list in a thread about poison
key(s):
"> Any chance that sks will be fixed some day?
"Short answer, no. SKS is effectively running as end-of-life software at
this point. It gets emergency bugfixes but little
20 matches
Mail list logo
