4 ms·

My crank opinion is that we should invest in capability-based security, or an effects system, for code in general, both internal and external. Your external pac

• candiddevmike 2y ago
  I wonder how you could retrofit something like that onto Go for instance. I've always thought a buried package init function could be devastating. Allow/deny listing syscalls, sockets, files, etc for packages could be interesting.
  • fpoling 2y ago
    Most languages have that early init problem. C++ allows global constructors, Java has class statics, Rust can also initialize thing globally. Even C allows library initializers running arbitrary code. It was used to implement that attack against ssh via malicious xz library. Disabling globals that are not compile-time constants or at least are never initialized unless the application explicitly called things will nicely address that issue. But language designers think that running arbitrary code before main is a must.
    • Philpax 2y ago
      Rust doesn't have static initialisers for complex objects; it has lazy initialisers in the standard library that run when they're first requested, but there's no way to statically initialise any object more complex than a primitive: https://doc.rust-lang.org/reference/items/static-items.html#r-items.static.init https://doc.rust-lang.org/reference/items/static-items.html#...
      • fpoling 2y ago
        Thanks, I stand corected. Rust does not allow to initialize globals with arbitrary code running before main even with unsafe. One more point to consider Rust over C++.