Bug #113492 for IO-Socket-SSL: Support SecureTransport on Mac OS X

Fri Apr 01 04:43:01 2016 REHSACK [...] cpan.org - Ticket created

Subject:

OpenSSL stopped working on Darwin, don't rely exclusively on Net::SSLeay

Regarding to http://lists.apple.com/archives/macnetworkprog/2015/Jun/msg00025.html, no future version of Xcode will come with OpenSSL headers. It can't be the recommendation to all users to install pkgsrc, macports or homebrew.

Fri Apr 01 06:51:35 2016 Steffen_Ullrich [...] genua.de - Correspondence added

Am Fr 01. Apr 2016, 04:43:01, REHSACK schrieb: Show quoted text

> Regarding to > http://lists.apple.com/archives/macnetworkprog/2015/Jun/msg00025.html, > no future version of Xcode will come with OpenSSL headers. > > It can't be the recommendation to all users to install pkgsrc, > macports or homebrew.

Since SecureTransport is a completely different API there is no easy way to make IO::Socket::SSL use it instead of OpenSSL (via Net::SSLeay). For the foreseeable future IO::Socket::SSL will only support OpenSSL and LibreSSL. I don't think that this is actually that much of a problem: we have the same situation on Windows where users also need to either OpenSSL or just use Strawberry Perl which includes everything already. And Ruby, Python, PHP ... also have their SSL built on top of OpenSSL so this Requirement is not really unusual. And it is actually not that uncommon to expect users to have 3rd-party libraries in order to use specific perl libraries: XML handling usually needs expat or libxml, dealing with graphics often needs ImageMagick, ... - and openssl is just yet another 3rd-party libraries needed to compile a 3rd-party module.

Fri Apr 01 06:51:38 2016 The RT System itself - Status changed from 'new' to 'open'

Fri Apr 01 06:51:55 2016 Steffen_Ullrich [...] genua.de - Status changed from 'open' to 'rejected'

Fri Apr 01 07:13:43 2016 REHSACK [...] cpan.org - Correspondence added

On Fri Apr 01 06:51:35 2016, SULLR wrote: Show quoted text

> Am Fr 01. Apr 2016, 04:43:01, REHSACK schrieb:

> > Regarding to > > http://lists.apple.com/archives/macnetworkprog/2015/Jun/msg00025.html, > > no future version of Xcode will come with OpenSSL headers. > > > > It can't be the recommendation to all users to install pkgsrc, > > macports or homebrew.

> > Since SecureTransport is a completely different API there is no easy > way to make IO::Socket::SSL > use it instead of OpenSSL (via Net::SSLeay). For the foreseeable > future IO::Socket::SSL will only > support OpenSSL and LibreSSL.

The reason of an abstraction layer is to abstract, not to persist on an API. Even if currently no tuits neither resources are available, keep the issue. Show quoted text

> I don't think that this is actually that much of a problem: we have > the same situation on Windows > where users also need to either OpenSSL or just use Strawberry Perl > which includes everything > already. And Ruby, Python, PHP ... also have their SSL built on top of > OpenSSL so this Requirement > is not really unusual.

Because of billions and billions fly's eat shit, it's not unusual to eat shit? I don't tell Net::SSLeay to move away from OpenSSL - I ask a high level abstraction layer to think about opening the mind for different implementations securing sockets. Neither I forced a quick own implementation - I suggest watch for non-OpenSSL libraries. Show quoted text

> And it is actually not that uncommon to expect users to have 3rd-party > libraries in order to > use specific perl libraries: XML handling usually needs expat or > libxml, dealing with graphics > often needs ImageMagick, ... - and openssl is just yet another 3rd- > party libraries needed to > compile a 3rd-party module.

We don't talk about extra functionality, we talk about core OS functionality. While every OS spread around is able to use SSL or TLS, not all of them rely on OpenSSL or LibreSSL. So you compare cars with horses when naming ImageMagick or graphwiz - good example is expat vs. libxml: complete different API's - different distributions to build the Perl-Native-Bridge - XML::SAX abstracts all of them. Similar doing Log::Any.... And API-Wise (not driver-wise), IO::Socket::SSL provides a very high level API for secured communication. Like Log::Any or XML::SAX - not like Git::Wrapper (which naturally won't do fine with clearcase). Cheers

Fri Apr 01 07:13:46 2016 REHSACK [...] cpan.org - Status changed from 'rejected' to 'open'

Fri Apr 01 08:36:24 2016 Steffen_Ullrich [...] genua.de - Correspondence added

Show quoted text

> Because of billions and billions fly's eat shit, it's not unusual to > eat shit? I don't tell Net::SSLeay to move away from OpenSSL - I ask a > high level abstraction layer to think about opening the mind for > different implementations securing sockets. Neither I forced a quick > own implementation - I suggest watch for non-OpenSSL libraries.

While I understand your wish please also consider my situation: - I use part of my time to maintain IO::Socket::SSL - for free. - Adding and supporting another SSL backend would be a major effort. - It is still possible to use IO::Socket::SSL on Mac, it only got slightly harder to compile it yourself. Thus I feel actually not much motivation to do lots of work just to make it a bit more comfortable for others to compile the library themselves. But fortunately this is free software. This means you are not restricted to what I want to support. You can simply take the software and add the features you want yourself.

Fri Apr 01 08:36:26 2016 Steffen_Ullrich [...] genua.de - Status changed from 'open' to 'rejected'

Fri Apr 01 08:52:23 2016 REHSACK [...] cpan.org - Correspondence added

On Fri Apr 01 08:36:24 2016, SULLR wrote: Show quoted text

>

> > Because of billions and billions fly's eat shit, it's not unusual to > > eat shit? I don't tell Net::SSLeay to move away from OpenSSL - I ask a > > high level abstraction layer to think about opening the mind for > > different implementations securing sockets. Neither I forced a quick > > own implementation - I suggest watch for non-OpenSSL libraries.

> > While I understand your wish please also consider my situation: > - I use part of my time to maintain IO::Socket::SSL - for free. > - Adding and supporting another SSL backend would be a major effort. > - It is still possible to use IO::Socket::SSL on Mac, it only got > slightly harder to compile it yourself. > > Thus I feel actually not much motivation to do lots of work just to > make it a bit more comfortable for others to compile the library > themselves. > > But fortunately this is free software. This means you are not > restricted to what I want to support. You can simply take the software > and add the features you want yourself.

And then I have a ticket. I don't open the ticket to force you to do anyting. Just be aware and let other people be aware, too. You act as if I asked for free service - I didn't. You agree, there is an issue. You agree that the issue can be solved by someone - but stated "not by me, at least not in near future". That's fine. Please have a look how many tickets I have open in https://rt.cpan.org/Dist/Display.html?Name=List-MoreUtils or https://rt.cpan.org/Dist/Display.html?Name=Net-Interface. It is one thing to state "Patches welcome" (which means, let the issue open) or state "Patches are not welcome, please fork and please all current users to switch to the fork". I kindly ask you to state "Patches welcome" - neither to apply them blindly nor do the work on your own. Best regards

Fri Apr 01 08:52:24 2016 REHSACK [...] cpan.org - Status changed from 'rejected' to 'open'

Fri Apr 01 09:33:53 2016 Steffen_Ullrich [...] genua.de - Correspondence added

Show quoted text

> I kindly ask you to state "Patches welcome" - neither to apply them > blindly nor do the work on your own.

Sorry for the misunderstanding. Of course I welcome patches which can also be seen when looking at the history of the module at github or the Changes file of the distribution. But so far nobody added a bug without any patch just to ask me if patches would be welcome and therefore I assumed that you asked me to implement the feature myself. If you would help to add such a feature I would recommend to implement the SecureTransport layer as a separate module, similar to what Net::SSLeay does for OpenSSL. If this new module would then offer an API compatible with the parts of Net::SSLeay used by IO::Socket::SSL then it would be easier to integrate with the existing IO::Socket::SSL.

Fri Apr 01 09:34:00 2016 Steffen_Ullrich [...] genua.de - Status changed from 'open' to 'stalled'

Fri Apr 01 09:44:14 2016 REHSACK [...] cpan.org - Correspondence added

On Fri Apr 01 09:33:53 2016, SULLR wrote: Show quoted text

>

> > I kindly ask you to state "Patches welcome" - neither to apply them > > blindly nor do the work on your own.

> > Sorry for the misunderstanding. > Of course I welcome patches which can also be seen when looking at the > history of the > module at github or the Changes file of the distribution. But so far > nobody added a > bug without any patch just to ask me if patches would be welcome and > therefore I assumed > that you asked me to implement the feature myself.

I have more tickets without patch than with patch :( My today's work on CPAN was "updating my developer toolchain to start fixing my issues" - and this particular issue costs me (including research what's wrong) nearly two hours - that's why I insist that much in keep it documented ;) Show quoted text

> If you would help to add such a feature I would recommend to implement > the SecureTransport > layer as a separate module, similar to what Net::SSLeay does for > OpenSSL.

I see what I can do. Maybe this is also a task for a Werkstudent or summer project for a student ... Show quoted text

> If this new module > would then offer an API compatible with the parts of Net::SSLeay used > by IO::Socket::SSL > then it would be easier to integrate with the existing > IO::Socket::SSL.

Will analyze that when I find a tuit ;) Cheers

Fri Apr 01 09:44:14 2016 The RT System itself - Status changed from 'stalled' to 'open'

Fri Apr 01 15:29:49 2016 Steffen_Ullrich [...] genua.de - Severity Critical changed to Wishlist

Fri Apr 01 15:33:55 2016 Steffen_Ullrich [...] genua.de - Status changed from 'open' to 'stalled'

Fri Apr 01 15:34:31 2016 Steffen_Ullrich [...] genua.de - Subject changed from 'OpenSSL stopped working on Darwin, don't rely exclusively on Net::SSLeay' to 'Support SecureTransport on Mac OS X '

Fri Jun 17 04:17:56 2016 Steffen_Ullrich [...] genua.de - Correspondence added

Nobody so far came up with a module supporting SecureTransport which could be used to offer such support in IO::Socket::SSL. Since this wish seems to be more a illusion than realistic it will be rejected. If there will be once a usable Perl interface to SecureTransport and if there is still the wish to provide an IO::Socket::SSL layer to this interface then I'm pretty sure that a new wish will be created.

Fri Jun 17 04:17:57 2016 The RT System itself - Status changed from 'stalled' to 'open'

Fri Jun 17 04:17:57 2016 Steffen_Ullrich [...] genua.de - Status changed from 'open' to 'rejected'

Fri Jun 17 04:35:45 2016 REHSACK [...] cpan.org - Correspondence added

Well, that's finally your decision. Personally (check my distributions) I favor keep those wishes open - maybe someone comes around and fixes it or sponsors it.