cybler has asked for the wisdom of the Perl Monks concerning the following question:

Hi, I've been given the responsibility to rebuild a web server for an application we use. I'm using RHEL 3.0 for the OS and for now, I've taken the default installed Perl, v5.8.0.

Our application relies on some perl modules that are not looking compatible to v5.8, eperl imparticular. The current server runs fine with 5.005_03.

So my question, is version 5.005_03 still safe to use? If so, I'd just rather remove 5.8 and install 5.005_03. We don't need any functionality that 5.8 may offer as the app is no longer being updated, just bug fixed.

Also, if I may, following are the modules we use for our app. If anyone sees problems with any of these and the versions I'm using, please point that out too. Some of the names may not be quite right, these are what I was told we use.

Thank You!
Perl 5.005_03 Digest.MD5 2.16 MIME-Base64 2.12 URI 1.17 Net-FTP-Common 2.28 HTML-Parser 3.28 HTML-Tagset 3.03 libwww-perl 5.69 Net_SSLEAY 1.07 CGI 2.56 eperl 2.2.14 Java JDK 1.18 IO-Socket 0.8 KRB5 1.1 libnet 0.10.11 Net::FTP ? - is this the same as net-ftp-common? Perl_LDAP 0.2401 - not sure if this is a perl module
Thanks!

Edited by Chady -- fixed formatting.

Replies are listed 'Best First'.
Re: Is 5.005_03 still safe?
by RMGir (Prior) on Mar 09, 2004 at 18:45 UTC
Re: Is 5.005_03 still safe?
by Corion (Patriarch) on Mar 09, 2004 at 20:33 UTC

    One warning - don't remove/change the system/vendor Perl, but install "your" Perl besides it. Many system utilities rely on a specific version of Perl and specific versions of Perl modules installed and an unexpected downgrade will make the whole system instable.

    If you don't want to change your applications, you can either run them in a chroot environment or just change the hashbang line at the top of the executables to point to "your" version of Perl, which could be named /usr/bin/perl5005 or something similar.

Re: Is 5.005_03 still safe?
by arden (Curate) on Mar 09, 2004 at 18:23 UTC
    cybler, 5.005_03 should still be safe to use. In your place, I'd continue to use it. If you want/need any examples of others still using it, the United States Air Force still includes Perl 5.005 and uses it for login scripts on its Global Command and Control Systems.

    - - arden.
    If it ain't broke, don't fix it

Re: Is 5.005_03 still safe?
by cybler (Acolyte) on Mar 09, 2004 at 19:39 UTC
    Thanks for your replies.

    As far as safe, I mean could it be used for a DOS attack, like RMGir suggested? Will it provide a weakness to hackers to access the server? Could it cause the server to crash?

    It looks like so far thought there isn't anything major. The only information we hash, I think, is info from our own database. I guess bad info could get in there though. I'll keep a close eye on this issue through our development.

    Thanks again!

Re: Is 5.005_03 still safe?
by bageler (Hermit) on Mar 09, 2004 at 20:06 UTC
    my company uses 5.005_03 for everything still. works great, except for all those missing features in 5.8 :-/
Re: Is 5.005_03 still safe?
by etcshadow (Priest) on Mar 10, 2004 at 01:58 UTC
    Yeah, there is a lot of stuff out there still runs on 5.005_03. I work on a large application under active development that still runs under perl 5.005_03 (although we are planning to upgrade perl this year). To quote one of my sysadmins, "for many years, Redhat 6.2 essentially was Linux," and 5.005_03 was the perl that came with RH6.2.

    However, there are certainly "unsafe" things about perl 5.005_03, for example, it's non-reentrant signal handling.

    ------------ :Wq Not an editor command: Wq
Re: Is 5.005_03 still safe?
by Juerd (Abbot) on Mar 09, 2004 at 18:31 UTC

    It depends on your definition of "safe". Please elaborate.

    Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

Re: Is 5.005_03 still safe?
by tomhukins (Curate) on Mar 11, 2004 at 10:23 UTC
    In addition to others' suggestions (such as not replacing the vendor's version of Perl), you might like to consider 5.005_04 instead of 5.005_03. These versions differ only slightly: 04 compiles on a wider range of platforms with a wider range of compilers; 03 has problems building with newer versions of GCC and BDBM.