Comment by alphazard

Comment by alphazard a day ago

For some reason everyone wants to talk about all the solutions to supply chain attacks except designing languages to avoid them in the first place.

Austral[0] gets this right. I'm not a user, just memeing a good idea when I see it.

Most languages could be changed to be similarly secure. No global mutable state, no system calls without capabilities, no manual crafting of pointers. All the capabilities come as tokens or objects passed in to the main, and they can be given out down the call tree as needed. It is such an easy thing to do at the language level, and it doesn't require any new syntax, just a new parameter in main, and the removal of a few bad ideas.

[0] https://austral-lang.org/

rmunn a day ago

One guy I vaguely know (only know him online, never met him IRL) often says "If you're using NPM you deserve what's going to happen to you one of these days." (He means the package ecosystem, so he would say the same thing about PNPM). I don't agree with him — he goes way too far with his opinion — but I can't deny that he's at least partly right. Two major supply-chain attacks in the past month (Shai-Hulud, and that tea-farming attack earlier this month which AFAIK doesn't yet have a clever name) have served to demonstrate that he definitely has a point in there, even if he takes it too far. NPM has a long way to go in terms of hardening (they've started doing so, thankfully), and is a very popular target.

Reply View 0 replies

nextaccountic a day ago

How does Austral avoids supply chain attacks?

Reply View 1 reply

alphazard a day ago

The typical attack tries to get the victim to load a module which accesses information on the filesystem or in another module's memory, then exfiltrate that information using network access. Other attacks may install backdoors used for infiltration once the service is deployed.
If the module provides some small helper function like `appendSmileEmoji(x: String) -> String` then it shouldn't be accessing the network or the filesystem, and the only memory it should have access to is the string passed into the function. The programmer already provided enough information to explain to the compiler that the function should not do these things but poor language design allows them to happen anyways.
Components which do have access to the network should be vetted thoroughly because they can facilitate infiltration and exfiltration. Most supply chain attacks aren't introduced directly in a high profile project like a web framework, they are introduced deeper in the dependency chain in the long tail of transitively imported modules.
In Austral (or any language using these good ideas) a small poorly vetted function like `appendSmileEmoji` wouldn't be called with access to the filesystem or network. Without access to any resources, the worst it can do is append a frowning face or a null character or something annoying. You can tell by its function signature above, it doesn't take a capability for the network or filesystem, just a String. So trying to ship a change that secretly accesses the filesystem would produce a "variable not found" error. To even get the new version to compile, you would have to add an argument to take a filesystem capability. `appendSmileEmoji(x: String, fs: FS) -> String`. That breaks any dependent modules because they have the wrong number of arguments, and looks very suspicious.

Reply View | 0 replies