Is my Community/Business/Enterprise Edition version of ActivePerl vulnerable to HeartBleed?
ActivePerl Community/Business Editions which, as shipped, are affected:
- 220.127.116.115 - upgrade to 18.104.22.1686 (Business Edition only) or 22.214.171.1244 to fix
- 126.96.36.1993 - upgrade to 188.8.131.524 to fix
- 184.108.40.2060 - upgrade to 220.127.116.112 to fix
- 18.104.22.1681 - upgrade to 22.214.171.1242 to fix
Modules supplied through PPM are unaffected.
Modules compiled locally must be reviewed locally for vulnerability.
Enterprise Editions can be distinguished from Community/Business Editions by the presence of an additional fifth number before the six digit build number/version control number.
ActivePerl Enterprise Editions which, as shipped, are affected:
- 126.96.36.1999.9 through 829.12
- 188.8.131.529.9 through 1009.12
- 184.108.40.2066.2 through 1206.5
- 220.127.116.114.2 through 1405.3
- 18.104.22.1682.2 through 1603.3
New Enterprise releases have been issued and can be located under the 2014Q1.1 folder.
PPM gives me a 401 Authorization Required. Why?
UPDATE (Oct 2016): This FAQ was originally posted in 2010. If you are running a version of ActivePerl that gets a 401 error when it contacts a Business Edition Only repository, our advice has evolved. Now, you should replace that ActivePerl.
A "401" error when contacting PPM should now be treated as a indication of obsolesence.
Later versions of ActivePerl that fully support Business Edition Licences have a more informative error message instead of the basic "401". Old ActivePerls that can only report a "401" will not support a Business Edition licence if one is installed. An ActivePerl that reports a "401" from PPM is probably not compatible with your current operating system either.
The repository you are accessing contains exclusively Business Edition content. If you do not have a Business Edition license installed on the system, the PPM server will advise that you are not permitted to access the directory.
Perl versions move into Business Edition when the Perl Community is no longer actively supporting that version of Perl. ActiveState policy for PPM is that free and open access to PPM binary modules for versions that have moved entirely into Business Edition will continue for *at least* six months beyond the date at which the no Community Edition versions of that Perl are available.
All versions of Perl 5.8 and 5.10 required Business Edition licensing in 2010. ActivePerl 5.8 builds older than build 829, and ActivePerl 5.10 builds older than 1008 must use the manual download process described in this FAQ:
All versions of Perl 5.12 required Business Edition licenses as of September 2012. All ActivePerl 5.12 builds can use the normal PPM client with a Business Edition license installed, or the manual download process.
ActivePerl 5.14 requires a Business Edition license as of October 2013 for access to installers. PPM access for modules other than the installers remains free as of December 2013.
What is ActiveState's Support Policy for Community Editions?
The two most recent stable releases are available for free download. This corresponds to the Perl Community's own version support policy.
Whenever the underlying Perl version becomes unsupported by the Perl community itself, support for the corresponding ActivePerl versions will be limited to Business Edition and Enterprise Edition customers.
You can continue to use older ActivePerl releases indefinitely under the terms of the Community Edition license, but won't be able to download the installers from ActiveState.
The PPM repositories for unsupported ActivePerl releases will remain freely accessible for at least 6 months after support ends, but will no longer be updated with new builds from CPAN.
Are ActivePerl releases affected by CVE-2015-1793?
No ActivePerl releases, in any product line, are affected by CVE-2015-1793.
When I run the installer, it reports that several files are corrupted. I see this error:
This installer package does not have the expected content. Please try to download a fresh copy of ActivePerl from ActiveState's website at activestate.com. If you still have problems please contact us at SupportEmail.
How do I fix this?
Trash this folder. Download a fresh copy, and do not open the Download with the Linux Archive Manager.
Archive Managers use an incompatible algorithm.
Go to a Terminal Window, and extract the file on the command line, using GNUtar instead:
Where can I get past versions of ActivePerl? Is there a ftp server for ActivePerl?
Recent past versions of ActiveState Community Edition products, and some other download resources like checksums and alternate installers, are available from our downloads repository via the web at:
Version of ActiveState Products which have aged out of Community Edition are still available, but now require a Business Edition license. If you have a Business Edition license, the products to which your license applies become available from your "My Account" page on our site.
There is no ftp server.
We have read the Security alert for CVE-2012-5377, and would like more information.
This is not a new issue, and it's not really an ActivePerl issue. This vulnerability is a member of a class of vulnerabilities that apply to any software which needs to have a user-writable directory on $PATH. It has been a security concern on Windows for as long as software has been avoiding dll conflicts by using custom library paths.
It is already possible to mitigate the vulnerability by choosing to override the default install path and install to one of the various protected program files silos that newer versions of Windows offer. We don't do this as the default because ActivePerl has a long legacy of scripts and modules which do not handle spaces in the pathname.
It is also possible to migate the vulnerability on an inplace install. This powershell script will copy the permissions to the Perl directory (replace with your directory name, as installed):
powershell -command "(Get-Item 'C:\Program Files').GetAccessControl('Access') | set-acl 'C:\Perl'"
Be advised that protecting Perl from this vulnerability *will* result in reduced functionality. With altered acls, PPM will be unable to manage modules unless it is run with elevated priviledges.
Powershell is included in Windows 7. With older versions, you may be able to download.
ActivePerl isn't working on OS X. Why?
-Are you still getting the system version of Perl instead of ActivePerl?
You likely have not finished the installation. Read the Configuration step in the Installation Guide, which explains how to set $PATH so that ActivePerl is found ahead of the system version.
If you don't put ActivePerl on $PATH, then you must access ActivePerl and ppm using the full directory path, /usr/local/ActivePerl-5.16/bin/perl (or equivalent for other releases).
-I set $PATH yesterday, and I'm sure I had ActivePerl working, but today it's not working.
Changes to $PATH are volatile. You have to make the changes permanent by setting up your $PATH in your .profile shell configuration file.
-I can't do that. I don't have a .profile in my home directory.
No you don't. Apple designed OS X to use GUI interfaces, and they didn't think a config file for the command line shell would be necessary. You have to manually replicate what every other flavor of Unix does; copy /etc/profile to .profile in your home directory, and make changes to your personal copy.
-I did that, but it still isn't working.
You have to restart your shell before changes to .profile get read.
-Ok, I did all that, and Perl is working every time, but PPM won't add or remove modules.
You are a normal user. ActivePerl is installed into a directory which normal users can't write. PPM needs to be run through "sudo ppm" to give it the elevated privilege to manage modules.
-Huh? I wanted to replace the Apple Perl with ActivePerl. This process doesn't do that. How can I force ActivePerl to replace the Apple version?
Don't. Some of your system tools, and quite a few other vendor products expect to find a specific version of Perl in a specific place on a specific version of OS X. Replacing the Apple Perl will break things, and it is difficult to put things back without re-installing your operating system. Apple Perl will co-exist happily with ActivePerl if the defaults in the ActivePerl installer are used. Both versions will still be usable if you supply full paths to the command.
-Can't I just edit the system default /etc/profile to put ActivePerl on $PATH first? Won't that make it the default Perl?
Yes, it will, and so will creating symbolic links in system directories that are already high on the $PATH. Either of these approaches might still break third party software and system tools if they don't use hard-coded paths to the Apple Perl. On the positive side, making ActivePerl the default Perl in one of these ways is very simple to back out if for some reason things go pear shaped.
-I did everything above, but all I get is weird crashes when I run ActivePerl.
Do you have PERL5LIB set to point at the Apple Perl? Using PERL5LIB can force Perl to load libraries which contain incompatible binaries.
-I've got PPM working, but the module I want isn't available. I tried to build it locally from the CPAN source code, but I just can't seem to set the right compiler options.
ActivePerl binaries are multi-platform. Some releases were PPC/x86, and newer releases are x86/x86_64. When you compile a module locally, the compiler will only build a single architecture binary, and no matter which platform you are on, it won't match the dual architecture of the ActivePerl binaries unless you use the Apple SDK to convert what you build to match. Using the Apple SDK is a topic outside the scope of ActivePerl support.
I have a server without internet access, and I need to download and manually install modules.
***Manual Downloads of PPMX files now require a Business Edition license.***
Go to the PPM index page for the module you want, for example, for DBD-MySQL go to:
Select the version of Perl you need a module for, by platform and by Perl major revision number.
If the module has built successfully, you will see a green circle with a check mark. If if has not built, the circle will be red with an exclamation mark.
You can expand green circle or red circle links. The drill-down page will show you links to the build logs for each version of the modules the system has attempted to build. If the circle was green, and a version of the module sucessfully built, there will be a "ppmx" link on the right side for each successful build.
Clicking the ppmx link will open a screen which prompts for a username and password. To proceed past this point, you must have a Business Edition license.
The USERID and PASSWORD are *not* the same as the userID and password you use for posting to this forum, or accessing the rest of the ActiveState site. For Business Edition manual downloads, you must find these values in your Business Edition license file. To find your license file:
Scan the license file for the line which shows "|ActivePerl BE|".
Immediately following that field will be another field which starts with "|APIPassword#". The value after that tag is your PASSWORD for Business Edition manual downloads.
Further along in the same line is another field which starts with "|SerialNo#". The value after that tag is your USERID for Business Edition manual downloads.
If your license is Active and you are an End User linked to the Serial Number, you may also query your My Account page for the API password value.
Once you have the PPMX files downloaded, installing a module from PPMX files is documented here:
When I try to install ActivePerl on Windows, it says it is not supported by my processor type. My system meets the ActiveState requirements. Why is it not recognized?
This message isn't an ActiveState error message. It comes from within the Microsoft Installation tool, and it's rather misleading. The processor isn't in fact the problem.
What the message really indicates is that you are attempting to install a 64-bit binary on a 32-bit version of Windows. This won't work. A 64-bit processor will run either 32-bit or 64-bit Windows, but MSI installers for 64-bit software will only install on 64-bit Windows.
Most users solve this by using the 32-bit x86 ActivePerl installer with a 32-bit Windows, however in cases where a full 64-bit x86_64 ActivePerl is necessary there is no alternative except to first upgrade to a 64-bit version of Windows.