3 ms·

This is a valid concern. That is why we're building this in the open. You can take a look at the code. We welcome your feedback/suggestions and code contributio

• salawat 4y ago
  >That is why we're building this in the open. You can take a look at the code. ...You mean, in the same manner everyone should have been auditing code all along, but hasn't, thereby creating the problem you're trying to solve? It's alright. You're trying, and there's nothing wrong with that answer, but the people you're trying to sell a shovel to don't want to dig. That's the chief problem.
  • swatcoder 4y ago
    You’re not wrong, but at some point, the dependency problem will slip onto someone’s desk in then legal department and rules will be pushed back across the hall into the engineering department. It’s not a bad idea to stake out a product that’s mature and ready to go when that happens. It doesn’t even have to be foolproof. It just needs to be earnest enough to check off some boxes and show that “best practice” effort was made.
  • ashishbijlani 4y ago
    > people you're trying to sell a shovel to don't want to dig. That's exactly where a tool like Packj can help. It can cut the digging time down significantly. Auditing hundreds of direct/transitive dependencies manually is impractical, but Packj can quickly point out a "risky" behavior (file and line number). Using obfuscation to hide malicious code itself is a suspicious behavior, which is flagged. After all, we have to start somewhere.
  • i_love_cookies 4y ago
    [dead]