huronbikes  I started a general discussion on https://wildfly.zulipchat.com/#narrow/channel/174184-wildfly-developers/topic/WFLY-19966.3A.20externalizing.20HornetQ.20code.20from.20WildFly

ehugonne1@redhat.com After reading the CVE, it looks like one of the 2 recommended mitigation options is to assign permissions to the temp file, as the default mode creates a file readable by all members of the group that presumably the consumer is running.

The fix seems to be: https://github.com/hornetq/hornetq/pull/2144
This fix uses option 2 in the suggested mitigations, creating temp files user+rw only.

Even releasing a new version of HQ client jar wouldn't fix this CVE which is basically: you create a temp file in java.io.tmpdir , if you can explain to me how to fix that issue then I will happily find a way to release that new version (like we managed 2 years ago to have jakartaEE support). I'm trying to find a constructive way to 'fix' that 'CVE' but that's out of my reach.
We are getting a bunch of false positive from scanners, in my humble opinion this is just one more and doesn't justify removing that feature as people are still using very old versions of WildFly and will find this useful for migration. This seems quite similar to https://groups.google.com/g/wildfly/c/5IcEUar6TqA
WildFly policy is to use Galleon to trim down your server by removing the features you don't use while providing everything in the zip/tar.gz or container image.
Also I will also reiterate that, as of today, you should use Galleon to produce a trimmed down version of your server that you would copy on a simple java docker image instead of using a full wildfly.

ehugonne1@redhat.com I am not here to litigate whether something or not is a CVE, the presence of of the hornetq jar triggers any sort of image / filesystem scanner to notify that a vulnerability is present.

From reading, it looks like HornetQ was gifted to Apache ActiveMQ about a decade ago and is now ActiveMQ Artemis.  Given that there has not been a new version published in a couple of years, I would imagine that maintaining the original HornetQ codebase is not a priority, so I doubt there would be an interest in moving HornetQ client libraries forward.  I could also be completely wrong on this.

I'm happy to discuss things if it move towards a solution, and I can say that the solution that I would like to see is that the package that comes from the main "Download" link for Wildfly (how I was initially exposed to getting a Wildfly redistributable) has as few active reported dependency vulnerabilities as possible, which I imagine is a goal shared by Wildfly maintainers seeing as things like Netty are pushed forward.  At this particular point I am getting a tad frustrated by the responses, especially for responses like "the HornetQ team should have rejected the CVE" especially since there might not even be much of a HornetQ team if at all.  Like I said, from engineering perspective the CVE/bug/whatever you want to call it might not be that severe and has mitigations but the fact is that any automated tool that scans images will flag hornetq dependencies in particular and the information from those scan results are not always used by technical people.

So:

Are there any actions I can take to move this issue forward in a constructive manner?
If there are, what are they so I can continue moving this issue forward?

huronbikes Honestly this CVE should have been refused by HornetQ team if it still exists. Basically the issue is that /tmp is too permissive, like I wrote in the linked Jira, setting java.io.tmpdir to any directory with less permissions is sufficient. Sorry but I don't consider this a CVE.
Second, users should use galleon and provisioning to build their images and reduce their exposure to only the features they actually use.

ehugonne1@redhat.com That sounds reasonable but for users subject to automated vulnerability detection done in an unreasonable way, saying "it's ok this thing is here because we won't use it" will lead to administratively-induced hurdles for those users.

As stated, I am not entirely familiar with the codebase for Wildfly so if you have relevant source files or directory I could take a glance at to better understand how this is consumed, I would much appreciate it.

I am less concerned with the vulnerabilities being exploited in this case, what I am trying to mend is the results of a vulnerability scan (spoiler: I probably will add an issue about the velocity-engine version as well but I wanted to go through this one first to get used to interactions and the ebb and flow of reporting issues in Wildfly.  The other vulnerable dependency in that scan result, Netty, is already up-to-date in the Wildfly 35 codebase).  Things like vulnerability scan reports are used by non-technical users and those users will not necessarily be welcome to nuances about the dependencies that show up in scan results and will mostly fall back to "well the number of high/critical is not 0 therefore this is bad".

Like I said, I can take the extreme action of deleting the jar in images created but I think there is a possibility for a better solution that does not break legacy use cases and also does not depend on an unmaintained dependency (or moves that functionality out of the base redistributable archive and offers it as a separate installable package).

I hope that clarifies where I am coming from on this.  Thanks for taking the time looking at this, and let me know if I am being too unreasonable.

1/ the HQ code is required at compilation and at runtime for legacy connection factories.
2/ The code is only used when you are using legacy connection factories. It shouldn't even be provided with galleon provisioning unless you are using that feature.
3/ you can set the jvm tmp dir to another directory with less permissions if you think that issue could be a problem.

Added a Dockerfile and a screenshot with results from Trivy.  To reproduce, run `docker build . -t wildfly && trivy image wildfly` in a directory with the docker image.