3 ms·
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 functiona
by criemen 1y ago
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?
- immibis 1y agoIt 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.
- tome 1y agoI 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 https://hackage.haskell.org/package/bluefin
- yencabulator 11mo agoNo 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.