The next release of #swad will probably bring not a single new feature, but focus on improvements, especially regarding #performance. Support for using #kqueue (#FreeBSD et al) to handle #signals is a part of it (which is done and works). Still unsure whether I'll also add support for #Linux' #signalfd. Using kqueue also as a better backend for #timers is on the list.

Another hopefully quite relevant change is here:

https://github.com/Zirias/poser/commit/798f23547295f89fa0c751f0e707c3474b5c689c

In short, so far my #poser lib was always awaiting readiness notification (from kqueue, or #epoll on Linux, or select/poll for other platforms) before doing any read or write on a socket. This is the ideal approach for reads, because in the common case, a socket is NOT ready for reading ... our kernel must have received something from the remote end first. But for writes, it's not so ideal. The common case is that a socket IS ready to write (because there's space left in the kernel's send buffers). So, just try it, and only register for notifications if it ever fails, makes more sense. Avoids pointless waiting and pointless events, and e.g. with epoll, even unnecessary syscalls. 😉

When writing a #daemon that follows best practices (handling of #detaching with a locked #pidfile, and #SIGHUP for #configuration #reload), an extremely simple "init script" will do (reliably!) for #FreeBSD's mewburn-rc. 😎

#C #coding #swad

I'm trying to add "genric" #signal handling to #poser. Ultimate goal is to provide a way for #swad to handle #SIGHUP, although signal handling must be done in poser's main event loop (signals are only ever unblocked while waiting for file descriptor events).

Okay, I could just add explicit handling for SIGHUP. But a generic solution would be nicer. Just for example, a consumer might be interested in #SIGINFO which doesn't even exist on all platforms ... 🤔

Now, #POSIX specs basically just say signal constants are "integer values". Not too helpful here. Is it safe to assume an upper bound for signal numbers on "real world" OS implementations, e.g. 64 like on #Linux? Should I check #NSIG and, if not defined, just define it to 64? 🙈

#C #coding #question

Just released: #swad 0.5

swad is the "Simple Web Authentication Daemon", meant to add authentication using a #cookie and a #login form to your reverse proxy. It's designed for #nginx' "auth_request" module. It's written in pure #C with very few external dependencies (zlib, and depending on build options OpenSSL/LibreSSL and #PAM).

And with this release, it also allows guest logins using the crypto puzzle you may already know from #Anubis!

Read more in the release notes, grab the .tar.xz and build/install it 😎

https://github.com/Zirias/swad/releases/tag/v0.5

Some progress, I can successfully "hijack" #swad's login handler to display a special hidden form with (currently dummy) javascript attached plus a random challenge. Also, verify a nonce (passed as a password) whether when appended to the challenge hashes to a #sha256 hash with "x" leading zero nibbles.

So, now I "just" have to write some #javascript to make this fly ... 🙈

There's a lot that could still be improved in #swad, but I don't get that "proof of work" idea out of my mind, so I started a branch to work on it:

https://github.com/Zirias/swad/pull/1

I really think it makes sense when you want some publicly known "guest login" which is still protected against #bots. Not sure yet whether this will succeed, we will see!

It certainly won't be as "fancy" as #anubis, but do the same thing functionally: Require the client to find a #nonce that, combined with a server-provided #challenge, hashes to something with 'n' leading zeros using #sha256. In contrast to anubis, swad won't have to proxy everything (but rely on nginx' auth_request), and no challenge will be issued when the user logs in with credentials some other credentials checker accepts.

And documented.

I guess I should test a while before releasing this with #swad 0.4

https://github.com/Zirias/swad/commit/70607960709ae17833cf31192c702f4017d89b44

#C #coding

And here's the "real world" usage 😎

So now I can give ppl a #login for #swad with a monthly changing password to access my #poudriere logs. Hopefully still keeps the #bot hordes out.

Here's a script I wrote to test the next #credentials checker module for #swad: "exec" 😎

Ok, #swad #release 0.3 updated to fix these stupid issues.

Oh boy, I discovered two quite problematic bugs after releasing #swad 0.3:

* The #PAM checker could cause swad to deadlock under unlikely, but possible circumstances: Creating another PAM checker instance when the PAM helper process already died (or couldn't be started at all)

* The file checker had a bug of the stupid kind, it failed to authenticate users that don't have a "real name" set in the password file because it didn't correctly strip the newline following the hash in this case. 🙈

Fixed them both now!

I think I'll do something you normally should never do: Re-roll the existing #release. It's IMHO kind of acceptable because this is still an incomplete 0.x version AND there are (as far as I know) no packagers yet.

Just released: #swad v0.3!

https://github.com/Zirias/swad/releases/tag/v0.3

swad is the "Simple Web Authentication Daemon", your tiny, efficient and (almost) dependency-free solution to add #cookie + login #form #authentication to whatever your #reverse #proxy offers. It's written in pure #C, portable across #POSIX platforms. It's designed with #nginx' 'auth_request' in mind, example configurations are included.

This release brings a file-based credential checker in addition to the already existing one using #PAM. Also lots of improvements, see details in the release notes.

I finally added complete build instructions to the README.md:

https://github.com/Zirias/swad

And there's more documentation available: manpages as well as a fully commented example configuration file.

The new #password #file management tool for #swad, #swadpw, is almost done, tests finally look sane 😉

Of course, this new credentials checker in #swad needs a #tool to edit these #password files, that's currently work in progress.

I just implemented the class for reading a password, pretty simple thing from a pipe, but an "interesting" job from a #terminal. Turns out doing that portably, reliably and secure needs quite some code. 🙈

There's #getpass, but that's deprecated for good reasons (global state and not perfectly clear how it deals with #signals that could interrupt the input). And there's the sane replacement #readpassphrase in some systems (e.g. #FreeBSD), but that's not portable. 🙃

So, plain old #tcsetattr it is, with some signal handling on top:
https://github.com/Zirias/swad/commit/447f48096fc275a5bae113393ffe9a3cbc66cc95

So, there we are: #swad has its second credentials checker module, using #password #files, partially #apache #htpasswd compatible (only #bcrypt, using #OpenBSD's code). 🥳

https://github.com/Zirias/swad/commit/385bc5286c607c7220067844c37bc5eb6cb6c18c

#C #coding

I need some advise: Is there a good portable and free (really free, not GPL!) #implementation of #bcrypt in #C around?

There's #OpenBSD source I could use, but integrating that would probably be quite a hassle...

Background: I want to start creating a second credential checker for #swad using files. And it probably makes sense to support a sane subset of #Apache's #htpasswd format here. Looking at the docs:
https://httpd.apache.org/docs/current/misc/password_encryptions.html
... the "sane subset" seems to be just bcrypt. MAYBE also this apache-specific flavor of "iterated" MD5, although that sounds a bit fishy ...

I finally eliminated the need for a dedicated #thread controlling the pam helper #process in #swad. 🥳

The building block that was still missing from #poser was a way to await some async I/O task performed on the main thread from a worker thread. So I added a class to allow exactly that. The naive implementation just signals the main thread to carry out the requested task and then waits on a #semaphore for completion, which of course blocks the worker thread.

Turns out we can actually do better, reaching similar functionality like e.g. #async / #await in C#: Release the worker thread to do other jobs while waiting. The key to this is user context switching support like offered by #POSIX-1.2001 #getcontext and friends. Unfortunately it was deprecated in POSIX-1.2008 without an obvious replacement (the docs basically say "use threads", which doesn't work for my scenario), but still lots of systems provide it, e.g. #FreeBSD, #NetBSD, #Linux (with #glibc) ...

The posercore lib now offers both implementations, prefering to use user context switching if available. It comes at a price: Every thread job now needs its private stack space (I allocated 64kiB there for now), and of course the switching takes some time as well, but that's very likely better than leaving a task idle waiting. And there's a restriction, resuming must still happen on the same thread that called the "await", so if this thread is currently busy, we have to wait a little bit longer. I still think it's a very nice solution. 😎

In any case, the code for the PAM credential checker module looks much cleaner now (the await "magic" happens on line 174):
https://github.com/Zirias/swad/blob/57eefe93cdad0df55ebede4bd877d22e7be1a7f8/src/bin/swad/cred/pamchecker.c

#C #coding

On a #coding mission to improve my #poser lib 😎.

In the current implementation of #swad, I don't really like that I need an extra thread, just to control a child #process. A first piece to add to poser is generic "child process support", which I'm testing right now. I realized I could reuse my #Connection class, which was built for #sockets, but works just as well with #pipes 🙃

TODO now is mostly testing. See screenshots for some mimimal testing code and its output ... would you like this kind of interface? 🤔

#C #programming

About the #random thingie ... I need random data in #swad to generate unpredictable #session IDs.

I previously had an implementation trying the #Linux-originating #getrandom if available, with a fallback to a stupid internal #xorshift#PRNG, which could be disabled because it's obviously NOT cryptographically secure, and WAS disabled for the generation of session IDs.

Then I learned #arc4random is available on many systems nowadays (#FreeBSD, #NetBSD, even Linux with a recent-enough glibc), so I decided to add a compile check for it and replace the whole mess with nothing but an arc4random call IF it is available.

arc4random originates from #OpenBSD and provides the only sane way to get cryptographically secure random data. It automatically and transparently (re-)seeds from OS entropy sources, but uses an internal CSPRNG most of the time (nowadays typically #ChaCha20, so it's a misnomer, but hey ...). It never fails, it never blocks. It just works. Awesome.

More #poser improvements:

* Use arc4random() if available, avoids excessive syscalls just to get high-quality random data
* Add a "resolver" to do #reverse#DNS lookups in a batch, remove the reverse lookup stuff from the connection which was often useless anyways, when a short-lived connection was deleted before resolving could finish 🙈

As a result, #swad can now reliably log requests with reverse lookups enabled 🥳

#C #coding