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…
Can We Trust the Libraries We Use?
31–40 of 55 posts
Re: Can We Trust the Libraries We Use?
#32This 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?
#33Re: Can We Trust the Libraries We Use?
#34You 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 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?
#35Self 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> 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?
#37Another PVS Studio advert
(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?
#38The 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?
#39Depends 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.
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?
#40Of 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?