Closed dbast closed 1 year ago
hmaarrfk
commented
1 year ago I'm not clear on the usefulness of a test we ignore.
This seems to be a service that we want to have outside this repo, where we scan more than just this installer.
There, the tests would not be ignored and could be used to communicate with others about things that fail particular scanners.
dbast
commented
1 year ago Was thinking about this for a while. Malware/Anti-Virus scans are not stable over time as the scanners are updated regularly. That means blocking anything does not help as this can also be a temporary false positive result. That is why registering a file (without waiting or blocking on the result) is maybe a better pattern. The user can then look up the last scan result bz the provided links and be satisfied with it or press the re-scan button (without any further uploads) and get a current result.
Agreed having this generally available for all packages would be nice, like a non-rate-limited token to register all packages on upload and conda subcommands like conda scan/check {--update} $package{==$version} or conda scan/check env {--name, --prefix} {--update}. But that is a much bigger concept with more work to be usable.
Still registering solely installers could be particularly interesting (while the bigger concept of scanning public packages / entire channels is in the making) as installers bootstrap every installation and there are also users out there who then install from locally mirrored + antivirus scanned channels.
hmaarrfk
commented
1 year ago The fundamental problem, is that if it is "green", my tendency to look at what happened drives down to 0.
Will somebody monitor it on every release? Will we report out finding to anybody that will listen?
I would, instead, encourage you to create a small project, that tries to test, and report findings, for a list of packages.
You could:
My point is mostly that if it is "green" then we will just ignore it, and waste "resources" in the general sense of the word.
s-m-e
commented
1 year ago Just noticed this discussion.
My point is mostly that if it is "green" then we will just ignore it, and waste "resources" in the general sense of the word.
The original PR has an important point: False positives. I see this way too often, especially within certain "enterprise" deployments with "enterprise" AV products that are lately also popping up in academia. At the end of the day, it is virtually never the fault of conda-forge or any of its packages, but it is time-consuming and annoying to find a point release that does not trigger a false-positive on a given system. Besides, it harms the reputation of the project, although it's clearly not its fault.
As to the use-case: Have a known & well documented overview for the most current installer releases, conda releases and "critical packages" (anything related to node.js for instance that AV software tends to jump on). From there, users have a known path to work around the false-positives (which otherwise requires a ton of manual labour, i.e. trial and error). In addition, conda-forge has a way to complain "upstream" to the AV folks to fix this. Perhaps the output of VirusTotal could even be used to automatically generate notifications to the responsible AV companies - this would be fun ;)
hmaarrfk
commented
6 months ago The proposal sounds great, but I don't want to add a requirement that our packages must thread the line of "compatibility with AV's virus scanner from 2021" for example to our mix.
What you are asking for seems separate from the problem of compiling packages to maintain API + ABI compatibility among themselves.
I think it makes sense to have an AV monitoring feedstock, that periodically checks common installation patterns helps users navigate this.
I don't think it makes sense to put this responsibility on the feedstock maintainers.
Besides, it harms the reputation of the project, although it's clearly not its fault.
I don't disagree with this, but AV software has been problematic for bleeding edge software since its inception.
Maybe its better to have this discussion on: https://github.com/conda-forge/conda-forge.github.io
hmaarrfk
commented
6 months ago Sorry i confused this repo with that of opencv.
I'm more open to adding this to feature to our installer, but I would just like to understand what actions get triggered when we fail a virus scanner.
Who is responsible for following up with various companies that offer AV services?
This adds scanning released installers with VirusTotal, which currently scans with 61 different Virus/Malware Scanners.
It is neither blocking a release nor marking it red/green, instead a collapsible is added to the release description containing all the links to the VirusTotal results, see e.g. the releases made in my forked repo https://github.com/dbast/miniforge/releases .. The links even have a re-scan button without the need to re-upload anything as they cache uploads.
This is both for the sceptical people, who want to have installers scanned before using them AND also for everybody else to check if there are any false positives that could block the installers on machines with active scanners. While any true positive findings are not really expected, really proofing it is some value as installers are the most common way to bootstrap installations (besides micromamba / conda-packed envs without installers).
The VirusTotal scan API can be used freely by OpenSource Projects with a rate limit of 4 lookups / minute (Monthly quota: 15.50 K lookups / month). It requires a core/miniforge developer to sign up there, get the API key from https://www.virustotal.com/gui/my-apikey and adding it to the repo secrets called
VT_API_KEY(I can also provide my API key, if that is of help).The implementation required changing the ci.yml workflow triggers as the
crazy-max/ghaction-virustotal@v3action relies on thereleasetrigger to work.