Windows Defender False Positve
Closed this issue · 20 comments
If program is downloaded, windows defender detects a "virus" in the program and the download is blocked. no viruses are in arrayv
This has been an experience with ArrayV in the past. This is because we use something called "Jar-in-Jar Loader" to dynamically load sorts. Jar-in-Jar loader, just like any other good tool, can also be used maliciously though. Windows Defender likes to call programs that use Jar-in-Jar loader "viruses," even though they aren't. Your options are either downloading the program with the green "Code" button and using Apache Ant, or using wget, curl, or similar to bypass Windows Defender.
I know this is closed but surely there must be another way of getting around this? In general I don't trust scripting languages like java (I don't consider "compiled to bytecode" 'compiled', and a jit doesn't count either), so I could understand why windows defender would get antsy when it starts loading random scripts, but it really seems like there should be a much better way of going about this.
This was closed because it was fixed!
Downloading the last release says otherwise :(
Sorry, let me add in I know that build predates the fix, what I'm saying is is that downloading the latest release still gives the impression of it not being fixed, and that seems like something pretty important lol.
The latest release is not up to date. It hasn't been updated in months. You can download the up-to-date version here (will be added to the README): https://nightly.link/Gaming32/ArrayV-v4.0/workflows/ant/main/standalone-jar.zip
I know this is closed but surely there must be another way of getting around this? In general I don't trust scripting languages like java (I don't consider "compiled to bytecode" 'compiled', and a jit doesn't count either), so I could understand why windows defender would get antsy when it starts loading random scripts, but it really seems like there should be a much better way of going about this.
With all due respect, this is just wrong. Java is, by any reasonable definition of a programming language, a programming language. Java is absolutely compiled to .class files and its syntax and semantics are not only more complex than what constitutes scripting languages, but also more than dynamic enough to distinguish Java programs from simpler commands being run through a console.
Yes.
In fact, every language is compiled to bytecode, including assembly (assembly is literally bytecode in text form, so IDK if that actually counts though). C compiles to the bytecode used by your computer, while Java compiles to a bytecode used by a virtual computer (a VM, known as the JVM), which runs on your computer, just like any VM run with VMWare or VirtualBox (even though the semantics are different, with the JVM intended to run as a VM, not through an emulator).
Those are some pretty long lines to draw from one to the other. The JVM is pretty far from a VM in any sane sense, seeing as how virtual machines have been hardware backed for a large amount of years now. The sheer fact that the language itself produces 'binaries' that cant be executed on any hardware, and instead are interpreted/'compiled' in software which is then run on the actual hardware defines it as a scripting language, no matter the capabilities of the language itself.
This was not meant to be a flame war, simply stating that I can understand why defender would flag it because the very operation of it depends on whats going to interpret it, instead of just it itself.
The JVM is not very far. In fact, there are CPUs that execute JVM files directly.
I will admit that I was wrong in the sense of there being no hardware for it, though in the implementations I see, calling it solely hardware is a bit of a stretch, but its definitely a lot closer than running the standard jvm
Those are some pretty long lines to draw from one to the other. The JVM is pretty far from a VM in any sane sense, seeing as how virtual machines have been hardware backed for a large amount of years now. The sheer fact that the language itself produces 'binaries' that cant be executed on any hardware, and instead are interpreted/'compiled' in software which is then run on the actual hardware defines it as a scripting language, no matter the capabilities of the language itself.
This was not meant to be a flame war, simply stating that I can understand why defender would flag it because the very operation of it depends on whats going to interpret it, instead of just it itself.
No, this is not something I can agree with; this is not the distinction between programming languages and scripting languages. The JVM is an abstract representation of compiled machine code, which is something tied to programming languages by definition.
The reason I'm strongly pushing back against this claim is because I worry labelling Java as a scripting language could be construed by other people as a gateway to devaluing and delegitimizing programming work done using Java. Any programming language (outside of machine code) has some layer of abstraction baked into it; that doesn't mean one language shouldn't be included alongside the rest of programming languages. This is similar, in my opinion, to criticism towards the social sciences being referred to as the "soft" sciences, an arbitrary way of "othering" fields of study not seen as "pure" as the "harder" sciences. All programming work deserves to be recognized as programming work.
I think that 'devaluing' and 'delegitimizing' are something of your own interpretation. I never said anything about scripting languages being inferior, yet youre seemingly drawing these conclusions.
I don't particularly see the issue with calling something what it is, and I dont even know how social sciences got grouped into this, but consider something thats mathematically true, such as the mass of a proton vs a social science like economics, where things follow trends and theres a general pattern to how things work but nothing is set in stone because people are entropy machines.
Does that mean its something we should frown upon or dismiss as invalid or even value less? Absolutely not, but you also shouldnt totally swing the other way and try to shoot down a term because theres supposedly an inferiority complex around it.
I think that 'devaluing' and 'delegitimizing' are something of your own interpretation. I never said anything about scripting languages being inferior, yet youre seemingly drawing these conclusions.
I don't particularly see the issue with calling something what it is, and I dont even know how social sciences got grouped into this, but consider something thats mathematically true, such as the mass of a proton vs a social science like economics, where things follow trends and theres a general pattern to how things work but nothing is set in stone because people are entropy machines.
Does that mean its something we should frown upon or dismiss as invalid or even value less? Absolutely not, but you also shouldnt totally swing the other way and try to shoot down a term because theres supposedly an inferiority complex around it.
I never said you referred to scripting languages as inferior; rather, I was pointing to the connotations of those labels at large. Many people would interpret "scripting languages" as "less valuable" compared to "programming languages".
Given the most common definitions of programming languages in computer science, Java fits the bill. I was simply using the social sciences example as an analogy to illustrate my point. No more, no less.
I didnt mean to imply that you implied I implied that they were inferior, simply that you raised the point of them being thought of as inferior when it wasnt really germane to the topic as much as it was "well if they were called this people will think theyre bad".
If you use a full aot compiler(graal/gcj) then I can totally agree that java would be a programming language in that sense, but given how the overwhelming majority of java applications are still interpreted in the jvm, even if it gets chipped away into actual processor instructions at runtime, its still running through another piece of software, capabilities aside.
I didnt mean to imply that you implied I implied that they were inferior, simply that you raised the point of them being thought of as inferior when it wasnt really germane to the topic as much as it was "well if they were called this people will think theyre bad".
If you use a full aot compiler(graal/gcj) then I can totally agree that java would be a programming language in that sense, but given how the overwhelming majority of java applications are still interpreted in the jvm, even if it gets chipped away into actual processor instructions at runtime, its still running through another piece of software, capabilities aside.
Simply put, I think labelling Java as a scripting language is reductionist because by this logic, C having to pass through a layer of abstraction to get to actual processor instructions also raises the question, "is C a scripting language?" The main difference between AOT and JIT compilation is when the code is compiled and not whether it is or isn't.
"The main difference between AOT and JIT compilation is when the code is compiled and not whether it is or isn't."
Yes, the main
Thats totally disregarding any sort of runtime optimization which constantly happens. If it was as cut/dry as 'oh after the program launches it no longer needs the jvm supporting it' Im pretty sure wed see jvm implementations that took advantage of that, but we dont.
As far as C goes, you write C, you compile C, the processor executes the instructions and nothing else.
With java you write java, you compile java, you run java to run the java binary, java generates processor instructions that are then executed, all whilst the garbage collector frantically takes care of the sloppiness thats occurred.
I understand where youre coming from regarding both having to be transformed before they can actually be utilized, but theres a major major difference.
Do note with C im referring to embedded programming, in which i write both C and assembly for risc-v/mips/6801 etc
Just a small factual note: The garbage collector has little to do with the JIT or execution, but rather the objects created directly by the Java program. Basically the consequence of no free, rather than the consequence of runtime code generation.
Sure and I mean that just solidifies my point further regarding that in the majority of instances (non aot) java programs are not freestanding applications, and rely on the jvm to actually work, which is quite the opposite of say, a C program calling a library.
"The main difference between AOT and JIT compilation is when the code is compiled and not whether it is or isn't."
Yes, the main
Thats totally disregarding any sort of runtime optimization which constantly happens. If it was as cut/dry as 'oh after the program launches it no longer needs the jvm supporting it' Im pretty sure wed see jvm implementations that took advantage of that, but we dont.
As far as C goes, you write C, you compile C, the processor executes the instructions and nothing else. With java you write java, you compile java, you run java to run the java binary, java generates processor instructions that are then executed, all whilst the garbage collector frantically takes care of the sloppiness thats occurred.
I understand where youre coming from regarding both having to be transformed before they can actually be utilized, but theres a major major difference.
Do note with C im referring to embedded programming, in which i write both C and assembly for risc-v/mips/6801 etc
Sure, there's a major difference; I suppose I don't quite understand what your definition of a scripting language is, then? Feel free to clarify.