Config option for "Crypto Party" mode

Issue #45 wontfix
Volker Diels-Grabsch
created an issue

I'd like to add a configuration option for a "Crypto Party" mode (or however you wish to name it).

If that option is set, all gossip and other connections to keyservers are disabled completely. Moreover, the web interface provides a "Delete All Keys" button at an appropriate place.

Background: At crypto parties, among others, beginners are taught how to upload their keys if they chose to become part of the WoT. Usually these are test keys, perhaps including too much personal information by accident, having wrong key sizes, and/or are deleted afterwards and are hence just worthless noise to the WoT as a whole.

So I'm maintaining an SKS instance to be used at Crypto Parties that behaves like a normal keyserver for uploading and downloading, but with disabled gossip, where I manually delete the whole BDB directory from time to time.

I'd like to automate this. Of course I could put a separate web interface around it, and script the database deletion. However, I believe it makes more sense to integrate this feature directly into SKS, so that others can use it with less hassle than what I'm currently doing.

Comments (10)

  1. Kristian Fiskerstrand

    My take is that it is outside of scope (I do the same as you indicate, just resetting database using a script). Having an administrative user interface to delete etc doesn't seem relevant for the generic usage, as for gossipping this is already naturally supported by simply not providing any peers.

  2. Volker Diels-Grabsch reporter

    I agree that an administrative user interface for deletion may be over the top.

    However, resetting the database is also very ugly, as I have not yet found a way to do this without some annoying downtime. What I'm currently doing is (Debian):

    service sks stop
    rm -fr /var/lib/sks/DB /var/lib/sks/PTree
    su - debian-sks -c '/usr/sbin/sks build'
    service sks start
    

    Is there any more elegant way to that? Maybe removing all records using some BDB tools, or anything?

  3. Volker Diels-Grabsch reporter

    Thinking more about that, the ideal solution would be an automatic removal of sufficiently old keys. That is:

    • Define some "age" criteria (first upload? latest update? Whatever is easier to track)
    • Define some "max age" (not sure. 2 hours may be too short, 2 weeks may be too long, maybe make it configurable)

    My feature request is then:

    • SKS should automatically remove all entries whose "age" exceed the "max age". Ideally, directly within the SKS daemon, without having to run a cronjob.

    Would that be a feature of general interest? Is there any existing cleanup mechanism within SKS that already does something similar?

  4. Volker Diels-Grabsch reporter

    How exactly do you script that?

    Are there any BDB tools to delete all keys that have a certain age?

    Moreover, is it feasible to run that while SKS is running, or do I need to shutdown / restart SKS during cleanup?

  5. Kristian Fiskerstrand

    I don't understand the use case for "age", the keysigning is presumably reset for each event, which is scripted as you demonstrate above when setting up the server for the event.

    You can delete keys using sks drop <hash>, if you want to export a list based on some sorting criteria, look into iterating over the data in sksclient and https://bitbucket.org/kristianf/sks-keyserver-patches/src/1c72f694d235160e172a0a0f81a84e72898de7a4/SKSStats?at=default&fileviewer=file-view-default that you can use in combination with this to drop keys matching your criteria you can just build this as standalone utility similar to sksclient (check Makefile). But depending on use case you might want to check out hockeypuck to work directly with a RDBMS

  6. Volker Diels-Grabsch reporter

    Thanks for all the hints!

    The use case of "age" is that this keyserver may be used on multiple crypto parties, where I'm not always present, so an automatic cleanup makes the system more independent from my spare time availability. Also, crypto parties may overlap, so I might want to delete the keys for last week's party, but keep those from today and yesterday.

  7. Log in to comment