Hacker News Reader

Comment by criemen | Hacker News Reader

Fair enough, it makes more sense in a, say, Haskell-style pure functional language. Instead of getting a general IO monad, you pass in more restricted functionality.

Still, it'd be highly painful. Would it be worth the trade-off to prevent supply chain attacks?

View on HN

It prevents a lot more than just supply-chain attacks. Give the unzipper a subdirectory handle with parent disabled, and it won't be vulnerable to directory traversal attacks, no matter how badly it's written.

No need for pure FP or monads I believe. Consider statically analyzing the library for:

1. `unsafe`

2. import/use of any ambient effects (std::fs::open etc; good enough to have a much smaller allowlist). allow using methods on passed-in &std::fs::File but do not allow std::fs::File::open. beware anything making openat a method on File. Making this realistic may need new API conventions. WASI is doing some of this work already.

3. apply recursively to dependencies

Now the library can only operate on the things passed in to it.

Much preexisting source won't qualify, but e.g. PNG decoding should.

I developed my Haskell library Bluefin to program in this way, not as a security measure but just as a way to help structure programs in a coherent way (which is one of the benefits of many well typed Haskell libraries). In principle the same idea could be use for high assurance software, but that's not what I'm going for specifically. Anyway, I find writing in this style much more convenient than in any other Haskell style.

https://hackage.haskell.org/package/bluefin

Reply on news.ycombinator.com