[platform-dev] Still open Jakarta EE, MicroProfile and Adoptium Bugzilla

[Jan Westerkamp <jan.westerkamp@xxxxxxx>]

Hi Marta,

can you help me regarding how to proceed with these tickets, please?


Jakarta EE:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=581580

https://bugs.eclipse.org/bugs/show_bug.cgi?id=581588


MicroProfile:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=581579

https://bugs.eclipse.org/bugs/show_bug.cgi?id=581586


Adoptium:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=581589


The recent MicroProfile 6.1 made some small progress to fix them, but 
except two component specs all others are still affected, even when 
addressing this was part of the release plan.
We have a similar issue is on the Jakarta EE side, where we (Ed Burns 
and Ivar) discussed how to address this in the new Jakarta Platform 
Maintenance Call a few weeks ago and Ivar suggested to meet with you at 
EclipseCon to find solutions for that.

A main issue is, that these tickets are not public (for good reasons) 
and there is now defined way how to communicate the existence and status 
of them to the component spec leads to let them fix the issues and 
plan/do a release with the fixes.

I tried to address them in the WGs multiple times, but my observation 
is, that the priority to address (at least these) CVEs in the first two 
projects is relatively low (in contrast to the Adoptium and AsciiDoc, 
where the last was the origin of two of the issues with a response time 
of about 2 h and fix within less than a week!). When you want to get 
them fixed, you need to do it by yourself - which is always helpful, but 
should not be the only solution. ;-) Especially you need to have 
Committer rights and I generally prefer the four-eyes-principle.

This communication responsibility gap might be a general issue for 
Eclipse projects and Ivar suggested to bring this up to the Architecture 
Board at EclipseCon to discuss this with Wayne to improve the processes. 
The new OpenSSF Security Insights 1.0 Specification 
(https://openssf.org/blog/2023/10/11/openssf-introduces-the-specification-security-insights-1-0/) 
might be helpful too to address this.

Also there where some discussions about the impact of these issues and 
the need to fix them - especially when being just before the release and 
need an excuse not to fix them yet...

From my perspective, these concrete examples have not the highest 
severity too, but they have the potential for Supply-Chain-Attack and 
should be fixed, especially as there are solutions and workaround 
available to fix most of them with minimum effort. In special cases, 
end-users could be affected by them too. Unfortunately the people also 
do not discuss them on the original tickets at all, where this 
discussion should happen form my point of view.
At the end, somebody need to make a decision about the actions have to 
been taken and I think this is the point where the Eclipse Security Team 
came into responsibility, right?

Also, do you still track these Bugzilla issues at all? Meanwhile they 
need to be reported on GitLab, but they where not mirrored or referenced 
there as far as we could find out.

Last, but not least: The 90 days period is over and then the current 
process requires to make them public. What does this mean in this context?

I hope we can find some time at EclipseCon to discuss this in person and 
find some practical solutions for the concrete and general issues.
I will be in Ludwigsburg and attending the EclipseCon Java Community Day 
on next Monday and plan to leave late on that day/night. It would be 
nice to meet you there!

Best Regards,

Jan