Live data from Hacker News

Can We Trust the Libraries We Use?

viva64.com

11–20 of 55 posts

Re: Can We Trust the Libraries We Use?

#11
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 unprecedented scale with an enormous impact. A lot of the worst mistakes were corrected and a lot of the most important software was tightened up, leading to a long "security cold war" lasting from roughly the late '90s or early 2000s to today. Right now we're sort of in a cuban missile crisis period in the cold war, or something similar, the impact of computer security holes could result in events (of several possible kinds) which might have as much global economic and geopolitical impact as a major war. Whether that happens or not is as yet unknown, but the potential is there, and will remain there for likely quite sometime (several key vulnerabilities: core libraries such as openssl, essentially every major operating system, firmware on usb devices and storage devices in general, BGP, and SSL/TLS under the CA system).

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.

Re: Can We Trust the Libraries We Use?

#13
post #5

Code coverage and static analysis are such valuable tools, I can't believe they are not used more and more frequently .. it really seems that a lot of open source projects would benefit from a coverage/analysis phase on checkin.

No code should be set live in production without having at least static analysis on the build server validating official builds.

Sadly many managers see this as extra cost, rather something that will reduce costs in project lifetime.

Re: Can We Trust the Libraries We Use?

#15

Test the hell out of anything you use, both hardware, software, and infrastructure -- and write the tests before you write any code. Double-down on that for stuff like medical tech. Now, is anybody doing that? Anybody? (Sound of crickets chirping)

That would be the case if people hadn't learn to disregard computer errors, when compared to other industries.

Re: Can We Trust the Libraries We Use?

#16
post #5

Code coverage and static analysis are such valuable tools, I can't believe they are not used more and more frequently .. it really seems that a lot of open source projects would benefit from a coverage/analysis phase on checkin.

Using a language with a more powerful type system (e.g. Haskell) you can derive the same benefits as you would from static analysis tools, but integrated with the rest of your development tools, extensible, and supported by other users of the same language (e.g. library writers). So I think most people who appreciate the benefits tend to move on from C (particularly given how large the library ecosystem in safer languages is these days).

Re: Can We Trust the Libraries We Use?

#17
post #15

Test the hell out of anything you use, both hardware, software, and infrastructure -- and write the tests before you write any code. Double-down on that for stuff like medical tech. Now, is anybody doing that? Anybody? (Sound of crickets chirping)

That would be the case if people hadn't learn to disregard computer errors, when compared to other industries.

Moving to FP over the previous few years, it continues to amaze me the number of code paths that most programmers completely blow off.

Re: Can We Trust the Libraries We Use?

#19

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…

My opinion is that technology development is going to have to bifurcate -- or perhaps even split into three paths. No longer can you simply sit down and code something. Instead, you'll need to code some set of "rules" (this system can't use the internet, it should never access the GPS, and so on) at the same time. Technology will "run" when all the separate systems agree that everything is behaving correctly.

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.

Re: Can We Trust the Libraries We Use?

#20

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…

My opinion is that technology development is going to have to bifurcate -- or perhaps even split into three paths. No longer can you simply sit down and code something. Instead, you'll need to code some set of "rules" (this system can't use the internet, it should never access the GPS, and so on) at the same time. Technology will "run" when all the separate systems agree that everything is behaving correctly. We've t…

Well, yes. A big part of the problem is the lack of terminology and models. "Software development" is a stupidly large scope, it encompasses activities that are comparatively as varied as backyard astronomy and heart surgery. There are many different kinds of developers and many different kinds of software, but we lack the words to express the differences clearly. Which makes it that much more difficult to improve processes and standards. It's common for bromides and recommendations to be made as blanket statements applying to all software development, when it's clear that no one set of practices could possibly apply universally.

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.

Post reply on HN