Can We Trust the Libraries We Use?
viva64.com
viva64.com
I don't think most tech companies and governments are taking the risks and threats seriously enough as of yet so I suspect some sort of calamity will have to happen first before things are truly tightened up well enough for anyone to be able to trust anything and not be deluding themselves in doing so.
We've tried to do this with various XML/manifest declarative constructs, but the problem is that these constructs just rely on subsystems which are themselves insecure.
These systems will have to be baked into the metal, and they're going to need to come from different vendors.
Unlikely to happen, but that looks like the way forward.
Worse, many devs aren't even aware this is a problem, and few people are working on fixing it. We're deep in a morass that will take a long, long time to get out of.
Sadly many managers see this as extra cost, rather something that will reduce costs in project lifetime.
This is hardly a surprising result, and does not tell us anything new about how one might evaluate or build highly trusted software.
If this is the case, then you can provide 100% trusted software even if it has been built with insecure code bases / libraries, as long as all the external interfaces has been tested for all possible inputs.
Off course this is extremely difficult / impossible. This is why we will never arrive at a point where software is 100 trustworthy.
edit - spelling
Testing isn't a way of fixing bugs. It's a way of making sure you don't introduce bugs when things change. The important thing to remember that 'code the first implementation' - where you go from having no code to having some code - is a change just like any other.
Writing code without bugs is a lot more efficient than writing code with bugs and then fixing them.
Testing is good for doing one thing: Validating that the code meets a specific quality target.
In my opinion, the biggest security liabilities in Node are with npm:
1. The culture that emphasizes tons of tiny packages, each bringing in dozens of other dependencies managed by multiple maintainers. The increases the attack surface dramatically. All it will take will be one single maintainer of a small package used by dozens of other packages to expose his npm password, and exploit could easily spread to hundreds of node apps in a very short period of time. I'm surprised this hasn't happened already.
2. On a related note, npm's lack of package signing. Most of the other popular dynamic languages (Python, Ruby, Perl) offer or even require package signing. npm does require SSL, but package signing is even more important, since only package signing can prevent the scenario I describe above.
That said, I do see lots of unit testing in node packages, so I can't criticize them there.
The more I think about it, the more I think it's the latter. There are tons of crap libraries out there for any language - but the more mature languages/ecosystems naturally tend to have a wider selection of more mature libraries.
I've found oddities like improper implementations of http digest auth and what not. When libraries are small you can sometimes catch these things easily.
Self assignment is used to silence overly aggressive and incorrect uninitialized warnings in GCC (esp prior to 4.5).
I'm not sure if thats what the code there is doing— not enough context, but I'd guess it's likely. Odd that the author hasn't seen that before.
Another one that I've seen quite often is casting to void.
E.g. in older GCC you would get int x; switch (!!foo) { case 0:x=0;break; case 1:x=1;break; /no default/ } print(..x)
Or many other cases and the compiler will give an erroneous uninitialized warning. you can assign x to itself at the stop to eliminate the warning without changing the generated code.
The same mechanism can also help increase trust in a third-party library from a security point of view. Every access to a file or network resource, for example, is checked before being granted.
That's not true at all. You may catch some lib bugs, but not all, even through testing of your own code that leverages the lib. Unless you're implying that you'll pass every possible value to your tests which will then cover 100% of any and all code in the lib.
Your tests will be testing the parts of code in the library that your application uses, which is the part that matters to you.
Moreover, the guys behind PVS-Studio seem like great guys. The CTO, Andrey Karpov, was interviewed in early 2014: http://www.viva64.com/en/b/0231/.
Selling software development tools isn't easy. PVS-Studio "adverts" are interesting and useful to the community.
(The title in this case should have been less link-baity, though. I almost didn't even click on it, til I saw the URL.)
Now, is anybody doing that? Anybody? (Sound of crickets chirping)
It also did not help the way C compiler phases were split.
If anything, we have to thank LLVM guys for making static analysis part of clang.
I won't change my initial comment, but please be aware that by "testing" I also meant static code analysis. (Thought had it covered with software, hardware, and infrastructure, but forgot one)
[NB I can remember in 1990s being on a project where someone was telling us about the safety shutdown equipment on a UK AGR nuclear power station - it was mechanical logic as when the plants were designed in the 1960s they wanted to use really well tried and tested technology.]
You're right, I should have read more of the article to realize that it's basically about nothing (someone looking for, and fixing bugs in a library he uses, which everyone who cares does).