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.
The process names in the sanctum project made me smile :) I wonder why you chose "guardian" and not "bishop" (or even "episcopus"), which is literally "overseer".
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.
For me, too much was tied into using the Kore CLI to build and manage the actually application. Plus configs for routing is the only (apparent) option.
I think Kore would be an awesome framework if it weren't built with the assumption that you want to use its configs and its CLI. And although these could be useful too, I don't think it's too much to ask that the actual functionality there be exposed nicely and well-documented.
In particular, I'd just like to be able to wrote my own main and start Kore from there with high-level calls (including building routes).
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.
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.
Right. I could have guessed these were based on some coding style guide from somewhere.
I still don't see the point, or why any sane guide would prefer to treat return as a function. It just never seems helpful to me, and always wasteful/more complicated. I realize it's just two tokens, so it's probably not "important" in any real sense of the word, but it irks me. I like to point it out since it can help others cargo-culting this.
It's not sufficiently const if there are places where a variable could be const but still isn't. :) To be super-specific, the variable 'r' here: https://github.com/jorisvink/kore/blob/master/src/cli.c#L542 is one such case. It should be declared inside the loop, i.e. as "const ssize_t r = write(...);" since once assigned the return value from write(), it's read-only.
Of course, many ancient-smelling style guides seem to outlaw declaring variables as close to their point of usage, too. Note that declaring variables inside scopes other than the "root" one in a function isn't even C99, but many people seem to think you can't do that.
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.
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.
If you are the author, thanks for sharing the project. You did a great job and made the right choice of having per CPU worker processes each with their own epoll loop.
reply