| Re: [eclipse.org-planning-council] Future of Jarsigning requirement |
_______________________________________________You mention a trust store and prefilling it to skip dialogs. These are details that I assume you know well. I know next to nothing about that, so I cannot comment on what is already implemented and what is not yet implemented Nor does it really matter at this point. I trust that something very cool will be implemented and your assurance that "it may take 2 releases" before it's ready is more than enough assurance that we are on the right path and will proceed when we are ready. I hope it doesn't take that long! I was hoping we could have what's needed for the coming release to move forward more quickly. In any case, I can assure you that we (and I) have trust in you.
I support 100% this new direction and I will support 100% changing the rules when we collectively agree we have achieved lift-off.
I have no requirements to add because that isn't my role nor responsibility. I believe strongly that the PGP proposal will more than fulfill the requirements, which in the end boils down to "we want to make sure that users install only what we provide and not some crap that some evil person tries to inject in its place". In the end, that's the only requirement...
So please make the following assumption: we need only implement the best and most usable new security mechanism. Trust that we as a group will be more than happy to support that, and that I personally will help as best I can. No one will try to throw a new hurdle in the way. Not if I have anything to say about it.
On 14.10.2021 19:56, Aleksandar Kurtakov wrote:
On Thu, Oct 14, 2021 at 8:51 PM Aleksandar Kurtakov <akurtako@xxxxxxxxxx> wrote:
On Thu, Oct 14, 2021 at 7:55 PM Ed Merks <ed.merks@xxxxxxxxx> wrote:
Comments below.
On 14.10.2021 17:26, Aleksandar Kurtakov wrote:
Again, I'm 100% in favor of this new direction. I believe we will be successful in rolling out this better approach and it will make our lives simpler and easier.
On Thu, Oct 14, 2021 at 9:55 AM Ed Merks <ed.merks@xxxxxxxxx> wrote:
Jonah,
I think the direction is good, but there is a but.
1) -0.5 At this point, I don't think we should approve changes to the requirements for the current release cycle but rather indicate that we intend to do so for the next release cycle, with the caveat that the current release will release with a fully-functional, properly-vetted implementation of the proposed PGP approach. Why? Because a great many people update their installation from the previous release to the latest release if not broken by https://bugs.eclipse.org/bugs/show_bug.cgi?id=576506 on Windows. If those people see warnings about unsigned content they'll be rightly concerned. Of course I do not know the current state of the 2021--09 PGP implementation and few of us do. Maybe it's already fully functional in 2021-09 without security flaws. But, based on lack of details on this front, I personally will not give this a +1.
I was never under the assumption that we speak about 2021-12. More like "when we have feature XXX available" mode. Right now the PGP support is full featured except for missing the initial set of trusted keys and I do realize this is release critical so there is no warning about unsigned content. It is important that we make a decision about the path here - if PGP signing is gonna be allowed we are going to work on initial truststore and ways for products to preset its content at build time so 2021-12 is released in a way that later updates can handle PGP signed content properly. This requires acting now though as in - changing requirements for signing with clear prereqs for these requirements to take effect. Spending time on unknown prereqs is plain unproductive and halts progress here.
I know well the feeling of how hard it is to keep your head above water.FWIW, this week I've fixed 2 CVEs (guava 21.x and jsoup 1.8 usages) that are in our 2021-09 and our user base is vulnerable right now. The issue is not these have been found late or smth like that - they were known but our processes are so cumbersome that the current committer base can't keep up.
I think we're all on the same page then. We all agree we need a new and better approach and we should take immediate steps toward making that a reality. I just got the fuzzy feeling that I am being asked to sign a blank check. I will most definitely approve changes to the requirements, when the new design is concretely available and verified.This calls for ***immediate*** actions so we work towards providing a working solution and not shipping vulnerable(e.g https://www.cvedetails.com/cve/CVE-2021-37714/) but jarsigned content. It may take 2 releases to achieve the desired technical state but every delay lost on making a decision about what is required makes one or more releases vulnerable content is shipped in our releases, probably more in every next release looking at change of affairs lately.
What I am asking for is to get the verification requirements right now so we can implement them.
So supporting truststore which can be prefilled by products to skip the user visible dialog whether they trust a PGP key is all that is not implemented. Are there other requirements? It's impossible to fulfill requirements if they are not known.
_______________________________________________
2) Of course -1 for this unless there is a +1 for 1).
3) +1 We should ask for a review of the PGP proposal and its current released implementation in 2021-09.
4) +1 Note though that whatever is done here impacts the installer and that falls on me personally to resolve. The installer has "extended" p2 in rather invasive non-API ways (because p2 has so few APIs). The installer can remember the licenses (SUAs) the user has agreed to, can remember that the user is okay with unsigned content, and can remember certificates. These are important usability concerns. All this is easily broken by the platform and when that happens a lot of righteous finger pointing ensues. So all such work ends up not just being thankless, but really unpleasantly thankless, and that's something I wish we, as a team, will avoid.
_______________________________________________
Regards,
Ed
On 13.10.2021 20:33, Jonah Graham wrote:
Hi folks,
We had a fairly productive meeting on Wednesday with regards to the future of the Jarsigning requirement.
The current signing requirement is defined as follows in the simrel requirements:
Signing (tested)
Projects must use signed plugins and features using the Eclipse certificate.
[added 12/2015, for Neon]. Note: If a jar is already signed by the Eclipse certificate, then it must not be re-signed by projects for the release train.
And the handbook says:
Signed Artifacts
Where technically sensible, all downloadable artifacts should be signed by an Eclipse Foundation certificate.
Proposal
This is the proposed replacement for SimRel
Signing
Projects must deliver signed plugins and features to the Eclipse SimRel repository. These can be jarsigned with the Eclipse certificate, or they can be signed using a PGP key in the web of trust of the Eclipse Foundation key with the signature stored in the p2 metadata. The Eclipse Webmaster issues per-project keys which are suitable for such use.
It is permissible to sign with both methods, see the wiki entry on Jar Signing to ensure that the multiple signatures are handled correctly or for any other information on how to perform the signing.
The signing of artifacts delivered by SimRel is an important piece to achieve the overall goal of "Build artifacts made available at the Eclipse Foundation are verifiably the ones built by respective projects." The signing allows users to either as part of the installation, or at a later time, to verify that the downloaded artifacts are the ones that various projects have published. See the wiki entry on Jar Signing for information on how to perform such verification.
The Eclipse Platform (Equinox's p2 specifically) will verify, using checksums, that downloaded artifacts match the checksums in the metadata. Users can optionally enable various levels of signature verification as made available by the Eclipse Platform (Equinox's p2 specifically).
Assuming the above is acceptable for SimRel, then the Eclipse Handbook could be updated to read as follows:
Signed Artifacts
Where technically sensible, all downloadable artifacts should be signed by an Eclipse Foundation certificate or a PGP key that is in the Eclipse Foundation's web of trust.
What Next?
There are a number of items left to resolve:
1) The Planning Council must approve the changes to SimRel requirements. Please reply +1 to indicate your approval.
2) The Planning Council will recommend to the Eclipse Foundation the changes to the handbook. Please reply +1 to indicate your approval of this recommendation to the Eclipse Foundation.
3) The Planning Council will recommend to the Steering Committee that an audit of the security practices of the SimRel be conducted. Please reply +1 to indicate your approval of this recommendation to the steering committee.
4) The Eclipse Platform team has indicated their intention to do some additional usability improvements. The summary is that the current implementation of PGP signing in Eclipse Platform causes security prompts to confirm users trust the content (IIUC similar to how self signed jars are presented). Please reply +1 to indicate your approval with having an initial release with these prompts.
Therefore, can all planning council members reply with +1 for each of the four items. I think the first three above are fairly straightforward. If you don't think the third item is ok as is, please indicate what you believe the minimal viable implementation looks like?
Thanks,
Jonah
~~~
_______________________________________________ eclipse.org-planning-council mailing list eclipse.org-planning-council@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/eclipse.org-planning-council
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/eclipse.org-planning-council
--
Aleksandar KurtakovRed Hat Eclipse Team
_______________________________________________ eclipse.org-planning-council mailing list eclipse.org-planning-council@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/eclipse.org-planning-council
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/eclipse.org-planning-council
--
Aleksandar KurtakovRed Hat Eclipse Team
--
Aleksandar KurtakovRed Hat Eclipse Team
_______________________________________________ eclipse.org-planning-council mailing list eclipse.org-planning-council@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/eclipse.org-planning-council
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/eclipse.org-planning-council