The Perl API to ServiceNow stopped supporting TLS 1.0 and 1.1. Are there any quick Perl 5.8 fixes? - perl

I am a perl developer and have been working on a ServiceNow API to create change tickets. It has been working well until this past Friday when ServiceNow depreciated support for TLS 1.0 and 1.1. My version of Perl is 5.8 so it's quite old. Are there any quick Perl 5.8 fixes?
Here are the perl modules I'm using.
use MIME::Base64;
use HTTP::Proxy;
use JSON;
use REST::Client;
the new errors;
Response: 500 SSL negotiation failed:
Response status: 500 Header: Content-Type=text/plain Header: Client-Date=Fri, 10 Jan 2020 23:06:10 GMT Header: Client-Warning=Internal response 500 SSL negotiation failed:

If you have any say in this you should really, really, really, really, really update your Perl. I mean, really. 5.8 is ancient.
If you cannot do that, you must at least update the piece of code that handles the TLS to a version >= 1.2 (Good luck!). Rest::Client uses LWP::UserAgent which in turn uses either Net::SSL or IO::Socket::SSL (I think) for the SSL stuff. If both are present Net::SSL will be used.
So you must investigate which one(s) you have and update one of them. Net::SSL is probably your best bet, since it is just a wrapper around the c library openssl (apt!). The other one probably has a rats tail of dependencies, but I didn't look.

Perl 5.8.0 is from July 2002. Perl 5.8.8 (which is what I suspect you are actually using) is from January 2006. Both of these are ancient versions and I highly recommend not using them.
I realise that you're using a specific version of an operating system (I'd guess RHEL5) and that upgrading your OS is a project that your company aren't going to want to undertake. But this is why we don't use the system installed version of Perl.
You have a few options.
Install another version of Perl alongside the system Perl. Put it in /opt/perl or somewhere like that. Make it a recent version and install a completely new library of modules for it. perlbrew is one nice way to achieve this.
Use a virtual machine or, better, a Docker container to host your API. That can be a newer OS, running a newer version of Perl with a newer version of the system libraries (which you're probably going to need - as your older version of openssl probably doesn't support TLS 1.2).
Stop using legacy hardware to host your project and move it into a cloud provider like AWS.
You either need to be more agile about updating your OS (which very few companies are very good at) or you need to separate your application's runtime environment from the underlying OS. That second route is what switched-on projects have been doing for several years now.

Related

What perl version is required for dancer2?

Godaddy supplies perl 5.8 on the "standard" unix share. Before attempting to use Dancer2 I would like to know if 5.8 will suffice.
Thank you.
A GoDaddy-wise comment: if you are trying to do this on a GoDaddy-hosted server and aren't running a dedicated server, it is doubtful they will upgrade the version of perl installed there on demand.

Perl "lwp-request" giving error 500 using TLS 1.2

We've been using a shipping API via our Unix server, specifically SCO Openserver 5.0.7, for a little over a year.
Our system generates XML files, sends them to the server using the lwp-request command, receives the response, interprets it, and processes it as needed by our system.
The exact command we use is:
lwp-request -m POST https://url.com < REQUESTFILE.XML > RESPONSEFILE.XML
The shipping company is upgrading all servers to require TLS 1.2, and now I get
500 SSL negotiation failed:
as a response when using this command.
I'm not sure how to go about making our system compatible.
Do I need to update Perl? (Current version is v5.8.8 built for i586-pc-sco3.2v5.0). If so, what is the minimum version to use TLS 1.2?
Do I need to update LWP? I believe my LWP version is 5.805 (got this using perl -MLWP -le "print(LWP->VERSION)")
Do I need to go into the lwp-request script and manually modify it?
Or is there perhaps another command that does an equivalent job using TLS 1.2?
Given your very old version of Perl (5.8.8, where 5.8.9 was release 2008) and LWP (5.805, 5.806 was released 2007) on a very old OS (SCO OpenServer 5.0.7, last update around 2009) it is likely that you are also running a very old version of OpenSSL. TLS 1.2 was only specified in 2008 and got available in OpenSSL only with 1.0.1 which was released 03/2012, i.e. several years after any software updates to your system.
You can check it it with openssl version and my guess is that it says something about version 0.9.8, i.e. way too old.
To make TLS 1.2 work on this old system you would need to compile a newer version of OpenSSL (at least the latest 1.0.1) and rebuild the Perl modules interfacing with OpenSSL so that they use this new version. Depending on your setup this might be Crypt::SSLeay or Net::SSLeay. And given how old your system is it is not unlikely that you run in various problems with compiling simply because most don't expect that somebody tries to compile newer software on outdated systems. Thus it might just be easier to upgrade everything to a recent and supported OS instead of trying to fight with an old system.

Does installing Perl modules require a paid license?

I need to work on a Perl script that has some tasks, like reading/writing Excel sheets, connection to an Oracle database, etc.
First I used ActivePerl. On installing modules, ActivePerl threw an error:
Authorization required 401
(I.e., it requires a business licence for adding modules.)
Then I tried the same with Strawberry Perl, but I still could not install.
What I have tried:
CPAN
ppm
Download a module and install using it nmake
Install modules using the Padre Perl IDE.
Is this a license issue? Or am I missing something here? Is Perl a free distribution for development?
The image shows installing DBD::Oracle on Strawberry Perl v5.22.0:
It looks like you are using Strawberry Perl. That requires no license or other special steps to use. It's ready to go.
One of the top lines of output in your picture is "Can't connect to cpan.strawberryperl.com:80". It then tries to connect to other sites and has the same failure. It looks like a network issue.
The community edition of ActivePerl provides support to only the latest versions of Perl, and access to the packages ActiveState built for older versions is available in Business and Enterprise edition.
If you install Perl 5.18.4, 5.20.2 or 5.22.0 then you'll not get a 401 error.
Alternate solution: Use CPAN instead of ppm to install Perl modules.
See more at: Download and Install Perl: ActivePerl
ActiveState is a commercial company. They release a community edition, but they make money from support. Part of that means they only offer "free" the newest versions. Which is why you get the error you do - upgrade to a newer Perl, and they'll let you update.
More broadly - technically each module can be licensed separately. There's no requirement to release Perl code (including modules) under any sort of FLOSS license.
However, bear in mind that the ActiveState community edition isn't the same license as CPAN modules would be. CPAN modules are "Mostly GNU". But ActiveState CE has some additional terms.
For example,
The use of the Software is unsupported and is for non-commercial or non-production use.
You should make a point of reviewing licenses, because it really is a bit of a minefield if you're not careful.

Where do I get the MQ DLLs I need for Perl's MQClient::* and MQSeries:: modules?

I need to rejig some VERY old Windows code that uses Perl to talk to MQ. Specifically, I need to be able to install Perl's MQClient::MQSeries, MQSeries::QueueManager, MQSeries::Queue and MQSeries::Message modules.
When I fire up Strawberry Perl, go into CPAN and try to install them, I can see that there's several MQ client DLLs that are required for these Perl modules to build. However, they're not on my system, even after downloading and installing the current MQ Client from IBM.
It used to be that downloading and installing the MQ Client from IBM gave you the option to install a whole bunch of development libraries (presumably including the bits necessary to install the above Perl libraries), but it seems that's no longer the case. For example, there's no MQM.DLL file anywhere, which is one file that the Perl libraries seem to need to build correctly.
Suspect I've probably just not installed the correct MQ Client package to get this stuff, but have no idea where to find it (Google is no help). Any suggestions?
MQSeries 1.29 was released in 16 Jun 2009, so I guess you can just ask it's maintainer.
You can also ask in newsgroup news://news.software.ibm.com/ibm.software.websphere.mq , or ask IBM's support.
where'dja get the MQ download?
maybe you might try mqseries.net - it's a hotbed of MQ activity.
I'd suggest downloading the WMQ Client installation. Depending on which one you want, v7.0 is SupportPac MQC7 and v7.1 is SupportPac MQC71. This will get you the client libraries with which to build the Per module. If you need the server libs, the Evaluation download of WMQ Server v7.1 is here:

Which versions of Perl are you using?

According to the Perl source code page on CPAN, 5.8.9 is now 14 days old, and will be the last 5.8 release. 5.10.0 is over a year old and presumably ready for use in Production.
Leaving aside discussion of Perl 6 for now, can I ask what versions of Perl folks are testing, rolling out and using in production? We have currently standardized on 5.8.8 on our Ubuntu (workstation) and Solaris (production) platforms, and I'm wondering about the pros and cons of making small step to 5.8.9 or a larger one to 5.10.0.
According to the Perl Survey, performed over a year ago now predating 5.10, as their minimum version of Perl people are using...
4.x 3%
5.0.x 3%
5.4.x 2%
5.5.x 6%
5.6.x 17%
5.8.x 66%
and the maximum is...
5.6.x 3%
5.8.x 88%
5.9.x 5%
5.6.1 and 5.8.8 are most popular within their major group. The missing percentages are miscellaneous versions.
Since the survey didn't define what "using" means, ie. if you're actually running production code on it or if you just test your software against it for backwards compatibility, or you just have it around for kicks, the minimum can be taken with a grain of salt.
This data, and the general lack of feedback from users, lead me to drop support for 5.5.x from the module installation toolchain modules I maintain (MakeMaker and Test::More) effectively end-of-lifing 5.5.x. 5.6 has had a stay of execution, but is still on death row.
I personally only recently switched from 5.8.8 to 5.10.0. I know of places still using 5.6.1 in legacy apps, but they've moved to 5.8.8 for as much as possible and all new dev. I don't know of anyone still using 5.5 in production. For backwards compatibility I test against 5.6.2, 5.8.8 and 5.10.0. The numbers say I should be testing 5.6.1 instead of 5.6.2 but there's only so far I can be arsed by folks who won't even upgrade to the latest bugfix release in their line.
Perl 5.8.8 is (and will be until at least 5.10.1) our production environment. The performance regressions in 5.10.0 (regarding #_ assignment in sub's for example) make it impossible for us in production.
But we run our test suites with both 5.8.8 and 5.10.0 to prepare our move to 5.10.x in the future. I'm trying to have a system that will compile the bleadperl and run our test suites with that also...
I use Perl 5.10.0 in development and 5.8.8 in production and code is tested for compatibility. But I haven't seen so many internal Perl bugs than in Perl version 5.10.0 It's really terrible. I have reported three easily reproducible assert violations and core dumping ones and still cope with some strange hard to reproduce bugs which causes core dumps, memory leaks and so.
Primary development 5.10, QA and production 5.8.8 .
I use primarily Perl 5.10.0. I test backwards compatibility on 5.6.1 and 5.8.8. I do still have a Perl 5.5.3 which I occasionally use. (I still have the source for 5.4.4 - or 5.004_04 as it was then termed; it is not currently built and I can think of few reasons why I'd need to do so.)
Thanks for the information about 5.8.9. I'll have to get that.
I just started using 5.10.0 a few weeks ago, but I keep testing my modules on 5.8. When I upload something on CPAN I will put an effort in making it 5.6 compatible if possible.
We're using v5.6.1 in our production server. I guess we're old school. :P
Unless there's a specific features that you need, I think just upgrading might require plenty of testing on all related components.
So that only answers your first question. For the second one, you might want to research on what's the new features in the newer version.
You might also like my answer to How do YOU manage Perl modules on Linux?. I install several versions of Perl and test against many of them.
5.8.8 on FreeBSD for production and development. We're preparing to roll out a VM/jail to test 5.10 in (to verify compatibility for the future).
I use Perl 5.10, mainly because I can hardly wait until Perl6 implementations, are more complete