3 ms·

That sounds like bad software engineering to most, but if each OpenSSL copy was actually in a separate Docker image, reactions would suddenly be much milder I s

• yjftsjthsd-h 8y ago
  To be fair, while much of that boils down to what is considered normal, Docker images are also far easier to update and maintain then manually grafted together libraries.
• xemdetia 8y ago
  This is a very upsetting comment. Docker is one of the things that is making modern security compliance about 10 times harder than it was before even on 10k-100k systems. Especially in government contexts where using the approved/certified/correct cryptographic modules (FIPS 140-2) is an absolute requirement. FIPS 140-2 in particular requires not only the appropriate package to be available (commonly OpenSSL) but also for the application to opt into a FIPS 140-2 mode after linking. There is also the fact that cryptographic libraries that are certified are often on a 2-3 month delay from the non-certified modules. You have to verify that the Host OS's kernel, the runtime that is providing the containing environment, and every single Docker image that is used to run an application, ensure that each application is running in an appropriate FIPS 140-2 mode inside the container, and also verify that every container is being appropriately kept up to date. Using Docker does not eschew responsibilities you have to ensure that your OpenSSL and other materials is up to date, especially since Docker doesn't give you any protections when it comes to encryption over the wire or encryption with data at rest which is exactly where a cryptographic library with a vulnerability like in the original article leaves a vulnerability where there shouldn't be one.