3 ms·

Given the ease with which the parser and AST are made available to developers, we should be able to implement tools which can detect naughty packages. Also, giv

Given the ease with which the parser and AST are made available to developers, we should be able to implement tools which can detect naughty packages. Also, given the speed at which projects can be compiled, the impetus to keep the source code should remain strong.

aaaaaaaaaab 8y ago
Reductio ad "sufficiently smart compiler". http://wiki.c2.com/?SufficientlySmartCompiler http://wiki.c2.com/?SufficientlySmartCompiler
viraptor 8y ago
https://en.m.wikipedia.org/wiki/List_of_tools_for_static_code_analysis https://en.m.wikipedia.org/wiki/List_of_tools_for_static_cod... They're either going to miss things or have false positives. They sure improve the situation, but you can't find all of the issues automatically.
- stcredzero 8y ago
  Granted. But it will at least raise the bar for building an exploit package from "knows how to code" to "knows how to code, knows something about exploits, and knows how to avoid detection by an automated scanner."
Kalium 8y ago
> we should be able to implement tools which can detect naughty packages We can! It's one thing to know that there's no major technical obstacle to having a security-oriented static analysis suite for your language of choice. It's quite another for one to actually have already been written. The primary wrinkle tends to be around justifying the cost of building one. For companies that use small languages, that means a non-trivial cost in engineer time just to get a research-grade scanner. For companies whose products are security scanners, it means waiting until there's a commercial market for supporting a language. This is a problem I've been struggling with. I sympathize a great deal with developers who want to use the newest, most interesting, and above all most productive tools available to them. This stacks up awkwardly against the relatively immature tooling ecosystem common in more cutting-edge languages with smaller communities and less corporate support.

aaaaaaaaaab 8y ago

Reductio ad "sufficiently smart compiler". http://wiki.c2.com/?SufficientlySmartCompiler http://wiki.c2.com/?SufficientlySmartCompiler

viraptor 8y ago

https://en.m.wikipedia.org/wiki/List_of_tools_for_static_code_analysis https://en.m.wikipedia.org/wiki/List_of_tools_for_static_cod... They're either going to miss things or have false positives. They sure improve the situation, but you can't find all of the issues automatically.

stcredzero 8y ago
Granted. But it will at least raise the bar for building an exploit package from "knows how to code" to "knows how to code, knows something about exploits, and knows how to avoid detection by an automated scanner."

Kalium 8y ago

> we should be able to implement tools which can detect naughty packages We can! It's one thing to know that there's no major technical obstacle to having a security-oriented static analysis suite for your language of choice. It's quite another for one to actually have already been written. The primary wrinkle tends to be around justifying the cost of building one. For companies that use small languages, that means a non-trivial cost in engineer time just to get a research-grade scanner. For companies whose products are security scanners, it means waiting until there's a commercial market for supporting a language. This is a problem I've been struggling with. I sympathize a great deal with developers who want to use the newest, most interesting, and above all most productive tools available to them. This stacks up awkwardly against the relatively immature tooling ecosystem common in more cutting-edge languages with smaller communities and less corporate support.