I wonder what we can do to prevent this from happening?
Some search results talk about signing the executable that is created
with launch4j, there is apparently an extra tool for this in the
launch4j distribution.
I see the source code for sign4j, but I’m not sure what good it would
do. AVG isn’t complaining about VASSAL.exe, which is what launch4j
produces.
But then there are also reports that even the
signed versions are detected as false positives by some AVs. It looks
like there was/is some windows virus or malware that can be distributed
inside a modified java binary, and some AVs just go nuts when they see
an application bring their own JVM.
The java.exe we’re distributing comes straight out of the JDK I’m using
for bundling. It’s not modified.
What we can do…
try to sign the releases
How would we do that? (I suspect it won’t matter in this case, however.)
tell users to stop using AVs in general as they are usually worse than
the viruses they are supposed to protect from
learn from the best and write a list of “Known Incompatible Software”
like minecraft does: minecraftirc.net/support-articl …
-software/[2] - oh look, AVG is first on that list, but only due to
being first in alphabetical order, the rest of the list is made up of
almost all other AVs, who would have thought that
These will let us say “we told you so”, but that’s about it.
send letters to AV manufacturers and ask them how to get Vassal
binaries onto their whitelists
Want to head that up? (In the past, I’ve complained to Norton about
listing our files as malware…)
tell users to install to some place other than “C:\Program Files” to
not get any issues with windows UAC
tell users to download Java and “Vassal other” distro, unzip and run
the .bat file
Also:
produce a live-usb linux with Vassal preinstalled, and an instruction
how to copy that onto an USB drive and boot from that
or a virtualbox VM
or a docker image
All of these will technically work, but have about zero uptake from
users.
If you’re already messing with the build script, you could automate it
so it downloads and unzips the necessary JDKs automatically, of course
only if they are not downloaded and unzipped yet. Adopt even has a REST
API for this: api.adoptopenjdk.net/[1]
That’s done in HEAD, as we needed a different JDK for Macs due to Bug
13176.
Another option would be to automate the whole build so that it can run
on a “naked” ubuntu machine, install all requirements first then build
all 4 distributions.
There might be a package for nsis? Building dmg and launch4j isn’t
very hard, and they’re all small. The less convenient thing is that
the three JDK tarballs are 562MB collectively… Downloading half a
gig of stuff on every build on a CI system is not ideal.
You already tried writing to Norton, let me guess how good that worked.
These AVs are the worst viruses of them all, they infect more computers and use up more resources than all viruses combined. And since they have the knowledge and the financial incentive, I am pretty sure that they themselves are responsible for creating most viruses and the media hype about how dangerous it is on the internet. It’s classical racketeering only with computers.
The one thing that we could do which would most definitely work is paying money to the AV mafia for getting on their whitelists.
About automated builds,
yes nsis is just an “apt install nsis” on ubuntu.
If we can get dmg and launch4j to download and build from a script, would be cool.
The JDKs, yes it would be too much for every CI build but we could configure a special release build, something like “if the commit is from release branch then do the full release build else do the regular compile+test”. Travis has some options to configure a build right in their .travis.yml file, and if that is not enough we could still write our own build script in bash which looks at the branch name and does what we need.
You already tried writing to Norton, let me guess how good that worked.
Actually, it did work, but I had to do it for a while after every single
release, so it was rather tedious. That was the only one where we got
a lot of reports of problems, and it was some years back.
The one thing that we could do which would most definitely work is
paying money to the AV mafia for getting on their whitelists.
Yeah, no.
About automated builds,
yes nsis is just an “apt install nsis” on ubuntu.
If we can get dmg and launch4j to download and build from a script,
would be cool.
I’m sure I could do that. I’ll look into it.
The JDKs, yes it would be too much for every CI build but we could
configure a special release build, something like “if the commit is from
release branch then do the full release build else do the regular
compile+test”. Travis has some options to configure a build right in
their .travis.yml file, and if that is not enough we could still write
our own build script in bash which looks at the branch name and does
what we need.
If we could have something like a docker image which was pre-populated
with the JDKs, that would help a lot. (Also, it’s too bad AdoptOpenJDK
doesn’t let you rsync, or provide binary diffs to apply from version
to version… That would cut our downloads to almost nil.)
And we wouldn’t even need to download that much, we would just need to download the JDKs when we do a full or beta release, that’s 4 JDKs once or twice a month, this is less than this sormuras bach project does per day. Also the travis guys are probably smart enough to use some kind of caching mechanism and it’s likely that our JDKs would come from this cache instead of all the way from the adopt/zulu/graal/whateverjdk servers.
Another idea I just got - if we automate this whole thing anyways, it’s going to be very easy to add additional Vassal distributions with alternative VMs like GraalVM and/or with alternative JIT compilers like OpenJ9 which “might” improve performance for some users.
Looks like they just do it for testing their build.
And the build doesn’t even build anything, it just downloads over a dozen of different JDKs for different OSes then checks if they were downloaded properly. Talk about waste of bandwidth and CPU cycles
I know that may NOT be the “ideal” thing, but basically:
Vassal itself is Java. Inside java it does not really matter what OS you got.
So the only thing is that this particular “bundled” Java version does not fit “your world” / OS.
If you got your hands on an appropriate JAVA installer, you can always download an “VASSAL--other.zip”
And get an apropriate Java installed.
For a 3.1 or earlier take a Java 8
For a 3.5 take a Java 11 (or later)
in 2021-03 Java 16 got released …
For in between … test it.
JRE or JDK ?
Well nowadays there is only JDK. JRE is contained in that package.
It’s 50 MB HDD space or so delta … so nothing really big.
Maybe you got Java already …
type “java --version” in a terminal / shell / bash
also sth like “whereis” or “which” as commands may help.
On OS X there are - i forgot what - a few “special tools” that you got to put into your ~/.bash_profile to select a java version nicely. but there are nice tutorials out there.
Now which Java to use ?
Oracle Java: up to Java 8 works, but may lock you in as it leaves some hard-to-remove trails on Windows.
OpenJDK: for any Java since Java 8
Azul JDK: If you got a windows or a mac that complains about a “non signed application” or want a “more efficient” Java Binary for your windows box.
How to set up my machine ?
If you got Windows - Use the Java Installer
If you got Linux - Use your Distro installer (eg. apt for Debian/Ubuntu/Pop!Os)
If you got Mac - Use the .dmg
