[pkg-fetchmail-maint] Bug#775255: fetchmail: Fails to start when libssl has SSLv3 disabled

[Matthias Andree]

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