Vcpkg: [security] vcpkgmetricsuploaded-0.0.110.exe is detected as a virus

[ghost]

Please provide explicit way to opt out of sending metrics for your users, add it in documentation and the usage of vcpkg. If possible make the metrics sending optional and ask user if they want to opt-in for the program.

[alexkaratarakis]

Which antivirus is this? I guess it is not too surprising that uploading something can be flagged by heuristics as a virus.

To build vcpkg.exe without metrics, you can use:
.\scripts\bootstrap.ps1 -disableMetrics 1

To verify, check the version:
.\vcpkg.exe version

It should have a -external in the version. For example:
0.0.110-2018-04-27-08afae2a7a5cd276fd251cbeef9a27f15261fc0c-external

In case it is of interest, here is what metrics are collected and why. Also, the source code: metrics.cpp

[MikeGitb]

Can you give some actual examples, where this metrics helped with the improvement of vcpkg or are you just collecting them because nowerdays everyone collects everything in the vague hope that at some time all that data night become useful?

[ghost]

Ideally, users will appreciate if they are asked nicely on first usage, "do you want to opt-in for improvement program (y/n)?", they will most likely choose yes, if they have legal or personal reasons, they won't. If you read this thread: https://github.com/dotnet/cli/issues/3093, you will agree that this is a general community consensus, what they expect from command line utilities with data collection capability.

[codedokode]

I agree, collecting any data should be opt-in, not opt-out.

[starikcetin]

I just wonder who makes these business decisions.

[alexkaratarakis]

@MikeGitb
One of the areas that we use metrics for is to identify/prioritize failing packages. Going from memory, here are some examples:

1) Our tests show that a port succeeds, metrics show that it fails for users. This means that something in our environment made the port succeed, but it is not so in the general case.

2) A "correct" port lists all dependencies it needs and doesn't use anything else. In practice, a port may use another library if it is available but can do without it. This leads to inconsistencies depending on the order the libraries are installed, i.e. it might fail depending on the order the libraries are installed, or even succeed in both cases but create inconsistent builds causing subsequent dependent libraries to fail. Metrics have helped us identify such issues. Also, after investigating a related failure, we have modified our CIs to randomize the order the libraries are built (so, the toposort is different each time).

3) Some ports in the library fail in certain configurations (triplets), so we use metrics to decide which port to investigate next.

@kasper3
Prompts are a valid solution and we used to have them in the early versions of vcpkg. It made sense since tools like apt-get and brew use them along with -y flags to auto-accept prompts.

Here is the full story of the current state:
There were various prompts e.g. for downloading cmake/git/etc. You would get a Y/N prompt about it, as well as an A(lways) option that placed a file AllowDownloads to automatically accept further downloads without asking. There was also an AllowEverything file that you could manually place and if present, all prompts would be treated as "yes". I intended for AllowEverything to be an all-prompts-included solution for CI systems (or generally using vcpkg in an automated manner) in which prompts are problematic.

However, user feedback suggested that prompts cause a lot of headaches in automation. For example, depending on the automation environment used, a prompt would appear as the script hanging forever. Too many prompts-on-first-use also degraded first impressions. Since the AllowEverything and similar files did not seem to be effective, we removed all prompts from vcpkg.

The current design avoids prompts and instead the commands exit with a detailed error message. For example, if you try to remove zlib while the dependent library boost is installed, it won't prompt you with y/n if it is ok to also remove boost. Instead, it will fail and inform you that you need the --recurse flag. So, it is a fail-and-re-run-with-flags approach as opposed to prompting.

Having said that, this is only an explanation of why we haven't simply added a prompt.
Adding a prompt is still on the table :).

[simonowen]

Just to add another report... Bitdefender blocked my metrics upload attempt:

"Advanced Threat Control has blocked the launch of a process that has been detected as malicious.C:\Users\USERNAME\AppData\Local\Tempvcpkgvcpkgmetricsuploader-0.0.113.exe"

That was using the latest corporate program and definition updates:
Product version: 6.6.3.61.
Engines version: 7.76974 (11994045)

[dgendreau]

My company's Symantec Sonar is going crazy over this metrics reporting executable. Thanks for getting me yelled at for your creepy spyware Microsoft!

Can we please have a package manager that doesnt do shady shit like this without asking permission first!?

[MikeGitb]

Has this been resolved now in any way? If so, how?

Has the telemetry been removed? Is the user informed about these metric uploads? Have all vendors of virus scanners informed about this, so they can ignore that behavior?

Or is it officially classified as not an issue/won't fix?

[needfulthing]

What's wrong with you, Microsoft? I installed the Windows version by cloning and executing "bootstrap-vcpkg.bat -disableMetrics". Still AVG quarantines vcpkg.exe when I try to install packages. reporting IDP.Generic and IDP.ALEXA.51 threats. This sucks. Last message here is almost one year ago and you did... nothing?

[malkia]

Why was this and this https://github.com/microsoft/vcpkg/issues/6551 closed?
I'm having the same issue:

Please talk to Symantec in order to resolve this.

[malkia]

The hash: is 9036AC26B53D36CBFE21B68ECCB0E9C94F42ACC0327858D32A5F99E898820B21
The name: SONAR.Heur.RGC!g403
File size: 275456
Symantec: Version 14 (14.2 RU2) build 5323 (14.2.5323.2000)

(e.g. just to make copy+paste easier)

[needfulthing]

This wouldn't be a topic if the "-disableMetrics" parameter would do what it should. Closing this ticket is just other words for "We don't care about your problem and/or your privacy" from Microsoft. Best solution is not to use this piece of crappy spyware at all >:(

[MikeGitb]

This wouldn't be a topic if the "-disableMetrics" parameter would do what it should. 

Do you have any reason to believe that it doesn't? I only had a quick look at the bootstrap script and IIRC it at least passes the flag to the build.

[malkia]

This wouldn't be a topic if the "-disableMetrics" parameter would do what it should.

Do you have any reason to believe that it doesn't? I only had a quick look at the bootstrap script and IIRC it at least passes the flag to the build.

Fair point, trying it out now (just saw the option).

[needfulthing]

Well yes, I did use the parameter with the batch as described in the doc. AV was still triggered. See my first post above. Despite all this I think it is very bad practice not to ask the user in a simple dialog before activating the metrics. Without the notice from AV I would have never recognized the tiny comment regarding the metrics at the end of the installation.

[MikeGitb]

Well yes, I did use the parameter with the batch as described in the doc. AV was still triggered. 

But that's different from saying the switch doesn't work. It might be just as well that your AV triggers regardless of whether vcpkg is uploading anything.

[ajimal1992]

Why is this closed?! Its a legitimate issue. I just had the same issue too