5 ms·

I know nothing about this... However, I can see a little bit of sense to this (not much - and nothing that couldn't be solved a lot better). If you have access

I know nothing about this... However, I can see a little bit of sense to this (not much - and nothing that couldn't be solved a lot better). If you have access to the source code it is very easy to start adding patches. On the other hand if you have access to binaries it is also very easy to start modifying them...

pknopf 8y ago
Their argument seems to suggest that I should roll my own openssl, for "risk management". I mean, these projects typically have thorough tests.
- asfdsfggtfd 8y ago
  Surely it's more that you should obtain certified binaries of openssl from a third party?
  - pknopf 8y ago
    Yeah, I get it. However, if I use SOUP, I'm responsible for bugs. How would I debug with no source?
    - wgjordan 8y ago
      > 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]. [1] https://www.openssl.org/source/openssl-1.1.0h.tar.gz https://www.openssl.org/source/openssl-1.1.0h.tar.gz
- yzmtf2008 8y ago
  That’s not a very accurate analogy. The situation would be more like “you can only use a pre-compiled, audited version of OpenSSL”, which makes much more sense. Of course you could audit source code as well, but it’s much harder to verify than a binary.
  - Hello71 8y ago
    wait, wait, it's harder to audit source code than a binary? wtf?
    - yzmtf2008 8y ago
      I should probably clarify: it’s easier to make sure that a binary is the same as a version that has been audited, whereas with source code, there’s much more uncertainty in the build process.
      - pknopf 8y ago
        With Yocto, you can audit the recipes (example [0]) being used to build the library. 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/recipes-graphics/harfbuzz/harfbuzz_1.7.5.bb https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/re...
        loup-vaillant 8y ago
        How about the following? "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?

pknopf 8y ago

Their argument seems to suggest that I should roll my own openssl, for "risk management". I mean, these projects typically have thorough tests.

asfdsfggtfd 8y ago
Surely it's more that you should obtain certified binaries of openssl from a third party?
- pknopf 8y ago
  Yeah, I get it. However, if I use SOUP, I'm responsible for bugs. How would I debug with no source?
  - wgjordan 8y ago
    > 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]. [1] https://www.openssl.org/source/openssl-1.1.0h.tar.gz https://www.openssl.org/source/openssl-1.1.0h.tar.gz
yzmtf2008 8y ago
That’s not a very accurate analogy. The situation would be more like “you can only use a pre-compiled, audited version of OpenSSL”, which makes much more sense. Of course you could audit source code as well, but it’s much harder to verify than a binary.
- Hello71 8y ago
  wait, wait, it's harder to audit source code than a binary? wtf?
  - yzmtf2008 8y ago
    I should probably clarify: it’s easier to make sure that a binary is the same as a version that has been audited, whereas with source code, there’s much more uncertainty in the build process.
    - pknopf 8y ago
      With Yocto, you can audit the recipes (example [0]) being used to build the library. 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/recipes-graphics/harfbuzz/harfbuzz_1.7.5.bb https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/re...
      - loup-vaillant 8y ago
        How about the following? "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?