Published:

Jarle Aase

Monthly update, July 2024

bookmark 4 min read

These monthly updates may be a bit technical. They are written to my future self (to remember how I spent the month - and to motivate me to do at least something remotely interesting), to friends and colleagues (past and future) to have an idea about what I work on. And of course to potential clients for my C++ freelance business and fellow software developers.

Projects

stbl

stbl is an acronym for "Static Blog". It is a command-line application for Linux I made 8 years ago. I did some nice upgrades here in June. In July I added support for videos.

I expected this to be hard, as a friend of mine who work with web and webrtc components, warned me that using the html5 tag <video> was, well, complicated.

It turned out to be pretty easy. I use the same a syntax in the .md documents as an image. When stbl comes across one of these "images" that is actually a video, it runs the video trough ffmpeg to compress and scale it for .mp4, .ogv and .webm.

The very nice thing is that I was able to do it in plain html5. No JavaScript required.

I know most people today have JavaScript enabled in their browsers. This is something that may hopefully change as more people realize how crazy it is to allow any website or advertiser to execute code on their device. As supply chain attacks like the recent spectacle with polyfill.io becomes more frequent, and front-end developers continue to use hundreds of 3rd party JavaScript components and libraries - eventually corporations and security minded individuals will need to switch off JavaScript for websites that don't need to be a web-application. Personally I have called JavaScript for "the new Flash" for a very long time.

Btw, this is one of the contexts where C++ shines. It don't have a huge repository of mostly unvetted components (like npm op pip), and once compiled, most applications will use the libraries they were compiled with until they are upgraded. That's very different from web applications who pull potentially hundreds of JavaScript components form various sources on the internet, every time they are started. Each of those components could be compromised at any moment.

Nsblast

Nsblast is a massively scalable authoritative DNS server.

I resumed work on nsblast. This was my primary project until I started working on Nextapp in December last yer.

First of all I made it work well with Ubuntu Noble and then I deployed the first cluster; one server in Germany and one in Canada.

I added some scripts to use certbot with DNS authentication so that I can get letsencrypt TLS certificates without any stress. For example, all I need to do to get a valid public cert for a hostname that don't have a web server on the public internet - for example for a gRPC endpoint on my internal network, is to run this command:

1
2certbot-wrapper.sh you@example.com -d '*.all.test.some-zone.example.nsblast.com' -d www.test.some-zone.example.nsblast.com
3

After a few seconds the command returns and I have the certs. And I'm not talking figuratively. The nsblast name servers use gRPC streams to replicate changes - so that happens almost instantly. The REST API waits until all the name servers in the cluster are updated with a change until it returns. As a result, there is no need to add a sleep statement after the curl command to create the verification TEXT entry that certbot use for DNS authentication.

Next-App

Next-app is an upcoming GTD/productivity application for desktop and mobile.

The most significant development in nextapp is that the multi tenant and multi user feature is implemented!

The security and privacy is pretty good. There are no passwords. There are no 3rd party authenticators. Many apps today let you sign up with your Apple or Google account. It's convenient - but it's not secure. If your account gets compromised (or cancelled!) you are - well let's call it fracked. It also allows Apple or Google to know that you are using this service, which is information they can monetize - which may not be in your best interest.

With July's changes, Nextapp has two back-end services. There is the nextappd server who maintains the state of your application. Then there is a new signupd server that handles new users and new devices.

Signupd has a public TLS certificate. That means that the first time your application connects to a back-end, it can and will verify that the server is who it pretends to be. (This assumption holds most of the time. SSL/TLS is broken when it comes to defending against state actors like intelligence agencies, and other resourceful adversaries).

When a new user connects to the signup service, they can create a new user account. The server needs a unique email address, but that's the only personal information a user have to provide - and there are no filters or verification. You can use an email on example.com if you want.

Your client will then create a X509 Certificate Signing Request and a 4k bits key, and send the CSR (not the key) to the server for signing. The signup server forwards the request to the nextapp server, which signs the CSR with it's own self signed root cert and returns a valid X509 certificate.

When the signup work-flow is completed, the user's app connects to the nextappd server using gRPC with TLS and a constraint that all requests must have a X509 client certificate signed with the servers root CA. The client also have the servers public root cert, and validates the server. This is pretty basic Public-key cryptography, but it still provides strong security. The user is identified by the signed certificate, and the key is kept locally on the client's device. Ideally, it will never leave this device.

If the user want to add another device, they must connect the new device to the signup service. This time they specify that they are an existing user. The user then asks for a One Time Password (OTP) form the existing device, enters the OTP and email in a dialog on the new device, and the server signs a new CSR for the new device.

Doing it this way, there are no passwords to loose or re-use. If the server is compromised, it don't know the users private keys, so there is no authentication data to steal. Even the OTP's are unknown to the server. It knows only a cryptographic hash, and how to create a similar hash from an OTP and email pair presented by the user. There is no information-leaks to 3rd parties and no impact if the user gets locked out from Apple or Google or if they have an outage.

It's very simple to use. There is nothing you need to remember. Not even the email. When you ask an existing device about an OTP, it will also remind you about the email you must use.

I hope to have an early Beta version ready by the end of August.

Books Completed

Videos produced