I remember your comment from back then :D. Great news: Since then, I actually did make it a library. The runtime has been a library for a long time now, and ObjFW itself is also almost there in the amiga-library branch.
Yes, it does not protect the running system from being compromized, but that was never the idea behind Secure Boot anyway: You could just backdoor a binary, why even bother with the kernel.
As for evil maid, yes, it does help: You can't just change keys if you have a UEFI password. Sure, a determined attacker could externally reprogram your SPI flash. But that is a lot more effort. Absolute security doesn't exist, but you can make it as hard as possible :).
Another use case is actually dual booting with Windows: You can add Microsoft's cert to the DB and only the DB. This way, Windows can not add any new certs. And you can only load bootloaders signed by Microsoft (no shim etc, as MS was clever enough to use a different key for that). That way, Windows could only compromise your Linux if Microsoft signs a malicious Linux kernel. I would hope they have their key on an HSM and don't sign everything lightly ;).
This is exactly what intrigued me and made me switch to Fossil. I don't want to have my issues, wiki etc. held hostage by some company. And if someone wants to fork it, they should be able to fork it including issues and wiki.
This is running on a server with super slow single core performance and slow I/O (Sun Fire T1000 with full disk encryption, giving ~ 2 MB/s for the disk), and yet it feels fast and I've never encountered any performance issues. As long as your repo is not as gigantic as https://pkgsrc.fossil.netbsd.org, you'll be fine, no matter what slow hardware you throw at it.
That is only true for projects where you need to deploy. In that case, yeah, you of course can only close the bug once you fixed production. But for normal software development, you can fix the bug in the software and you can update the bug tracker, and then push everything once you're back online.
For example, on a flight, I can look at the bug tracker (since it's part of the clone), pick a bug I want to work on, create a few commits to fix it, then update that bug (set it to closed, reference the commits that fixed it), and then upload it all when the plane landed again.
It's quite sad to see that so few projects use it. The idea of having everything in one repo, incl. bugs, is just great. I can create new bugs while offline, update bugs while offline, etc. and then just sync everything once I'm back online.
It also has pretty good support for incrementally importing from and exporting to Git: https://blog.nil.im/?79