Am 16.01.2015 um 01:24 schrieb Debian Bug Tracking System: > Processing control commands: > >> tags -1 + experimental > Bug #775255 [fetchmail] fetchmail: Fails to start when libssl has SSLv3 > disabled > Added tag(s) experimental. >
IMO this is an error from the shell and the dynamic run-time linker, not a fetchmail issue, and Sebastian is right, symbol removal REQUIRES bumping the .so version appropriately. It needs to be OpenSSL 2.0 then (at least libssl) in my understanding. I wonder how people get the package build though, if the symbol is dropped from the lib it most certainly should also be dropped from the header, and that would already jam the build. (OK chances are that the library package is younger than the fetchmail package, please check that. You should NOT be able to build fetchmail on a libssl that has SSLv3 disable, else please file a bug against the libssl*-dev package.) Now, if OpenSSL chooses to disable options in an incompatible way, by causing compile or run-time link trouble by removing symbols, so be it, the proposed fix however is wrong and rejected. For 6.3 the proper fix will be to amend to configure and conditionally disable SSLv3, but it will need to tell the user what the matter is, so just silently removing a line without adjusting parsers and thereabout is an offense. For 7.x I may consider killing SSLv3 support altogether, it's no longer default in the Git version since 2014-10-15 anyhow. I would need to add a deprecation warning in a 6.x release though, and distributors may also need to do that. Having said all that, grab a2ae6f8d15d7caf815d7bdd13df833fd1b2af5cc from one of the three upstream Git mirrors and extract the relevant parts. If you break it, you get to keep the pieces, though... My take is that this bug should be demoted to wishlist and also bestowed with "upstream, fixed-upstream, patch" tags. HTH -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
