gmake.exe and perl.exe constantly updated

[PhilterPaper]

I opened this on perlorg/cpanorg#54 and they told me to ask over here.

Anyway, of late (last 2 or 3 months), every time I run cpan on Strawberry Perl (5.26, 5.32, 5.38) to upgrade my library of installed packages, my AntiVirus tells me that gmake.exe has been updated -- do I want to proceed? Frequently, I also get a warning that perl.exe has been updated. Is this expected behavior? Are you unnecessarily packaging fresh copies of gmake and maybe Perl every day?

This is a problem for me because the warning about the update suspends the update process until I give permission to proceed. I can't just fire off the massive daily update (for three Perl versions) and forget about it. It would be nice to have these utilities only update when they've been changed.

[shawnlaffan]

I am not aware of anything in the Strawberry Perl ecosystem that would update its gmake.exe.

This sounds like it is an issue with your antivirus and/or file system. Or perhaps some other utility is changing the modification time of the executable?

[PhilterPaper]

The AV doesn't say that the behavior is suspicious; it says that the program was just changed while cpan is running, which it flagged. I'm on Windows 10 with the normal MS updates it does. I'm not aware of anyone other than cpan running gmake, and no one that I know of is touching the file. Maybe the AV is somehow sensitive to the order in which I run the cpan update and the AV -- let me try that out.

[shawnlaffan]

Is this using the system you described in #133 where you use junctions to change the in-use perl version? If so then this will change the various exe files each time, and this could be triggering your AV if it does not detect that there is a junction in place.

[PhilterPaper]

Ahhhh. Good point. Yes it is, but I've been using the junction to map \Strawberry to \Strawberry-5.xx for years, and it just within the last couple of months it started doing this. Since the \Strawberry gmake and perl .exe's will be different, that well could trigger it. I'll have to ask the AV people if they have any suggestions for suppressing the check for these particular files.

[PhilterPaper]

The AV people asked me

Did you check if those executables are digitally signed? This could be a reason for them to be flagged.

Are they? I have no idea how to check them.

I have tried over the past few days to see if the order I ran them in made any difference. First the CPAN update (\Strawberry linked to 5.26, then 5.32, then 5.38; and finally restored to 5.32) and then the AV run. Then reverse the order (AV run through and then CPAN update). Then run simultaneously (\Strawberry...perl.exe and gmake.exe could be any of the three levels when the AV looks at them). Since I get the warning popups when CPAN update is running (not the AV full scan), it must be a behavioral thing that's triggering the warnings.

[shawnlaffan]

None of the Strawberry Perl generated executables are signed. I checked one of the Winlibs executables and it is not signed.

Does the AV trigger when you use the various perls directly? i.e. from their source dirs and not via the junction.

And what if you only switch between 5.36 and 5.38? Those have the same set of files in the .../c/bin dir so the AV should not be seeing any difference from its last scan.

[PhilterPaper]

Does the AV trigger when you use the various perls directly? i.e. from their source dirs and not via the junction.

It doesn't appear to. I can run \Strawberry-5.38\perl\bin\perl.exe -v without the warning popup.

My program invokes "cpan" twice, which is a .bat file (under \Strawberry\perl\bin) that in turn invokes "perl", which via PATH should be picking up \Strawberry\perl\bin\perl.exe, which via the Junction should run \Strawberry-5.xx\perl\bin\perl.exe. Which often (but possibly not always) gives me the warning popup. I'm not experienced enough with .bat files to want to try to bypass the PATH and Junction business in there, so I tried in my Perl program to use $path = "\\Strawberry-${perl_v}\\perl\\bin\\"; and add ${path} to both cpans. First test didn't cause any warning popup -- let me try it for a few days and see if it's fixed.

And what if you only switch between 5.36 and 5.38?

I don't have 5.36 installed, and don't really want to install it just to do this testing. Let's see if bypassing \Strawberry works, before I think about installing 5.36.

[shawnlaffan]

@PhilterPaper - given the discussion the issue would seem to be an interaction between your AV and the junctions on your system?

I've marked the ticket as closable and will do so in a few days (or so).

However, if it can be shown to be a Strawberry Perl issue then we can keep it open.

[PhilterPaper]

Yeah, it seems something is going on as you describe, so I'll go ahead and close it.