sks-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Sks-devel] Presenting Peaks


From: Andrea Grazioso
Subject: [Sks-devel] Presenting Peaks
Date: Fri, 15 Mar 2019 16:14:34 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0

Hello everyone,

as the "SKS is effectively running as end-of-life software
at this point", thread pointed out, a new implementation of a
keyserver would need to:

- be totally backward compatible, both with the current keyserver
infrastructure, and client (i.e GnuPG)
- be robust to "silly" attacks, like limiting UID size, UIDs per key,
certificate size, all to a reasonable size (as in "normal usage", having
more than 100 UID per single certificate IMHO is not quite normal)
- be robust to data corruption
- have a modular source, understandable, upgradeable, customizable as needed

The one of the main problems of SKS itself, was the lack of proper
documentation, which does not encourage developers to dive in the
internal of the OCaml code to understand how the current keyserver works

Now we want to present our keyserver, Peaks, which we like to describe
as a modern and modular keyserver (is more like an OpenPGP framework
with a built in keyserver, but the definition holds).

Peaks is by design:

- modular: the keyserver itself is split in several modules, all data
is stored in a RDBMS (we picked MySQL)
- extensible: is possible to support several databases, add modules for
the keyserver, change the internal parameters, etc.
- documented: the code is documented via Doxygen, and the actual
keyserver interal mechanism is explained in several documents [0]
- natively multithreaded: no need to cluster 2+ instances to search keys
while the database is working
- modern: written totally in C++, based on modern libraries [2]
- fully compatible with the current SKS synchronization protocol, to
ease gradual deployment


Regarding problematic keys, especially vulnerable keys our proposal is
to stop synchronizing old key material, keeping just up-to-date
certificates regarding standard security practises, and leaving the
certificates which do not meet the standard in a read-only storage, not
to be synchronized again

Developing from scratch Peaks took a significant effort, which we are
happy to freely provide to the OpenPGP community.
Currently an instance of Peaks is running at peaks.deib.polimi.it [3], and
is synchronized (acting as a client only) with the sks network.

Lastly, we believe in the OpenPGP community, hopefully the source code
and the documentation will attract developers which would be able to
further contribute to the project, and we welcome any feedback.

[0] https://github.com/r4yan2/peaks/tree/master/doc
[2] https://github.com/r4yan2/peaks
[3] http://peaks.deib.polimi.it

Attachment: 0x91FFB243503240F0.asc
Description: application/pgp-keys

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]