I don't need this `windows_x86_64_msvc` crate on my computer anymore, how to delete it?

I've attached the latest (I think) file that I could find.

Murray

(Attachment build_script_build-630d88eb945eaa63.exe is missing)

They couldn't have had the same name in the same folder; were they named differently, or were they in different folders?

And I didn't mean attach the exe, I meant the file named exactly build.rs.

You are correct, they were all in different folders.
Which folder should I choose to upload the file from, none of the folders had a current creation date?

Murray

Email attachments probably won't work when replying by-mail to this forum thread.

You don't really need to upload any source code from a crates-io crate anyways… it’s easily readable online:

https://docs.rs/crate/windows_x86_64_msvc/0.48.5/source/build.rs

Of course, feel free to double-check that those really are the file contents… but anyway,
as @jofas already mentioned, and linked (though in a different version of that crate then the one that this seems to be about for you) the crate does very little anyways, and the build-script is super super tiny. We needn’t talk attachments, this should literally be the whole script:

fn main() {
    let target = std::env::var("TARGET").unwrap();
    if target != "x86_64-pc-windows-msvc" && target != "x86_64-uwp-windows-msvc" {
        return;
    }

    let dir = std::env::var("CARGO_MANIFEST_DIR").unwrap();

    println!("cargo:rustc-link-search=native={}", std::path::Path::new(&dir).join("lib").display());
}

It also really should not be much of a security concern at all, because the crate comes directly from microsoft.

1 Like

To understand the full content of this script, here’s some documentation on


  1. Given the version (0.48.5), the file on your computer should be the exact same binary file, as this one on GitHub. ↩︎

  2. In case it seems like really important to you to learn even more about this file nonetheless, of course feel free to ask, perhaps someone here knows. ↩︎

1 Like

I was mostly operating under the assumption that, if there's anything wrong with it, it was added after or during the download. I'm not certain how any antivirus could flag as malware a program that just reads env variables and writes to stdout. It doesn't do anything that a brief search tells me EvoGen does.

Right… I don’t know either. A minute of googling shows that this “EVo-gen” seems to be some generic trojan-detection algorithm, so false positives are definitely very possible (probably quite common). It seems like - to double-check - e.g. by scanning the exe file with virustotal.com, which also seems to be recommended in multiple places I’ve come across looking for “EvoGen”.

That being said, as far as I remember, with antivirus software in general, false positives are super common with executables you’ve compiled yourself, and the actual program behavior generally doesn’t matter too much (it could be just a Hello World).

Antivirus software generally tends to be extra suspicious of executables that were created by other programs, because downloading, decompressing, decrypting, or permuting other parts of their code is one way that viruses hide from antivirus. But a build script — compiled and then immediately run — looks just like that kind of virus activity.

4 Likes

And in addition, a lot of virus detection heuristics are trying to match on "looks like a normal program", and it's possible it's not familiar with Rust output yet, or at least the latest version of the compiler (which recently bumped the major version of llvm), and a super small executable like for a build script is also suspicious.