https://bz.apache.org/bugzilla/show_bug.cgi?id=57815
--- Comment #3 from Christopher Schultz <ch...@christopherschultz.net> --- (In reply to Justin from comment #2) > (In reply to Christopher Schultz from comment #1) > > when it comes to discovering available functions > > Seems to me there are many ways to do this. OpenSSL's own "ciphers" command > tells you what ciphers are supported. Ciphers are s different story: you give a list of ciphers to OpenSSL and tell it to use those. Any that it doesn't support, it will ignore, and there are (usually) plenty of others to choose from. For protocols, you're pretty much limited to 3 useful ones, and some versions of the library only support one. If you choose one it doesn't support, it simply will not support it, no matter what version you built against. > These are standard names which also indicate which SSL protocols are > supported. While true, the mechanism for configuring OpenSSL for a protocol is fundamentally different from the way that ciphers are specified and selected. The Java analogy would be that I have to know at build-time the exact name of the class I want to instantiate in order to get an engine that supports e.g. TLS1.2. If it's not available at built time, I simply can't guarantee it will be available at runtime, so I can't compile-in the usage of that class (it's a function that returns a complex structure in C) or you'll get runtime failures that will usually bring-down the process. Bringing-down the process is much worse than downgrading to the features available in the build-time version of OpenSSL. > > 14-Apr-2015 17:30:50.069 INFO [main] > > org.apache.catalina.core.AprLifecycleListener.initializeSSL OpenSSL > > successfully > initialized (OpenSSL 1.0.1e 11 Feb 2013) > > I'm a little bothered that you'll log the runtime library, but not the build > time library that you are restricting users to. Bothered? Well, feel free to ask for that information to be added. I'm the one who added the version information to that log message, and it didn't occur to be to log the version of OpenSSL we built-against. If you think that's useful, I'm happy to add it. Back to "doing the right thing". I'm not sure it's possible to make tcnative forward-compatible with as-yet-unseen versions of OpenSSL; the best we can do is build against the version we have at hand. On the other hand, we could be better about picking a protocol given the protocol(s) requested by the caller and those supported by the build-time library. I can review the code in there, which I thought was a little funny at the time. I can also fix the error message so that it makes more sense. > This obviously isn't a problem on Windows where most use the pre-built > Tomcat Native where OpenSSL is statically linked. They must wait for a new > build of Tomcat Native. Windows users can certainly build their own; they just aren't used to compiling their own software like most UNIX admins are. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
