Bug #85278 for IO-Socket-SSL: 1.81 broke HTTP::Daemon::SSL test suite

Tue May 14 03:40:44 2013 mabzug1 [...] gl.umbc.edu - Ticket created

Subject:

1.81 broke HTTP::Daemon::SSL test suite

IO::Socket::SSL 1.81 breaks the HTTP::Daemon:SSL test suite. I can verify that prior versions of IO::Socket:SSL, specifically 1.77, 1.79, and 1.80, do not break HTTP::Daemon:SSL. Version 1.88 of IO::Socket::SSL still breaks HTTP::Daemon:SSL. I'm a sysadmin looking to upgrade Perl and a bunch of modules. Is there a fix for this issue? Or should I just downgrade IO::Socket:SSL to 1.80? Thanks!

Tue May 14 03:41:11 2013 mabzug1 [...] gl.umbc.edu - Severity Normal added

Tue May 14 03:41:11 2013 mabzug1 [...] gl.umbc.edu - Broken in 1.81 added

Tue May 14 03:45:10 2013 mabzug1 [...] gl.umbc.edu - Reference to ticket #81932 added

Tue May 14 03:47:01 2013 mabzug1 [...] gl.umbc.edu - Correspondence added

BTW: there is also a ticket about the HTTP::Daemon::SSL error, #81932. Thanks again!

Tue May 14 09:42:09 2013 Steffen_Ullrich [...] genua.de - Correspondence added

Am Di 14. Mai 2013, 03:47:01, MORTY schrieb: Show quoted text

> BTW: there is also a ticket about the HTTP::Daemon::SSL error, #81932. > > Thanks again!

The problem described in RT#81932 is caused by an error in IO::Socket::IP, which was fixed in 0.20. I've released IO::Socket::SSL version 1.89 so that it uses IO::Socket::IP only with versions at least 0.20. But this has probably nothing to do with why it broke with 1.81 for you. This is a problem in HTTP::Daemon::SSL testsuite, where it declares which SSL_cert_file and SSL_ca_file to use, but forgets to specify SSL_key_file. Up to 1.80 it would use a default (which worked in this case), with 1.81 you must either specify both cert and key or none of it, only in the latter case it will use defaults.

Tue May 14 09:42:10 2013 The RT System itself - Status changed from 'new' to 'open'

Tue May 14 09:42:10 2013 Steffen_Ullrich [...] genua.de - Status changed from 'open' to 'resolved'

Wed May 15 02:44:51 2013 mabzug1 [...] gl.umbc.edu - Correspondence added

Thanks! Is there any way to get back the old behavior of IO::Socket::SSL, i.e. where it's possible to mix user-supplied settings and default settings? I'm building Perl modules for a large org, with several PB of storage and scripts all over the place. There are almost certainly scripts that are using IO::Socket:SSL that would break based on the 1.81 behavior. The safe way to proceed would be to avoid breaking backwards compatibility.

Wed May 15 02:44:51 2013 mabzug1 [...] gl.umbc.edu - Status changed from 'resolved' to 'open'

Wed May 15 03:15:21 2013 Steffen_Ullrich [...] genua.de - Correspondence added

Am Mi 15. Mai 2013, 02:44:51, MORTY schrieb: Show quoted text

> Thanks! > > Is there any way to get back the old behavior of IO::Socket::SSL, i.e. > where it's possible to mix user-supplied settings and default > settings? > > I'm building Perl modules for a large org, with several PB of storage > and scripts all over the place. There are almost certainly scripts > that are using IO::Socket:SSL that would break based on the 1.81 > behavior. The safe way to proceed would be to avoid breaking > backwards compatibility. >

I can understand your problem, but the old behavior simply did not made sense: either you use the default locations or you don't. Explicitly specifying the location of the cert, but trusting the default for the location of the key is not a sensible and expected behavior. Having a default location for key and cert at all was IMHO a bad decision anyway, but this decision was done years ago (and not by me). If you have control over your code I would strongly recommend to look, if you are affected by the problem at all. Unless you have strange setups you will probably not be affected. If you are affected you might try to work around the problem if you have a module, which is included from all your code. There you can setup your own defaults, like SSL_cert_file and SSL_key_file, with IO::Socket::SSL->set_defaults.

Wed May 15 03:15:22 2013 Steffen_Ullrich [...] genua.de - Status changed from 'open' to 'resolved'