> On 7 Nov 2018, at 16:43, Yegor Timoshenko wrote:
>
> It's not just storage, it's also immutable and distributed.
In the keyservers, removing immutable content is a Very Hard Problem, but it is
theoretically possible.
With blockchain, it is impossible by design.
A
> Free storage to upload arbitrary data is easily available (e.g.
> p2p, free mail accounts). Having a searchable index to that
> data is more challenging. Thus removing the search capability
> from the keyservers will render its free-as-in-beer storage
> feature mostly useless.
It's not just
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 07.11.2018 11:50, Andrew Gallagher wrote:
>
>> On 7 Nov 2018, at 10:16, Yegor Timoshenko wrote:
>>
>> World-writable storage is problematic even if there is no search.
>> Proof of work and some operator-controllable data removal
>> mechanism (like opt-in key blacklists) can help limit this
> On 7 Nov 2018, at 10:16, Yegor Timoshenko wrote:
>
> World-writable storage is problematic even if there is no search.
> Proof of work and some operator-controllable data removal
> mechanism (like opt-in key blacklists) can help limit this attack
> vector.
>
> Storing immutable data,
> Purpose 4, distribution of key signatures, worked as long as
> people didn't used the key listings of the server or tools for
> more or less funny messages. Uploading key signature should be
> possible only by the holder of the key. However, to enforce
> this the keyservers need to employ real
> Purpose 4, distribution of key signatures, worked as long as
> people didn't used the key listings of the server or tools for
> more or less funny messages. Uploading key signature should be
> possible only by the holder of the key. However, to enforce
> this the keyservers need to employ real
So it seems like the usual response is to ignore the fatal issues that could
affect this network. 6 months on from the first set of PoC's and no one has
stepped forward to fix them - they have only attempted to defend the network
through pride. How is anyone meant to trust infrastructure run by
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 6 Nov 2018, at 20:09, Mike wrote:
>
> I don't think "resilient" can be used any more in relation to sks-keyservers
> as they drop offline on and off and even one malicious individual could take
> the whole network down if motivated enough.
Individual servers drop on and offline but the
I don't think "resilient" can be used any more in relation to sks-keyservers as
they drop offline on and off and even one malicious individual could take the
whole network down if motivated enough.
On Tue, 6 Nov 2018 18:34:49 +
Andrew Gallagher wrote:
>
> > On 6 Nov 2018, at 16:57,
I don't think "resilient" can be used any more in relation to sks-keyservers as
they drop offline on and off and even one malicious individual could take the
whole network down if motivated enough.
On Tue, 6 Nov 2018 18:34:49 +
Andrew Gallagher wrote:
>
> > On 6 Nov 2018, at 16:57,
On Tue, Nov 06, 2018 at 17:57 +0100, Volker Birk wrote:
> On Tue, Nov 06, 2018 at 05:27:14PM +0100, Andy Mueller-Maguhn wrote:
> > 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
On Tue, Nov 06, 2018 at 05:27:14PM +0100, Andy Mueller-Maguhn wrote:
> 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
>
On 23 May 2018, at 11:07, Patrick Brunschwig wrote:
> There are actually two different types of keyservers, which should be
> clearly distinguished.
>
> 1. the pool of SKS keyservers: as anyone can upload anybody's key, and
> as it does not allow to delete keys, it's IMHO by not compatible with
16 matches
Mail list logo
