Hi,
On Wed, 2022-06-15 at 06:03 +0200, Kiss Gabor (Bitman) wrote:
> And moreover how will I do?
You can parse the file with, e.g., sequoia.
But you surely knew that you can parse the file, so I wonder what you're
trying to convey with your message.
Best,
Tobi
Hi,
On Fri, 2019-08-16 at 19:28 -0400, brent s. wrote:
> SO for starters, please keep this off the "pool is shrinking" thread.
> I'd like to see that thread relevant to resolving resiliency issues of
> the SKS network, given that's the actual purpose behind starting that
> thread. GDPR is off-topi
Hi,
On Tue, 2019-08-13 at 11:59 -0400, Robert J. Hansen wrote:
> If I, as a US citizen with no
> overseas business ties, receive a GDPR notice, I'm going to laugh and
> throw it away as it's not binding within the US. The EU can't even
> haul me into court over it.
Fair enough. Then you're igno
Hi,
On Tue, 2019-08-13 at 11:00 -0400, Robert J. Hansen wrote:
> > They are!
>
> No, they're not.
I think your assessment is wrong.
>
> There are (or at least were) a large number of US-based keyserver
> operators who were immune to the GDPR.
I fail to see how this is in accordance with the GD
Hi,
On Mon, 2019-05-13 at 19:35 +0200, ilf wrote:
> So far, I stand by last year's statement:
>
> > tl;dr: Keep calm and keep running keyservers.
>
Are you standing by your statement because you believe that processing
that data is lawful or because you don't fear the consequences of a
potentia
Hi,
On Wed, 2018-11-21 at 15:42 -0800, Todd Fleisher wrote:
> onto the public SKS network that many people rely on every day.
do we have actual numbers here?
Cheers,
Tobi
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailm
Hi,
On Wed, 2018-11-07 at 12:33 +0100, Wiktor Kwapisiewicz via Autocrypt
wrote:
> If cryptographic verification was enough for X.509 there
> wouldn't be Certificate Transparency
CT solves a slightly different set of problems related to
the centralised trust model that we don't necessarily have.
T
On Wed, 2018-11-07 at 17:34 +0100, Werner Koch wrote:
> Thus removing the search capability from the keyservers
> will render its free-as-in-beer storage feature mostly useless.
Only if you assume that nobody creates such an index.
Cheers,
Tobi
___
S
Hi,
On Wed, 2018-11-07 at 10:13 +0100, Werner Koch wrote:
> This requires that there are no rogue keyservers in the network and
> that
> in turn means that they are under the control of a single entity.
It depends on your use case, but you might be happy enough if you have a
proof of who introduce
Hi!
On Mon, Jul 06, 2015 at 08:22:48AM -0700, Daniel Roesler wrote:
> Ok, just confirmed that openpgp-python can still parse the pool.
Cool! Thanks for that.
> Do you have a public key that throws an exception?
I tried a couple of years back:
http://lists.nongnu.org/archive/html/sks-devel/2012-06
Hi Hanno!
On So, 2015-03-22 at 12:58 +0100, Hanno Böck wrote:
> Code:
> https://github.com/hannob/pgpecosystem
>
This is great work, thanks.
I tried to parse SKS dumps in the past, but I failed miserably, using
python-openpgp.
I'm looking forward to seeing your implementation.
Have you seen the
Hi.
On Fr, 2015-04-10 at 17:18 -0400, Daniel Kahn Gillmor wrote:
> I consider this a bug in SKS, if it can overconsume RAM on the basis
> of one misbehaving or rejecting peer.
>
> the implication is that a network attacker can force any SKS server
> into this state.
>
> Have you filed a bug repo
Heya :)
On Fri, Jun 08, 2012 at 10:11:11AM +0200, Sebastian Urbach wrote:
> [...] if something goes wrong
> with the import. Better loose 5000 than 15000 keys.
For the fun of it, I tried to parse a few weekly dumps and very often,
not even GPG can successfully parse the packets, i.e. gpg --list-p
13 matches
Mail list logo
