/noclip

Quoth the Raven, "Be careful with that cable, it's carrying 48 volts"

-- Edgar Allan PoE

@hacks4pancakes to disambiguate, I mean the D&D one

@hacks4pancakes Running your infosec/pentesting module across two sessions, finished the first one last week. Damn sight better than 90% of the paid modules I've seen.

electricity fedi: I have a gorgeous old analog hifi setup that puts nasty pops through my speakers when my heatpump HWS (on the same circuit, unfortunately) switches. what do I need to fix this? just a bog standard surge protector or more fancy power conditioning?

@shortridge While working tech support, I got a call on a Monday. Some VPNs which had been working on Friday were no longer working. After a little digging, we found the negotiation was failing due to a certificate validation failure.

The certificate validation was failing because the system couldn’t check the certificate revocation list (CRL).

The system couldn’t check the CRL because it was too big. The software doing the validation only allocated 512kB to store the CRL, and it was bigger than that. This is from a private certificate authority, though, and 512kB is a *LOT* of revoked certificates. Shouldn’t be possible for this environment to hit within a human lifespan.

Turns out the CRL was nearly a megabyte! What gives? We check the certificate authority, and it’s revoking and reissuing every single certificate it has signed once per second.

The revocations say all the certificates (including the certificate authority’s) are expired. We check the expiration date of the certificate authority, and it’s set to some time in 1910. What? It was around here I started to suspect what had happened.

The certificate authority isn’t valid before some time in 2037. It was waking up every second, seeing the current date was after the expiration date and reissuing everything. But time is linear, so it doesn’t make sense to reissue an expired certificate with an earlier not-valid-before date, so it reissued all the certs with the same dates and went to sleep. One second later, it woke up and did the whole process over again. But why the clearly invalid dates on the CA?

The CA operation log was packed with revocations and reissues, but I eventually found the reissues which changed the validity dates of the CA’s certificate. Sure enough, it reissued itself in 2037 and the expiration date was set to 2037 plus ten years, which fell victim to the 2038 limitation. But it’s not 2037, so why did the system think it was?

The OS running the CA was set to sync with NTP every 120 seconds, and it used a really bad NTP client which blindly set the time to whatever the NTP server gave it. No sanity checking, no drifting. Just get the time, set the time. OS logs showed most of the time, the clock adjustment was a fraction of a second. Then some time on Saturday, there was an adjustment of tens of thousands of seconds forward. The next adjustment was hundreds of thousands of seconds forward. Tens of millions of seconds forward. Eventually it hit billions of seconds backwards, taking the system clock back to 1904 or so. The NTP server was racing forward through the 32-bit timestamp space.

At some point, the NTP server handed out a date in 2037 which was after the CA’s expiration. It reissued itself as I described above, and a date math bug resulted in a cert which expired before it was valid. So now we have an explanation for the CRL being so huge. On to the NTP server!

Turns out they had an NTP “appliance” with a radio clock (i.e, a CDMA radio, GPS receiver, etc.). Whoever built it had done so in a really questionable way. It seems it had a faulty internal clock which was very fast. If it lost upstream time for a while, then reacquired it after the internal clock had accumulated a whole extra second, the server didn’t let itself step backwards or extend the duration of a second. The math it used to correct its internal clock somehow resulted in dramatically shortening the duration of a second until it wrapped in 2038 and eventually ended up at the correct time.

Ultimately found three issues:
• An OS with an overly-simplistic NTP client
• A certificate authority with a bad date math system
• An NTP server with design issues and bad hardware

Edit: The popularity of this story has me thinking about it some more.

The 2038 problem happens because when the first bit of a 32-bit value is 1 and you use it as a signed integer, it’s interpreted as a negative number in 2’s complement representation. But C has no protection from treating the same value as signed in some contexts and unsigned in others. If you start with a signed 32-bit integer with the value -1, it is represented in memory as 0xFFFFFFFF. If you then use it as an unsigned integer, it becomes the value 4,294,967,296.

I bet the NTP box subtracted the internal clock’s seconds from the radio clock’s seconds as signed integers (getting -1 seconds), then treated it as an unsigned integer when figuring out how to adjust the tick rate. It suddenly thought the clock was four billion seconds behind, so it really has to sprint forward to catch up!

In my experience, the most baffling behavior is almost always caused by very small mistakes. This small mistake would explain the behavior.

Conservatives everywhere be like...

#SVpol #Election2026 #Sverige

cybercrime should probably be illegal regardless of how much linear algebra was involved

back on my bullshit

TIL Kelvin's Balls are the two soft iron balls attached to either side of a ship's magnetic compass binnacle. Invented by Lord Kelvin (of °K temperature fame), they are adjustable to counteract the local magnetic deviation caused by a ship's metallic structure.

https://en.wikipedia.org/wiki/Binnacle
#til #todayilearned
https://www.reddit.com/r/todayilearned/comments/1vq8qzk/til_kelvins_balls_are_the_two_soft_iron_balls/

Welcome to the jumble
Sale
We've got old board games
We got jars of local honey, made by what's-his-name
£1 admission, people, so you can find whatever you may need
If you got the money, honey, buy my home made quiche

I want to remind you: these bastards have spent $1.5 trillion of society's money on this technology. That it's produced *something* should not be surprising. That's 'solve aging', 'cure cancer', 'eliminate all poverty', 'shift climate change into reverse', or 'send a probe to another solar system' money. It's not 'write shit software 20% faster' money.

I'm talking with a journalist who has some deep questions about the #Mastodon codebase. Their questions are now well beyond my depth.

If you know the Mastodon codebase (specifically Mastodon, not other ActivityPub implementations) well and would like to go on the record with a journalist regarding technical details about the codebase, I could use help.

Update 2026-08-15: A key Mastodon developer has volunteered to do this, so I think it's covered. Thanks to all for the help finding someone.

which of you nerds came up with this wording

Ethics aside, we can clearly no longer deny the utility of necromancy. Perhaps a year ago, when the pathetic shambling of the animated dead so often made a hollow mockery of our arts. But now! Incantations that once took weeks of toil can be wrested from their tormented souls in mere minutes!

Without the awesome power of the newly dead coursing through our veins, how are we to solve the great problems of our age, like the mysterious disappearance of so many of our elderly and sick friends, or the festering piles of rotten flesh that now clog our streets and homes?

If you still have qualms about using the large soul providers, you can always obtain your own local, free range specimens, although of course they won’t obey quite as faithfully as ones from the leading charnel houses.

Honestly, do you want to be left behind?

@scroeser I love how bell hooks can relentlessly dissect the extreme pathology of socially defined masculinity without ever so much as hinting that men as such are the enemy. She recognizes the brainwashing to which we are subjected.

Anyone consider themselves an expert on tree-sitter S-expressions? I got some questions