Quote:
Originally Posted by resolver
I haven't looked at that thread
|
It's the one you created.
Quote:
|
If you blindly trust binaries, there is nothing to stop a malevolent person (and NSA or GCHQ operative perhaps) from inserting malware into binaries and falsely claiming they come from the public source code. All they have to do is patch the public version, compile and claim the binary's benevolent.
|
Right, this is covered in the thread already regarding signatures.
Whether you're comparing the signature of an executable or of an archive, or of some (say) C source directly - you're still engaged in the business of trust.
Quote:
|
Haven't you heard of reproducible builds?
|
Sure, and this is what I was referring to when I mentioned 'consistency', but 'reproducible builds' isn't to do with security or validation of data of any kind. Reproducible builds means that when you build something, the output is identical each time. The process of how the environment is established (dependency packages installed and so on), is linked to, but separate from this.
When vendors build the packages for distribution, typically a build starts, and the environment is populated with the dependencies which are binary packages from the distribution vendor itself.
All of that is automated, and the installation system takes care of validating the signatures of the packages.
The difference here is that it's the vendor's binary repo, not a 3rd party - so as the vendor you're in control of what's in there and can ensure that whatever versions are downloaded are what you want. However, the process of _verification_ on the build client is typically the same as whether they're 3rd party repo's: the data is (hopefully!) downloaded over a secured connection using TLS, and the payload is validated against a digital signature.
What a vendor (such as ourselves) doesn't and wouldn't do, is let some automated process download whatever's the latest versions available and use it to build and package something. Even when the build process validates the authenticity of every piece of data involved, you must keep strict control over what *versions* of software are included and being used. This will go some way to helping have 'reproducible builds', but not only that, it is necessary for debugging and troubleshooting.
Again, this is separate from security in the sense of 'do I trust this data, can I trust this data? can I trust this source?'
