> It's written in an unusual programming language called OCaml, and in a fairly idiosyncratic dialect of it at that. This is of course no problem for a proof of concept meant to support a Ph.D thesis, but for software that's deployed in the field it makes maintenance quite difficult. Not only do we need to be bright enough to understand an algorithm that's literally someone's Ph.D thesis, but we need expertise in obscure programming languages and strange programming customs.
Looking at the code [0], it looks like fairly standard Ocaml. Any particular reason it's difficult to maintain (other than the lack of popularity of FP in general)?
(It looks like the original author of the SKS Keyserver is Yaron Minsky, the guy who convinced Jane Street to use Ocaml.)
To the commenters blaming OCaml - it is being used in the Project Everest[1] (along with F#) for creating a proven network security stack. Basically, they created ML-like language called F*[2], which fits the task perfectly. There is also a pure OCaml implementation[3] of TLS stack, along with x509[4].
> Any particular reason it's difficult to maintain (other than the lack of popularity of FP in general)?
A much bigger issue than the language itself is the overall architecture of the server. It uses Berkeley DB as the main database and only handles one connection at a time. So, if your gossip process starts syncing a huge spam key, you block all front-end web requests (see my issue #61[1]). Also, the keyserver is completely synchronous, so you effectively have to cluster multiple keyservers running on different ports and different databases and load balance across them if you want to add any sort of scalability to your setup.
Overall, the server code feels like an MVP or academic implementation. Definitely not designed for high scale or the ability to handle abuse like this. It would take a heavy re-write to make get the server code to where it needs to be, which is why no one has stepped up yet.
BTW, I'd love to step up and write an sks-compatible keyserver in python (using postgres as the database), so that it could scale using something like uwsgi, but so far I haven't been able to find a mentor who can help me learn the gossip protocol that's largely undocumented.
Also according to TFA, the server apparently can cope with these pathological keys just fine, it's the GnuPG client, "production" code implemented in C, that falls over dead after it has downloaded the key from a server. Which leaves me puzzled why the server needs bashing.
Looks like fairly standard OCaml and usage of functional programming idioms. Q: Where's the CI and property tests? If you feel uncomfortable maintaining the code base, start there.
I’ve gotten stuck maintaining Python code for a testing framework and again for a CI/CD system. The fact that I know less than a junior programmer didn’t really slow me down that much, but it did make me a bit anxious.
One of those systems involved a large and obvious crypto component. If the python code had been part of that work instead of merely peripheral to it, I would have rewritten it.
Why? Because I can make python work but I can’t tell you if it’s safe. I have no idea what the weird gotchas are that look like good code but are not. What the “printf” of python is. Hackers do.
And I know even less about O’Caml. I would not sign up for that gig. Lots of the sort of rational and cautious people you want working on crypto would not.
I get that but in this case though this codebase has safety guarantees baked in via the Hindley–Milner (HM) type system whereas your python code base did not. Additionally there's a published, peer reviewed paper for this software that serves as a written specification. Those two things are fantastic resources when coming up to speed with an unfamiliar codebase.
I’m an old school strong, static typing proponent (strong typing shall rise again!) but I laugh at the notion that it protects you from crypto attacks.
Are you a maintainer or an armchair critic? I hope the latter, because if you think type safety is anything more than necessary but insufficient, then that’s number three.
Did he say it defends you against crypto attacks? It does defend you against a lot of attacks that would still endanger the system. Think denial of service attacks for exemple. Extremely easy in Python because bugs don't get caught at compile time.
The way I read it: In practice it's easy to DOS the server even if it's written in that language for which was here claimed to have a property of protecting from DOS. Especially due to the pooor scalability of it.
Also, there are few enough tests that I had to do a text search for the word test to spot them. How many ml files in the top directory, and the word test appears nine times.
So that’s the second big problem with this code, and it’s a huge one. The crypto project I worked on had better test coverage than anything I ever did before and quite possibly since. Because it was a dangerous animal and, like a responsible exotic pet owner, I treated it with respect at all times. Unlike the guy I took over the project from.
And because of my paranoid fastidiousness, I stopped a user from shipping with only 8 bits of entropy in their key generator. That would have been a fun bug for a DEFCON presentation.
is not an 'expression of confusion', it's an attempt at offtopic shitstirring and mockery. It's kind of dumb in the gist - keeping it up on HN (where it's sensibly forbidden) is worse.
Looking at the code [0], it looks like fairly standard Ocaml. Any particular reason it's difficult to maintain (other than the lack of popularity of FP in general)?
(It looks like the original author of the SKS Keyserver is Yaron Minsky, the guy who convinced Jane Street to use Ocaml.)
[0] https://bitbucket.org/skskeyserver/sks-keyserver/src/default...