Hi Till, It looks to me like the discussion you are bringing up here has several different questions:
1) How can we protect a Qt binary from picking up a bad ssl library - for example a wrong version? 2) How can we protect a Qt binary against an attack with a hacked ssl library? 3) What is the correct procedure when scanning for the ssl library? To me this looks like the correct answers depend a lot on the answer to number 2. As we will not have a statically linked OpenSSL with commercial Qt apps, currently we have no choice but to deliver the two dll files. That means the question no longer can be a security issue, since we can't solve that. So number 3 and 1 becomes one question. My argument that we should recompile Qt without ssl support is the proper solution to avoid a Qt app, that we didn't intend to use ssl, picking up the library anyway. But it would be nice if qt.conf had a "disallow ssl" option. Then it's easy to avoid a crash from a bad ssl library picked up from somewhere else. It would be great if we could have trusted plugins that are cryptographically signed so my application could be shipped with a public key and check plugins. This would solve the security problem as well. It should be possible to create one that links statically to OpenSSL and ship that. I think. The license of OpenSSL is pretty annoying. Bo. -- Bo Thorsen, European Engineering Manager, ICS Integrated Computer Solutions. Delivering World-Class Applications http://ics.com/services _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
