Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw

Re: Installation of Storable 3.11 fails due to antivirus removing test data

by davido (Cardinal)
on Jan 28, 2019 at 22:49 UTC ( #1229098=note: print w/replies, xml ) Need Help??

in reply to Installation of Storable 3.11 fails due to antivirus removing test data

An issue with the use of tmp files during testing came up a week or so ago here, and it may be that a solution in that thread is going to be similar to the solution you will have to employ:

t/CVE-2015-1592.t uses File::Temp to create a temporary directory. Typically this will be in /tmp for linux, or wherever Windows thinks temp directories should go. File::Temp uses File::Spec's tmpdir function to tell it where to put tempfiles and tempdirs. On Windows, File::Spec gets that information from File::Spec::Win32, which has the following semantics:

=item tmpdir Returns a string representation of the first existing directory from the following list: $ENV{TMPDIR} $ENV{TEMP} $ENV{TMP} SYS:/temp C:\system\temp C:/temp /tmp /

In other words, you can set $ENV{TMPDIR} or one of several other environment variables to influence where the temporary directory will be created. By default it will be in SYS:/temp, or C:\system\temp, or C:/temp, or /tmp, or /, in that order. But you could specify an alternate location before running the tests. It's been years since I used Windows in any meaningful way, but Google seems to find for me that set or setx can be used to set the appropriate environment variable. I've found under Linux it's useful to create a ~/tmp/ for times when the systemwide /tmp is not appropriate. For example, on my centos7 box /tmp is mounted without executable set, so tests that must execute something in /tmp will fail (local::lib, for example) unless I hint the system to use a different temp directory with less restrictive execution privileges.


Replies are listed 'Best First'.
Re^2: Installation of Storable 3.11 fails due to antivirus removing test data
by Lotus1 (Priest) on Jan 29, 2019 at 03:47 UTC

    Before I posted I suspected the temp file so I tested it. I modified the test file to print the temp file location to STDERR and turned off the CLEANUP option in tempdir(CLEANUP => 1). I then ran the install again and found the 'sploit' file in the temp folder. That wasn't the problem.

    The file "t/" is one of the files included with the module in the test folder. It is being deleted by the Antivirus scanner as soon as it is copied to the hard drive. When "t/CVE-2015-1592.t" runs it attempts to run the inc file with Perl (actually $^X) but it isn't there so Perl complains with the "Can't open Perl script [...]" I posted in the OP. Normally, the test runs the inc file, which contains the exploit code, and outputs the result to sploit. It then checks the contents of the sploit file for the warning that Storable is supposed to produce when it detects the exploit.

      The file "t/" is one of the files included with the module in the test folder. It is being deleted by the Antivirus scanner as soon as it is copied to the hard drive

      Your AV software is committed to sabotaging the test.
      If you want to install version 3.11, I can see only 2 options - either you disable the AV software, or you force install Storable-3.11.
      I guess a third option is to modify t/CVE-2015-1592.t to be skipped if t/ is missing.

      The version of Storable that ships with current blead is 3.14 and, although it contains a test file named t/CVE-2015-1592.t, there's no sign of
      Perhaps its removing of is in response to the very problem you are experiencing.

      I don't know why Storable-3.14 is not available separately.

      I guess another option is to grab that source from blead source (it's in the 'dist' directory) and see how it goes - or even update your perl to the latest devel vesion of 5.29.7.
      Perl-5.29.7 is proving to be very serviceable for me on Windows 7. It's just a matter of whether you're prepared to build it and use it.


        Rob, Thanks for the suggestions. The force install seems like my best option for this.

        To confirm what you suspected about the Metasploit code being removed from the test suite I found the following on Github in the Perldelta notes for Storable:

        =item * L<Storable> has been upgraded from version 3.13 to 3.14. Storable no longer probes for recursion limits at build time. [perl #133708] and others. Metasploit exploit code was included to test for CVE-2015-1992 detection, this caused anti-virus detections on at least one AV suite. The exploit code has been removed and replaced with a simple functional test. [perl #133706]

        I agree with this. Disable your antivirus software (which you probably cannot do), or file a report with IT suggesting their AV software is preventing you from getting your job done, or install with --force (or whatever the option is called for your cpan installer). Force install allows for installation even if the tests fail. You know the tests will fail, but assume that things are probably ok anyway.

        The other alternative is to download and extract the tarball, then make, make test, verify that the only failure is the one you believe you can live with, and then make install.


Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1229098]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others making s'mores by the fire in the courtyard of the Monastery: (2)
As of 2019-05-26 08:21 GMT
Find Nodes?
    Voting Booth?
    Do you enjoy 3D movies?

    Results (153 votes). Check out past polls.

    • (Sep 10, 2018 at 22:53 UTC) Welcome new users!