How is this different than Fabrice Bellard’s achievement in 2011? https://bellard.org/jslinux/

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 disagree: self hosting and enterprise are not mutually exclusive. In fact, “enterprise on-prem” is the marketing description for self-hosting. I do not accept any definition of self-hosting that gate-keeps to any degree.

It is incongruous to talk about “only home self-hosting” or “only enterprise on-prem” when it comes to security mitigations, threat modeling, and risk management: it is merely a question of scale.

Sure, the user base for a home setup might be single digits, but the attackers are identically situated: their capabilities do not grow or shrink based on whether they are targeting a bank or a Jellyfin server.

In a nutshell, doing it this way adds robustness when – not if – the destination software changes its behavior, inadvertently or not. It’s very similar to software assertions: if this assumption stops holding, then we want to know ASAP because it means subsequent logic is no longer valid.

In the Immich case, the author writes:

This is a side effect of how Immich checks permissions, not a feature made for this purpose, so a future version of Immich could change it. If this ever changes, the share links will answer 404 and I will notice quickly.

Suppose the author updates their Immich instance but missed a remark in the release notes that share keys will be using a different hash algorithm. That’s a mistake with their upgrade procedure, sure, but it’d be ideal if such mistakes were detected sooner than later. Without the check for link validity, the only log that would record the now-invalid share links would be in Immich logs. But with this additional check, there is also a log at Caddy. More visibility, combined with an existing alerting regime, means errors and mistakes are captured earlier.

At first glance, it might seem like both approaches still result in a 404 for the user, which suggests neither approach is really “robust”. But one is a near-silent failure yet the other gives a loud, unmistakable signal that something is broken, meaning it can be addressed. Phrased another way, the signal-to-noise ratio of an assert fail is very strong.

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.

This is an awesome series, but that 20 month wait for a /24 IPv4 subnet would be unbearable to me. I’d rather just go mostly-IPv6 and maybe run NAT64 or something on a VPS to cover legacy uses.

I say this because while some are fine with waiting, I view self hosting as an act of self sufficiency and resilience, which really shouldn’t be on someone else’s timeline. If IPv4 subnets are the only thing holding someone who’s willing and able to run an AS, I would genuinely recommend ditching IPv4 and the scarcity that comes with it, even with the translation costs elsewhere. Perfection must not become the enemy of good-enough.

Port forwarding is moderately simple but there are risks to just opening a port and not guarding it with appropriate firewall rules. This includes an SSH server if not up-to-date.

Whereas setting up something like Tailscale on your machine and on your laptop is exceedingly straightforward, avoids firewall reconfigurations, and Just Works™. You could then connect to whatever service you have running, just as if you were on your LAN. My only gripe is that you do need a Google/Microsoft/GitHub/Apple account or OIDC to set up.

In the long term, if you have misgivings about that company operating the coordination server necessary for this tunneling solution, then there’s always the open-source Headscale, which is a drop-in replacement.

My network and server setup eat about 200 W, split right down the middle. I have plans to cut the network consumption by replacing the PoE switch, so that I can use the savings to add another server.

So it’ll still be about 200 W, but more useful.

This appears to be an AI port of an AI project named after a conspiracy theory?

For other folks reading, be mindful that not all PC fans can efficiently draw airflow through a filter. The key word is “static pressure”, which refers to how much force can be exerted on a fully-blocked opening, which would then produce airflow through the parts that are less blocked. The simplest PC fans basically have zero static pressure, and so they’ll just spin uselessly when covered by an HVAC filter.

As an aside, dust and lint in PCs can be reduced by limiting dust and lint in the environment: replacing your home HVAC filter, not wearing shoes indoors, electrostatic fans, and using mechanical ventilation rather than opening the window are effective ways to keep detritus away from your machine in the first place.

dust blanket

Me: hmm, that’s an odd way to describe a bit of dust

[looks closely at photo]

Me: oh dear gawd!

In the end, programming is commanding a computer system to do your bidding. If your goal is to make electronic metal music, or complex 3d designs, simulate fluid dynamics, or solve for wheel settings on the Enigma machine, those are all programming tasks. Some may involve long runtimes, but the programming is giving the instructions to execute.

Even formulas in Excel are programming. But make no mistake that programming and software engineering are very different tasks: the latter is about devising good designs that balance countervailing interests. Software engineers define the problem which programmers would command onto a computer to find a solution or produce a product.

It is time for all computing professionals billionaires and corporations to accept responsibility for computing’s humanity’s current state

FTFY

In all seriousness, Vardi correctly identifies the problems with “move fast and break things” and “efficiency at the expense of resilience”. Yet then uses victim-blaming language that “we allowed” mega corporations to exist. Even if the “we” is read as “society at large”, it cannot be reconciled with the call-to-action, which unambiguously targets the individuals of the industry. Without effective organization, no amount of individualized action can overcome a structural problem. It’s unclear to me what his point is.

I didn’t watch the video – and YT isn’t letting me speed-read a transcript? – but generally speaking, if you have a need for memory that isn’t backed by the filesystem, and you’re writing in C, just use malloc. It’s designed for that purpose, although malloc might very well be calling to mmap to obtain an anonymous mapping under the hood. Even if you’re going to hold on to memory for the entire lifetime of a program, still use malloc in C.

If your application does need some filesystem backing, or if you’re allocating enough memory that hugepages might be reasonable, then that’s when you’d want to use mmap.

The CA cannot decypt: they don’t have the secret key which only the server has. When requesting a new certificate from the CA, the server generated a secret key (aka private key) and then generated a derived public key that goes into a Certificate Signing Request (CSR). The CSR is what the CA receives, not the secret key, and then the CA returns the certificate file to the server, which has been endorsed by the CA and thus trusted by the user base.

Phrased another way, a certificate is the instrument that confirms that a purported public key can in-fact be safely used, and that no MITM attack is happening (assuming you trust the CA that signed the cert). But once you’ve confirmed the public key, the rest of the cryptography is public key cryptography, meaning the secrecy of the secret key is the whole game.

I think Signal tries to be E2EE but has other problems, including that MLS (the E2EE mechanism) inherently requires a client app instead of being usable with just a browser.

I’m having trouble imagining what in Signal’s implementation of the Double Ratchet, or any part of RFC9420 Message Layer Security, would inherently require a client app. Perhaps you mean that there is no readily available browser-implemented API for carefully managing secrets? Even in that situation, all the libraries needed to implement the RFC can be compiled as WebAssembly or to JavaScript (with the assumption that the browser and OS are outside a malicious actor’s capabilities) and ran that way.

To be clear, I’m not suggesting Signal is perfect, and papers about problems found in Signal and other apps are readily found, like this one from last month. But with that said, it does appear that OP’s described use-case involving hundreds of users in group chats is very much not what Signal was designed for,.