Security: TestHeadlessComponents downloads its own JDK

[adamfarley]

Summary
TestHeadlessComponents downloads two dependencies for use during testing.

This sidesteps Adoptium's control over test dependencies

Ideas

We should:

• modify the test to prevent the downloads.
• set $BOOTJDK_ARCHIVE_DIR to prevent a JDK download.
• set $RFaT to prevent the git clone.

Ideally we should do all 3.

P.S. It looks like, if BOOTJDK is not provided, the test starts doing things inside ~/bootjdk rather than inside the workspace.

That should probably be fixed too.

Links
https://ci.adoptium.net/job/Test_openjdk11_hs_dev.functional_x86-64_mac
https://github.com/rh-openjdk/TestHeadlessComponents/blob/main/testHeadlessComponents.sh

[andrlos]

I would like to take this issue.

[andrlos]

@adamfarley would setting RFaT as github dependency of https://github.com/rh-openjdk/run-folder-as-tests be admissible as a solution to the third bulletpoint?

[andrlos]

to the other two bullet points I was toying with the idea that there should be support for using jre isolated from the sdk used for compilation purposes with the USE_JRE checkbox.. I gave it a whirl in Grinder, however it seems that despite providing two links to jre and sdk adoptium tarballs with jdk customized flag set, it seems that only the sdk binaries are being used:

TEST_JDK_HOME=/home/jenkins/workspace/Grinder/jdkbinary/j2sdk-image
and
JAVA_HOME is set to /home/jenkins/workspace/Grinder/jdkbinary/j2sdk-image

as I see it this means that the JRE build although extracted is not being used.. can you confirm? I might look at that as well as part of this assignment.

[adamfarley]

Confirmed. It looks like only the tck tests use the JAVA_TO_TEST variable set by the USE_JRE flag.

JAVA_COMMAND:=$(Q)$(TEST_JDK_HOME)$(D)bin$(D)java$(Q)
ifdef JRE_IMAGE
   JRE_COMMAND:=$(Q)$(JRE_IMAGE)$(D)bin$(D)java$(Q)
endif

JAVA_TO_TEST = $(JAVA_COMMAND)
ifeq ($(USE_JRE),1)
  JAVA_TO_TEST = $(JRE_COMMAND)
endif

https://github.com/adoptium/TKG/blob/53fb20ae51018f0a2f7ca2c05347c0149151f382/settings.mk#L173

[andrlos]

hm, I would like to use the JAVA_TO_TEST variable as it obviously does exactly what I want - stores a path to the JRE installation in case USE_JRE is checked.. however.. there is also a TEST_JDK_HOME as well variable and the real question is: are they not supposed to be pointing to the same java location? TEST_JDK_HOME still links to the SDK installation in case the USE_JRE is set to 1. I am just trying to avoid rewriting the code in the future..

[adamfarley]

That sounds like an extensive change to the playlist files, so they use JAVA_TO_TEST instead of JAVA_COMMAND.

One alternative is something like this:

JAVA_COMMAND:=$(Q)$(TEST_JDK_HOME)$(D)bin$(D)java$(Q)
ifdef JRE_IMAGE
  ifeq ($(USE_JRE),1)
    JAVA_COMMAND:=$(Q)$(JRE_IMAGE)$(D)bin$(D)java$(Q)
  endif
endif

JAVA_TO_TEST = $(JAVA_COMMAND)

Plus maybe error messages if the user specified USE_JRE and there was no JRE_IMAGE

[andrlos]

@adamfarley okay, so what you are saying is that both JAVA_COMMAND and JAVA_TO_TEST should always point at the same location, whereas TEST_JDK_HOME will always point to the sdk installation, correct?

[smlambert]

TEST_JDK_HOME is the enclosing folder of the jdk under test whereas JAVA_COMMAND and/or JAVA_TO_TEST is the java executable within the home folder, I am guessing as a cleanup to the makefile templates, one would look at removing confusing unnecessary duplicate variable names.

@andrlos - we have had the conversation about using USE_JRE before (see DMs in RH Slack from July 2024), where I mentioned we should utilize it. Some modifications would need to be done for other test groups (like functional or openjdk) to utilize. Typically done in a .mk file in the test group folder.

---

To answer the question in #6653 (comment) - one of the issues is where that git repo is being cloned on the test node, which I believe is not in the workspace under TEST_ROOT, so we can not 'see' it to track it (see related: adoptium/TKG#651) and not where our jobs would clean it up after the run.

---

This has come up in previous conversations around running tests from rh-openjdk repos, ideally. Given how much hidden behaviour lives in the launcher script, what would it take for us to call the test classes directly, as in changing the command from:
https://github.com/adoptium/aqa-tests/blob/master/functional/testHeadlessComponents/playlist.xml#L52-L53
to using direct calls to https://github.com/rh-openjdk/TestHeadlessComponents/blob/main/testHeadlessComponents.sh#L87C3-L87C123 instead of calling testHeadlessComponents.sh.