Has anyone from the AUR team (such as that is) published a retrospective yet? This was some impressively fast firefighting but in all honesty, it seems like some changes are needed, either in AUR policies or in the wrappers.
I should be able to set a minimum package age just like I can with pnpm.
Orphaned packages should not be adoptable by just anyone. Maybe there should even be a global rate limit on this as a sign of attack.
Someone or something should vuln-scan these packages as they're published, as a number of companies do for NPM now. That would likely have found these pretty quickly.
Most of these are not changes to be made by the AUR maintainers, but rather by packaging helpers and 3rd parties.
Are you suggesting like <package-name>.packaged-by.joe-Schmoe ? And then if Joe Schmoe abandons it, people should instead switch to <package-name>.packaged-by.Abe-Lincoln etc?
> Orphaned packages should not be adoptable by just anyone. Maybe there should even be a global rate limit on this as a sign of attack.
Why not? I agree some limits should be added, but also shouldn't be too limited, then lots of things that could be properly maintained, won't. Maybe limit adoption to one package a month or something, to users registered since some date. But no one has automatic (& unreviewed) updates applied to their locally installed AUR packages (that'd be utterly bananas) so the attack vector is already pretty small here.
> Someone or something should vuln-scan these packages as they're published, as a number of companies do for NPM now. That would likely have found these pretty quickly.
No. It wouldn't have. That's the whole point of the miasma worm, because it changes too fast in its signatures and helper methods. The encrypted malware implant uses a changing AES-128-GCM key that's used to decrypt the payload, and that key is per-where-it-is-uploaded on GitHub. The code itself is dynamically renamed in its methods, re-used shuffled offsets for encrypted symbols, among other things. It's a mutating malware and the worst enemy from tools that rely on signatures.
Ironically, APT28/29 is somewhat relying on Microsoft being too slow to auto block users and repositories on GitHub that are the C2 infrastructure. Think about that for a second what this implies for your cyber strategy.
By the time you're able to scan signatures or "strings" you're already playing a cat and mouse game with a fully automated botnet, which you will never win. The only other ones I've observed during the last week that seem to be able to track this malware implant's changes were socket.dev. ALL other supply chain tools didn't even know about Miasma and re-invented it as a new campaign. They didn't have the skilled enough people nor toolchain to reverse the malware payload quickly enough to be able to keep up every 24h when they push out a new adapter for another ecosystem.
By fully automated I mean they're already using the credentials they stole less than 48 hours ago from a different package ecosystem, because the email addresses and names etc keep appearing from people who likely didn't even understand the impact of this self-spreading worm.
And having an IOC that checks for, let's say, any package that depends on bun won't help either because the malware will just use external means to re-download it. See the second PyPi campaign, where they just changed the dropper to use compressed WHL files and the setup.pth files that are auto-executed to download the dropper. They changed this after the PyPi maintainers flagged the first wave of malware droppers from the RedHat campaign.
As long as the package managers in those ecosystems aren't fully rewritten from scratch to accomodate for chroots, sandboxes, network and domain logs that are _only allowlistable per entry_ this won't change, and will stay being a feasible malware deployment strategy for supply chain attacks.
Repo for Mitigation Tool (I'm human so I play catch 21 with an LLM powered botnet) [1] ... Tech details in the blog post [2]
Also this is a problem across all package managers. Composer is also affected. Rubygems is also affected. NPM is also affected. PyPi is also affected. Go is also affected.
Nobody is talking about this, and I think this should be more openly discussed how much negligence and external trust we put in package managers in general. This really needs to change.
With this _actual_ attack, it would have been trivial to detect. The signature was:
1. Orphaned package adopted
2. Has post-install hook added
3. Which uses npm or bun
Yes, you're right - detecting this could have led to a more sophisticated attack. Security is always a cat and mouse game. The purpose isn't to stop every attack - it's to raise the costs for attackers and the visibility for defenders.
Any attacker who wants to attack 1000s of packages is going to necessarily leave some signatures, unless they're extremely careful. If they change one thing but not another, you can tie them both together.
Think of this like email anti-spam. It hasn't gotten rid of spam, but it has made it much more expensive to operate.
Combine this with a minimum package age to give the scanners time to run and humans time to inspect, and the ecosystem as a whole gets much more secure.
I had 15 of the infected packages installed! Luckily I have not updated any of them during the campaign. The full script checks this (in a fairly brittle way) but this comm one-liner does not.
It seems like the AUR should change the orphan recovery process, and helpers should probably offer a minimum package age feature like pnpm.
To be fair, I struggled since forever to understand this root group thing and didnt bother to add to docker group. This workaround give me a better understanding, like seeing someone cut themselves on a scissor
Yeah this is really dumb. If someone really wanted to cause harm, they would just name their device "April's iPhone" or something. If they really wanted to send a threat, they'd pass a note to a flight attendant or name it something like you said.
I get the "abundance of caution" mentality and it's a big part of why airplanes are so safe. But at some point, pilots _have_ to assume that the rest of the apparatus has done its job. They have to assume that when maintenance clears them, the plane actually works (at least with some degree of trust). And they have to assume that when security lets people on the plane, those people don't have bombs.
That doesn't mean they need to ignore the evidence of their eyes and ears, just that they should apply some base level of reason and logic to the situation.
Yeah, it's all CYA and following procedures, who wants to take responsibility for any decision, "not me, I don't want to get sued and be in debt for 7 generations if I get it wrong"... so the bullshit rises all the way of the chain of idiots until someone thinks "Let's just play it safe and turn around, because if there's an actual bomb onboard, turning around will make it not explode!"
This makes me idly wonder what would happen if a Bluetooth device appeared mid-flight with a title like "Bomb will explode if we do not land at LAX before 3 pm" (on a flight to LAX scheduled to land at 2:30 pm or whatever). The idea is... what if turning around is explicitly given as the actual trigger? Would they still turn around out of an abundance of caution? Kinda like Speed I guess ... gotta go fast to be safe.
That'd be a great way of getting your flight to LAX very very quickly, probably even with military escort. But of course afterwards you'll be stuck at the tarmac while a million police and military surround the plane figuring out what to do.
Don't try this at home, kids, (I mean, in the sky).
>Heard on ramp frequency. United appeared to tell the captain of a different United flight that there was a Bluetooth device with a “certain four letter word” (quoting) on the plane causing the emergency.
If you're ideologically willing to use a Mac, you're really not the market that the Framework is targeting. Apple has always had some of the best hardware. Where they really struggle is in respecting user choice and allowing power users to alter their systems. The Neo is an appliance. The Framework is a tool. They're fundamentally intended for different people.
If your choice of platform is driven by hardware instead of software, and you really like tablet mode, check out a Surface Pro. They're decent tablets that run full Windows/Linux instead of some neutered tablet OS, with a keyboard you can attach to use like a laptop.
> The Neo is an appliance. The Framework is a tool.
I get where you're coming from in principle, but I'm not sure to what audience this actually applies. If you just want a laptop that can run the software you use, both are adequate as tools. The Framework's greater flexibility only applies to making changes to the tool itself, which doesn't matter if you didn't need to change it to suit your purposes. (And I say that as someone who has built their own Linux & Windows PCs from parts since high school, because I know I'm not the target audience for a Neo)
It's like I consider my Dewalt power drill a very decent tool because it has exactly the modularity I need -- it even has interchangeable batteries -- and it wouldn't even occur to me to call it an outright appliance even if another power drill offered more customization for some niche use case. The Neo is an adequate tool for many people even if other tools do offer more customization or maintainability.
This would be a much stronger argument against using an iPad for productivity, because many people simply cannot run the software they need, or only at a significant expense to productivity and quality of life. I use iOS devices only as communication and media terminals, and even then I would struggle to call them appliances, they're still tools for their particular tasks.
True, I was being a bit loose with my terminology. Some tools reward customization more than others. Machine tools and 3d printers are often used to produce parts, mods, and upgrades for themselves, for example. Screwdrivers aren't usually used to work on themselves though.
The principle I was trying to express is that a Framework (and Linux, for that matter) is a tool more like a mill or an older 3d printer from the RepRap era. You will get the most out of it if you spend time customizing it, altering it, upgrading it, understanding it, etc. A MacBook Neo is a tool more like a screwdriver or a power drill. It is immediately fit for its purpose, even if that purpose isn't quite as wide ranging.
It feels a bit odd to compare them directly across categories. The MacBook Neo feels like it should be compared to a Chromebook or a cheap Windows laptop, not a high-end Linux-first upgradable machine. That's like comparing a Dewalt power drill to a 1930s drill press. They can both drill a hole... but they're just not the same tool, and I (personally) wouldn't expect to use them in the same way.
Framework's hero image when you build the laptop is someone removing the keyboard to tinker with the machine.[1] If you don't intend to do that, then yeah, it's probably not the choice for you. If you are indifferent between macOS and Linux, then it's probably not the choice for you.
One thing I miss from when I mained workstation-class Linux laptops is indeed just how tinkerable they were, in a way that didn't feel like a compromise because no other workstation-class laptop was smaller, and smaller laptops had limited performance. You could upgrade RAM and replace a HDD with an SSD, you could drop in a PCMCIA card, you could bring interchangeable batteries, etc.
I appreciate that Framework has not only brought that back but expanded on it further, but they've done it at a very different time in the market. Now that maintainability and customizability does come at a compromise to at least one of cost, bulk, or performance. That's not only the case when compared to the Neo, as far as I know it's also the case at the high end compared to a MacBook Pro.
They've set out to do something that would be difficult in any case, but they're also doing it against Apple's advantages of vertical integration and economy of scale. I'm sure I'm not the only person that can deeply respect that while still not feeling any interest in buying any of their available products.
It's a bizarre distinction, because "tool" does not imply "highly customizable" or even "repairable." In fact, even the distinction between "appliance" and "tool" is odd, since those are nearly synonymous in everyday usage, and both strongly imply a device designed for a narrow use case.
They might disagree with that framing, but it does seem to be the majority of folks I see who are interested in them.
And I'm not saying that as a negative - my Framework 13 is my favorite laptop by a fairly wide margin, but it's clearly not at the hardware level of my work issued mac.
Apple produces fantastic hardware. It's a shame I can't stand them as a company, and that they cripple that hardware with their OS.
Prior to framework, I'd be buying something along the lines of a Dell XPS (developer edition for linux compatibility) because a mac is just a non-starter for me. But a mac hands-down the best hardware you can get for a personal laptop right now. Turns out that's not the main driver of what laptop I want.
> But a mac hands-down the best hardware you can get for a personal laptop right now
That's pretty much almost always been the case with Mac laptops though. Last Intel gen(s) aside for heat at the top end.
I find that Apple's overall build quality, display and touchpads have pretty much always been second to none... I like the keyboards on most Thinkpads, especially historically, more than Apple's though. That said, being able to run Linux proper has become a higher priority... I plan to continue using my M1 air until it dies or I can't stand it anymore... but I bought it with 16gb ram and a bigger drive, so it does what I need and then some.
I don't "work" on it, so that isn't a big deal and I can remote edit in VS Code to my desktop via wireguard+ssh wherever I am with internet access. That could be a differentiator, but my vision is so bad, I probably won't be able to get away with the maxed out display on any laptop eventually.
> That's pretty much almost always been the case with Mac laptops though
I think that's a Rosy take. I remember the macs from before the intel generation, and they were hardware garbage (there's a reason they finally gave up and went to intel)
Then the intel macs were nice looking exteriors with very lackluster internals.
So for a long time it genuinely was an overpriced laptop from a performance point of view.
I'd say it really wasn't until the M1 that Apple has been at the top on both sides of the hardware equation.
But they are there now. I'm waiting to see if we get some real competition opening up in that space (hopefully).
I guess it's hard for me to judge, I never really used Macs during the PowerPC era... I used the prior generation when I was at school sometimes, but not much. Mostly a PC user most of the time until well after the Intel transition.
But even if the performance wasn't great, they did have very good displays, and touchpads with good keyboards and better than most speakers. A lot of laptops didn't come close to that portion of the experience at least at the base pricing, which IMO matters. That physical level of interface is what has had me use Apple more than most other factors.
I'd say there's definitely a lot of competition from Apple... I'd even say the Neo is a surprisingly good option for a lot of people... too many compromises, imo, for anyone doing technical work though. But even a base model M1 Air is also pretty good value.
yeah, not disagreeing about the competition from apple. The Neo is the first machine from them that I really can't rag on at all for the "I browse the web and occasionally edit documents" user.
It's a solid machine at a surprisingly reasonable price from Apple, and too many vendors for Windows just release absolute garbage at that pricing tier.
Will I ever use it? Nope. Not a machine for me. But it's hard not to suggest for a non-technical user on a tight budget.
I don't think people buy Macs for ideology. They buy cause they like it. Framework, on the other hand, is more ideological proposition than practical. Which is fine, because whatever your choice is it should make you feel comfortable.
Pixel 8 uses a version of stereo imaging but at the pixel level instead of at the full sensor level. It's not fake at the base level, the physics of it allow for depth information to be retrieved this way (compared to most monocular deep depth for example, which does not)
IDK about other manufacturers, but the iPhone Pros have a pretty good measurement app that uses LIDAR, there's some augmented reality apps that use it, and it's also used for autofocus in dark environments. There's plenty of ways to use depth information.
Oh yes definitely. Was always the plan. I was honestly just hoping someone would publish a crate to do that for me.
To be clear, I don't mean publishing a crate to read an environment variable. Of course. I mean a crate that converts a POSIX locale into a Unicode locale.
I guess there's probably a 20% solution that gets 80% of the way there. e.g.,
$ BTTF_LOCALE="$(echo $LANG | sed 's/_/-/' | sed 's/\..*//')" bttf
Thu, May 28, 2026, 11:46:21 AM EDT
If Biff just did that as a stop-gap until the full solution lands, I bet it would work in lots of cases.
https://github.com/pgpartman/pg_partman/blob/development/doc...
reply