tl;dr:

• 3459 lines of code added (+3378 net)
• 48 test functions across 9 new test files
• 30 commits: 25 for new features and tests, 2 fixes, and 3 chores
• Complete build pipeline rewrite: Docker replaced with ko (daemonless); no more external actions
• Dex integration with JWT validation middleware + rate limiting
• Full REST API: 8 endpoints for tenants + member CRUD
• CLI tool: login via Dex password grant, 9 subcommands for management

Part 3 ended with a promise: “authentication, an API gateway with rate limiting built-in, and if I’m feeling generous both a CLI tool and a Web UI”. On the surface, I failed because I’m not delivering on the full promise, as there’s no Web UI (yet!). But there’s so much more that was added besides what was promised. We have a lot of tests! We have an even better CI/CD pipeline! We eliminated external dependencies! We have Helm charts! And, of course, we have all the other promises that were made before. I feel like this is a good trade-off: less show-off, but better foundations.

Sometimes, laziness can be a great motivator.

In effect, what I wanted was a zero-trust setup for remote authentication. On one hand, because it’s way more secure; but the real motivator was that I got tired of typing or copy/pasting passwords.

For a while now, I’ve been using both a Nitrokey and a Yubikey for authentication and signing on my local machine. This has many interesting features, e.g.: combined with my password manager workflow it means I can securely get a password without much work, as the touch of a button is enough. And not only is this more convenient, but it’s also more secure. Not only do they add a physical layer to workflow, which makes the workflow depend on the physical presence of a device; they also obviate the need for the usage of other apps or devices, which decreases the attack surface from other sources. Not only are they easier to use and manage, but they also increase security? This is exactly my kind of jam!

tl;dr:

• 1557 lines of code added
• 17 fix commits vs 8 feature commits
• Almost 60% of the commits were related with debugging the platform
• Complete rewrite of the webhook TLS logic

It’s been a while since I last posted about this project. The reason was not that it was abandoned, on the contrary: in the meantime, I’ve been able to add ~1500 lines of code to this project. I know this might not sound a lot in this day and age, but trust me: the problem is never about how many lines of code you write, but rather whether the code is good quality. And at this point, it was time to start testing what we had built so far; so much so, that in this time, ~60% of my commits have been related with fixing existing issues in the actual implementation. But I’m getting ahead of myself.

It’s hard to think about a more fundamental part of one’s digital identity than a password manager. In a sense, if you want to be sovereign over your digital presence, the password manager is what allows you to hold the keys to your kingdom. It’s pretty much that one security measure that everyone can agree on; managing all your passwords by yourself is bound to create problems of its own: either you are reusing the same password, or you are writing them down somewhere. This is not okay, and why password managers were born.

I saw this post on my feed, and it caught my eye because I self-host a Mattermost instance. The fact that it has possible critical security issues is a concern for me. So I checked the github issue with the details.

Of course, it’s fully LLM generated, but that’s to be expected at this point. So I opened the first issue described there, a CRITICAL VULNERABILITY no less. It’s the possibility for XSS in email templates. Ok, sure, let’s dig deeper. This post will have a technical part, where I dig into the code; and a more sociological part, where I dig into other things.