Scott Stark wrote:
These are about the possibility of information exposure during the creation of the specification documents. The mitigation would be to not produce new specifications until that dependency is
updated. It would not be to update the EE10 branch and produce new specs that have zero content changes.
Unless a CVE can be traced to executable code in API artifacts, I can't see a reason for a CVE causing a point release. The requirements around trusted content in terms of SBOMs
and attestations is still a work in progress that the EF will have to set guidelines on and possibly provide CI infrastructure for.
So true. To that end, I have submitted this trivial PR that upgrades the asciidoctor dependencies to versions without the CVE vulnerabilities.
https://github.com/jakartaee/jakartaee-platform/pull/750
Anyone willing to give a review, I’ll merge it.
Also, regarding the maintenance release coordinator role.
Maybe I should convene the platform project meeting 30 minutes earlier to cover these aspects? People can show up early if interested?
Anyone willing to do that? Jan?
| Reply anonymously to this email:
https://purl.oclc.org/NET/edburns/contact
From:
jakartaee-platform-dev <jakartaee-platform-dev-bounces@xxxxxxxxxxx> on behalf of Scott Stark via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx>
Date: Tuesday, August 8, 2023 at 12:24
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Cc: Scott Stark <starksm64@xxxxxxxxx>
Subject: [EXTERNAL] Re: [jakartaee-platform-dev] DISCUSS: Define role for "maintenance release coordinator"
https://bugs.eclipse.org/bugs/show_bug.cgi?id=581580
https://bugs.eclipse.org/bugs/show_bug.cgi?id=581588
Following the documented progress at that time - this may have changed
meanwhile...
Am 08.08.23 um 17:00 schrieb Scott Stark via jakartaee-platform-dev:
> Where are the reported CVEs?
>
> On Tue, Aug 8, 2023 at 8:55 AM Jan Westerkamp via
> jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote:
>> Hi Scott,
>>
>> I disagree:
>>
>> The current situation is not sufficient at all:
>>
>> We are not able to organise thinks in a form, that we are able to fix
>> known CVEs in a given time - let's say 90 days, as shown with the
>> current reported two issues form myself.
>> I recognised, reporting security issues on the (at that time) intended
>> way is not enough to get them fixed.
>> If I want to get it done, then I have to do it by myself. I am in a
>> position where I can push things forward - but it takes very much time
>> and resources to fix it everywhere (completely) at the moment.
>> A normal Contributor, who only is being able to report the issue (and
>> this should be welcome too), can only hope it will be done in some (far)
>> future...
>>
>> And doing a Service Release on my own is another security issue:
>> If one of us get hacked his/her credentials could be used to publish a
>> release on Maven Central with the attack included! Such a release will
>> be advertised to others by i.e. Dependabot then before somebody
>> recognise it as harmful and we again can do a Service Release to fix it...
>>
>> So I think there must be some improvement in our JESP (And EFSP,
>> MPSP...) to raise the barrier to prevent this happen.
>> It also should prevent worse things happen, if anybody changes to the
>> dark side - even if I don't expect this now for all the community
>> members I know and trust well, but this is how zero trust works.
>>
>> We have existing and upcoming regulation in the US and the EU that
>> requires us to make progress, if Jakarta EE is used in critical
>> environments in the future too.
>>
>> And there are organisations that are responsible to do it and get paid
>> for this already: Some companies sell Licences, SaaS-Offerings and
>> Subscriptions to customers, who expect maintenance is done. Some of
>> these Organisations pay for the EF Membership and the Jakarta EE WG
>> Membership. The EF pays their staff for doing work in this direction etc.
>>
>> So expecting community volunteers doing it seams not the best solution
>> to me.
>>
>> I am not sure we need a (separate) role, but we need to do some progress
>> in the security aspect.
>>
>> Best,
>>
>> Jan
>>
>>
>> Am 01.08.23 um 22:25 schrieb Scott Stark via jakartaee-platform-dev:
>>> On Tue, Aug 1, 2023 at 12:41 PM Edward Burns via
>>> jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote:
>>>> Do we need this role?
>>> No. The platform and profile releases are major release only type of
>>> specifications. Service releases for CVEs are the only thing I can
>>> see, maybe doing something for until the next major release is out.
>>>
>>>> How rigorously do we need to define it?
>>>>
>>> Not at all.
>>> _______________________________________________
>>> jakartaee-platform-dev mailing list
>>> jakartaee-platform-dev@xxxxxxxxxxx
>>> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
>>
>> _______________________________________________
>> jakartaee-platform-dev mailing list
>> jakartaee-platform-dev@xxxxxxxxxxx
>> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
> _______________________________________________
> jakartaee-platform-dev mailing list
> jakartaee-platform-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
|
