PureOS Byzantium Gradle Version

Hi guys. I generally have been an PureOS enjoyer but I have not totally moved my life off of the evil nonfree software yet. Because of this, I was using my Windows PC and using the Discord technology to converse with a game modding community that I have enjoyed for several years. In that nonfree world of things, a Discord user who I have seen as a legitimate member of this game modding community for years and who I have personally played the game with, asked if I would evaluate the software that they were writing to help them mod this old game.

Of course, in that world of bad ideas, they sent me a binary of the software that they were writing. However, upon downloading the zip that contained this binary and without even unzipping the ZIP archive file, Microsoft Defender instantly had a fit, deleted the archive, and then said that the threat “might not be completed remediated” and that the problem is “severe” as if it believes that its attempts to eradicate whatever malicious designs existed inside the zip file were not successful. Microsoft Defender, being opaque trash in these sorts of cases that lists nothing remotely meaningful about what it believes was in the zip file, nor any information that I could meaningfully use to discern if this was a false positive. It also seems to have no GUI for allowing me to help or rerun its removal of the malicious technology. It simply says, “Remediation incomplete” with a “learn more” link that links to an exceedingly unhelpful page about general malware.

Some basic attempts to read about the arbitrary name given by Microsoft to this malware using standard web searches landed on a mixed bag of some people trying to claim that users should ignore their antivirus because surely these are false positives, and then other users describing that the malicious technology supposedly in this zip file sent to me (or something else that it shares a Microsoft-generated name with) is sufficiently advanced to transfer itself from computer to computer for anyway infecting, using the all-to-common modern “Browser sync” logins (Chrome, Edge, etc) as well as cloud storage apps like Microsoft’s OneDrive and others. Some of these technologies and their derivatives (i.e. rebranded Chromium fork(s)) are present on my Windows machine and actually on a second Windows device that I sometimes use from before I started pushing myself more onto PureOS.

So, I went back to my PureOS machine and I decided I should very much like to use the Ghidra tool from the National Security Agency to rip apart this application that was sent to me by this discord user, and then see if I can locate within it enough of the malicious code to have a sufficient understanding whether this is a false positive, or what I am up against, and why the mere presence of the archived ZIP on the Windows machine could cause the built-in Windows security to have a fit. It might be that this is the moment in life when I need to stop using Windows, but I wanted to look and to see and to try. Navigating through the binary inside this executable on a PureOS machine even with a basic text processor shows a substantial volume of text indicating to me based on my domain-specific knowledge that some parts of this binary are legitimately an advanced text-processing tool for modifying the old video game that this user and I share a common interest in.

So, one possible scenario for me based on this information might be that:
(1) the error message from Windows claiming it was unable to purge this file from existence is some stupidity in the design of Windows and not representative of the malicious technology’s ability to self-execute when the binary itself was never extracted nor intentionally executed by me as the Windows user (I certainly hope…)
(2) the person who contacted me online is a real person and not a malicious agent
(3) this real person was themself infected by a sophisticated trojan that embedded itself into the basic text-processing .NET GUI app that they tried to create and send me, which (I certainly hope) was detected in advance by Windows and removed

But this is where, in the spirit of free software, I wanted to see if I could compile GitHub - NationalSecurityAgency/ghidra: Ghidra is a software reverse engineering (SRE) framework on my PureOS machine myself using only byzantium repo software distributions and not anything third-party. But this is where I became stuck because for some reason, the Byzantium repo is stuck on the 2017 version of the gradle build system for Java, whereas the National Security Agency’s Ghidra technology for reverse engineering binaries or whatever, appears to require a much newer version of the gradle build system – this despite the fact that Byzantium has the totally correct Java version 17 available as far as I can tell.

I am a hobbyist and have almost never used Ghidra save for one time idly on a train a year or two ago. It is possible that it will be time consuming for me to try to investigate this situation further and whether the alert regarding this binary the person sent me is or is not a false positive. But I would enjoy trying, and I think that in the spirit of free software and security it would be preferable for me to compile Ghidra from source simply because I can.

Is the only option for me to switch to landing or wait for crimson? Or is there some other way to get a version of the gradle build system in byzantium that would seeming match this Java 17 version that is itself already in byzantium?

It just seems like maybe I missed something. I used the standard apt install gradle from byzantium, and then gradle -version and it’s telling me that it is gradle version 4.4.1. But at the same time, apt install openjdk-17-jdk worked fine. Based on the release notes, it looks like Gradle version 4 was built to support Java 10 or something like that, way before Java 17. So that just left me wondering if there might be some way to load newer alternative versions of gradle on byzantium, or if I was missing something.

Is that a crocodile in your profile image? (Sorry… I’m easily distracted.)

Yeah. It’s a picture of me holding a crocodile, from a long enough time ago that I probably don’t look that way anymore so I figured the picture wouldn’t actually be personally identifiable but would instead just be funny

1 Like

The current release of Ghidra requires Gradle 7.3 or newer.

You should be able to download a more recent Gradle version (e.g. Gradle v8.4), unpack it into the project directory and try running the build from there. That shouldn’t interfere with system-provided Gradle in any way.

However, I haven’t been able to build Ghidra on my Librem 5, apparently due to lack of memory.
Not even the preparation steps ran to completion; Linux’s out-of-memory killer got a hold of one of Ghidra’s Gradle initialization tasks after it ran for more than half an hour.

So even if the Librem 5 is powerful enough to run Ghidra (which is already a big if), I can’t recommend using it to build Ghidra. Have you tried building on another computer that has more memory, then copying over the build artifact?

This is surely true, but what if I wanted to use the package manager provided software to be certain that it passed the certifications of the FSF, because the whole point of the endeavor was that I felt like being paranoid about security?

It may be that “paranoid” is the right word, though. I am certainly aware that you are entirely correct; if I am willing to download software from outside my package manager for my particular case, then my problem would be entirely solved.


Technically the FSF endorses free GNU/Linux distributions, not package managers or their repositories’ software, and the FSF’s main criteria is freedom, not security.


Note the quote at the very top of the page:

Gradle uses the Apache 2.0 license so you can audit their repository’s software code, and there are build instructions in their documentation.



I think @FranklyFlawless is correct in that the FSF offers limited guarantees (if any) in terms of package vetting or security.

Regardless, trusting Debian’s (or PureOS’s) binary builds more than the Gradle organization’s packages may be justified – if only because the former have undergone additional testing compared to the Gradle organization’s fresh upstream releases. There’s a reason why Debian packages are lagging in freshness, and that includes compatibility with the rest of the system.

I therefore recommend that if at all possible, you stick to the version installed by your package manager. Avoid replacing that system package by a more recent one such as Crimson.
Instead, if you really need a more recent version, download that newer version or build it yourself from source, and then install it to a separate location. Only use that newer version for the particular build where you really need it, and leave the package manager’s version as is. By leaving your system packages unmodified, you stay on the tested path, which means your system remains stable.

1 Like