3 ms·

So? Any method of detecting a "malicious package" faces Rice's theorem, unless you want to claim that "malicious" is a trivial property.

• 7373737373 4y ago
  Which is why any approaches relying on identity verification or scanning are bound to fail - sandboxing/capability security MUST become built into languages
  • ashishbijlani 4y ago
    Are you suggesting that you would rather wait for languages to provide robust sandboxing capabilities and not use available static/dynamic analysis tools (e.g., Packj [1]) to audit packages for malicious/risky indicators, particularly when we hear about new attacks on open-source package managers almost every week? 1. https://github.com/ossillate-inc/packj https://github.com/ossillate-inc/packj [Disclaimer: I built it]
    • 7373737373 4y ago
      No, I'm merely suggesting that they are not a solution to the problem, and that the fundamental issue has to be approached at the language level. What you are building is mainly a smoke detector (and maybe a bit of a sprinkler if it takes some decisions itself), not fireproof doors (that only at install, not test- or runtime). Smoke detectors by themselves cannot prevent fires from spreading and are not completely reliable. Analysis tools are still useful - even with perfect language-level access and resource control, packages which are given many required permissions may behave maliciously (e.g. through compromise of any component in the development or distribution pipeline), or return malicious data (which is out of scope/unsolvable at the language level). Both approaches complement each other nicely.