Windows development and "virus" in LLVM test suite

Hi,

I just filed a bug because LLVM’s test suite includes a virus. This is not normally a problem on Unix (not even Linux), but as everyone know, Windows is so vulnerable to vira, that Windows users have to have an antivirus solution installed. The problem is that the virus in:

projects/test-suite/MultiSource/Applicaations/ClamAV/inputs/rtf-test/rtf1.rtf

BREAKS the SVN pull of the LLVM test suite: Once the file is read onto disk, the antivirus solution aborts the SVN pull because SVN cannot access the file anymore.

I filed a bug to have the offending file removed from LLVM, but it was immediately closed with a WONTFIX flag.

So, I am asking here, in the greater context of the LLVMdev mailing list, what can be done to fix the presence of a “virus” in LLVM permanently? It is not acceptable to have to ask people to uninstall their antivirus solution if they want to use the test suite on Windows.

The problem occurs with Microsoft Security Essentials (the poorest antivirus solution in existence), so it is likely to occur with many antivirus solutions.

A quite from Wikipedia regarding the file:

A compliant virus scanner, when detecting the file, will respond in exactly the same manner as if it found genuinely harmful code.

So any compliant virus scanner will choke and panic upon encountering this file!

Cheers,
Mikael

Tell your AV to ignore that folder and program. I don't have an issue
with it on Windows.

- Michael Spencer

Agreed -- and I'm using MS Security Essentials too, FWIW. :wink:

~Aaron

  1. I can’t tell Microsoft Security Essentials to ignore anything. Even if I click Allow, it breaks the pull.
  2. The issue is not me. I don’t download virus infested stuff and I don’t visit dangerous sites so I rarely have a need for antivirus solutions.

The issue is the newcomer Windows user whom I have to instruct to disable and/or remove his antivirus program if he or she wants to set up a Windows buildbot slave. A bit drastic, but that’s life as it is now.

2012/6/15 Michael Spencer <bigcheesegs@gmail.com>

Okay, I can configure MSE to ignore certain places. Just have to do it in advance. Thanks for the hint.

2012/6/15 Mikael Lyngvig <mikael@lyngvig.org>

At a fundamental level, I don’t see easy ways to fix this.

A major user of LLVM is an anti-virus software suite.

A reasonable test case for them is to detect, well, a virus.

A reasonable use of the test suite (which note is not part of the primary LLVM repository!) is to include tests that are a bit tricky to include with LLVM by default either because they take too long to run, have too many host dependencies, have weird license restrictions, etc etc.

It’s not clear to me that making this optional test suite easier to install on restrictive platforms like Windows with this security software you mention is worth neutering the ClamAV tests run…

Solution found (instruct the user to add an ignore directory to his or her antivirus solution). It works too :slight_smile: And Windows users ought to suffer a little bit for having chosen that platform :wink:

And me who couldn’t for the life of me figure out why the heck a compiler needed to include an antivirus testcase. Well, there are greater wonders under the sky than anyone can ever imagine.

2012/6/15 Chandler Carruth <chandlerc@google.com>

From: "Chandler Carruth" <chandlerc@google.com>
To: "Mikael Lyngvig" <mikael@lyngvig.org>
Cc: "LLVMdev Mailing List" <llvmdev@cs.uiuc.edu>
Sent: Friday, June 15, 2012 5:00:03 PM
Subject: Re: [LLVMdev] Windows development and "virus" in LLVM test suite

1. I can't tell Microsoft Security Essentials to ignore anything. Even
if I click Allow, it breaks the pull.
2. The issue is not me. I don't download virus infested stuff and I
don't visit dangerous sites so I rarely have a need for antivirus
solutions.

The issue is the newcomer Windows user whom I have to instruct to
disable and/or remove his antivirus program if he or she wants to set
up a Windows buildbot slave. A bit drastic, but that's life as it is
now.

At a fundamental level, I don't see easy ways to fix this.

A major user of LLVM is an anti-virus software suite.

A reasonable test case for them is to detect, well, a virus.

A reasonable use of the test suite (which note is *not* part of the
primary LLVM repository!) is to include tests that are a bit tricky to
include with LLVM by default either because they take too long to run,
have too many host dependencies, have weird license restrictions, etc
etc.

It's not clear to me that making this optional test suite easier to
install on restrictive platforms like Windows with this security
software you mention is worth neutering the ClamAV tests run...

Might we also have problems with virus-scanning firewalls? Would it work if we XORed the ClamAV test's inputs with something, and then modified the test to XOR the results of its reads (to undo the transformation). If that is sufficient to get around this issue, then it might be worthwhile.

-Hal

Sounds like a great idea. On Windows there are so many types of antivirus solutions, that it is impossible to provide a detailed description of how to add an ignored folder for all of them.

– A Windows user only for the games.

2012/6/15 Hal Finkel <hfinkel@anl.gov>

No, it’s not a great idea. These are exactly the types of things virus already do to get by detection systems. They will be defeated by some extra clever anti virus software.

Look, let’s not try to hack around this. Let’s just admit it. There is a virus inside of a virus scanner’s test suite. That’s OK.

This test suite is not required to hack on Clang or LLVM, so I think its fine as is.

If people are seriously peeved, we could split the test suite in two, but honestly this is the first time it has ever come up, so I suspect the cost of dealing with this file is lower than the cost of dealing with this email thread. ;]

A solution was found and that’s all I care about. Thank you, gentlemen, for your time and for helping to resolve this issue. Which will make it into the Windows docs so that we won’t ever see the issue raised again.

2012/6/15 Chandler Carruth <chandlerc@google.com>

The intersection of "people using the LLVM test-suite" and "people who don't know how to disable their antivirus" may not be empty, but it's really too small to care about. The test-suite isn't meant to be used by end-users, we can expect anyone who wants to try the testsuite to be smart enough to put "eicar" in the search engine of their choice and then then disable their antivirus after finding out what it is.

I'm also strongly suggesting to disable any kind of antivirus guard on a machine that builds and tests llvm because it slows down builds significantly and has the tendency to make testing more unstable. Racing file handle locks on windows are a big pain, and antivirus solutions tend to create these conditions all the time. We have seen bogus, hard to reproduce test failures because of this in the past.

- Ben

I admit I belong to a small group of not-too-bright people who still aspire to use LLVM. But I kind of see that as a highly valuable feature, insofar I convert this fact into something constructive (such as FAQ writing) :slight_smile:

I actually did recommend people to disable their antivirus solution for two reasons - the aforementioned “virus” and the speed slowdown that they’ll experience, but then somebody (can’t remember who) reacted and said it wasn’t a good idea to recommend people to disable their antivirus solution.

However, I see a nifty compromise visualising behind my eyes: Ask the user to add the LLVM source and build directories to their virus ignore list. This will solve both issues.

– Geez, sometimes I’m smarter than I am.

2012/6/15 Benjamin Kramer <benny.kra@googlemail.com>

Mikael Lyngvig <mikael@lyngvig.org> writes:

I admit I belong to a small group of not-too-bright people who still aspire
to use LLVM. But I kind of see that as a highly valuable feature, insofar
I convert this fact into something constructive (such as FAQ writing) :slight_smile:

I actually did recommend people to disable their antivirus solution for two
reasons - the aforementioned "virus" and the speed slowdown that they'll
experience, but then somebody (can't remember who) reacted and said it
wasn't a good idea to recommend people to disable their antivirus solution.

I agree about not recommending *people* to disable their antivirus. The
human beings that work with the LLVM test suite are not "people", they
ought to understand the implications of disabling the AV. Moreover, they
will be happy to have just another reason for not having an active AV
running on their machines. Quite a few AV packages are worse than most
of the malware they supposedly protect from.

However, I see a nifty compromise visualising behind my eyes: Ask the user
to add the LLVM source and build directories to their virus ignore list.
This will solve both issues.

No, they shall add the *specific* file that triggers the AV alert to the
ignore list, otherwise those directories could act as safe harbors for
malware. It is a good thing to put a warning on the web page that
explains how to obtain the LLVM test suite about the existence of such
file and suggesting to disable the AV while checking out the package and
to add the exception after that.

Thanks for your input. We are getting closer and closer to the final solution to this issue. I agree with you, on second thought, that only THE offending file should be excluded.

If somebody is stupid enough to disable their antivirus or remove it (namely me), it is their own choice and is not something that all of the LLVM group has to take part in.

So, I’ll make sure the Windows docs very precisely and accurately tell the user to add that one single file to the ignore list. Only thing I disagree about is that I think the exception should be added beforehand; no need to ask people to disable their antivirus solution if they can add the exception beforehand.

2012/6/16 Óscar Fuentes <ofv@wanadoo.es>

Mikael Lyngvig <mikael@lyngvig.org> writes:

Thanks for your input. We are getting closer and closer to the final
solution to this issue. I agree with you, on second thought, that only THE
offending file should be excluded.

If somebody is stupid enough to disable their antivirus or remove it
(namely me), it is their own choice and is not something that all of the
LLVM group has to take part in.

Not having an AV or swithching it off at times is not a sign of
stupidity. The best antivirus is a mindful, knowledgeable user. And the
antivirus doesn't really protect you in case of risky behavior.

So, I'll make sure the Windows docs very precisely and accurately tell the
user to add that one single file to the ignore list. Only thing I disagree
about is that I think the exception should be added beforehand; no need to
ask people to disable their antivirus solution if they can add the
exception beforehand.

Yes, if the antivirus accepts an exception for a yet nonexistent file. I
bet most of them won't do that without fiddling with configuration
files.

Not having an AV or swithching it off at times is not a sign of
stupidity. The best antivirus is a mindful, knowledgeable user. And the
antivirus doesn’t really protect you in case of risky behavior.

I couldn’t have said it better myself. I’ve had three viruses in 29 years and only one of them was my own fault. I’ve spent hours trying to explain people that trusting an antivirus solution is unfortunate at best.

Yes, if the antivirus accepts an exception for a yet nonexistent file. I
bet most of them won’t do that without fiddling with configuration
files.

Ok. You get it your way :slight_smile: Disable antivirus, checkout, and then add the offending file to the exclusion list.

A better rule of thumb I would say is to exclude the entire source and build directories from antivirus. On-access file scan hurts build times a fair amount, and I really doubt that any of your source code is going to have viruses in them :stuck_out_tongue:

Well, I actually ended up writing a compromise of compromises:

The recommended course of action is that you do this: