> On Aug 15, 2019, at 3:33 PM, Werner Koch wrote:
>
> On Thu, 15 Aug 2019 00:02, gnupg-users@gnupg.org said:
>
>> But at least then we will want to add cryptography to see which
>> selfsigs are truly legitimate, right?
>
> That would be the first and most important step to get the keyservers
>
On Thu, 15 Aug 2019 00:02, gnupg-users@gnupg.org said:
> But at least then we will want to add cryptography to see which
> selfsigs are truly legitimate, right?
That would be the first and most important step to get the keyservers
back for the WoT
Shalom-Salam,
Werner
--
Die Gedanken sind
> On Aug 14, 2019, at 6:32 PM, MFPA via Gnupg-users
> wrote:
> On Wednesday 14 August 2019 at 10:39:56 AM, in
> , Alessandro Vesely
> via Gnupg-users wrote:-
>
>> I'm no expert, but it seems to me that 3rd party
>> signatures should not
>> be allowed.
>
> Perhaps a "keyserver no-third-party-s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi
On Wednesday 14 August 2019 at 10:39:56 AM, in
, Alessandro Vesely
via Gnupg-users wrote:-
> I'm no expert, but it seems to me that 3rd party
> signatures should not
> be allowed.
Perhaps a "keyserver no-third-party-signatures" option would re
On Wed, 14 Aug 2019 15:45, r...@sixdemonbag.org said:
> developed *more than twenty years ago* it was decided to support
> arbitrary numbers of third-party signatures. GnuPG faithfully
At least OpenPGP has this:
5.2.3.17. Key Server Preferences
(N octets of flags)
This is a list of o
> Can you give me a valid reason why anyone would want their key signed by
> 150,000 people or more?? How can you meet 150,000 people?
Sure, if you can give me a valid reason why I *should* give you a valid
reason.
Seriously.
I'm not a GnuPG developer. I don't run an SKS keyserver. I know a go
On 14/08/2019 12:29, Vincent Breitmoser wrote:
>> The algorithm is designed to withstand very well funded actors,
>> oppressive regimes were what the designers were thinking of.
>
> We are talking about a sand castle here that was kicked down by a kid. It's
> a bit bizarre to claim that it was bui
On 14/08/2019 12:09, Andrew Gallagher wrote:
> Indeed, but that condition is fundamentally incompatible with
> decentralised reconciliation - because deletion without permissions
> management is an open door, and permissions have to be enforced by an
> authority.
H the authority could just
On 14/08/2019 11:39, Alessandro Vesely via Gnupg-users wrote:
> Absolute monotonicity is wrong. It must be possible to delete errors.
In that case we need a different algorithm.
Which I had already been advocating, so you are preaching to the choir.
You can keep reiterating that you do not like
Hello David,
> Can you give me a valid reason why anyone would want their key signed by
> 150,000 people or more??
I don't see anybody claiming that this is a valid use case.
There are several issues preventing actually limiting this in the
current keyserver network, but this has already been ex
On 13/08/2019 15:54, 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
> The algorithm is designed to withstand very well funded actors,
> oppressive regimes were what the designers were thinking of.
We are talking about a sand castle here that was kicked down by a kid. It's
a bit bizarre to claim that it was built to withstand rockets.
Given that the recon algori
On 14/08/2019 10:39, Alessandro Vesely via Gnupg-users wrote:
> Absolute monotonicity is wrong. It must be possible to delete errors.
Indeed, but that condition is fundamentally incompatible with
decentralised reconciliation - because deletion without permissions
management is an open door, and p
On Tue 13/Aug/2019 13:07:07 +0200 Peter Lebbing wrote:
> 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
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
> 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
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
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
18 matches
Mail list logo