2 comments

  • gkapur 13 days ago
    Cool idea -- in some ways this "deno"-fies node, which I think is a sensible approach.

    So far, Hagana only blocks outbound traffic from packages that are using the http or https modules. Support for other modules (e.g. net, dgram, dns) is coming soon.

    This could be a problematic approach, though. If you are going OSS and do want to become ubiquitous, you will likely need much stronger protections. Obfuscation is not a path to security but blocking only some very basic vectors and then being explicit about it will have attackers adopt other similar vectors.

    All in all, a cool first attempt at building with some work to do!

    • jackbeck 13 days ago
      Thanks! This sort of "deno"-fies Node, but in my opinion it's a bit smarter. With Deno, it's an all or nothing approach where 3rd party libraries still have the same access as the main application.

      Hagana is still not at the stage where it's fully ready to block all attacks, there's still work to be done, but I do want to be transparent about the approach taken so that the open source community can create issues that show sandbox breakouts (as someone already has).

      Eventually it'll get to the point where the security will be tight enough that having it open source won't make a difference.

      Additionally, even having this rudimentary protection is still more effective at blocking generic supply chain attacks than not having any protection at all.

    • ovao 14 days ago
      Firstly, congrats on the release! With recent events, something like this seems like it could be valuable.

      I will kind of jump in to the obvious thing first here though: the offer is tooling around dependency security in the npm ecosystem with a package users will install from npm.

      Granted, vetting one package that works to vet others helps reduce the surface area to something manageable, and that’s a good thing, but I’m curious about how you’re thinking about the chicken-egg scenario that this introduces. What assures users that malicious code doesn’t seep its way into this package as it’s seeped into others?

      • jackbeck 14 days ago
        Thank you!

        I've given this exact question some thought. I think that the only real way to make sure this doesn't happen is by not allowing any 3rd party packages into the codebase. That means any package I want to install will have to be manually copied over. Granted, that this isn't the state now in the repo since I wanted to get to a POC phase as quickly as possible, but it's something I'm going to do.