79 Followers
6 Following
143 Posts

Maintainer and primary hardware producer of Signet: the completely open source, encrypted, hardware password manager!

https://hax0rbana.org/signet

New Signet client release is now available on https://hax0rbana.org/signet/downloads.html

Notable changes include:

- Support for importing extra fields from KeePass databases
- Support for importing KeePass v4.x databases

The other changes are things like the Windows executable being compiled automatically by my CI/CD system, so I don't have to manually go to a Windows box to compile it.

Hax0rbana - Signet - Downloads

I've got the deb building issues solved for Debian. There's an Ubuntu release (Jammy) that upgraded libbotan2 but not libgcrypt so the Debian 11 has one library that is too old and another that is too new and I think it's reversed with the .deb from Debian 12. At least something like that, I'm tooting from memory.

The solution is to build it on Jammy so it'll pick the library versions that match. I should get that done after the weekend. And I'll add in some more testing for more releases too.

I'd like to go beyond this and match the Extended Long Term Support (ELTS), but this is challenging.

Docker doesn't keep images around forever, which is a problem for my CI/CD environment.

Debian doesn't keep their apt repos around, which is a problem for installing dependencies and build tools.

ELTS is 3rd party paid support.

While it'd be possible to run my own apt mirror and docker registry, it's a lot of work for something nobody is asking for. So for now, I match Debian's LTS policy.

As the years march on, maintaining support for older distros becomes more complex. One version of a library is required on one release, and a different one on the next.

Most projects shy away from putting the work, even huge projects with large communities and/or corporate funding. It's a lot easier to just support the latest release.

Not Signet. I support Debian 11, both i386 and amd64. At a minimum, I will match Debian's Long Term Support commitments.

I was able to reproduce the issue outside the CI environment. I think I know what needs to be done to clean all this up now, but I ran out of time before I got it done.

Plus I made a change to the CI runners which should prevent the Docker caching issue from recurring. Just need to get that into the Ansible scripts so it will never regress. THEN I can call it done.

Resolved that, now on to trying to figure out why there are CMakeCache folders that are breaking the .deb build process.

This related to the new keepassxc project in place of keepassx.

And frustratingly, this only seems to happen in the CI environment. Running the same commands on a fresh VMworks fine. So I expect it'll probably turn out to be more Docker issues. Time & effort will reveal all.

I spent all day trying to track down some alarming PGP signature problems.

In the end, it was docker caching some file that was downloaded from the internet, as if there's no chance something online could possibly change...

Frustrating to waste time on Docker nonsense, but at least the explanation wasn't that it was detecting a compromise.

Onward.

I've also made progress on the hardware side of the house. The current hardware is effectively USB-A only, and the new revision aims to fix that. I feel like the details are somewhat interesting on this. Perhaps that isn't true for hardware developers, but I think everyone else will enjoy, so it's story time!

I took on maintenance at hardware v1.2. It relied on a voltage regulated that was not available anymore. The journey begins...

I'm pretty sure that they'll work as my prototype did, but there's still some chance I made a mistake in KiCAD and will have to make yet another revision before it has real USB-C support. Time will tell.

So there you have it. A behind the scenes look at hardware development and how I'm pushing to make this tech more accessible to people and adding native support for USB-C.

#OpenHardware made with ❤️

The net result is that v1.4 hardware is basically still USB-A only. Yeah, you can put both USB ends on, but it's not going to work as most people expect

This brings us to v1.41, which is nearly identical to v1.4, except a 56K Ω resistor was swapped out for a pair of 5.1K Ω resistors and slightly different wiring. I've hand soldered this on a prototype board and can confirm that it works properly. I updated the board and published it, but I haven't had new boards made yet. So the story continues