Mostly been working on tier6 [0], which is "like" zerotier but over the sanctum protocol and fully open source (ISC licensed).
Getting ready to release a 1.0.0 of sanctum [1], after almost a year of internal testing, dogfooding and talking about it at security conferences.
We've also setup conclave [2] as an official release site for the projects tied to sanctum such as tier6, or the library implementation of the protocol etc.
Working on cross-flock discovery in sanctum [1] so I can cut a 1.0 release hopefully before Christmas.
I am always looking for more people to test and play with it or even review the code. We've got a nice little user community going.
Usually this comments drowns in the crowd of the massive amount of awesome stuff people are building, but if you find sanctum useful, hit me up. Good things are happening.
Soon approaching a 1.0 release for sanctum once I get my brain out of vacation mode and into hacking mode again. A lot has happened this year and I am excited.
I will be talking about how sanctum and its cathedrals work at sec-t 2025 [2] so in full swing working on the demos and presentation.
Look into sanctum [1] it's cathedral mode. You can self-host those entirely and they're only discovery nodes. Once the tunnel is up the cathedral isn't involved unless for black key distribution or if your peers are behind restrictive NAT.
There's reliquary [2] which I host and run for me and my hacker friends based on sanctum.
I am continuing work on https://reliquary.se - a VPN for the hackers - based on my fully privilege separated and sandboxed VPN sanctum (https://sanctum.se).
It is shaping up nicely towards an actual 1.0 release in the near future, with a little less keccak based AEADs this time around. It was a fun experiment but in the end I have yet to do any cryptanalysis on it or provide security proofs for it - neither which I have time for at this point - so the swap to AES was expected on my end.
You're not forced to use the CLI create/build/run commands for anything. They just make it easier, but you are in no way tied to this.
Building the module itself can be done on your own for example, as it is just a normal dynamic library you can use whatever build system you want.
I've considered time and time again to turn kore into a "library" that you can link against and include into your own applications but every time I decided against it as it didn't give me any real benefits. It would make certain things considerable harder, who takes care of the worker processes? Who takes care of the logging and the internal message relaying? Having this abstracted away in a library is probably possible but adds tons of expectations on your own application.
Having Kore as the platform your code runs under makes this easier.
That's fair. Parenthesising return is a matter of readability and flavour to me. It tickles my spidey sense if it is missing.
I strongly dislike declaring variables anywhere else but the function root, but I agree with you on the example you provided that those kind of variables could be constified to be sane.
I see you picked out the few things that I consistently hear on the coding style I adopted which is based on my time hacking on openbsd. I have no real points to argue against those as it is based on preference in my opinion.
I am curious why you arrived on it not being sufficiently constified however. I'll gladly make sensible changes.
As for the multiple fprintf() calls ... to me it just reads better and the place it occurs in is as you stated pretty obvious non performance critical.
The accepting socket is shared between multiple workers which each have its own fd for epoll or kqueue. Because of this a form of serialising the accepts between said workers is needed to avoid unnecessary wakeups.
Except you are basing yourself on the fact it creates a single worker process per connection. It does not.
Workers are spawned when the server is started. Each of them deals with tens of thousands of connections on its own via the listening socket they share.
This is a common technique and scales incredible well.
It is not a run time option by design, but it is there.
I want Kore to have sane defaults for getting up and running. That means TLS (1.2 default by only), no RSA based key exchanges, AEAD ciphers preferred and the likes.