Just released: #swad 0.11 -- the session-less swad is done!

Swad is the "Simple Web Authentication Daemon", it adds cookie/form #authentication to your reverse #proxy, designed to work with #nginx' "auth_request". Several modules for checking credentials are included, one of which requires solving a crypto challenge like #Anubis does, to allow "bot-safe" guest logins. Swad is written in pure #C, compiles to a small (200-300kiB) binary, has minimal dependencies (zlib, OpenSSL/LibreSSL and optionally libpam) and *should* work on many #POSIX-alike systems (#FreeBSD tested a lot, #Linux and #illumos also tested)

This release is the first one not to require a server-side session (which consumes a significant amount of RAM on really busy sites), instead signed Json Web Tokens are now implemented. For now, they are signed using HMAC-SHA256 with a random key generated at startup. A future direction could be support for asymmetric keys (RSA, ED25519), which could open up new possibilities like having your reverse proxy pass the signed token to a backend application, which could then verify it, but still not forge it.

Read more, grab the latest .tar.xz, build and install it ... here: ๐Ÿ˜Ž

https://github.com/Zirias/swad

GitHub - Zirias/swad: Simple Web Authentication Daemon

Simple Web Authentication Daemon. Contribute to Zirias/swad development by creating an account on GitHub.

GitHub

I just fixed a "horrible" bug in #swad:

https://github.com/Zirias/poser/commit/fcd8f4eb44d9676dde2546042b5fe3165aecc52c

In case you don't understand C: This potentially dereferenced "wild" and null pointers before the (copy-and-pasted ๐Ÿ™ˆ) typo was fixed, which means it's "undefined behavior", so might do surprising things, but more likely crash.

It affects the #epoll (on #Linux) and #eventports (on #Solaris / #illumos) backends. A quick smoke test on these platforms was done in swad 0.11 and didn't show any unexpected behavior. Only after preparing for the next release (that hopefully has multiple parallel event loops) by moving some static service data to thread-local storage, it suddenly failed on illumos, that's how I tracked down that embarrasing crap. ๐Ÿ˜ž

I hope to complete a new version soon enough, so I don't have to do a "bugfix release" for it.

Service: Fix bug finding watch parent ยท Zirias/poser@fcd8f4e

POsix SERvices framework for C. Contribute to Zirias/poser development by creating an account on GitHub.

GitHub
@zirias
Just built it on #Debian - builds fine ๐Ÿ˜‰

@jhx Hopefully ๐Ÿ˜Ž I just verified it still builds and works on #illumos (#solaris descendant) as well.

A linux build without specific options should show using #epoll, #signalfd and #timerfd here ๐Ÿ˜‰

@zirias
It builds fine for sure ๐Ÿ˜‰
cool to hear that it also builds on illumos ๐Ÿ˜Ž
truly portable!

@jhx Regarding that, at least in theory, it's indeed "truly portable" as it works fine using only #POSIX compliant APIs.

In practice, there can be issues with platforms that don't implement the *full* POSIX feature-set (which is in fact most platforms nowadays). There can also be nasty issues with how feature-test macros are handled (set by the compiler, interpreted by the system's headers) and sometimes with which libraries are needed (unfortunately, POSIX doesn't specify that, e.g. on illumos, you have to link a libsocket for any socket functionality ๐Ÿ™„).

Once I started to add optional support for the platform-specific mechanisms #epoll on #Linux and #kqueue on #BSD (because the POSIX standard select and poll have severe scalability issues), I wanted to also add support for /dev/poll as used on solaris, that's why I installed #OpenIndiana (illumos-based) in a VM to do tests, and I quickly learned /dev/poll was superseded by "event ports", so that's what I added instead.

@zirias
true that. POSIX is not implemented fully everywhere - that can for sure pose some problems!

But hey, it works on BSD, Linux and Illumos so far ๐Ÿ˜‰