IPv6 is not affected by this race because the kernel copies the options for IPv6 connections.

It’s been a slow-going effort to get a compile flag into the kernel that disables IPv4, but this is precisely the type of bug which that flag would have avoided. When devices choose to natively use IPv6-only – eg IoT – they really shouldn’t have to also accept an increased attack surface from Legacy IP, something that is increasingly unnecessary.

Disabling IPv4 when it’s unneeded is good security posture, but such a choice is not available yet in Linux.

This does not comport with what OP says below.

What language is this?

I like this idea, even though it’s the opposite of dull haha.

I do have to ask: have you considered tape backup? Even the latest LTO-10 isn’t as dense as a single BD XL disc, but the read/write speed for linear data would be higher and sustained. Whereas a disc often only gets faster when reading the outer edge. This would be most useful when periodically verifying that the backup is still intact.

There are automatic tape libraries, but that’s quite the investment, I think.

If you’re dealing in probabilities, that’s not threat modeling; it might be in the larger umbrella of risk management though. Defining a threat model means to qualify what sort of attacker you expect to face and what they are assumed to be capable of. An assumption such as “this adversary can send arbitrary packets to the public IP address” is what would be documented in a threat model.

The raison d’etre of threat modeling is to methodically tackle the actual or assumed risks that an attacker can pose against you. It is not an exercise in swinging at shadows, though I wouldn’t discourage overstating the capabilities of an attacker, if needing to protect assets like patient info or PII. Doing threat modeling based on “gut feeling” is a recipe for not recognizing risk where it’s present and seeing risk when there isn’t any.

The fact remains: you cannot squeeze blood from a stone. Even the most sophisticated AI cannot steal PII from a computer that doesn’t store PII. Proper threat modeling means you don’t put anything on the line that you haven’t squared up against the risks, however improbable. For any non-zero concern, a good threat model will discuss its mitigation, whether it will be absorbed, or if it is an open question. For an out-of-scope concern, a good threat model will explicitly state that assumption.

Answering the titular question, why would the advent of AI-found vulnerabilities substantially change one’s threat model? Before LLMs, the prospect of an undiscovered vulnerability was non-zero probability then, so what exactly has changed now?

In terms of attacker capabilities, it would be a mistake to solely observe that attackers now have LLMs and conclude that this means the threat landscape has changed. The use of LLMs does not magically create a root escalation where one does not or cannot exist. Part of your threat model should include defense-in-depth mitigations, so that when (not if) an attacker finds a 0-day exploit, they are severely limited in gained functionality on your machines. In the simplest cases, jails or containers serve to keep separate the web-facing processes. VM isolation would be a further step, because an attacked cannot gain machine control without both a software exploit as well as a VM escape route. People hosting services can and should expect that their front line defense will fall, so they better have more defenses in place.

Phrased another way, the people who have done their threats analysis properly and have accepted the residual risk of hosting their own services that face the web, should not really be additionally perturbed by AI advances. This isn’t the same caliber of landscape change as would, say, the invention of a cryptographically relevant quantum computer. If the worst thing that can happen to your home IRC server is that it gets flooded by a script kiddie, AI does not mean your server can now burst into flames.

Much like with human hygiene, some basic rules are unusually effective against most threats. The equivalent to washing one’s hands is to stay on top of system and software updates. Institutionally funding the organizations (eg PHP Foundation, curl, USA CDC) so they can fix these problems would also help.

If the backing files are referencing “snapd”, then it seems plausible that these are the sandbox filesystems for software packaged using the Snap environment.

I use GnuCash, because it’s the only FOSS accounting package I’ve found that sensibly handles transactions that involve more than two accounts (aka “splits”) at a time. There’s a bit of a learning curve if you’re new to double-entry accounting, but it does support CSV import, can manually reconcile its records to whatever statement period you want, and can export to graphs or spreadsheets as needed. While highly capable, it can be used for simple cash-flow management as well.

It is, however, strictly a desktop app, and is wholly a separate endeavour to *GnuCash for Android". That said, one reason that I’ve continued to use GnuCash for the better part of a decade is because the UI basically doesn’t change. There’s not much room for enshittification when it’s all GTK-based. Anything else I want from this program, I can do using Python by crunching the data exported as a CSV file.

EDIT: to put into concrete terms why multi-split transactions are useful, I will offer two examples. The first is about granularity of expenses, such as a day at the thrift store. If I’ve acquired some home decor, a vintage shirt, and a trinket for my bicycle, then I would want to record the transaction as such:

• Assets:Cash: -$32
• Expenses:Home Furnishings: +$20
• Expenses:Clothes: +$7
• Expenses:Bicycle: +$5

This does take extra effort to break down into each expense category, but how granular you make your expenses is up to you. Certainly, some transactions wholly fall into one expense category (eg McDonalds as Expenses:Dining) and so there’s no big effort there.

The second example is about multiple money flows as part of the same logical action. Suppose that I treat my credit card as though it’s a debit card – to live within my means – and every time that I use the credit card, I move an equal amount of money from my checking account into my savings account, precisely to pay off the credit card bill at month’s end. This is how the transaction might look:

• Assets:Checking: -$67
• Assets:Savings: +$67
• Liabilities:Credit Card:American Express: -$67
• Expenses:Entertainment: +$67

When it comes time to reconcile (aka “balance my checkbook”), I can do that for each account, one at a time. So my checking account statement is reconciled to Assets:Checking, my savings account to Assets:Savings, and my American Express credit card statement reconciled to Liabilities:Credit Card:American Express. These can happen on their own cadence, since while the bank accounts might end on a calendar month, credit cards often use their own statement dates.

This seems like a lot of data entry, but seeing as GnuCash helpfully finds and clones fields when manually entering a new transaction, it’s almost like a copy/paste followed by a bit of cleanup. In my regular workflow, my typical transactions have two splits. The most irregular transaction I’ve ever created had 28 splits, because it involved donations to multiple charitable causes, split across cash, checks, credit cards, and US Treasury bonds (which paid interest upon withdrawal, and so had to be accounted as well).