On Mon 12/Aug/2019 19:27:49 +0200 Peter Lebbing wrote:
> On 12/08/2019 18:39, Stefan Claas via Gnupg-users wrote:
>> Why was is then not fixed a decade ago, like it was done with 2.2.17?
>
> There is no fix for the SKS keyserver network, which explains why it
> wasn't fixed in 2.2.17 either. In fa
On 12/08/2019 15:47, Ralph Seichter wrote:
> * da...@gbenet.com:
>
>> putting this code on Github whist demonstrating a point - was foolish
>
> No, it was not. Foolish would be to pretend the conceptual flaw does not
> exist, cover your ears with your hands and go "la la la".
>
>> To say that th
On Tue, 13 Aug 2019 09:54, gnupg-users@gnupg.org said:
> The bug, however, is in the program that chokes on poisoned keys!
Nope. This is a long standing DoS protection by limiting the total
length of a keyblock. The diagnostics were a bit misleading, though.
The time it took to process all the
On 13/08/2019 09:54, Alessandro Vesely via Gnupg-users wrote:
> More than a reasonable number of signatures makes no sense in
> practice, so I agree lists should somehow be "fixed" so as not to
> accept an unreasonable number of signatures (reasonable == 2??)
Others tell us: the synchronization pr
On 12.08.2019 19:09, vedaal via Gnupg-users wrote:
> Can this really be done?
>
> (Does not matter so much to me personally, as I grew up with v3
> keys, and even when using a V4 key, I don't generate a subkey, but
> allow all the functions (sign, encrypt. certify) to be done with the
> master key
I suspect we haven't seen this issue being done in the real world before
because it is not a useful attack in many scenarios. It's just a nasty
DoS that can be avoided by not using the SKS keyserver network. I'm
completely speculating, but I think that the people who really want to
learn something
On 12/08/2019 22:09, U'll Be King Of The Stars wrote:
> The things I missed are:
>
> - how to check and clean a user's local keyring
>
> - how to update the user's local configuration in ~/.gnupg
I generally felt there was a lack of concise, complete instructions for
users, after the event. I wa
On 13/08/2019 13:56, Kristian Fiskerstrand wrote:
> As you correctly point out its really not that relevant for encryption
> subkeys. It does have security implementations for signing subkeys; see
> [cross-certification section] for some details on that.
But this issue has been fixed for so long t
Peter Lebbing wrote:
[snip]
> Furthermore, the end goal is for all hosts to have the same dataset, so
> let's define progress as that the hosts become more and more alike: when
> the number of differences between the hosts has reduced, we have made
> progress. Once completed, it has progressed to
Peter Lebbing wrote:
> > I wonder why those SKS key servers are so important to be still in
> > service as of today since we have WKD, Hagrid, keybase, Mailvelope Key
> > Server and Facebook?
>
> Only people using the SKS keyserver network are affected by this issue.
> You say you don't see a rea
> Good write-up. Now I have a question, in hope that SKS operators are
> reading this too. I have learned from Robert's gist that the max. is
> 150.000 sigs per key the servers can handle, if I am not mistaken.
I didn't say this.
I said they handle up to about that, *because we've seen keys with
> I don't think the bit about the OCaml code complexity was a good
> argument in Rob's gist post.
In my defense, I wrote that front-to-back in under an hour. My goal was
to quickly release a useful précis, not to slowly write a definitive
reference on the problem. :)
That said, this particular
On 13/08/2019 17:11, Robert J. Hansen wrote:
>> I think the proper fix is to design an alternative to the SKS keyserver
>> network. The design choices in the reconciliation protocol don't work
>> out anymore, we shouldn't change the protocol but replace it.
>
> I agree.
Ah, then the discussion ab
Robert J. Hansen wrote:
> > Good write-up. Now I have a question, in hope that SKS operators are
> > reading this too. I have learned from Robert's gist that the max. is
> > 150.000 sigs per key the servers can handle, if I am not mistaken.
>
> I didn't say this.
>
> I said they handle up to abo
On 8/13/2019 at 7:59 AM, "Kristian Fiskerstrand"
wrote:
>As you correctly point out its really not that relevant for
>encryption
>subkeys. It does have security implementations for signing
>subkeys; see
>[cross-certification section] for some details on that.
>
>References:
>[cross-certific
15 matches
Mail list logo
