> It is no use to wait a great consensus.
Without exception, I have never met someone who was reluctant to
volunteer someone else's time. I think this is unfortunate. I'd rather
we were as reluctant to urge other people to commit their time and
effort to a project as we are to commit our own.
Additional note: Even when restricting append-only mode to the email field,
someone could upload keys for krypton...@domain.org to permanently store
the word "kryptonite" in the database. Also, one could use the first
characters of key IDs to store information, linking the keys together as
> There are a handful of people with the background and skills to write a
> next-generation keyserver. I looked into it a dozen years ago and wrote
> up a whitepaper on it. I know Phil Pennock has put a lot of thought
> into it. Andrew, likewise. There are easily five or six people on this
>
This sounds like you are missing the recommended DB_CONFIG values to prevent
your server from holding into those log files when an issue is encountered. As
I recall, the fix is to start over from scratch and rebuild after first putting
that file in place. It is covered in the list archives and
FYI - that site generates an untrusted ssl certificate warning and after
acknowledging that I get an error that the site couldn't be found on dreamboat.
Sent from the Fleishphone
> On Feb 6, 2019, at 19:15, Gunnar Wolf wrote:
>
> Kiss Gabor (Bitman) dijo [Tue, Jan 29, 2019 at 07:56:32PM
Kiss Gabor (Bitman) dijo [Tue, Jan 29, 2019 at 07:56:32PM +0100]:
> Hi folks,
>
> It is funny but one of my peer partners did not notice that his server
> is dead since a few months. :-)
>
> So I just show anyone who is interested in it how a simple but effective
> cron job warns me if my server
Hello,
Since a couple of days ago, I have noticed an incredible growth in
space usage (so much it has killed my server twice, hitting partition
limits). Since February 3rd, I have over 4000 files with binary-only
contents (could find no meaningful information in them) called
/var/lib/sks/DB/log.
> I disagree that we have to do a trade off, mostly for technical
> reasons.
Let's call forbidden information 'kryptonite'. Kryptonite is bad stuff.
We don't want it on moral grounds or legal grounds. We would rather
shut down keyservers than have kryptonite on our systems. We then have
three
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
I disagree that we have to do a trade off, mostly for technical
reasons.
The append-only database and gossip protocol only cares about
public key data, not additional key packet data (e.g. emails,
signatures, photos, etc.). So, it's entirely
I also applied these configuration options earlier today to all the servers in
1 of my pools that was experiencing high IO load and repeated SigAlarms:
command_timeout: 600
wserver_timeout: 30
max_recover: 150
And since then, everything has been quiet:
IO on the main node that gossips
To spare us all diving through list archives:
The keyserver network is in a lot of ways like a blockchain. In both
cases they are distributed ledgers where any change to the ledger is
propagated through to everyone with a copy of the ledger. (Blockchain
differs by adding more cryptographic
> Is it possible to develop a keyserver thar uses the same interface as
> the current one?
Sort of.
> Meaning that GnuPG-Clients don't need to change
Yes.
> and current keyservers can recon with the new keyservers (since they
> are not all upgraded simultaniously)?
No. Keyserver
Hi
On 06/02/2019 19:28, Robert J. Hansen wrote:
>> If only it were open-source software and individuals with the extra time
>> and talent to work on those design flaws were able to do so. Wouldn't
>> that be a great world to live in?
> Wouldn't it be great if people were to think before snarking?
> On 6 Feb 2019, at 23:15, robots.txt fan wrote:
>
> To answer my first question, I guess that it is possible to implement a
> keyserver with the same interface for GPG users that can still recon with
> older servers. The older servers might try to send them keys that are on the
> blacklist
Hi,
sks.powdarrmonkey.net has not been gossipping properly for a while because
of resource constraints. I have decided that it's not worth my while
reviving it every few weeks while the network find itself in such turmoil.
I only regret that I'm not in a position to offer a solution to some of
On Wed, 6 Feb 2019, 20:28 Robert J. Hansen
> It's a lack of community consensus on what a redesign should look like.
>
And, might I add, the desire for our efforts not to be ruined by others
"proving a point" rather than actors actually seeking malicious intent.
I've abandoned my keyserver, and
On 2/6/2019 11:26 AM, Andrew Gallagher wrote:
> On 06/02/2019 13:11, Steffen Kaiser wrote:
>> Is it meant litterally? The current SKS project is end of life and,
>> effectively, we have to look into another direction? Other software, new
>> fork with rewrite?
> I said "effectively", not
On 06/02/2019 13:11, Steffen Kaiser wrote:
> Is it meant litterally? The current SKS project is end of life and,
> effectively, we have to look into another direction? Other software, new
> fork with rewrite?
I said "effectively", not literally. And I was in a grumpy mood that
day. But I stand by
Hi,
Isn't Mozilla Thunderbird in a similar state? I'm still happily using it
*because* it has reached a point where further updates are rarely needed.
Best regards
Tobias Frei
On Wed, Feb 6, 2019, 14:22 Steffen Kaiser wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> I picked up
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I picked up this sentence here on the list in a thread about poison
key(s):
"> Any chance that sks will be fixed some day?
"Short answer, no. SKS is effectively running as end-of-life software at
this point. It gets emergency bugfixes but little
With your suggestions:
load average below 1
Traffic: ~150G/day
Best,
Rolf
Am 2019-02-04 12:52, schrieb Martin Dobrev:
Hi,
I've spent last week trying to optimize configuration as much as
possible. Following advise from a previous mail I've added:
command_timeout: 600
wserver_timeout:
21 matches
Mail list logo
