On Dec 26, 2012, at 12:37 PM, Alex Vandiver <alexmv@bestpractical.com> wrote: > Heya all, > This is a notice that cPanel has apparently begun shipping a fork of > Storable.pm which reports to be version "2.39_01", and which by default > does not bless objects during deserialization. This, unsurprisingly, > breaks any number of things; we've begun getting bug reports[1] from > administrators of RT whose installs have mysteriously been broken by > cPanel upgrading their perl install. > Core perl chose to document the issue[2] and release 2.40, but cPanel > seems to have decided to release their own fork of Storable into the > wild[3], under the same name, which breaks backwards compatibility. The > cPanel fork looks to actually be an extensive set of patches atop > version 2.25 (or thereabouts) of Storable, and thus does not contain a > number of changes included in the CPAN/core release of 2.40 -- but the > "2.39_01" release is the first to obviously break compatibility with the > canonical version. > - Alex Alex, Yes we have realized this was a problem and have taken steps to change the default behavior to be compatible with upstream in our upcoming major release (11.36) of cPanel, tentatively in January. 2.39_01 is actually 2.25 with patches from cPanel. We had to bump the version above the CPAN version to force the upgrade to work correctly. The _01 was meant to clarify that it was not the Storable version from CPAN. The work around is to set $Storable::flags = 6 (in their script not the perl module) and it will revert the default behavior. If they change this globally in Storable.pm, cPanel will become insecure, so this is not recommended. It sounds like the people reporting these issues are cPanel customers. I would encourage them to open a ticket with cPanel if they need help. I'm sorry for the RT noise and possibly wasted research. If you will give me a list offline of the CPAN RT tickets, I'll be happy to reply with my 2 cents. ToddThread Previous | Thread Next