Live data from Hacker News

Can We Trust the Libraries We Use?

viva64.com

31–40 of 55 posts

Re: Can We Trust the Libraries We Use?

#31

Of course not. You can't even trust the firmware on the storage your OS runs on. We're in a very weird period of time computer security wise. There was the first golden age, when computers weren't easily connected and harmful software was generally not very impactful. Then there was a brief dark age when computers became connected and the utter lack of concern for security was revealed to be hugely exploitable on an…

And how do you feel about static analysis which is the topic of the OP?

Re: Can We Trust the Libraries We Use?

#32
The title doesn't really fit the article. The author just picked up an open source C/C++ library and found some bugs in its dependencies using their commercial static analysis tool.

This is hardly a surprising result, and does not tell us anything new about how one might evaluate or build highly trusted software.

Re: Can We Trust the Libraries We Use?

#34
post #25

You can't guarantee trusted software even your code and the libraries are 100% trusted / bug less, as the combined software creates emergent properties which will also have to be properly tested. As such you can only trust a software system if it has been properly tested. 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…

Your comment provides no value. The OP has specific examples of tools being used to find bugs in software all without the need for testing. Testing is the least efficient way to fix those bugs. Tooling, as demonstrated in the OP, and other applications of programming language theory are far more efficient ways to have correct software. First, let the computer find the bugs we don't know about, then we can focus on hi…

Testing is the least efficient way to fix those bugs.

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.

Re: Can We Trust the Libraries We Use?

#35
> A variable is assigned its own value.

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.

Re: Can We Trust the Libraries We Use?

#36
post #35

> A variable is assigned its own value. 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.

That seems unlikely to be the case; the variable being assigned is through a pointer to a struct, which is already being accessed in the context. (Plus, of course, __attribute__((unused)) or similar in a macro would be preferable for silencing warnings) It's pretty likely that, had this occured at the top of a function, and been a direct assignment, the author would not have flagged it (indeed, perhaps PVS-Studio ignores that case; seems easy enough to implement).

Re: Can We Trust the Libraries We Use?

#37
post #14

Another PVS Studio advert

I actually really enjoy these articles. Seeing real pitfalls and thinking about how to correct them is useful, as well as a reminder about how bugs lurk everywhere. "The Last Line Effect" in particular will stick with me forever.

(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.)

Re: Can We Trust the Libraries We Use?

#38
Java has a very good sand-boxing mechanism (AcessController), which helps limit the effect of bugs in libraries. Firstly, the memory model is highly abstract; no pointer arithmetic and type-less references. To mess with the memory, the thread needs to drop down to native code, and this where sandboxing can trap this behavior.

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.

Re: Can We Trust the Libraries We Use?

#39
post #7

Depends where they come from. The average Python or Perl library seems better written and more tested that something I would write myself. JavaScript seems to have a lot less quality in my experience.

I was thinking about that in response as well; then I began to wonder. Is it that the quality is actual higher, or that I'm more likely to gravitate towards established, well-tested libraries (of which there are fewer in javascript)?

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.

Re: Can We Trust the Libraries We Use?

#40
post #31

Of course not. You can't even trust the firmware on the storage your OS runs on. We're in a very weird period of time computer security wise. There was the first golden age, when computers weren't easily connected and harmful software was generally not very impactful. Then there was a brief dark age when computers became connected and the utter lack of concern for security was revealed to be hugely exploitable on an…

And how do you feel about static analysis which is the topic of the OP?

The topic of the OP was how safe are 3rd party libraries. Seems pretty on topic to me.
Post reply on HN