IO::Socket::SSL version requirement?

[Charlie Brady]

I was wondering why Mojolicious requires IO::Socket::SSL 1.75. I see an
answer in the changelog:

...
3.0 2012-06-25
...
- Updated IO::Socket::SSL requirement to 1.75 for IO::Socket::IP support.
...

However, IO::Socket::IP support is only required for IPv6 support.

...
# IPv6 support requires IO::Socket::IP
use constant IPV6 => $ENV{MOJO_NO_IPV6}
? 0
: eval 'use IO::Socket::IP 0.16 (); 1';

# TLS support requires IO::Socket::SSL
use constant TLS => $ENV{MOJO_NO_TLS} ? 0
: eval(IPV6 ? 'use IO::Socket::SSL 1.75 (); 1'
: 'use IO::Socket::SSL 1.75 "inet4"; 1');
...

I think the following would be better:

use constant TLS => $ENV{MOJO_NO_TLS} ? 0
: eval(IPV6 ? 'use IO::Socket::SSL 1.75 (); 1'
: 'use IO::Socket::SSL 1.43 "inet4"; 1');

I've verified that TLS tests pass with IO::Socket::SSL 1.44 - which is the
latest version I've found packaged for RHEL6.

https://www.google.ca/search?q=perl(IO%3A%3ASocket%3A%3ASSL)+el6+rpm

[Sebastian Riedel]

> I think the following would be better:
>
> use constant TLS => $ENV{MOJO_NO_TLS} ? 0
> : eval(IPV6 ? 'use IO::Socket::SSL 1.75 (); 1'
> : 'use IO::Socket::SSL 1.43 "inet4"; 1');
>
> I've verified that TLS tests pass with IO::Socket::SSL 1.44 - which is the
> latest version I've found packaged for RHEL6.

-1 from me for this, only creates more hard to debug edge cases for very limited gain.

--
Sebastian Riedel
http://twitter.com/kraih
http://mojolicio.us

[Charlie Brady]

On Thu, 23 Aug 2012, Sebastian Riedel wrote:

> > I think the following would be better:
> >
> > use constant TLS => $ENV{MOJO_NO_TLS} ? 0
> > : eval(IPV6 ? 'use IO::Socket::SSL 1.75 (); 1'
> > : 'use IO::Socket::SSL 1.43 "inet4"; 1');
> >
> > I've verified that TLS tests pass with IO::Socket::SSL 1.44 - which is the
> > latest version I've found packaged for RHEL6.
>
> -1 from me for this, only creates more hard to debug edge cases for very limited gain.

What hard to debug edge cases? I don't see any evidence that
IO::Socket::SSL 1.43 doesn't work perfectly for IPv4. Isn't a core value
of this project that you avoid adding gratuitous dependencies?

---
Charlie

[Sebastian Riedel]

> What hard to debug edge cases?

SNI support for example was only added in IO::Socket::SSL 1.56. Or lets say you have IO::Socket::SSL 1.44 and decide to install something that requires IO::Socket::IP, suddenly TLS support in Mojolicious stops working.

> Isn't a core value of this project that you avoid adding gratuitous dependencies?

Not really, we aim for fast installation times, that's about it.

[Charlie Brady]

On Thu, 23 Aug 2012, Sebastian Riedel wrote:

> > What hard to debug edge cases?
>
> SNI support for example was only added in IO::Socket::SSL 1.56.

Is SNI support mandatory?

> Or lets say you have IO::Socket::SSL 1.44 and decide to install
> something that requires IO::Socket::IP, suddenly TLS support in
> Mojolicious stops working.

Is this hypothetical, or does merely installing IO::Socket::IP break
IO::Socket::SSL (but only for version 1.44, not for version 1.75)?

> > Isn't a core value of this project that you avoid adding gratuitous dependencies?
>
> Not really, we aim for fast installation times, that's about it.

I can install perl-IO-Socket-SSL v 1.44 quickly on the systems I manage. I
cannot do so with v 1.75 - installation via rpm is mandated in my
environment. I suspect that there are many users of RHEL6 (or CentOS6 or
SL6) with similar constraints.

---
Charlie

[sri]

> Is SNI support mandatory?

It is a rather important feature these days, and causes more special
cases when it might be missing.

> Is this hypothetical, or does merely installing IO::Socket::IP break
> IO::Socket::SSL (but only for version 1.44, not for version 1.75)?

Your proposal automatically bumps the IO::Socket::SSL requirement to
1.75 if IO::Socket::IP is available.

> I can install perl-IO-Socket-SSL v 1.44 quickly on the systems I manage. I
> cannot do so with v 1.75 - installation via rpm is mandated in my
> environment. I suspect that there are many users of RHEL6 (or CentOS6 or
> SL6) with similar constraints.

My -1 vote on this stands, i don't think the gain outweighs the
maintenance and support cost. But maybe the other core developers
disagree with me, we'll see.

--
sebastian

[Charlie Brady]

On Thu, 23 Aug 2012, sri wrote:

> > Is this hypothetical, or does merely installing IO::Socket::IP break
> > IO::Socket::SSL (but only for version 1.44, not for version 1.75)?
>
> Your proposal automatically bumps the IO::Socket::SSL requirement to
> 1.75 if IO::Socket::IP is available.

Then one of us has misunderstood the proposal. I was proposing that
IO::Socket::SSL 1.75 only be required if IPv6 is in use (which will also
require IO::Socket::IP). I was proposing that if IPv6 is not in use,
IO::Socket::IP not be required, and only 1.43 of IO::Socket::SSL be
required.

> > I can install perl-IO-Socket-SSL v 1.44 quickly on the systems I manage. I
> > cannot do so with v 1.75 - installation via rpm is mandated in my
> > environment. I suspect that there are many users of RHEL6 (or CentOS6 or
> > SL6) with similar constraints.
>
> My -1 vote on this stands, i don't think the gain outweighs the
> maintenance and support cost.

You are externalising the maintenance and support costs :-)

> But maybe the other core developers disagree with me, we'll see.

Thanks for keeping an open mind.

I don't want to harrangue you and don't want to seem ungrateful. But I
have a real problem and I think you are talking about a hypothetical
problem.

I don't see any tests which fail when I drop the requirement back to 1.44,
which is what I have installed, and which is what I have easily available.

[Sebastian Riedel]

> Then one of us has misunderstood the proposal. I was proposing that
> IO::Socket::SSL 1.75 only be required if IPv6 is in use (which will also
> require IO::Socket::IP). I was proposing that if IPv6 is not in use,
> IO::Socket::IP not be required, and only 1.43 of IO::Socket::SSL be
> required.

IO::Socket::IP will be automatically used if it is available, and therefore in-turn automatically bump the IO::Socket::SSL requirement to 1.75.

[tempire]

This sounds more like a RedHat issue than anything else.  Rather than requiring Mojolicious to keep track of multiple versions of ::SSL, I think a better solution would be to make an IO::Socket::SSL 1.75 rpm and have everyone benefit.

[Charlie Brady]

On Fri, 24 Aug 2012, Sebastian Riedel wrote:

> > Then one of us has misunderstood the proposal. I was proposing that
> > IO::Socket::SSL 1.75 only be required if IPv6 is in use (which will also
> > require IO::Socket::IP). I was proposing that if IPv6 is not in use,
> > IO::Socket::IP not be required, and only 1.43 of IO::Socket::SSL be
> > required.
>
> IO::Socket::IP will be automatically used if it is available, and
> therefore in-turn automatically bump the IO::Socket::SSL requirement to
> 1.75.

Yes, I see that now. So I modify my request (but leave the requested patch
unchanged). If I set MOJO_NO_IPV6, could I please be permitted to use
version 1.44 of IO::Socket::SSL? I know it works (on my platform).

---
Charlie

[Charlie Brady]

On Thu, 23 Aug 2012, tempire wrote:

> This sounds more like a RedHat issue than anything else. Rather than
> requiring Mojolicious to keep track of multiple versions of ::SSL,

I don't see that Mojolicious needs to do anything except make a change
s/1.75/1.43/ in one line of code.

> I think a better solution would be to make an IO::Socket::SSL 1.75 rpm
> and have everyone benefit.

If I make such an rpm, how will everyone benefit?

---
Charlie

[Charlie Brady]

It's not just a matter of making a newer perl-IO-Socket-SSL rpm.
IO::Socket::SSL v 1.75 reguires Socket 1.95. perl 5.10.1 provides only
Socket 1.82.

---
Charlie

[Justin Hawkins]

It's not just a matter of making a newer perl-IO-Socket-SSL rpm.
IO::Socket::SSL v 1.75 reguires Socket 1.95.  perl 5.10.1 provides only
Socket 1.82.

If you persist with RHEL, you're gonna have a bad time.

If you can't get rid of RHEL, I'd suggest spending some effort in spinning up your own perl stack (perlbrew would be a good start).

The time you burn will be trivial compared to your long term "investment" in making the RHEL based perl environment work right.

- Justin 

-- 
Justin Hawkins
jus...@hawkins.id.au

[Charlie Brady]

On Thu, 23 Aug 2012, Charlie Brady wrote:

> On Thu, 23 Aug 2012, tempire wrote:
>
> > This sounds more like a RedHat issue than anything else. Rather than
> > requiring Mojolicious to keep track of multiple versions of ::SSL,
>
> I don't see that Mojolicious needs to do anything except make a change
> s/1.75/1.43/ in one line of code.

In two places.

I don't see the down side in this.

If $ENV{MOJO_NO_IPV6} is not set, behaviour is unchanged.

If $ENV{MOJO_NO_IPV6} is set non-zero, and
IO::Socket::SSL >= 1.75 is installed, behaviour is unchanged.

If IO::Socket::SSL 1.43 <= version < 1.75 is installed, program now has a
probability of working much higher. Was 0, may now be 100%.

--- Mojolicious-3.33.orig/lib/Mojo/IOLoop/Client.pm 2012-08-23 20:25:31.780804233 -0400
+++ Mojolicious-3.33/lib/Mojo/IOLoop/Client.pm 2012-08-23 20:25:47.479732540 -0400
@@ -14,7 +14,7 @@

# TLS support requires IO::Socket::SSL
use constant TLS => $ENV{MOJO_NO_TLS} ? 0
: eval(IPV6 ? 'use IO::Socket::SSL 1.75 (); 1'

- : 'use IO::Socket::SSL 1.75 "inet4"; 1');
+ : 'use IO::Socket::SSL 1.43 "inet4"; 1');
use constant TLS_READ => TLS ? IO::Socket::SSL::SSL_WANT_READ() : 0;
use constant TLS_WRITE => TLS ? IO::Socket::SSL::SSL_WANT_WRITE() : 0;

diff -ru Mojolicious-3.33.orig/lib/Mojo/IOLoop/Server.pm Mojolicious-3.33/lib/Mojo/IOLoop/Server.pm
--- Mojolicious-3.33.orig/lib/Mojo/IOLoop/Server.pm 2012-08-23 20:25:31.781804228 -0400
+++ Mojolicious-3.33/lib/Mojo/IOLoop/Server.pm 2012-08-23 20:25:56.990689127 -0400
@@ -16,7 +16,7 @@

# TLS support requires IO::Socket::SSL
use constant TLS => $ENV{MOJO_NO_TLS} ? 0
: eval(IPV6 ? 'use IO::Socket::SSL 1.75 (); 1'

- : 'use IO::Socket::SSL 1.75 "inet4"; 1');
+ : 'use IO::Socket::SSL 1.43 "inet4"; 1');
use constant TLS_READ => TLS ? IO::Socket::SSL::SSL_WANT_READ() : 0;
use constant TLS_WRITE => TLS ? IO::Socket::SSL::SSL_WANT_WRITE() : 0;

[Charlie Brady]

On Fri, 24 Aug 2012, Justin Hawkins wrote:

> > It's not just a matter of making a newer perl-IO-Socket-SSL rpm.
> > IO::Socket::SSL v 1.75 reguires Socket 1.95. perl 5.10.1 provides only
> > Socket 1.82.
>
> If you persist with RHEL, you're gonna have a bad time.

It's not my choice to make. And FTR, I don't have a bad time, with perl,
with RHEL. It works, for what I use it for. ymmv.

> If you can't get rid of RHEL, I'd suggest spending some effort in
> spinning up your own perl stack (perlbrew would be a good start).

That's more work than changing two lines of code, don't you agree? In any
case, I don't have that choice. perlbrew does not satisfy my requirements
(e.g. for rpm controlled/installed software). I would need to make and
maintain a large collection of parallel rpms. But thanks for the
suggestion.

> The time you burn will be trivial compared to your long term
> "investment" in making the RHEL based perl environment work right.

Thanks for your opinion.

---
Charlie

[Roland Lammel]

On Fri, Aug 24, 2012 at 2:46 AM, Charlie Brady <charli...@budge.apana.org.au> wrote:

On Fri, 24 Aug 2012, Justin Hawkins wrote:

> > It's not just a matter of making a newer perl-IO-Socket-SSL rpm.
> > IO::Socket::SSL v 1.75 reguires Socket 1.95.  perl 5.10.1 provides only
> > Socket 1.82.
>
> If you persist with RHEL, you're gonna have a bad time.

It's not my choice to make. And FTR, I don't have a bad time, with perl,
with RHEL. It works, for what I use it for. ymmv.

> If you can't get rid of RHEL, I'd suggest spending some effort in
> spinning up your own perl stack (perlbrew would be a good start).

That's more work than changing two lines of code, don't you agree? In any
case, I don't have that choice. perlbrew does not satisfy my requirements
(e.g. for rpm controlled/installed software). I would need to make and
maintain a large collection of parallel rpms. But thanks for the
suggestion.

I know thei pains of being limited by the perl that RHEL offers. Although it a really rock solid distribution (I'm talking RHEL5 and perl5.8 here) the limitations on the far to old perl where also too much for me to get some apps working. So maybe building, maintaining and packaging your own perl would be an option.

http://www.brabbel.net/2010/03/27/build-your-own-fast-perl/

It will also allow you to take advantage of super-cow methods of modern perl (sane UTF8 support, local::lib, DBIx-Class, Moose, ...) are all just an installation away.
After installing, package up your big perl RPM and deploy. Of course you need to take care on external dependencies, just add those to the RPM spec file before building. So you can be sure, that the right RPMs are pulled in.

If you are using RHEL you probably have your own corporate repository anyway.

Although I like RHEL, I really think it hinders modernizing software stacks due to it's policy of never updating anything (only patch the hell out of every software)

Maybe you give it a try, cheers

+rl
 

> The time you burn will be trivial compared to your long term
> "investment" in making the RHEL based perl environment work right.

Thanks for your opinion.

---
Charlie

--
You received this message because you are subscribed to the Google Groups "Mojolicious" group.
To post to this group, send email to mojol...@googlegroups.com.
To unsubscribe from this group, send email to mojolicious...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/mojolicious?hl=en.

[Charlie Brady]

On Fri, 24 Aug 2012, Roland Lammel wrote:

> http://www.brabbel.net/2010/03/27/build-your-own-fast-perl/
>
> It will also allow you to take advantage of super-cow methods of modern
> perl (sane UTF8 support, local::lib, DBIx-Class, Moose, ...) are all just
> an installation away.
> After installing, package up your big perl RPM and deploy. Of course you
> need to take care on external dependencies, just add those to the RPM spec
> file before building. So you can be sure, that the right RPMs are pulled in.

I don't have need for any of that, and don't want to do that work. I just
want to access https:// URLs with Mojo::UserAgent (over IPv4) on my
platform. And I know that it works. It just requires two bytes to change
in two files.

Sebastien says:

Or lets say you have IO::Socket::SSL 1.44 and decide to install something that
requires IO::Socket::IP, suddenly TLS support in Mojolicious stops
working.

Or, to put that another way, you don't have TLS now on your platform, and
we can't give it to you, because you might break it at some time in the
future (by installing IO::Socket::IP, which, BTW, isn't compatible with
your platform).

I'm not convinced :-)

I can continue patching. Others would just give up on Mojolicious, which I
would think unfortunate.

---
Charlie

[sri]

> I'm not convinced :-)

Good thing you have to convince us, and not the other way around. ;)

P.S.: So far we have two core developers not in favor of this change.

--
sebastian

[Roland Lammel]

On Fri, Aug 24, 2012 at 2:38 PM, Charlie Brady <charli...@budge.apana.org.au> wrote:

On Fri, 24 Aug 2012, Roland Lammel wrote:

> http://www.brabbel.net/2010/03/27/build-your-own-fast-perl/
>
> It will also allow you to take advantage of super-cow methods of modern
> perl (sane UTF8 support, local::lib, DBIx-Class, Moose, ...) are all just
> an installation away.
> After installing, package up your big perl RPM and deploy. Of course you
> need to take care on external dependencies, just add those to the RPM spec
> file before building. So you can be sure, that the right RPMs are pulled in.

I don't have need for any of that, and don't want to do that work. I just
want to access https:// URLs with Mojo::UserAgent (over IPv4) on my
platform. And I know that it works. It just requires two bytes to change
in two files.

Not doing any work will cause having to do a lot of work at some point in the future ;-)

Sebastien says:

 Or lets say you have IO::Socket::SSL 1.44 and decide to install something that
 requires IO::Socket::IP, suddenly TLS support in Mojolicious stops
 working.

Or, to put that another way, you don't have TLS now on your platform, and
we can't give it to you, because you might break it at some time in the
future (by installing IO::Socket::IP, which, BTW, isn't compatible with
your platform).

I'm not convinced :-)

I can continue patching. Others would just give up on Mojolicious, which I
would think unfortunate.

As you only deploy software in RPM packages anyway, you need to package it up anyway. So why not provide a RPM package with your patch applied to the repoforge (former rpmforge) repository or similar. This would definitly aid the RHEL/CentOS Camp (even if you would do it for RHEL6 only now). And also probably bring you a lot of kudos from the Mojolicious community, the core devs could add that info to the documentation (or wiki) too then, so others will use the correct thing, which will just work, as you said.

Hope you get around to do that!

Cheers

+rl

[Charlie Brady]

On Fri, 24 Aug 2012, Roland Lammel wrote:

> Not doing any work will cause having to do a lot of work at some point in
> the future ;-)

I'd ask all of you to allow me to be the best judge of that.

> As you only deploy software in RPM packages anyway, you need to package it
> up anyway. So why not provide a RPM package with your patch applied to the
> repoforge (former rpmforge) repository or similar.

Good idea. Thanks.

[Charlie Brady]

On Fri, 24 Aug 2012, Charlie Brady wrote:

> > As you only deploy software in RPM packages anyway, you need to package it
> > up anyway. So why not provide a RPM package with your patch applied to the
> > repoforge (former rpmforge) repository or similar.
>
> Good idea. Thanks.

For the impatient, someone has a head start here - although last
Mojolicious packaged was 2.76 (the IO::Socket::SSL version discussion does
not apply):

http://www.pkgbox.de/wordpress/2012/01/a-new-hope-package-repository-for-rhel-6-based-linux/

[Roland Lammel]

That is definitly great. So getting the Source RPM will save you nearly all of the time. Let us know if you get around to build a package for the latest Mojolicious

Thanks for sharing.

+rl