Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This is a common response but it's not addressing the core issue.

Bugs and vulnerabilities are discovered every day in the layers that can be independently verified. Your argument extends to every single piece of software everywhere that runs on Intel and AMD microprocessors, for instance. It's foolish to say that an OpenSSL instance shouldn't be examined because the network interface it communicates over uses a proprietary firmware blob, or runs on Windows, for instance.

I agree that the freedom to verify the behavior of (what amounts to) firmware is not one of the Four Freedoms, but there is a non-zero value in being able to find bugs and help the manufacturer improve the product, as well as being able to use that information to inform a purchasing decision. Especially for something which could potentially be considered to provide organizational security.



My point is not that you shouldn't verify OpenSSL code. My point is that you shouldn't pretend that you don't implicitly trust Intel/AMD (or Yubikey).


So something _has_ changed in other words. You used to implicitly trust Yubikey's word that they put the publicly available source code on their devices, just like now, but you used to also be able to verify their code such that you could be fairly sure that if the trust in the company is warranted, their product is fairly secure, or more importantly, find security issues in their code.




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

Search: