Ace Hardware, a Stripped Door Lock, and a Security Patch Rolled Out Everywhere
Split pretty evenly between a normal workday, a favor for a friend, and a security patch that touched almost everything I run.
Delivery day at Ace
Worked the floor at Ace Hardware from 8:00 to 13:00. It was delivery day, so most of the shift was stocking shelves. Also swapped out one of the alarm sensors that had been throwing a trouble alarm — good to get that cleared instead of living with it blinking.
A stripped screw and a dead door lock actuator
Spent 17:30 to 19:15 helping a friend take his front passenger door apart to chase down a fault in the electric door lock actuator. Would have been a straightforward swap, except the previous owner had apparently tried the same repair before and stripped the head of one of the screws holding the assembly in — so a simple actuator replacement turned into a bigger teardown than it needed to be. Suggested he call BC Automotive in Zion to see if they can source a used actuator, or the whole lock assembly, off a junk car.
Patching a security hole across everything
A security hole was found in the encryption library almost every project of mine uses to talk HTTPS, so that meant a real pass across the whole fleet: updated the library and cut fresh releases for mlvpn-rs (v0.7.4), notify (v0.2.3), OmniBridge (v1.0.9-beta13), rust-proxy (v0.1.1 — its first tagged release, moving it off manual builds and onto the automatic release process it already had set up but hadn't used yet), software-support (v0.1.6), store (v0.4.23), and TicketTracker (v0.1.16), plus an update on wiki. While I was in there I updated all the other dependencies too, not just the one with the hole in it — no actual code changes, just newer building blocks, and everything still passed its full test suite. Rounded it out with the same kind of update on the JavaScript-based projects (nursinglog, omnibridge-web, r2-secure-dir-indexer, jpps/web, and this site).
Two more TrustBridge fixes: getting login certificates working on iPhone
Circled back to yesterday's TrustBridge work because a login certificate installed on an iPhone wasn't actually logging anyone in. Found two separate real bugs, not one: the certificate downloads were labeled with a file type the iPhone's browser just treats as plain text, instead of the file type that tells it to offer to install it. Fixed that labeling, and wrote down the one manual step Apple never lets a server skip: even after a certificate installs, it isn't trusted for anything until you turn that on yourself, under Settings → General → About → Certificate Trust Settings.
The second bug was in rust-proxy: it only trusted certificates signed directly by TrustBridge's main certificate, not the one underneath it that actually does the day-to-day signing — and the way iPhones install these certificates doesn't reliably carry that middle one along for the ride, so the check failed outright. Added that middle certificate as a second thing it trusts, and told it to accept either one as a valid signer, so a phone that's picky about which certificate it offers will actually offer it now.