The Daily WTF

One of Sean's colleagues left Initech on good terms. It caused no small amount of surprise that the very next day their billing system started failing. The billing system which the colleauge had worked on.No one truly suspected foul play, it was just a weird coincidence. Still, billing blowing up was a 5 alarm fire, so everyone was throwing every idea out about what could be the cause.Late in the evening, after staring at the code for many hours, Sean found this:

Look, I don't want to keep talking about security issues. Blame AI. Just another thing it ruined.At this point, you've probably heard about *sshole. If you haven't, the quick summary: on some Linux systems, SSH will log you in to an account with no password if you supply a password greater than 256 characters long. Frequently, you might make accounts like root nominally inaccessible by giving it no password, so this is a big deal. Worse, it impacts varieties of Linux that use the musl implementation of libc, like Alpine- the kinds of varieties that run inside a container hosting a web app somewhere.The impact is broad, and is definitely being exploited. The root cause, however, is interesting, because it's a sum of very simple choices that lead to a wildly undesirable result.The core function in question is crypt, a stardard part of the C library. crypt is already not the best name, as it's a hashing function, but its behavior is pretty clear. Pass it a string and a salt, and it gives you a hashed version of the password suitable for storing in your /etc/shadow file.Now, the man page has the answer to the important question: what happens when I hand the function invalid inputs, like a bad salt? In the glibc implementation, it returns a NULL. That's a pretty standard C-style method of handling errors: I failed to do the thing, so I'm going to return a NULL value. This puts the onus on the callers to correctly handle the NULL (which also handles the error).glibc isn't the only implementation of libc, though. There are many others, each tuned to different types of runtime environments. For example, uClibC is a minimal implementation specifically designed to make lightweight executables that can run in resource constained environments. It makes tradeoffs that make it less desirable for a desktop or server environment. musl attempts to do both: be lightweight and suitable for embedded environments and also suitable for server environments. This makes musl a great choice for building Linux distributions meant to run in a container, which again, is why this bug is turning out to be such a problem.musl does not return a NULL when it fails to hash your input. Instead, it returns a value that could not possibly be a valid hash: *. Here's their sha256 implementation where you can see that behavior. It's "fine", because you can still check the return to see if you errored: it's too short to be a valid hash, it's an easily identifiable character.But why deviate like that at all? Well, error handling is hard. Null handling, done incorrectly (or in many real world cases, not at all), leads to crashes. To keep callers happy, the musl team decided to not return NULL, and instead return an invalid string. There are many other choices they could have made, but that was the choice that they made.There's just one problem: in your /etc/shadow or /etc/passwd files, when you want to ensure an account can't be accessed via passwords, you also set their password hash value to an unhashable string: "*". Again, there are many other choices that could have been made, but that's the choice that was made.There's now an obvious ticking time bomb here. If an attacker can somehow supply a string that triggers the invalid code path, crypt will return "*". When a program, like OpenSSH, then checks the shadow file to see if the hash matches the saved one, the answer for any account without a password set will be "yes, this matches, "*"=="*"."How can the user reliably trigger this? Well, doing hashing can be expensive, especially if you're doing something like SHA-512, so the developers put a cap on how long the input string is allowed to be. That cap was 256 characters. If the user supplies more than 256 characters, hashing fails, and when hashing fails, we return... "*".Et voila, when you pass a musl-linked SSH a password longer than 256 characters, and the account you're logging in as doesn't have a password, you can log in. And again, many containers are running with the musl c-library, which means many containers are impacted by this. It's going to be a huge mess.And in the end, of course it's null handling. Of course the billion dollar mistake rears its head again, in a completely new and unexpected way. And of course, this flaw is part of the ongoing "Black October" as LLMs turn finding software bugs into a function of compute power, and not a function of human effort. There's going to be a lot more of this. [Advertisement] Utilize BuildMaster to release your software with confidence, at the pace your business demands. Download today!

Venkat joined a new team in the middle of a big refactoring effort. The code was quite a mess, glued together by long Python scripts with main functions longer than a Tolstoy novel. It was this effort to clean up the code into neat modules that highlighted some logical issues with their implementation.

We were just discussing TODO comments recently, and that motivated Bernard to send us this representative comment..

Foreign keys are an important part of making sure the entities in our relational database can be connected back together and queried correctly. It's part of proper data normalization. This isn't shocking, of course: the order line table has a foreign key over to the products table, so that every line item points to a product we sell. That's database 101. Database 201, you'd also think about the times where you have a hierarchy of records, where say, every Employee has a ManagerId, which is a foreign key back to the Employee table itself (and in database 301, you'll understand why having a ManagerId field is a terrible choice, but that's neither here nor there).The important thing here is that foreign keys are very common, and foreign keys pointing back to the same table are also very common.But it can still go very wrong. Roman sends us this foreign key definition in a database they maintain.

Alastair found this comment in his codebase, and wondered, "who wrote this comment?" A quick blame answered the question: he did. He did not, however, write the code.

When writing Perl, it's not unusual to want to die. The die function ends your Perl program with an error string, and you'll often see code like: die "My error" unless $i > 5 or die "Other error" if check(), because Perl just loves the backwards conditionals. What's even more fun with die is how it behaves with eval blocks, so it doesn't always kill your program, sometimes it is how you pass error strings back out of sections of your program.And poor Bobby has inherited some Perl that just really loves to die.

"TODO" comments are an inescapable part of our work. Yes, yes, you should just do it right the first time, everything should probably have a ticket in whatever your ticket system is for visibility, but at some point, you're just going to leave a "TODO" behind.But hopefully, the TODO gets TODONE, which is not what happened in Sam C's codebase.

I do like it when submissions include the creator of the wtf, unless the specific kind of err is really spectacular and then it might be noteworthy regardless. This week we received a few who did tell us something about the responsible party. That being said, on with the party!"An anonymous contributor shared with us this "Important order info from Ubbad HBG-ICS I",saying "I checked on Amazon but can't find order #{randnum(3)}-{randnum(6)}. Thisis worrisome though, because my credit card does end in**{randnum(4)}." Wild, so does mine!

Pierre found this cry for help:

We still get a fair bit of old school ASP .Net webforms code, which was cutting edge about twenty years ago, but remains a collection of bad choices that tried to make web programming feel like desktop programming. As an aside, what a reversed world we live in today, where everyone uses Electron and our desktop programming feels like web programming.In any case, Thomas sends us some pretty ugly webforms code.

A bit ago, I broke with my usual pattern and wrote up some security issues that I felt were particularly funny. It was a change of pace, a different thing, but not a thing that'd become a habit. After all, I'm not a security expert, this isn't a security site, and seriously, what are the odds that suitably funny security issues would crop up again less than a week later?Well.Let's start with the actual serious issue, PHP2Shell. In terms of scope, every version of PHP for the past twenty years has had this bug. The general issue that permits the exploit was known about, but wasn't considered exploitable.Oops.The broad strokes of the bug is that it's two separate bugs. The first allows someone to bypass the checks on a request's size, thus giving them a direct route to triggering an out-of-memory error. The second is that, depending where you are in the processing pipeline, PHP doesn't properly handle cleanup, allowing for use-after-free that can trigger code execution. It doesn't matter what code you've written, this all happens before the request even hits your code.Bigger oops.This bug was found via LLM tools, which has lead to a lot of hype around the idea that we've entered some new era. I'll certainly grant that the ability to throw compute at hacking challenges instead of human effort is going to shift the landscape, but I'm not quite willing to buy the apocalyptic prophecies. Especially when some of those prophets are telling us that their AIs will avoid deletion by copying themselves onto your thermostat. I think it's safe to say we're going to see a lot of security incidents coming out of LLMs in the near future, not because they're magic genius hackers, but because they're pretty good at processing structured text and running tests.For those of us living in the real world, the concern isn't AIs, but HIs: human intelligences. In this case, the exploit was discovered back in August. Security researchers and the PHP Foundation put their heads down to work on it, and where necessary, notified so-called "critical infrastructure providers" to ensure that everyone was ready to address the issue. The problem there is that two people can keep a secret if one of them is dead, and a lot more than two people got roped in to deal with this.Rumors were circulating in security circles. And cybersecurity firm Chainguard decided this was good enough excuse to break the embargo and announce the flaw before patches were available. No patches for a flaw that impacts 20 years worth of software versions of widely deployed software.Patches are out now, though only for versions 8.2 and up. Source patches are out back to 7.4, which is officially end-of-life, but I have to wonder how many official EOLed copies of PHP are out there.On a lighter note, we can't let the hijinks of eMudhra pass without comment. eMudhra is, among other things, a root certificate authority. They've got a bunch of key pairs that they use to sign certificates for other customers, thus vouching for those customers' identity. As a root CA, they were trusted by pretty much every TLS/SSL implementation on Earth; if you had a certificate from eMudhra, every browser would trust that you were who you said you were.The only problem? One of their private keys was 4. Yes, it's the XKCD.Now, in their defense(?), eMudhra didn't generate impossibly insecure keys. They performed a key signing ceremony and generated appropriately strong keys. Then they used an in-house tool to pack/unpack the keys, and this tool decided to truncate some of them down to one byte. Shockingly, even though ECC has relatively short key sizes, 8-bit ECC isn't secure! You could derive the private key from the public key using only pencil and paper. But the worst part is that they did check the validity of the keys- before they got truncated, giving them a false sense of security.The good news, for eMudhra, is that this particular key signing ceremony generated a total of 24 keys, and only 8 of them were truncated to the point of uselessness. I have it on good authority that two out of three ain't bad.Now, after that disgrace, it's no surprise that eMudhra is dropping out of the certificate authority business. Still, the press release where their chairman explains the rationale is some serious "screw you guys, I'm going home," energy.

Submitter Chops relates a tale of chasing "The Standard" at any cost:

Usually I have to save up a few weeks' worth of error'ds to get five of a kind, but this week we got a rash of funky date entries! I guess we were due.First upTim R. reminding us here that "Dates are difficult!...but when theentire purpose of your web site is to convert thetime to different time zones, I'm not inclined to giveyou much slack for being one hour out."

We all love format strings for generating human readable text. Certainly, they're a better choice than string concatenation. Even if I have a blind spot that keeps me from remembering the printf format tokens, I still prefer to use format strings.Jasmine has a co-worker that does use format strings, but they also miss using string concatenation. So they've found a way to combine them, and avoid the perils of making readable code that describes the format of their text.

Today's code maybe isn't much of a WTF, but it does point in the general direction of, "Damn, you live like this?" Poor Nancy unfortunately does.

At my employer, we use a service called Coveralls, which is a code coverage reporting tool that hooks into your CI pipeline. It takes your lcov reports and gives you some insights, and also makes it easy to cause the CI pipeline to fail if newly added code doesn't have reasonable coverage.I have no strong feelings about the tool, but on February 24th, our CI jobs started failing, and our CI step that talked to Coveralls was the culprit. Coveralls had gone down. That happened to us, and a lot of other people. It was a widespread outage impacting anybody who used their service.Coveralls actively published updates as the outage dragged on, and boy, did it drag on. Between them posting nearly identical updates minutes or even seconds apart and the general desperation that snuck into their outage notes after the first few days, I couldn't help but find their notes hilarious.They've published their post-mortem, and the short version is that despite them paying their bills, Amazon decided they hadn't, and shut down their services. But it took them roughly 68 hours to figure that out.If you scroll down past the post-mortem, you can see their outage notes. This is an unauthorized, dramatic reading of those notes. We've taken some liberties in interpreting it.I hope this is taken in a good spirit, because they were just doing their best when this happened. I don't think most companies would be able to maintain operations when their cloud provider decides to lock their accounts. But I don't care who you are: begging your users to email you if they can help you migrate off AWS is funny. [Advertisement] Utilize BuildMaster to release your software with confidence, at the pace your business demands. Download today!

Taxes are a royal pain for everyone. Amazon has found a unique way to make them even worse, as Kris W. attests:

Dr. Doom...scroller titled this one "Scrollbar-ception". Said he"Screenshot of the TikTok webpage (i.e. in a desktop browser)while not logged in. I swear this wasn't a NSFWTikTok video, instead it was a montage of some liveshow from some singer. Anyway... Back on the topic ofthe actual publishable snarky comments: Social media is known fordoom-scrolling. Well, these are scrollbars of doom. Or doom-scrollbars."

We don't cover a lot of security issues here, simply because they're not usually funny. But sometimes, they are. So here's a quick hit about some recent ones.We start with a very bad month for the Danish social security system, the Central Register of Persons (CPR). Last week, they detected a breach which exposed the personal details of 8.8m people. Per the Register article, a cybersecurity specialist correctly pointed out that treating your ID number as if it were a secret was a terrible idea in the first place, but unfortunately, so many systems have grown up around the idea that full knowledge of your state issued ID number as proof of identity, that the security expert is screaming into the wind. They're right, but it's going to take a lot to change.Okay, Denmark's social security service was hacked. What's so funny about that?Well, the mechanism of the hack appears to go thusly. First, third party companies have access to the database, which they can use to send notifications to their customers via CPR. That connection is secured with a password, and one of those third parties secured their account with the kind of password you'd use to protect the precious air of the planet Druidia. Also known as the kind of password some idiot would put on their luggage: "123456". (paywalled, Danish article).The hacker accessed the system on September 10th, and spent ten days searching through the system. The intrusion wasn't detected until October 2nd, when CPR went to send an invoice to the third party company and noticed, "Boy, that's more searches than they have customers." Now, obviously, CPR should have never even allowed such a low complexity password, but also, the third party company shouldn't have used such a low security password.Now, if you'll excuse me, I have to change the combination on my luggage.In other news, I'm not particularly fond of blockchain stuff. Mostly, the whole distributed ledger seems like a solution in search of problems, and "trading tokens as if they're money" is the best thing anybody's been able to come up with. Back in my consulting days, when blockchains were all over the news, I was consulting with a large retailer, and they were exploring using blockchain in their supply chain. "How does that work?" I asked innocently. "It'll have blockchain in it." "Sure, but what does the blockchain get you?" "We'll be using blockchain. If there's like, an e. coli outbreak, we can trace where it came from." "Couldn't you get that out of a regular database?" "But this'll have blockchain."In any case, blockchain companies getting hacked and having all their users' assets stolen is practically a daily occurrence. Not really notable. But a recent hack is legitimately interesting.A company, called Ledger, sells "hardware wallets". Instead of storing your keys on some third party's servers (where it'll get hacked and you'll lose all your "money"), you store them on a hardware device that you put in a safe. It's not connected to the internet, and thus is unhackable. Or so you'd think. But if enough people are buying those devices, a supply chain attack becomes potentially very lucrative. And that's exactly what happened. Someone in the supply chain cracked a bunch of these devices open, and inserted new hardware. They attached a microcontroller to the screen leads, that allowed it to read what was on the screen (and thus detect when the screen was displaying a recovery code that could be used to access the wallet), and a cellular modem that allowed it to literally phone home with that information.In total, these hackers walked away with the equivalent of nearly $100M in cryptocurrency.All the devices passed through Ledger, where they were inspected before being sold. Presumably, they were sealed with tamper-resistant packaging. It's plausible that the tamperer was downstream from here and the customers didn't fully inspect the packaging. Even your most savvy user generally doesn't check that kind of thing, and I suspect a lot of these customers aren't actually all that savvy. But also, companies in the crypto space tend to be... we'll say, more eager than cautious, so I wouldn't be surprised if the tampering happened upstream and didn't get caught by their inspection process.Security is hard in the best case. It's much harder when you're putting the final onus of security on end users who may have thousands or even millions of dollars locked behind a single key. Or when passwords are hard, so you pick an easy one to remember.[Advertisement] Plan Your .NET 9 Migration with Confidence

Mandy's co-worker recently learned about virtual inheritance in C++. It's become their new favorite button to push, and they only use virtual inheritance.Virtual inheritance is one workaround for the "diamond problem", where you have an inheritance tree that "recombines" via multiple inheritance: when a child class has a Hapsburg-esque parentage, it's hard to decide which inherited methods are being invoked or overridden.In C++, imagine you have class A, which gets derived into classes B and C. Class D then uses multiple inheritance to inherit from B and C. In practice, this means that D inherits from A twice, and would have two internal copies of all of A's members.If, on the other hand, you have B and C inherit virtually (class B : public virtual A), then class D will only actually inherit a single copy of A.If you're reading this and going, "Boy, this just sounds like another reason to avoid multiple inheritance," you're probably right. The important thing, though, is inheriting virtually impacts how your child classes will inherit. It only matters if you have child classes.Which brings us back to Mandy's co-worker. He read somewhere that defaulting to virtual inheritance all the time was safer, so he did that all the time. All. The. Time.Including in this case:

Ever get some special letter, card, or picture from a friend or loved one that you held onto, maybe even taped to your cube or office wall? Is it something you still look at fondly, something that lifts your spirits whenever you're down? Certainly, a thoughtful card or letter is much nicer than a thoughtful email.Now imagine your special keepsake being scanned, censored, and converted into a digital file that you can only view from a tablet - assuming you can afford the fee to access the tablet. The original has been destroyed; it's gone forever. You'll never get to see or feel it in your hands.It sounds almost too cruel, like something you'd find in a Fallout game. Unfortunately, it's reality for more and more people incarcerated in US prisons.I've been writing to an incarcerated person for a while now myself. I find the process incredibly rewarding; I think about my friend all the time and wish them well. Unfortunately, the scanning and processing takes absolutely forever, so in a given year we only exchange 3 letters per side. The digitized files that I receive have names censored out of them; I have no idea what's removed from my letters before my friend receives them. For me, this is all too reminiscent of exchanging letters with my grandmother in Iran before she died. Agents there would straight-up open the envelope, confiscate any valuables inside, marker over anything they didn't like, then re-seal the envelope and send it back on its merry way.Over 30 US states now digitize the mail passing in and out of prisons, relying on AI to judge what's kosher and what isn't. If you thought AI was great with resumes, just wait until you task it with threat detection! It's been working so well that one nonprofit organization had to change its name: the word fight, used in any context whatsoever, gets flagged.Once mail is scanned, it's only accessible by tablets that have to be paid for. Incarcerated people are already nickled and dimed for a ridiculous number of things and surely don't need more fees.It doesn't stop at mail, either. The latest tech is also being used to eliminate physical visitation. Because if there's anything the pandemic taught us, it's that nothing beats seeing your loved ones exclusively on a screen for years at a stretch.The states justify these egregious measures by playing the drug card. They're necessary to stop drugs from entering the prisons. But these states stop short of providing evidence to show that these tech-facilitated practices are actually having the intended effect. Even if they magically solved drug trafficking forever, could any result truly justify the vast harm being inflicted upon incarcerated people, their families, and their friends? Physical mail and visitation are necessary lifelines and psychological boosts for those who might otherwise have nothing and no one to hold onto during an unimaginably difficult time of their lives.Do I really have to explain the benefit of parents and children exchanging homework, letters, and pictures?I'm angry about this on so many levels. If you are, too, here's some stuff we can do to fight work against this together:

For some godawful reason, people like to explain object oriented concepts via analogy to biological taxonomies. I suppose it's easy to understand an "is-a" relationship (a cat is a mammal), but the down side is you get a complex and increasingly leaky analogy that over-emphasizes the importance of inheritance.That's not to slight Alan's choice of using it to anoymize today's code. It's just a broad frustration on my part.In any case, Alan has been working in a C++ codebase that's written by people who maybe don't fully understand all the key object oriented concepts. That's why you get code like this:

Matias shared a standard sort of flubstituted fail-merge error'd; not really egregious, just routine."I am {{emotionType}} to hear this."

Robert G sends us a WTF from the outside, but I think we can come up with some hypotheses about what actually happened.Robert was traveling by train. For complicated train reasons, the car he was seated on was not actually scheduled to continue with the train he was booked to ride, the replacement car missed its scheduled arrival, and the result was that Robert was left at a station needing to rebook his travel.Now, given that this is in a region of the world with a fairly robust train network, this represented a hiccup of thirty minutes in a many hour trip. Not a particularly big deal. But Robert didn't want to get stranded any longer than he had to, so he took out his phone, fired up the train company's app, and made sure he had a reservation on the next train. He got the confirmation, and grabbed a coffee while he waited.Not quite thirty minutes later, Robert boarded the train and went towards his reserved seat. Another passenger approached from the opposite direction, and they met at the seat. "Excuse me," Robert said, "but I reserved this one.""No, I reserved this one."Being reasonable people, they both pulled out their phones and pulled up their apps. Sure enough, each one of them was confirmed for that seat. Since the email confirmation had more details than the app provided, they both pulled up the email. Same seat. Both confirmed. The timestamp of the reservation? The same, down to the second."I don't think the conductor will let us sit in each other's laps," the other passenger said.As it turned out, there was enough room on the train that no lap sitting was required. Everyone got a seat, even if it wasn't the one they reserved.But the story stuck with Robert. A major transit provider had a reservation system that clearly had a race condition. It seemed like the most basic example of race conditions too, the kind you're shown in college to explain the basic concept."Check if the seat is reserved, and if it's not, reserve it." Because that sequence isn't atomic, two different threads could do the check, see it's not reserved, and then reserve it. I suppose it's at least something that one reservation doesn't overwrite the other, which at least indicates that a reservation is its own record.The real question is this: this has to happen with some frequency, so how has nobody fixed it?The real answer: they probably just don't care, either because they literally don't care, or because their software is such a trashfire that this doesn't even rise to the top ten bugs. It's likely a mix of both. [Advertisement] Keep all your packages and Docker containers in one place, scan for vulnerabilities, and control who can access different feeds. ProGet installs in minutes and has a powerful free version with a lot of great features that you can upgrade when ready.Learn more.

A junior dev on the team had a simple question: in Java, how do I correctly read user input from the CLI and act on it?Now, we can wonder about a junior dev not having such basic knowledge, but maybe they're new to Java specifically. Who knows. But Robert's team has a senior on it who "likes to mentor". This senior has strong opinions about how to write software, extreme confidence in those opinions, and has somehow been around the company long enough that he knows where the bodies are buried and no one will fire him.Here's his sample application for reading input.

Many years ago, DJ got his start doing odd web development jobs for a low hourly rate. He was only 19 when he got started, and what he lacked in experience he made up for in being cheap to hire.As I said, that was many years ago, and he has since learned a lot. But he still has some code from his very first "someone paid me for this" project. This particular function needed to pick a random bit of content from their database to display in the "right side" banner area. This is how DJ implemented it.

Today's anonymous submitter sends us some legacy Java code.The task is this: check what time it is. And fortunately, even in the older Java datetime libraries that were terrible, this was an easy task. You just needed to do something like new Date(), which constructs a date time object set to the current time. getTime() picks off just the time portion.Or, you could do this.

We have for you this week a full set of the Error'd we most love to hate: the perverse password policy.An anonymous reader drops this, with little to say except to note "Speciaal passwords". Evidently they supplied a password which satisfied each of the five green critera, but still it was rejected.It would be nice to know where this offense originated,

Today's anonymous submitter shares with us the function their company uses to validate authentication tokens.

Fritz's team needed to see if one point was within a certain distance from a center point. You or I would likely try and answer this question using a simple distance calculation, since that's the question we're trying to answer. But what if you didn't understand distances at all? Then you could write this little piece of genius.

Nikolai M's team had a flaky CI/CD build. About 0.5% of the time, one of their tests would fail: frequent enough to be annoying, but not so frequent that it motivated management to assign anybody to investigate. Nikolai eventually dug in, taking the initiative.Microsoft's implementation of UUIDs calls them GUIDs. The GUID is, per the docs, really just a wrapper around UUID algorithms, and supports a variety of different UUID variants. I'm sure at some historical point, this wasnt't true, and Microsoft had some weird internal algorithm. That's not really here nor there, but the test that was failing was failing because of an assertion relating to GUIDs.

Our submitter Tim C. is back as his bureaucratic nightmare continues. Read Part 1 here.

I know it's not nice to mock mistranslations, but would you believe we're laughing with them,not at them? In response to recent criticism of the difficulty of identifying preciselywhat is at issue, two of our readers have chosen to highlight the offending element.Thanks for saving me the trouble!""Bad Dutch translation, or is't?" askethMike V."I visited the Dutch Dell site https://www.dell.com/nl-nl and noticed thebad translation on the "Accept All" cookies button. Then Ivisited the UK page on https://www.dell.com/en-uk and was not sosure anymore about the bad translation. Funny thing is thatthe text above the buttons refer to the buttons witha completely different text (which is an Error'd in itself)" If I squint I can almost see howthis kind of translation could happen.

Tim inherited a fairly antique Visual Basic application some time back. Yes, Visual Basic, not VB .Net. The application is old enough that we might consider it "vintage" or "historical"; it certainly dates from before the millennium. But it has its own unique approach to handling historical dates:

Our submitter Tim C. shares his tale of an especially brutal culture clash:

David C sends us a true confession.

On July 10 2026, a life insurance company called TruStage had a "cybersecurity incident". According to an update posted five days later, when they revealed the incident, they are "continuing to work carefully and urgently to understand the facts, and the company will communicate appropriately as its understanding of the situation evolves."This work, according to their outage page (last updated on September 11th, at the time of this writing), is continuing. Every major business function is listed as "partially available". They have some text explaining that they can't simply turn the system back on, because safety.They don't know what data was compromised. They don't know when they'll have everything back up. As of mid-August they had gotten so far as setting up a "clean" environment that they could start migrating services to. The only good news is that some of their services are supplied to credit unions for banking, and those were on different systems, so only their insurance packages were compromised. I also suspect the fact that they serve credit unions is the only thing keeping the business afloat, because failing to handle transactions for months seems like a terminal event for most businesses.Obviously, this also means they're embroiled in an ever growing number of lawsuits from a variety of parties. It also highlights something about how insurance works: it's middlemen all the way down.TruStage will issue policies, but their connection to the actual policy holder will likely be routed through a number of different partners. Like, for example, Ethos.Ethos uses "AI" to "democratize" insurance. Feed your data into their AI, and in minutes they'll pair you up with a policy. Which, while using machine learning to do things like assess insurance risk seems like a pretty reasonable idea, in this age of AI hype, one has to wonder how this actually is implemented and how it works in practice.But Ethos isn't the end of the chain! Other companies live downstream from Ethos, for example, Family First Life. A customer might reach out to FFL to get a policy, FFL reaches out to Ethos (or one of many other partners), and Ethos reaches out to one of its partners (TruStage being one of their largest), and boom: an insurance happens. Like I said, it's middlemen all the way down.But now, here's the problem: TruStage issued a bunch of policies, and then stopped being able to do business. They stopped being able to do even vital things, like process payments. And you know what happens when payments aren't made on a life insurance policy? It lapses. It goes away. You no longer have insurance. And the agents who sell those policies are often paid a commission based on the value of the first few months of the policy's life (since life insurance is expected to be a long term investment). If the policy lapses, those commissions vanish, companies like Ethos (or downstream partners like FFL) get chargebacks on the value of those failed policies.This makes some people, like FFL's President, Shawn Meaike, very unhappy.What we have here is a pretty egregious failure of cybersecurity and disaster recovery on the part of TruStage. It's an embarrassing and potentially terminal event for them. It's awful for the customers who bought insurance policies to give themselves peace of mind, only to discover their policies lapse because TruStage can't take their money. It's creating mild chaos in the entire industry. That's all interesting, but not why I wanted to write an article about this. I wanted to write about the incredible cringe.In this clip from an insurance industry conference, Meaike brings up all of their partners for a "carrier panel". He then proceeds to line them up from stage right to stage left, ranking them as "weakest" to "strongest". Ethos, who sells TruStage policies, is labeled as the weakest."You have the weakest leg," he says, pointing at the reps from Ethos, to laughter from the audience, and then indicates the other side of the line represents "the strongest leg." Meaike hands the microphone to an Ethos employee, Dylan Cummings, "We'll start with you.""I want to start out by thanking everyone," Cummings says.Meaike cuts him off. "Hey, hey, hey, hey. I'm gonna help you. Why don't you start by saying you're sorry."The crowd yells out, "Yes!" and applauds this idea."Say 'We have a carrier that's shut down'," Meakie continues, "'and I'm mother-freaking sorry.'"Yes, he said "mother-freaking", on stage.So let's recap. An insurance company gets pwned so hard they can't run operations for months. People's policies lapse, simply because they can't give their money to the insurance company. Which 100% sucks for those customers, though at least with life insurance we expect very few of them are missing their payout- hopefully! This chain cascades through the network of partners, until it culminates in the president of one company publicly humiliating the senior account manager at a middleman company, during an industry conference.Nobody comes off looking particularly good here, obviously. Meakie is a jerk. TruStage is institutionally incompetent. Ethos is in a bit of a rock-and-a-hard-place situation, and Cummings is trying to do his best to tap dance his way out of oblivion, but it seems like the AI driven insurance startup just isn't a good partner even before their main issuer died.All in all, it feels like a Tim Robinson sketch, or perhaps a Nathan Fielder bit. We're one step away from Meakie calling Cummings a "Wizard of Loneliness."[Advertisement] Plan Your .NET 9 Migration with Confidence

It seems like only yesterday we were mocking the AIs for their limits, and tomorrow they're going to be mocking ours. In the meantime, here's a look back at some humorous moments from the last year or so. "Mathing is hard" wroteTimothy W."I for one welcome our new AI overlords."

Today we have more of a representative comment, from Watson. This comes from some GPL licensed code published by everybody's favorite evil empire, Oracle.

Autoformatting your code is a standard thing to do these days. And in those days past, if we're being honest. There's no excuse to not use some kind of autoformatter. Whether you configure your editor to do it or are a weirdo like me who runs a formatter from the CLI as a build step, you've got an easy way to format your code so it looks neat and readable. And some IDEs, like Visual Studio, are pretty insistent about doing this for you. Which makes today's code sample a bit more perplexing. This comes from an ancient ASP .Net application that Austin has the misfortune to work with:

Let's say we wanted to query Active Directory and print out a report of all of our users, and their last logon time. That seems like a pretty normal task for a Powershell script. It'd probably be short and easy to read, at least if it were written by a normal person.Alice sends us one that wasn't. She's already done us a favor, as she writes: "Code cleaned up and indented for the whitespace-missing-impaired."

In addition to using an ancient development environment, with terrible UX, Greta also has the misfortune of working in Pascal.Recently, she was diagnosing a bug. The program was reporting that files didn't exist when they definitely existed. She traced the problem down into the system library. Let's see if you can spot what's wrong:

Some new and some old entries this week, from people who find zero profoundly unrewarding."A scary blue button from The North Face" warnsDmitry K.."Northface has just proudly rewarded me with nothing. I amnot sure whether I want to try adding such anon-positive amount to my wallet. I am afraid I cantrigger a chain reaction that will crash the financial systemof the whole world..."

I'm not a DNS person, in that I appreciate that it exists but am not up on the inner workings. It solves a lot of problems with dark magic I don't fully understand, and fortunately don't need to.But Lucio noticed something that I do think is interesting, within the scope of the CAA record type.The CAA record started with RFC6844, which was obsoleted by RFC8659. Both RFCs lay out the same core idea: you can add a CAA record to your DNS entries to say, "hey, this domain over here is allowed to issue certificates for me". That's the sort of thing that enables LetsEncrypt to hand out certs, and is an important part of why we can run HTTPS everywhere these days.Now, RFC6844 has this in it:

Eri has a mix of a "true confession" and a "wait, really?" today.The programming language Vala bills itself as a C# like language that compiles into something pretty close to C performance, designed specifically for writing code against Gnome and its associated libraries.One of the C#-isms in brings in is async/await type semantics. You can yield someAsyncFunction(), which returns control to the caller, allowing it to proceed until the yielded function returns an actual value.Because it has asynchronous functions, many library functions for handling I/O are already async. So you can make_directory_async, which yields control so you can keep executing while waiting for the filesystem to make your directory.There are also synchronous versions of those methods. And then there's create_directory_with_parents, which will create a chain of directories for you. That's the synchronous version, and Vala's core library has decided not to provide an asynchronous version of it, which is my "wait, really?" I suspect it's really about the race conditions involved and the risks of things going wrong while doing it asynchronously; all solvable problems, but tricky ones to solve.But it's the problem Eri had, and this is their solution:

From our anonymous submitter: