Security Update 2009-001 (Server Leopard) 'killed' perl

Because of these kind of problems, I stopped recommending Apple Servers to my enterprise customers.
God forbid if you are using AD integration.

Thanks for your help, Pterobyte.

With all due respect, "God forbid" one should apply an update to a production server without vetting that update on a testing server, let alone having a full & known-good backup prior to applying any update, before the very necessary step of carefully inspecting the content(s) of said update prior to applying it.

This is a server we are talking about, and due diligence is called for as a matter of best-practices,
regardless of what platform - hardware and software - is in use.

You can use pkgutil

man pkgutil

or the Flat Packager Editor that comes with the free Developer tools, or Pacifist, to readily determined the contents of any update.

So we see that there's a significant amount of Perl material. Also some actions pertaining to clamav and postfix, which personally I'd take a good look at prior to proceeding. The postfix script seems innocuous enough, whereas UpgradeClamAV is a compiled binary. Running "strings" on it makes it look as though it makes changes to the (Apple-supplied, default) clamav config file, so that'd be another key point.

Etc.

This procedure got my perl scripts running again. Thanks.

I work on perl at Apple, and would like to take the opportunity to apologize for the unforeseen problems that the 2009-001 security update has caused. As others have explained, the root cause of the problem is how perl has historically (and on all platforms) ordered its module directory search path. The system perl directory (on Mac OS X, /System/Library/Perl/5.8.8) comes before the site-specific ones (e.g., /Library/Perl/5.8.8). This means that if you try to update a module in the system perl directory by installing it in a site-specific directory like you normally would any other perl module, the search path order would result in the old module being found first. So, the only way to do this kind of update is to directly overwrite the module in the system perl directory. The cpan command has an option (INSTALLDIRS=perl) specifically for this purpose.

Apple has always reserved the right to modify files in /System for software and security updates. Most users do stay away from /System, but using the cpan command to install a third party module can indirectly cause system perl modules to be updated. The system perl modules that have both a perl side (a .pm file) and a binary side (a .bundle file) are the ones that might be affected by 2009-001. In this case, 2009-001 installed many original version .bundle files with security fixes, but not their corresponding .pm files (since they weren't modified). So when the newer version .pm file tries to load an older version .bundle file from 2009-001, it fails.

At the present, the only fix is to reinstall the affected module(s). We are working hard on a solution that should rectify this issue, and we will make this available in a future update.

And I'll add this: since it's proven (Apple says so itself, right?) that Security Update 2009-001 wreaked havoc on a lot of machines in the Perl department, isn't it conceivable that maybe it did the same for other applications and/or pieces of hardware...?

See this: http://discussions.apple.com/thread.jspa?threadID=1914325&tstart=0

So-oo...?

Hi all, does anyone know if this affects perl on non-Server Leopard please? Also, (off-topic but you are probably the best guys to ask) is there a good way to get a list of the modules I have installed using CPAN please?

Aha - there's a doc called perllocal.pod, seems to have the information regarding my 2nd (off-topic) question. 1st questions was - is non-Server Leopard affected too? TIA -Terry.

Yes, I've found one more thing that was broken by 2009-001 and that's Fink. Fink needs a few Perl-modules to work and some of them were affected (at least on my system).

I ended up needing to replace:
DB_File
threads
threads::shared
Storeable
Digest

in order to get Fink working again (if cpan thinks that they are up to date, force the install).

But how to set these INSTALLDIRS=perl?
I'm clueless. Did the mentioned steps to install IO 'by hand', and after that reinstalled a lot of other modules via CPAN.
Still get
IO object version 1.22 does not match bootstrap parameter 1.23 at /System/Library/Perl/5.8.8/darwin-thread-multi-2level/XSLoader.pm line 94.

So I'm pretty sure my problem exists because of these INSTALLDIRS=perl.
have 13000 mails in que (most of it spam of course) since yesterday.. (self updated amavis and spamassassin).

Thanks!

Ok, I understand now how to use INSTALLDIRS-perl, just append it to the perl Makefile.PL line:
perl Makefil.PL INSTALLDIRS-perl

For some reason i still get the same bootstrap error. Even though the modules are up to date now. In CPAN:
Time::HiRes is up to date (1.9719).
IO is up to date (1.23).

But when I run "/usr/bin/amavisd -V" i get:
fetch_modules: error loading required module Time/HiRes.pm:
Time::HiRes object version 1.86 does not match $Time::HiRes::XS_VERSION 1.9715 at /System/Library/Perl/5.8.8/darwin-thread-multi-2level/DynaLoader.pm line 253.
Compilation failed in require at /usr/bin/amavisd line 195.
fetch_modules: error loading required module IO/Handle.pm:
IO object version 1.22 does not match bootstrap parameter 1.23 at /System/Library/Perl/5.8.8/darwin-thread-multi-2level/XSLoader.pm line 94.

Would be great if anybody has a tip, mail queue is now 17000..
Thanks!


Full output:
# /usr/bin/amavisd -V
fetch_modules: error loading required module Time/HiRes.pm:
Time::HiRes object version 1.86 does not match $Time::HiRes::XS_VERSION 1.9715 at /System/Library/Perl/5.8.8/darwin-thread-multi-2level/DynaLoader.pm line 253.
Compilation failed in require at /usr/bin/amavisd line 195.
fetch_modules: error loading required module IO/Handle.pm:
IO object version 1.22 does not match bootstrap parameter 1.23 at /System/Library/Perl/5.8.8/darwin-thread-multi-2level/XSLoader.pm line 94.
Compilation failed in require at /System/Library/Perl/5.8.8/darwin-thread-multi-2level/IO/Handle.pm line 263.
BEGIN failed--compilation aborted at /System/Library/Perl/5.8.8/darwin-thread-multi-2level/IO/Handle.pm line 263.
Compilation failed in require at /usr/bin/amavisd line 195.
fetch_modules: error loading required module Compress/Zlib.pm:
Bareword "IO::Handle::SEEK_SET" not allowed while "strict subs" in use at /System/Library/Perl/5.8.8/IO/Compress/Base.pm line 845.
Bareword "IO::Handle::SEEK_CUR" not allowed while "strict subs" in use at /System/Library/Perl/5.8.8/IO/Compress/Base.pm line 845.
Bareword "IO::Handle::SEEK_END" not allowed while "strict subs" in use at /System/Library/Perl/5.8.8/IO/Compress/Base.pm line 845.
Compilation failed in require at /System/Library/Perl/5.8.8/IO/Compress/RawDeflate.pm line 10.
BEGIN failed--compilation aborted at /System/Library/Perl/5.8.8/IO/Compress/RawDeflate.pm line 10.
Compilation failed in require at /System/Library/Perl/5.8.8/IO/Compress/Gzip.pm line 11.
BEGIN failed--compilation aborted at /System/Library/Perl/5.8.8/IO/Compress/Gzip.pm line 11.
Compilation failed in require at /System/Library/Perl/5.8.8/Compress/Zlib.pm line 13.
BEGIN failed--compilation aborted at /System/Library/Perl/5.8.8/Compress/Zlib.pm line 13.
Compilation failed in require at /usr/bin/amavisd line 195.
fetch_modules: error loading required module MIME/Entity.pm:
IO::Seekable::getpos missing at /System/Library/Perl/5.8.8/FileHandle.pm line 59.
Compilation failed in require at /System/Library/Perl/5.8.8/MIME/Decoder.pm line 89.
BEGIN failed--compilation aborted at /System/Library/Perl/5.8.8/MIME/Decoder.pm line 89.
Compilation failed in require at /System/Library/Perl/5.8.8/MIME/Entity.pm line 236.
BEGIN failed--compilation aborted at /System/Library/Perl/5.8.8/MIME/Entity.pm line 236.
Compilation failed in require at /usr/bin/amavisd line 195.
ERROR: MISSING REQUIRED BASIC MODULES:
Time::HiRes
IO::Handle
Compress::Zlib
MIME::Entity
BEGIN failed--compilation aborted at /usr/bin/amavisd line 234.

Ok, problem was that after the buggy security update was done, somebody applied a newer xcode. Because of this perl 5.8.9 was installed which didn't help much. After deleting /opt/local/bin/perl and creating an alias called perl that linkes to /usr/bin/perl we where back to perl 5.8.8.
Then all above did help!

Thanks!

Edward

Will the forthcoming 10.5.7 patch fix this issue? Im an ADC member and I have noticed comments in the recent Leopard builds regarding Perl, but I dont want to speculate. For the most part I have avoided this problem with my Mac Perl users by keeping the 2009 001 Security updated disabled on my SUS server, but a couple laptop users have installed it by accident and are now experiencing the Perl issues described in this discussion. Any word on an official fix by Apple? Its been a few months since this issue first cropped up.

Paul Derby wrote:
You can add the Logitech Squeezeserver to the list. Installing this security update kills Squeezeserver, too.

I spoke with Logitech about this and they propose a clean install of SqueezeCenter - it worked for me.

From Logitech:
1. First, go to System Preferences, click on SqueezeCenter and click on "Stop Server", close System Preferences.

2. Remove any of the following files and folders:
- Home > Library > Application Support > SqueezeCenter Folder
- Home > Library > PreferencePanes > SqueezeCenter.prefPane
- Home > Library > Caches > SqueezeCenter folder
- Macintosh HD > Library > PreferencePanes > SqueezeCenter.prefPane (may or may not exist)

3. Reinstall SqueezeCenter from: http://www.slimdevices.com/su_downloads.html

I can confirm that Slim/SqueezeServer dies for me in BEGIN as a result of this, umm, "improvement" by Apple.

For me, I tried after:
* IO (by hand)
* Scalar-List-Utils (by hand)
* Time::Hires
* Compress::Zlib
* Scalar::Util

and was successful. Scalar::Util through CPAN was probably redundant, but I was sick of dealing with this.