Their argument seems to suggest that I should roll my own openssl, for "risk management".
I mean, these projects typically have thorough tests.
I mean, these projects typically have thorough tests.
Yocto all generates checksums for all inputs and outputs, caching intermediate build steps, ensuring consistency in the build process.
Also, Yocto will not compile anything with your local/native gcc toolchain. It will however use your local gcc toolchain to build it's own gcc toolchain, which it will then use to build all the relative recipes. This again ensures build consistency across platforms/machines.
If the argument is purely a "well, I can't audit the produced binaries", I'd argue that you can audit the build system in great detail.
[0] https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/re...
"Sure, we do use the precompiled binaries. We can even prove it because they have the same hash, and our procedure fails if they don't"
How you obtained your binary is immaterial, if you can prove it's the same as the audited one. Surely regulatory people would accept that?
However, if I use SOUP, I'm responsible for bugs. How would I debug with no source?
I don't work in the field, but just because you're using a certified binary doesn't mean no source can ever be associated with it for debugging.
Continuing the example of a certified binary of openssl from a third party (say version 1.1.0h), I'd expect you to be able to debug the certified binary using a version-matched source tarball from the openssl website [1].