1. 28
  1. 14

    [full disclosure: I’m the Phil referenced; I’m not an SKS maintainer, but did write various wiki pages and do have patches in the codebase]

    The attacks causing disks to fill are problems with specific keys breaking reconciliation and triggering transaction failures in BDB, leading to many GB of disk usage by those unable to get the broken key.

    On-disk size has gone from around 6GB to 40+GB in the space of a couple of weeks, and that’s what’s knocked a bunch of SKS systems offline, repeatedly. All the decades of cruft is an order of magnitude less disk space than that caused by a couple of keys designed to break SKS.

    Also, Kristian is one of the SKS developers, but is not the original developer. He, like everyone else involved, is a volunteer with a day-job unrelated to SKS.

    I’ve been on the SKS devel mailing-list for probably 8 years (guess) and I’ve never seen hostility to the idea that SKS should change or to any reasonable proposal for doing so. I’ve seen various levels of resignation and annoyance at (1) people who propose changes without thinking through how to deal with the fundamental SKS reconciliation algorithm; (2) people who make demands that others do work for them, but never contribute patches themselves. The Almighty Designers who sketch out a non-viable proposal and can’t understand why others aren’t prepared to leap to do the work to make their vision a reality.

    In stark contrast, in March Andrew Gallagher posted (thread “SKS apocalypse mitigation”) and took on board the points about algorithm and design issues and himself put in the effort to design something which might work. Haven’t seen code yet, but he’s demonstrated how easy it is to get a productive discussion if you’re willing to take account of engineering design constraints; so many before have instead pouted and stomped their feet and said “well that should be fixed”.

    Hockeypuck has been around for a few years; it’s gained a little traction, but is not a silver bullet: it peers by using the SKS reconciliation algorithm and what’s needed is a design approach to change how reconciliation happens, not just a different codebase. SKS itself is GPLv2, Hockeypuck is AGPLv3, both are available for folks to work on and propose changes.

    1. 2

      i added the SKS apocalypse mitigation thread to the article so people can read whats going on.

      1. 1

        Thank you for the reply, i have added an edit about why the servers have gone off line. Could you send me the link to Andrew gallaghers thread i would be interested in reading it. i found the link

        1. 3

          I like how we get the update that you found the link, but not the link itself 😂

            1. 3

              <3

        2. 1

          Thanks. As a user, even though I enjoyed reading the post and be aware of the issues, I like to always hear/read the other side of the story/argument.