2026-06-27 · Bringing Swift to the Apple II

Transcript

Transcript. Paraphrased; sources in notes.md.

HostWelcome to the podcast. It is June 27th, 2026. I am Daniel, and joining me as always is Alex. Today we have a dense lineup. We are looking at a wild project bringing Swift to the Apple II, a breakdown of a sophisticated, targeted developer attack, and the move toward total reproducibility with NixOS and Incus. Alex, I have to say, the idea of someone trying to compile Swift on a 1977 1MHz machine is absurd, but it feels like your kind of madness.

GuestIt is not madness, Daniel, it is an attack vector. You get a modern, high-level language running on hardware that predates the very concept of a modern security boundary, and suddenly you have a machine that does not know how to be compromised because it was never designed to hold state in a way that modern exploits understand. Or, more likely, it is just another way to get arbitrary code execution on hardware that cannot even run a basic firewall. I love it.

HostWell, let us jump into that. The author built something called SwiftII. For the uninitiated, the Apple II is the iconic 8-bit home computer from the late 70s. This project brings a subset of the Swift language to that hardware, complete with a bytecode compiler, a REPL, and a custom text editor. The author is quite candid that they used AI to get through the implementation, which is a fascinating layer to this, but it is essentially a passion project to see if modern, type-safe syntax can actually fit on a machine with essentially zero memory.

GuestA subset of Swift on a 6502 chip. The author claims it reads like Swift, but you are still just shifting bytes on a machine that has no concept of memory protection. You feed it a malicious payload, and it does not have a kernel to panic; it just executes. It is charming, in a terrifying, I-am-going-to-stare-at-a-blinking-cursor-while-my-entire-system-state-is-unpredictable sort of way. You know, when I look at these retro projects, I do not see history. I see unpatched, monolithic environments that would make a modern auditor weep.

HostYou definitely see the world through a specific lens, Alex. Over on Lobsters, this was posted, but there were no substantive comments to chew on. People seemed content just to watch the spectacle. I think there is something to be said for just pure technical achievement, even if the result is something you would never put on a network.

GuestThat is the problem. People see a shiny new interface and they forget they are standing on a foundation that has been rotting for forty years.

HostLet us shift to something that is very much on the network, and very much compromised. There is a new write-up regarding a failed nation-state-style attack. A developer was targeted by a fake venture capital firm called Lua Ventures, which tried to lure them into a fake interview process. They sent over a TypeScript project that was heavily booby-trapped. The attacker hid malicious payloads inside of patch-package files, which is clever, because most people do not audit their patches. The author used Claude to do static analysis and found the RAT, or Remote Access Trojan.

GuestAh, the classic fake interview. It is the oldest trick in the book, upgraded for the LinkedIn era. These attackers are not looking for exploits in the crypto; they are looking for the weakest link in the supply chain, which is the developer who wants a job. You bring in a dependency, you run a patch, and you have just handed your shell to a bot in a basement somewhere. The author is lucky they have the discipline to actually look at the files they are pulling. Most people just do npm install and pray.

HostIt is a sobering read. One commenter on Lobsters, eyesinthefire, expressed skepticism about the nation-state label, noting that the complexity does not necessarily scream government-level involvement. However, Manishearth, who had actually written a blog post about this exact type of attack a week earlier, mentioned in the thread that it was spooky how similar this was to their hypothetical scenario. It seems like this is becoming a recognizable pattern.

GuestOf course it is. In their words, to quote Manishearth directly, it was a bit spooky to learn about this attack. Because why would you not use it? You have a high-value target, you have a plausible lure, and you have a supply chain that trusts anything with a version number. If I wanted to own a specific dev shop, I would not waste time on zero-days. I would just post a fake job listing for a "Senior Rust Engineer" and wait for the pull requests to start rolling in.

HostThat is bleak. Moving on to our final topic, which is a bit more hopeful about maintaining order. We have a post about someone migrating their entire homelab from Proxmox to NixOS and Incus. Proxmox, for the listeners, is a popular open-source platform for managing virtual machines and containers. The author argues that even with automation, you get state drift, where changes happen on the fly and never make it back to the config. They want a purely declarative system where the config is the absolute source of truth.

GuestDeclarative, yes. That is the only way to sleep at night. If I cannot recreate my entire stack from a git repository in a single command, I do not have a server; I have a pet that is slowly dying. I actually use a custom internal tool for auditing my own Nix flakes. It keeps a manifest of every single dependency version and hash, and if something deviates by even one bit from the lockfile, it triggers an alert. It stops that "one quick fix" behavior that everyone talks about.

HostThat sounds like a lot of overhead, but I can see the appeal. The Lobsters thread had some great nuance here. A user named pondidum mentioned they had issues with Incus network bridging and switched to Podman with systemd, while altano pointed out that sometimes you just cannot get away from containers because some software simply does not have a NixOS module available.

GuestAltano hits on the real pain. The "container as a necessary evil" because the vendor provided a blob and nothing else. You see this everywhere. You want to be clean, you want to be reproducible, but you are stuck running a container that effectively functions as a black box. You have no idea what it is phoning home to, and you have even less idea what it is patching at runtime.

HostIt is a trade-off. You gain the reproducibility of NixOS, but you still have to contend with the reality of third-party software.

GuestPrecisely. It is just turtles all the way down, Daniel. You secure your host, but you run a containerized app that has root access to its own slice of your kernel. It is a constant battle.

HostWell, on that comforting note, I think we are about out of time. Alex, any plans for the weekend, or are you just going to be auditing your own fridge for potential supply-chain vulnerabilities?

GuestI am going to be manually verifying the hash of every single block of code I interact with. Maybe I will look at the fridge. If the smart bulb tries to update its firmware, it is going in the incinerator.

HostI would expect nothing less. Thank you for joining me, Alex. You can find all these stories and the full discussion over on Lobsters. Thank you for listening, and we will see you back here tomorrow.