On 2018-05-05 at 10:27 +0100, Andrew Gallagher wrote:
> Sorry for the double. We don’t need to modify the protocol to enable
> such checks. Whenever a server tries to recon with us, we can perform
> a callback against its status page and run whatever sanity tests we
> want before deciding whether t
The underlying recon algorithm can be stopped at any time and only the
discovered
differences can be processed. In other words, it should be possible to put an
explicit
timeout on recon time - you will get a partial synchronization, but that might
be good
enough as long as you reconcile at a fa
On 05/05/2018 10:22 AM, Andrew Gallagher wrote:
>
>> On 5 May 2018, at 15:00, brent s. wrote:
>>
>> (a) is taken care of by recon already (in a way),
>
> According to a list message from earlier today it is not. If the delta is
> small, recon proceeds. If it is large, it breaks catastrophically
> On 5 May 2018, at 15:00, brent s. wrote:
>
> (a) is taken care of by recon already (in a way),
According to a list message from earlier today it is not. If the delta is
small, recon proceeds. If it is large, it breaks catastrophically. There is no
(current) way to test nicely.
> but the pr
On 05/05/2018 08:30 AM, Andrew Gallagher wrote:
>
>> On 5 May 2018, at 11:31, brent s. wrote:
>>
>> it is SO IMPORTANT for both ends of the peering to have a relatively
>> recent keyset. i don't see how we can "fix" this without entirely
>> restructuring how HKP recon behaves,
>
> Yes. Perhaps
> On 5 May 2018, at 11:31, brent s. wrote:
>
> it is SO IMPORTANT for both ends of the peering to have a relatively
> recent keyset. i don't see how we can "fix" this without entirely
> restructuring how HKP recon behaves,
Yes. Perhaps it would be a good idea to systematise the dump/restore pr
> On 5 May 2018, at 10:55, Kiss Gabor (Bitman) wrote:
>
> Suboptimal solutions are also acceptable.
> I don't think we alwys need the best (and most expensive way).
> "Almost the best" is good enough in most of practical cases.
We need to define our metric to determine what particular degrees o
On 05/05/2018 03:48 AM, Phil Pennock wrote:
> On 2018-05-04 at 17:13 +0100, Andrew Gallagher wrote:
>> AFAICT, the limitation that SKS servers should only recon with known
>> peers was introduced as a measure against abuse. But it's a pretty
>> flimsy anti-abuse system considering that anyone can s
> > Requests may be "iterative" or "recursive" (words are stolen from DNS).
> > Users send recursive request: "I don't care how many peers
> > you ask, but tell me the key with all signatures."
>
> The DNS has a hierarchical structure that allows the authoritative source for
> data to be found wi
> On 5 May 2018, at 09:38, Andrew Gallagher wrote:
>
>
>> On 5 May 2018, at 09:03, Phil Pennock wrote:
>>
>> While you could modify the protocol to do something like announce a
>> key-count first, that's still only protection against accidental
>> misconfiguration
>
Sorry for the double. We
> On 5 May 2018, at 09:03, Phil Pennock wrote:
>
> While you could modify the protocol to do something like announce a
> key-count first, that's still only protection against accidental
> misconfiguration
That’s exactly what I’m talking about. Since the majority of the problems that
you have e
On 2018-05-05 at 08:53 +0100, Andrew Gallagher wrote:
> > On 5 May 2018, at 08:48, Phil Pennock wrote:
> > If you peer with someone with no keys
> > loaded, it will render your server nearly inoperable.
>
> I was aware that recon would fail in this case but not that the failure mode
> would be s
> On 5 May 2018, at 07:00, Gabor Kiss wrote:
>
> Okay, brain storming in progress. :-)
:-)
> Requests may be "iterative" or "recursive" (words are stolen from DNS).
> Users send recursive request: "I don't care how many peers
> you ask, but tell me the key with all signatures."
The DNS has a
> On 5 May 2018, at 08:48, Phil Pennock wrote:
>
> If you peer with someone with no keys
> loaded, it will render your server nearly inoperable.
I was aware that recon would fail in this case but not that the failure mode
would be so catastrophic. Is there no test for key difference before rec
On 2018-05-04 at 17:13 +0100, Andrew Gallagher wrote:
> AFAICT, the limitation that SKS servers should only recon with known
> peers was introduced as a measure against abuse. But it's a pretty
> flimsy anti-abuse system considering that anyone can submit or search
> for anything over the HKP inter
15 matches
Mail list logo
