> > OpenSSL is *NOT* intended to be 'used' by people who use > > programs that use > > it. It is intended to be used by programs and by people who make them.
> I'll stick my 0.01 euro cent in here and state i disagree with this > hypothesis. whether you are a user via a 3rd party program (as almost > all users of openssl are!) or are directly using openssl as a developer > both camps and parties should be catered for - especially > as a lot of apps that use openssl really only look for the DLL > or shared library - or, if built from source, the required dev libraries > and link libraries. However, they generally require particular versions of OpenSSL or particular build environments. They impose their own requirements. If you can state and explain these requirements and reduce your question to one that is actually about OpenSSL, then I agree with you. OpenSSL explicitly is *not* a stable library such that you can make library upgrades without consideration application details -- other than withing the same minor version to fix specific security issues. If a post is about a specific known OpenSSL security issue, and the issue is how to fix that issue within the minor version required by the application, that would be an OpenSSL issue. Even then, it may be dangerous to do that if the application contains its own workaround to that same issue. Or the application may not even use the part of OpenSSL that has the vulnerability, making the exercise pointless. This should still, in most cases, be treated as an application issue first. If it is handled as an OpenSSL issue, that should be by one of the application's developers, not a mere user. > either type of user may be intersted in such things as keeping an > up-to-date version for security - or ways of configuring it for > better speed, performance or security settings. That's true. I agree, my position as stated is a bit too harsh. I disagree about security settings though, those are application issues, not library issues. It's dangerous to treat them as library issues. A security issue should not be fixed without the presence of *someone* with detailed understanding of how the application uses OpenSSL. An actual user (in the sense of application developer) of the library needs to do this to be sure it's done properly. Even OpenSSL experts would either have to familiarize themselves with the application or do a lot of guessing. Guessing in the security field is bad. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
