>That would make RHEL6 users, at least, sad: > >$ rpm -q openssl >openssl-1.0.1e-57.el6.x86_64 >openssl-1.0.1e-57.el6.i686
I feel your pain since we use a lot of CentOS 6 at work, but you don't have much longer to use it, right? I think support for it only goes until next year, unless you pay for extended lifecycle support. Maybe we can come out with a newer release of nmh before then, but it's not like it's tomorrow. But you motivated me enough to look ... I see that 1.0.1 DOES actually include the necessary function (SSL_set_tlsext_host_name()). It looks like that was added for 1.0.0. >I am not exactly confident that replacing that with 1.0.2 or later would >be feasible --- didn't they break ABI to some extent in that revision? Ummm .... 'maybe'. There is no ABI compatibility guarantee, that is for sure. It looks like what bit us was that going from 1.0.2 to 1.1.0 a library function (SSL_library_init) was turned into a macro. But there is nothing stopping you from installing a newer OpenSSL into /usr/local and linking nmh against that; it wouldn't conflict with anything installed. I feel that since SSL_set_tlsext_host_name() has been around for approximately forever I'm fine with just adding it and assuming that everyone is at 1.0.0 or newer (but I just know someone will show up still using 0.9.8). But it does beg a larger question ... should we still force a minimum version of 1.0.2? The reason I ask is our current code has an #ifdef for the function X509_VERIFY_PARAM_set1_host() which controls the verification of the name of the server certificate against the passed-in hostname, which is pretty important; without that no hostname verification of the server certificate is done. I don't know if we think this is important enough that we require nmh have this functionality or not (you can always turn it off with a command line switch). --Ken -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
