6 ms·

Where are the supply chain safe programming languages?

52 points by ingve 3y ago

082349872349872 3y ago
(a) I'm all for more widespread attempts at capability security* (b) failing that, an alternate approach to the problem of deep and wide supply chains is vertical integration: just spitballing here, but we're programmers (and these days, it's even claimed we have AI support); is it too much to ask that most of us ought to be able to code up wheels that roll? * free market mechanisms, at least as currently implemented, seem to me much better at figuring out how to compensate people after something bad has happened than at preventing it from happening in the first place.
- apantel 3y ago
  The vertical integration thing isn’t feasible for anyone besides a giant company that can afford to write its own OS with no outside input. Let’s say I code all my own dependencies in my particular domain (Java). I still have to run my code in an environment: there’s the JVM, then Linux beneath that, the hypervisor at my cloud provider beneath that, etc. You want me to code all of that myself too? You know, frankly I would love to understand and control the stack all the way down. But that’s a life goal. It’s not something most people can or would be interested in doing. We’re all stuck blindly trusting a vast, incomprehensible software supply chain.
arccy 3y ago
I feel like this is just going to end up like phone (android at least) app permissions where they give some vague justification to ask for every capability under the sun.
- JohnFen 3y ago
  That would be a shame. I think the app permissions model, at least as Android does it, isn't a very good solution at all.
- nuc1e0n 3y ago
  The software development community as a whole should look at that permissions inflation trend more closely also. We've all heard stories of android torch applications that require filesystem access for murky reasons. Or websites with cookie banners that ask to install thousands of cookies and refuse to work without access being granted.
JonChesterfield 3y ago
It seems relatively well established that C requires a trusted environment. You need to have faith in your collaborators and in your toolchain, and in your dependencies, to get something that works reliably. This trusted environment is looking increasingly optimistic as time goes on. The sandbox approach works relatively well where it's applied. If you're given a lua interpreter that doesn't know how to talk to the network, you're going to have a tough time compromising the underlying kernel to gain that capability. But your performance will be grim. Web assembly is roughly what you get if you run far enough down that path trying to engineer out the inherent limitations. I wonder if the microservices people are onto something here. Some boundary around a unit marked "database" or "hashtable" that can't talk to the internet, something RPC themed to tie the pieces together, possibly all fed into a single address space to bring the performance overheads down to something reasonable. The problem is it's a huge pain to work with and makes the dev process slower, i.e. you get outcompeted by something broken-by-design that shipped faster. It's an interesting problem space. Agreed with the OP that it seems underserved.
- hackable_sand 3y ago
  My experience is that C requires strong developers and attention to detail. That requires time, and complexity increases non-linearly per LoC. If we're talking supply chain, it's great for embedded and edge devices, otherwise I look to the old wizards to provide the foundational libraries for interpreted services. Supply chain safety is more a function of economics in my uninformed opinion. How can we reduce middlemen while preventing monopolies or bottleneck moats?
pull_my_finger 3y ago
Pony has a concept of Object Capabilities[1]. Basically it lets you whitelist capabilities like network access or more granular access like specific protocol access. In the docs it states "If the library is asking for more authority than it needs, do not use the library." This doesn't solve the problem of people pulling in huge dependencies that they can't reasonably scan, or so many dependencies that they can't scan, but surely it's a step in the right direction. [1]: https://tutorial.ponylang.io/object-capabilities/object-capabilities https://tutorial.ponylang.io/object-capabilities/object-capa...
- Avshalom 3y ago
  https://austral-lang.org/ https://austral-lang.org/ is another with capabilities baked into it.
- 1letterunixname 3y ago
  Doesn't do much good if the OS doesn't enforce them like seL4 can.
  - tauroid 3y ago
    If the FFI is also capability gated why can't the language do it? Edit: Pony seems to rely on restricting FFI privileges at the package level https://tutorial.ponylang.io/object-capabilities/trust-boundary https://tutorial.ponylang.io/object-capabilities/trust-bound.... Suppose it could have been function by function ("unsafe") but this sounds fine. Not sure what else I could have meant by a capability gated FFI.
    - gpderetta 3y ago
      In practice it means no redistributable native libraries or binaries. You would need installation time compilation, jittin or pure interpretation. Or some sort of trusted compiler-as-a-service with signed binaries.
  - IshKebab 3y ago
    You can compile to WASM to work around that, with some performance penalty.
hpeter 3y ago
Do not use dependencies. Implement everything from scratch. Maybe having a huge reviewed std library solves this, if you never need to import anything from a third party. As long as there are supply chains there are attacks. reduce your dependencies to bare minimum.
- leros 3y ago
  You can use dependencies. You just need to cache them internally, review them meticulously, and never upgrade them without going through the review process again. It's a huge pain but some companies do it.
  - brianhama 3y ago
    Out of date dependencies also introduces vulnerabilities though. So you’re screwed no matter what.
    - leros 3y ago
      That is true. So you need to continually audit those dependencies as well and upgrade them when security requires it.
      - uecker 3y ago
        Essentially this is was distributions such as Debian do for your (if you trust them and their security enough which depends on your requirements). xz is noteworthy because someone spent more than two years trying to subvert this. Note that the distributions used by package managers such npm, pip, or cargo do not do this. So be wary of the "all old is bad and needs to be rewritten and C does not even have a proper package manager" crowd. (memory safety is a good thing though)
      - hackable_sand 3y ago
        Or fork and cache with dedicated maintenence, if that's what you were indicating above.
1letterunixname 3y ago
Almost no one grasps, or interested in, formal verification. It's difficult to get software devs to even do unit testing much less prove their compilers always produce correct code.
- uecker 3y ago
  I agree. From a technical point of view formal verification would absolutely be the right direction. I haven't given up hope. A long time ago, I was flamed to death for suggesting that reproducible builds are needed, today we almost have this.
- hackable_sand 3y ago
  This sounds more like a business problem at odds with quarterly planning.
- IshKebab 3y ago
  Have you actually tried formal verification of software? It's extremely difficult. 99% of programmers will not be able to do it at all, and even for the elite who do know how to do it, probably 99% of programs are too complex to be formally verified anyway. Even if that were not true, it has absolutely nothing to do with supply chain security.
brianhama 3y ago
.net actually does support a lot of what you are talking about, although the features are rarely used/enforced in reality.
- nerpderp82 3y ago
  Would you go into some specifics to guide my web searching?
  - smackeyacky 3y ago
    https://learn.microsoft.com/en-us/nuget/concepts/security-best-practices https://learn.microsoft.com/en-us/nuget/concepts/security-be... However, I've seen some definitely dodgy packages in NuGet. Since "bulk insert" isn't (wasn't?) widely supported in EntityFramework packages, there were some extremely dodgy copies of commercial bulk insert frameworks being made available, along which who knows what else. I find npm/node.js the scariest package manager combo though. Including something simple that then drags in 20 or 30 other packages is inexplicable.
    - nerpderp82 3y ago
      That is a good list, many of these can also be applied to Rust because it has many of the same affordances in its build and supply chain ecosystem. I thought maybe there was module level capabilities in .net, I don't follow it at all but would be willing to take a look. I feel gross even using pip in python, because the thing you use as the noun in `pip install <noun>` isn't the same as the package you are importing. Name attacks in Python are trivial to exploit. JS is even crazier, your gonna get a disease! There is no safe JS.
      - smackeyacky 3y ago
        .NET does have signing capabilities for assemblies...but you have to trust who signed it. In theory that's a bit of extra protection, but in practice how do you know who signed it was trustworthy in the first place. I like .NET but I often feel it's safer than node.js by accident, because the range of packages you need to get something running is much smaller because the date/time classes are sane and things like networking and security are built in rather than imported. But there is no getting around the fact that you're still vulnerable to all the same supply chain attacks as Javascript.
AnarchismIsCool 3y ago
Ok, lets be realistic about our threat models. This attack wouldn't have done much if you were running fast and loose with dependencies but had proper layered network infrastructure. There should never be a single point of failure where a single supply chain attack, 0-day, insider threat, etc should be able to kill you and it's not that hard to achieve this. Put your shit inside a VPN, secure the systems inside the VPN as if they're connected directly to the internet, vlan or even airgap systems that are hyper critical, etc. I build satellites where we actually do some of the supply chain caching and review, but it's for very specific things that are absolutely mission critical and the risk of >0days is lower than the risk of a memory leak locking up a system. Think critically about what it would take to access and pivot within your network.
jaypatelani 3y ago
You can use something like this with Ada/SPARK programing language https://wikibook-ada.sourceforge.net/samples/pragmas_restrictions/#hello-world-4 https://wikibook-ada.sourceforge.net/samples/pragmas_restric...
gavinhoward 3y ago
I have one literally withering on the vine. I released it today. A week ago, I released a blog post that mentioned [1] a supply chain-safe build system and language. Despite that post and the traction it got, the 6-hour-old Show HN is already long gone, not even on the first 10 pages. Long ago, Java had something for supply chain safety in the form of SecurityManager. It was removed. There are no supply chain-safe languages because the industry doesn't care. [1]: https://yzena.com/2024/03/what-computers-cannot-do-the-consequences-of-turing-completeness/#rig https://yzena.com/2024/03/what-computers-cannot-do-the-conse...
- dvfjsdhgfv 3y ago
  That post is really, really long. And
  - gavinhoward 3y ago
    I try to make my marketing useful. Shame on me.
    - yjftsjthsd-h 3y ago
      It's fine for the explanation to be long, but the hook needs to be short. Edit: Also, if we're discussing https://news.ycombinator.com/item?id=39904895 https://news.ycombinator.com/item?id=39904895 - it's not even a question of length, I don't see a hook there at all. If I click into https://rigbuild.dev/ https://rigbuild.dev/ and get halfway down the page then I start to see interesting features, most of which are marked as coming soon (so... not present). But I almost certainly wouldn't click the link, because your actual post just says that it's a build system and that it's proprietary, at which point I lost interest. Some people will put up with a build tool that isn't open source, but you still have to give them some reason to be interested.
      - gavinhoward 3y ago
        It is not proprietary. I think that is the real reason: if it's not FOSS, people dismiss it out of hand. Also, I was hamstrung by Show HN rules.
hu3 3y ago
I'd like to think that there are supply chain safer languages. Which are languages that have a large comprehensive official standard library backed by a large corp. Those corps have the manpower to better audit contributions. Examples: Microsoft's .NET (C#/F#) and Google's Go.
- stefanha 3y ago
  I see what you mean. A "batteries included" standard library reduces the risk for obscure third-party dependencies. Qt comes to mind. It includes the kitchen sink and a lot of applications can be written without third-party dependencies. Go programs tend to have a lot of third-party package dependencies. I don't think it's a good example.
sebtron 3y ago
Maybe I am missing something,but it sounds like the features the author is looking for could be part of an OS, not a language. For example: > An example is that a hash table lookup function should be unable to connect to the internet. That way the function can be used without fear of it becoming a liability if it contains bugs or its source code is manipulated by an attacker. Reminds me of OpenBSD's pledge [1]. [1] https://man.openbsd.org/pledge.2 https://man.openbsd.org/pledge.2
- stefanha 3y ago
  Hi, I'm the author. See the "The best approach we have today for run-time isolation is through sandboxing" part in the blog post. It covers sandboxing, which pledge(2) is an example of. My experience with sandboxing approaches is that they are only used in the most security-critical software because they are difficult to integrate. If the programming language isolates components by default, then the majority of software should be able to benefit.
jijijijij 3y ago
I feel like the article misses the point, tho. The xz attack didn't happen because of an unsafe language, but for it's legacy build tools and social engineering. The relevant backdoor part about patching a vulnerability into C code, could just as well have been skipped/changed for another form of persistence/RCE. In the end, the original sin of breach was smuggling and execution of the malicious build script and payload, if I understand correctly. I don't see how a capability sensitive language would have prevented this, assuming the build environment remained the same. Of course certain features of a language are exploited, but for a supply chain attack, I think the real vulnerability is complexity, neglect, carelessness, social pressure and (arcane) code beyond immediate comprehension. Since, before any malicious xz code was shipped, the human element was manipulated and exploited. The same pull request about the introduction of IFUNC, could have been about extending capabilities for another made-up reason. The same exploitation of trust, which allowed packing malicious scripts, would have allowed for... well, packing malicious scripts. With the xz backdoor, the vulnerability was large chunks of infrastructure being the burden of a single human. I really don't see how this attack dynamic could have been prevented by language design alone. Sure, you wouldn't attack a compression library, if capabilities were tight. You would attack the neglected privileged code base elsewhere...
MattPalmer1086 3y ago
I liked the idea, but as I was reading it I realised that if we could provide that level of isolation within software, it would solve many of the issues of software security in general. And it would really need to be provided at the O/S layer. I wondered when it was going to start talking about capabilities and I was not disappointed!
simne 3y ago
World looks weird. All need infrastructure existed in 1990s in Ada, Modula-2/3, IBM works (even with hardware security, which still exists in Power machines), but nobody care. Now, sure all these things outdated, somebody have to rewrite ocean of code, add support of modern architectures, device drivers, even to teach people, as most programmers from that niches already retired, etc.
Ferret7446 3y ago
Supply chain security is a tool chain problem, not a language problem. Unfortunately, I don't think this author is able to contribute anything useful to the topic currently.

52 points by ingve 3y ago

(a) I'm all for more widespread attempts at capability security* (b) failing that, an alternate approach to the problem of deep and wide supply chains is vertical integration: just spitballing here, but we're programmers (and these days, it's even claimed we have AI support); is it too much to ask that most of us ought to be able to code up wheels that roll? * free market mechanisms, at least as currently implemented, seem to me much better at figuring out how to compensate people after something bad has happened than at preventing it from happening in the first place.

apantel 3y ago
The vertical integration thing isn’t feasible for anyone besides a giant company that can afford to write its own OS with no outside input. Let’s say I code all my own dependencies in my particular domain (Java). I still have to run my code in an environment: there’s the JVM, then Linux beneath that, the hypervisor at my cloud provider beneath that, etc. You want me to code all of that myself too? You know, frankly I would love to understand and control the stack all the way down. But that’s a life goal. It’s not something most people can or would be interested in doing. We’re all stuck blindly trusting a vast, incomprehensible software supply chain.

arccy 3y ago

I feel like this is just going to end up like phone (android at least) app permissions where they give some vague justification to ask for every capability under the sun.

JohnFen 3y ago
That would be a shame. I think the app permissions model, at least as Android does it, isn't a very good solution at all.
nuc1e0n 3y ago
The software development community as a whole should look at that permissions inflation trend more closely also. We've all heard stories of android torch applications that require filesystem access for murky reasons. Or websites with cookie banners that ask to install thousands of cookies and refuse to work without access being granted.

JonChesterfield 3y ago

It seems relatively well established that C requires a trusted environment. You need to have faith in your collaborators and in your toolchain, and in your dependencies, to get something that works reliably. This trusted environment is looking increasingly optimistic as time goes on. The sandbox approach works relatively well where it's applied. If you're given a lua interpreter that doesn't know how to talk to the network, you're going to have a tough time compromising the underlying kernel to gain that capability. But your performance will be grim. Web assembly is roughly what you get if you run far enough down that path trying to engineer out the inherent limitations. I wonder if the microservices people are onto something here. Some boundary around a unit marked "database" or "hashtable" that can't talk to the internet, something RPC themed to tie the pieces together, possibly all fed into a single address space to bring the performance overheads down to something reasonable. The problem is it's a huge pain to work with and makes the dev process slower, i.e. you get outcompeted by something broken-by-design that shipped faster. It's an interesting problem space. Agreed with the OP that it seems underserved.

hackable_sand 3y ago
My experience is that C requires strong developers and attention to detail. That requires time, and complexity increases non-linearly per LoC. If we're talking supply chain, it's great for embedded and edge devices, otherwise I look to the old wizards to provide the foundational libraries for interpreted services. Supply chain safety is more a function of economics in my uninformed opinion. How can we reduce middlemen while preventing monopolies or bottleneck moats?

pull_my_finger 3y ago

Pony has a concept of Object Capabilities[1]. Basically it lets you whitelist capabilities like network access or more granular access like specific protocol access. In the docs it states "If the library is asking for more authority than it needs, do not use the library." This doesn't solve the problem of people pulling in huge dependencies that they can't reasonably scan, or so many dependencies that they can't scan, but surely it's a step in the right direction. [1]: https://tutorial.ponylang.io/object-capabilities/object-capabilities https://tutorial.ponylang.io/object-capabilities/object-capa...

Avshalom 3y ago
https://austral-lang.org/ https://austral-lang.org/ is another with capabilities baked into it.
1letterunixname 3y ago
Doesn't do much good if the OS doesn't enforce them like seL4 can.
- tauroid 3y ago
  If the FFI is also capability gated why can't the language do it? Edit: Pony seems to rely on restricting FFI privileges at the package level https://tutorial.ponylang.io/object-capabilities/trust-boundary https://tutorial.ponylang.io/object-capabilities/trust-bound.... Suppose it could have been function by function ("unsafe") but this sounds fine. Not sure what else I could have meant by a capability gated FFI.
  - gpderetta 3y ago
    In practice it means no redistributable native libraries or binaries. You would need installation time compilation, jittin or pure interpretation. Or some sort of trusted compiler-as-a-service with signed binaries.
- IshKebab 3y ago
  You can compile to WASM to work around that, with some performance penalty.

hpeter 3y ago

Do not use dependencies. Implement everything from scratch. Maybe having a huge reviewed std library solves this, if you never need to import anything from a third party. As long as there are supply chains there are attacks. reduce your dependencies to bare minimum.

leros 3y ago
You can use dependencies. You just need to cache them internally, review them meticulously, and never upgrade them without going through the review process again. It's a huge pain but some companies do it.
- brianhama 3y ago
  Out of date dependencies also introduces vulnerabilities though. So you’re screwed no matter what.
  - leros 3y ago
    That is true. So you need to continually audit those dependencies as well and upgrade them when security requires it.
    - uecker 3y ago
      Essentially this is was distributions such as Debian do for your (if you trust them and their security enough which depends on your requirements). xz is noteworthy because someone spent more than two years trying to subvert this. Note that the distributions used by package managers such npm, pip, or cargo do not do this. So be wary of the "all old is bad and needs to be rewritten and C does not even have a proper package manager" crowd. (memory safety is a good thing though)
    - hackable_sand 3y ago
      Or fork and cache with dedicated maintenence, if that's what you were indicating above.

1letterunixname 3y ago

Almost no one grasps, or interested in, formal verification. It's difficult to get software devs to even do unit testing much less prove their compilers always produce correct code.

uecker 3y ago
I agree. From a technical point of view formal verification would absolutely be the right direction. I haven't given up hope. A long time ago, I was flamed to death for suggesting that reproducible builds are needed, today we almost have this.
hackable_sand 3y ago
This sounds more like a business problem at odds with quarterly planning.
IshKebab 3y ago
Have you actually tried formal verification of software? It's extremely difficult. 99% of programmers will not be able to do it at all, and even for the elite who do know how to do it, probably 99% of programs are too complex to be formally verified anyway. Even if that were not true, it has absolutely nothing to do with supply chain security.

brianhama 3y ago

.net actually does support a lot of what you are talking about, although the features are rarely used/enforced in reality.

nerpderp82 3y ago
Would you go into some specifics to guide my web searching?
- smackeyacky 3y ago
  https://learn.microsoft.com/en-us/nuget/concepts/security-best-practices https://learn.microsoft.com/en-us/nuget/concepts/security-be... However, I've seen some definitely dodgy packages in NuGet. Since "bulk insert" isn't (wasn't?) widely supported in EntityFramework packages, there were some extremely dodgy copies of commercial bulk insert frameworks being made available, along which who knows what else. I find npm/node.js the scariest package manager combo though. Including something simple that then drags in 20 or 30 other packages is inexplicable.
  - nerpderp82 3y ago
    That is a good list, many of these can also be applied to Rust because it has many of the same affordances in its build and supply chain ecosystem. I thought maybe there was module level capabilities in .net, I don't follow it at all but would be willing to take a look. I feel gross even using pip in python, because the thing you use as the noun in `pip install <noun>` isn't the same as the package you are importing. Name attacks in Python are trivial to exploit. JS is even crazier, your gonna get a disease! There is no safe JS.
    - smackeyacky 3y ago
      .NET does have signing capabilities for assemblies...but you have to trust who signed it. In theory that's a bit of extra protection, but in practice how do you know who signed it was trustworthy in the first place. I like .NET but I often feel it's safer than node.js by accident, because the range of packages you need to get something running is much smaller because the date/time classes are sane and things like networking and security are built in rather than imported. But there is no getting around the fact that you're still vulnerable to all the same supply chain attacks as Javascript.

AnarchismIsCool 3y ago

Ok, lets be realistic about our threat models. This attack wouldn't have done much if you were running fast and loose with dependencies but had proper layered network infrastructure. There should never be a single point of failure where a single supply chain attack, 0-day, insider threat, etc should be able to kill you and it's not that hard to achieve this. Put your shit inside a VPN, secure the systems inside the VPN as if they're connected directly to the internet, vlan or even airgap systems that are hyper critical, etc. I build satellites where we actually do some of the supply chain caching and review, but it's for very specific things that are absolutely mission critical and the risk of >0days is lower than the risk of a memory leak locking up a system. Think critically about what it would take to access and pivot within your network.

jaypatelani 3y ago

You can use something like this with Ada/SPARK programing language https://wikibook-ada.sourceforge.net/samples/pragmas_restrictions/#hello-world-4 https://wikibook-ada.sourceforge.net/samples/pragmas_restric...

gavinhoward 3y ago

I have one literally withering on the vine. I released it today. A week ago, I released a blog post that mentioned [1] a supply chain-safe build system and language. Despite that post and the traction it got, the 6-hour-old Show HN is already long gone, not even on the first 10 pages. Long ago, Java had something for supply chain safety in the form of SecurityManager. It was removed. There are no supply chain-safe languages because the industry doesn't care. [1]: https://yzena.com/2024/03/what-computers-cannot-do-the-consequences-of-turing-completeness/#rig https://yzena.com/2024/03/what-computers-cannot-do-the-conse...

dvfjsdhgfv 3y ago
That post is really, really long. And
- gavinhoward 3y ago
  I try to make my marketing useful. Shame on me.
  - yjftsjthsd-h 3y ago
    It's fine for the explanation to be long, but the hook needs to be short. Edit: Also, if we're discussing https://news.ycombinator.com/item?id=39904895 https://news.ycombinator.com/item?id=39904895 - it's not even a question of length, I don't see a hook there at all. If I click into https://rigbuild.dev/ https://rigbuild.dev/ and get halfway down the page then I start to see interesting features, most of which are marked as coming soon (so... not present). But I almost certainly wouldn't click the link, because your actual post just says that it's a build system and that it's proprietary, at which point I lost interest. Some people will put up with a build tool that isn't open source, but you still have to give them some reason to be interested.
    - gavinhoward 3y ago
      It is not proprietary. I think that is the real reason: if it's not FOSS, people dismiss it out of hand. Also, I was hamstrung by Show HN rules.

hu3 3y ago

I'd like to think that there are supply chain safer languages. Which are languages that have a large comprehensive official standard library backed by a large corp. Those corps have the manpower to better audit contributions. Examples: Microsoft's .NET (C#/F#) and Google's Go.

stefanha 3y ago
I see what you mean. A "batteries included" standard library reduces the risk for obscure third-party dependencies. Qt comes to mind. It includes the kitchen sink and a lot of applications can be written without third-party dependencies. Go programs tend to have a lot of third-party package dependencies. I don't think it's a good example.

sebtron 3y ago

Maybe I am missing something,but it sounds like the features the author is looking for could be part of an OS, not a language. For example: > An example is that a hash table lookup function should be unable to connect to the internet. That way the function can be used without fear of it becoming a liability if it contains bugs or its source code is manipulated by an attacker. Reminds me of OpenBSD's pledge [1]. [1] https://man.openbsd.org/pledge.2 https://man.openbsd.org/pledge.2

stefanha 3y ago
Hi, I'm the author. See the "The best approach we have today for run-time isolation is through sandboxing" part in the blog post. It covers sandboxing, which pledge(2) is an example of. My experience with sandboxing approaches is that they are only used in the most security-critical software because they are difficult to integrate. If the programming language isolates components by default, then the majority of software should be able to benefit.

jijijijij 3y ago

I feel like the article misses the point, tho. The xz attack didn't happen because of an unsafe language, but for it's legacy build tools and social engineering. The relevant backdoor part about patching a vulnerability into C code, could just as well have been skipped/changed for another form of persistence/RCE. In the end, the original sin of breach was smuggling and execution of the malicious build script and payload, if I understand correctly. I don't see how a capability sensitive language would have prevented this, assuming the build environment remained the same. Of course certain features of a language are exploited, but for a supply chain attack, I think the real vulnerability is complexity, neglect, carelessness, social pressure and (arcane) code beyond immediate comprehension. Since, before any malicious xz code was shipped, the human element was manipulated and exploited. The same pull request about the introduction of IFUNC, could have been about extending capabilities for another made-up reason. The same exploitation of trust, which allowed packing malicious scripts, would have allowed for... well, packing malicious scripts. With the xz backdoor, the vulnerability was large chunks of infrastructure being the burden of a single human. I really don't see how this attack dynamic could have been prevented by language design alone. Sure, you wouldn't attack a compression library, if capabilities were tight. You would attack the neglected privileged code base elsewhere...

MattPalmer1086 3y ago

I liked the idea, but as I was reading it I realised that if we could provide that level of isolation within software, it would solve many of the issues of software security in general. And it would really need to be provided at the O/S layer. I wondered when it was going to start talking about capabilities and I was not disappointed!

simne 3y ago

World looks weird. All need infrastructure existed in 1990s in Ada, Modula-2/3, IBM works (even with hardware security, which still exists in Power machines), but nobody care. Now, sure all these things outdated, somebody have to rewrite ocean of code, add support of modern architectures, device drivers, even to teach people, as most programmers from that niches already retired, etc.

Ferret7446 3y ago

Supply chain security is a tool chain problem, not a language problem. Unfortunately, I don't think this author is able to contribute anything useful to the topic currently.