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.

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'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: 5 years, then you need to upgrade your O/S and I'll keep on supporting you. 🫶

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 taught myself KiCAD and updated the design to use a different voltage regulator. The pins were reversed from the previous component, so this spawned v1.3. Exact same thing as v1.2 except it used components which were actually available. That was OK, but the board had components on both sides, which made assembly tedious and error prone. Plus people were asking about native USB-C support. Between my desire to make these devices easier for people to build at home (myself included) and the USB-C thing, v1.4 was born. This put all the components on the front of the board and added a USB-C connector. After a few attempts, I decided the surface-mounted USB-C connector was going to be too tedious for people to assemble, and I settled on the through-hole version. After making a huge batch of these new boards, I discovered I made two errors: 1. I didn't connect the data pins from the A-side to the B-side. The result, you can't plug it in either way. Awkward for a USB-C connector! 2. More importantly is would ONLY work with USB-A to USB-C cables. I had wired it per the USB spec for legacy mode because the MCU only supports USB 2.0. It was only later I realized that legacy mode was referencing the cables, not the protocol. 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. 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.

I've been grinding away, doing the completely unglamorous work of maintenance and cross platform compatibility, but I did add in one little improvement. - Switched from KeePass to KeePassXC library - Added support for importing KeePass v4 databases - Added support for importing extra fields from all KeePass files All these changes were in the client software, not firmware nor hardware changes.

Reason #25630 that I don't get things done faster: The MXE scripts to build .deb packages are broken and after dozens of hours trying to resolve it, I haven't been able to figure it out. I opened a ticket about it a couple weeks ago, but no replies.

GitHub

build-pkg.lua produces defective .deb files · Issue #3264 · mxe/mxe

I'm running into a situation where if I build .debs and then install them, I get assembler errors. If I build the toolchain locally, the same compi...

This is blocking my ability to fix the CI jobs that build the Windows releases of the Signet client, which is holding up a release. In this case, I don't think anyone who knows about these scripts is still around. The moral of the story here is that if you can afford to help with open source software, we could really use it! I'm not talking about money. I'm talking about project management, learning how to reproduce issues, debug them, working towards a resolution and not just being able to do these, bit actually doing them in practice. It takes time and effort. It means being part of a community. And the reward is that the world is a better place. It's not the riches tech bros promise.

Reason #25628 why I don't get things done faster. I had to set aside my tasks to patch reprepro so it could handle control.tar.xz files which is what are created by all of Debian's modern tools to create .deb files. I submitted a merge request 2 weeks ago, but it hasn't been commented on, let alone reviewed or accepted. But I've got the .deb for it on my apt repo and you can see the change and compile my version here if you want it.

I Challenge Thee

Reason #25629 why I don't get things done faster. I spend time trying to get my patches upstreamed so more people can benefit from my work. But just like my multi-year effort to get a patchlevel change in pam-u2f (from the original author and an official release, not a patch I wrote), it seems I'm being ghosted again. Last time around, I reached out to the maintainer via email, the former maintainer, another person in auth, the maintainer via IRC, tried to get a mentor in IRC... all failed.

Today I helped a user compile the #signet client for an #ARM based version of #MacOS. It required changing a couple library paths, and I've already upstreamed those changes to the latest copy of the repo. This was something I've been wanted to test for a long time now, but I don't have the hardware and it's hard to get the time of someone who does. But we did it. Together. Hardware secured encryption is #cipherpunk meets #cyberpunk ✊ signet - And physical access is within our threat model! Contrast that to the way hardware security work when made by Intel, AMD or ARM:

Infosec Exchange

Dan Goodin (@dangoodin@infosec.exchange)

AMD, Intel and Nvidia have poured untold resources into building on-chip trusted execution environments. These enclaves use encryption to protect d...

Well, that was... educational. Not only does v1.4 require plugging in the USB-C cable the right way, but it also only works with USB-A to USB-C cables (not C-to-C). Everything related to the USB-A connector is fine, and previous revisions didn't have a USB-C connector at all, so this version is still an improvement, but not as much of an improvement as I was aiming for. I've read a lot about USB-C cables and USB 3.1 and I think the next rev will fix both problems. Version 1.41, here we come.

This is what #patching a #bug in #hardware looks like. First attempt: I made things worse Second attempt (not pictured): it's as if I did nothing Third attempt: fixed! If you don't know how big a US dime is, the punchline here is that these wires are very small, tedious to work with and will probably come loose at the slightest provocation. #USBC And a shout out to those who know exactly what happened here without any explanation required. I goofed. Next rev will be better. #OpenHardware #electronics #diy

BTW, I am still looking for a reseller in Europe. If you or someone you know is there and wants to make open source security hardware available to people, reach out to me. The cost of shipping is Europeans €25-30 per order, but beyond that, there's a risk with every single order that something will go wrong in customs (on either end), and that cost would double just to give it a second attempt! That's why I don't offer international shipping. Because I end up losing money if 1 out of 10 orders requires re-shipping. Meanwhile the customer has to pay almost as much for shipping as the device. I want to slash that cost dramatically, and obviously I'll pass those savongs onto the user. Here's what I want to do: A.) Ship a batch of signets to someone in Europe, maybe 10x to start B.) Orders to europeans ship from there I'd prefer the reseller sells them, but I could enable shipping in my store if that's preferable. We can work out something to balance the risk of me shipping off signets and never hearing anything from them again, and the reseller buying these from me and then being stuck with them if they're not selling. We can work it out, and a return/exchange process too. We got this, I just need a little help.

New #hardware revision is in the works... #Signet v1.4 Native USB-C connector. No more need for those A-to-C adapters. I just ordered more parts to make more of them. I'm excited. #OpenHardware for life, yo!

Last night I found a lua script in the MXE repo that allows me to create .deb packages. This is something I asked for a couple months ago and never got any reply. This is a huge deal, not just for me, but for everyone who uses the MXE cross compiler to make Windows executables from Linux because the official repos have not been updated in a decade and they won't compile some modern software. Soon, I will have an update version of gcc in my apt repo for everyone. I am also going to be adding documentation on how people can compile the .deb packages themselves. The ones in my repo will be signed by me, but trusting me should not be a requirement.

Trying out Plebian Market. The censors won't let me call the signet a password manager. Password is a forbidden word. But I can say password on nostr all day long. Password password password! Take that censors!

Plebeian Market

I finally have a partial answer to the question "how long will a #Signet last?" Previously, we had never seen one wear out, but after 7.5 years, most of which was daily use, my 2017 Signet started having intermittent problems with the USB connector. I had to jiggle it to get it to work. 7+ years is better than you'll get from any commercial company, but here's the real kicker... I replaced the USB connector and it works reliably again! 💯 The part of the question about how long it will last which is left unanswered is: how long will it last after one simple repair? Any #Makerspace or #Hackerspace can help you make this #repair, even if you don't have any experience with #electronics. The USB connector costs less than a dollar and the space might even have some lying around they'd be willing go give it to you for free. This is how gadgets should be. Not disposable, but long lasting AND repairable. #environmentalism #sustainability #RightToRepair #FOSS #OpenHardware #sustainible

Achievement unlocked: get an ad in the back of the latest 2600 magazine. May all the cypherpunks have the tools they want, not merely the tools companies are willing to sell to them. 🤘😈