Opened 5 years ago

Closed 5 years ago

#57979 closed defect (wontfix)

perl 5.28 triggers malware filter, kills build

Reported by: darynwhite (Daryn White) Owned by: mojca (Mojca Miklavec)
Priority: Normal Milestone:
Component: ports Version:
Keywords: Cc: dbevans (David B. Evans)
Port: perl5.28 perl5

Description

As also documented here: https://github.com/perlorg/perlweb/issues/280

I realize that the codebase is outside of the control of the maintainers of the port.

The issue is that the port upgrade outdated fails due to this problem. McAfee removes the suspect file when it extracts and, for me at least, there is no bypassing McAfee.

The file is CVE-2015-1592.inc and is labeled as a trojan.

Attachments (1)

main.log (48.1 KB) - added by darynwhite (Daryn White) 5 years ago.
perl5.28 log file

Download all attachments as: .zip

Change History (10)

comment:1 Changed 5 years ago by darynwhite (Daryn White)

Port: perl5.28 added; perl.5.28 removed

comment:2 Changed 5 years ago by darynwhite (Daryn White)

Port: perl5 added

comment:3 Changed 5 years ago by Schamschula (Marius Schamschula)

Owner: set to mojca
Status: newassigned

comment:4 Changed 5 years ago by mojca (Mojca Miklavec)

Cc: dbevans added

Thanks for reporting, but I have absolutely no idea what to do, other than perhaps deleting the file and uploading a modified archive somewhere else, but I don't really like that. If this problem is not widespread (I suspect we would have had more reports earlier), maybe I can show you how to make a workaround on your computer? I could upload a modified tarball somewhere (assuming you are unable to do that at your computer anyway) and you would just change the checksums in the portfile, update perl from there and the rest should work.

I would heavily advise you to complain at McAfee. They need to fix such cases. When it's a false alarm, it shouldn't be the downstream project that needs to fix stuff, but the one who reported that false positive (i.e. virus scanner).

I would have deleted the file from MacPorts, but If the problem is triggered immediately after extracting the file, I strongly suspect that this will not really help you either, as it would come too late. Please attach some logs, just in case.

Last edited 5 years ago by mojca (Mojca Miklavec) (previous) (diff)

Changed 5 years ago by darynwhite (Daryn White)

Attachment: main.log added

perl5.28 log file

comment:5 Changed 5 years ago by darynwhite (Daryn White)

That's the log file. I was able to upgrade my remaining ports with a -p modifier, so that's done at least.

Maybe a modified tarball would work, but I fear that this is something that I'll just have to wait for an update through either Perl or McAfee. I don't have the ability to remove or modify McAfee on this machine so it may just be a waiting game for now.

The error comes because the file is removed immediately upon extraction, causing the rest of the install to fail due to a verification fail. I'll try to address it from my end, but I wanted some better documentation out there if anyone else runs into the same problem, specifically via MacPorts. Plus awareness breeds change, hopefully.

comment:6 Changed 5 years ago by mojca (Mojca Miklavec)

Please try to run

sudo port clean perl5.28
sudo port extract perl5.28
cd $(port work perl5.28)

and remove the following line from MANIFEST:

dist/Storable/t/CVE-2015-1592.inc  See if Storable works

then run

sudo port -vs install perl5.28

Do you know why perl wasn't install from the binary package?

comment:7 Changed 5 years ago by darynwhite (Daryn White)

That worked, thanks!

As far as installing from binary, I really don't know why it didn't. Perhaps it is how my system is set up; IT here doesn't give me sudo access at all, so I have MacPorts running in a directory in my User directory. It has never been a problem before this one update.

comment:8 Changed 5 years ago by mojca (Mojca Miklavec)

Thanks for confirmation, I'm happy that you found a way around the problem.

True, if you don't have admin rights, you don't get the binaries. That's slightly unfortunate, but it explains the behaviour.

I'm tempted to close the ticket: not because this would not be a real issue, but because I cannot imagine what I could possibly do until upstream fixes the problem. (We could do workarounds like modifying the tarballs, but they would all be ugly and suspicious.)

Last edited 5 years ago by mojca (Mojca Miklavec) (previous) (diff)

comment:9 Changed 5 years ago by mojca (Mojca Miklavec)

Resolution: wontfix
Status: assignedclosed
Note: See TracTickets for help on using tickets.