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
_______________________________________________
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
