On 02/06/2023 17:26, Brandon Sara wrote:
And just to be clear, this code would execute on the Fuseki server, correct?
I'm not sure what "this code" refers to.
A way to be safe is to run Fuseki with a Java17 runtime.
What is appropriate in your environment is something you have to decide.
The software is provided "without warranties or conditions of any kind".
Keeping up-to-date with software releases is good practice and that
applies to Java itself.
Unless you are running the WAR file, the choice of Java version to run
Fuseki is controlled in the server script.
Moving to Java17 as a requirement for Jena generally is something on the
project's radar.
Andy
On Jun 2, 2023, at 3:20 AM, Andy Seaborne <[email protected]> wrote:
"EXTERNAL EMAIL" – Always use caution when reviewing mail from outside of the
organization.
The advice from the project is to upgrade or at least run in a Java17+
environment, otherwise anything may be possible.
Andy
On 01/06/2023 17:57, Brandon Sara wrote:
Ok. When you say “arbitrary function”, could one craft and run code that makes
HTTP calls (via XMLHttpRequest or the fetch API, for example)? We don’t have
sensitive data in our store, but I want to make sure that no one could make
queries to other servers via queries to Fuseki.
On Jun 1, 2023, at 7:16 AM, Andy Seaborne <[email protected]> wrote:
"EXTERNAL EMAIL" – Always use caution when reviewing mail from outside of the
organization.
On 01/06/2023 09:42, Rob @ DNR wrote:
Yes, prior to 4.8.0 users can craft a query that calls arbitrary JavaScript
functions even if you have not explicitly configured custom scripts.
As discussed on our Security Advisories page [1] the projects advice is always
to use the latest version available.
Or as already noted in this thread run using Java 17 as that does not have a
script engine embedded by default. Java code is generally forward compatible
safe so even though the project releases builds made to target Java 11 it’s
fine to run that on a newer JVM.
A Jena release is compiled with Java17 at the moment, producing Java11
bytecode. This is done to work around Javadoc issues; some improvements
haven't been backported to the Java11 codeline.
We have Jenkins jobs for Java11, Java17 and Java-latest.
There are also github actions in the project codebase.
The project policy has always been "2 versions of Java" which we have
interpreted nowadays as two LTS. Java21 is Sept this year and, barring a
change of plan by OpenJDK, will be LTS.
Andy
