Hacker News new | past | comments | ask | show | jobs | submit login

> Ask yourself if it cheaper to fully review, sign, compile, and maintain third party OSS code or to write something focused on your needs on stop of the standard library yourself.

Why stop at the standard library? What about the rest of the language toolchain? Compilers, interpreters. What about the OS?




Those much more often have full time paid people whose actual job is to review them. E.g the standard library of Go has security and quality review by Google. It is reasonable to assume they are investing more in supply chain security than you are in those portions.

The random dep you grabbed that some hobbyist hammered out in a weekend... may not have 2FA on github, or maybe their email domain is about to expire, and it is very likely no one reviewed it.

If you choose to use the latter because it does what you need, then you are now the first party accepting the additional responsibilities of reviewing and maintaining that code to the level of safety appropriate for your use case.

If you are making a video game for personal use, then maybe the worst case scenario is tolerable for you to not care. If you are handling PII or money of other people... then suddenly you /must/ care.


He who cashes the check shall be the defendant in the lawsuit. If things went well the people behind the compiler, interpreter and OS wouldn't have received a dime from your successful enterprise, now that it's gone sideways you want to share?


The idea is risk reduction, not removal.

An OS is backed by thousands of developers, and usually billions of dollars. Theres negligible risk that the momentum stops.

If that OSS library, that is fundamental to your business, has three developers, then maybe you do have a problem.


I think that a lot of people should be asking themselves about the state of vulns and other bugs in linux. In fact, I'd call the state of correctness of the linux kernel and surrounding systems to be something resembling an industry emergency. It shouldn't be possible for bugs to regress in the kernel, but they do! A lot of very ordinary best practices aren't actually followed in the kernel world.


The linux kernel is a security shit show, but it is the only compatible option in most cases. You can at least strip it to the bone, apply Kernel Self Protection Project guidelines, and run it offline in TEEs or HSMs for your most sensitive operations. This is approaching as good as we will ever get.

Linux is a massive C codebase one can never /fully/ trust or harden and high security applications with sufficient resources should favor formally verified microkernels like SeL4 whenever possible.


It is true that Linux rules the world and is absolutely the right platform for a huge number of projects. I'm not saying "Linux is bad, reach for something else." I'm saying "Linux is the foundation for basically the entire computing landscape so the industry needs to take a real hard look at finding a way to make it safe."

I think it can be done. But I think it needs industry-wide effort in a huge way.


I think it is going to be much easier to produce a formally verified Linux ABI compatible microkernel than to ever fix Linux itself at this point.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: