Can We Trust the Libraries We Use? • Hacker News Board

Re: Can We Trust the Libraries We Use?

#51

Post by jnbiche » Mon, Aug 11, 2014, 4:23 PM UTC

collyw wrote: 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.

As someone who prefers Python to JavaScript (as far as dynamic languages go), but who has been recently using nodejs a lot, I disagree. I've found that there is a very strong testing culture among node hackers.

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.

Re: Can We Trust the Libraries We Use?

#52

Post by Mikeb85 » Mon, Aug 11, 2014, 4:40 PM UTC

glibgil wrote: post #29

Mikeb85 wrote: post #12

You have to, because there's no alternative. And even if it were possible to assure 100% safety from 100% of the code that runs on your computer, how do you know you can trust your hardware?

Let's down-vote these types of comments that answer, vaguely, the question proposed in the headline and reveal that they did not even skim the topics in the OP. Totally worthless.

Maybe the title shouldn't propose a question that is controversial (and obviously click-bait), and then have the bulk of the article be about something completely different.

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

Re: Can We Trust the Libraries We Use?

#53

Post by richardwhiuk » Mon, Aug 11, 2014, 8:21 PM UTC

onion2k wrote: post #34

glibgil wrote: post #25

Earlier quoted context omitted.

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.

It's a pretty rubbish way of checking whether you've introduced bugs when things change as well.

Testing is good for doing one thing: Validating that the code meets a specific quality target.

Re: Can We Trust the Libraries We Use?

#54

Post by ASneakyFox » Wed, Aug 13, 2014, 4:24 PM UTC

clarry wrote: post #43

jenscow wrote: post #41

Earlier quoted context omitted.

You, the user of the library, don't care about finding any bugs in parts of the library that your application isn't using. Your tests will be testing the parts of code in the library that your application uses, which is the part that matters to you.

You can still have bugs in parts of code that you use (or would use) given the right inputs. The problem is making your tests so diverse that they test every possible input.

You could. But you'd miss those bugs if you write that code yourself any way.

Re: Can We Trust the Libraries We Use?

#55

Post by nullc » Sat, Aug 16, 2014, 1:09 AM UTC

Mathiasdm wrote: post #48

tokenrove wrote: post #36

Earlier quoted context omitted.

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 ign…

__attribute__((unused)) indeed would be the best option when using gcc. I believe when using C++11, this can be replaced by [[gnu::unused]]. Another one that I've seen quite often is casting to void.

Not unused. Uninitialized.

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.