The scenario that I'm pushing back on is one where a security team that does not have committer status pushes updates into a repository without knowledge or involvement of project committers. This feels like an antipattern.
100% agree @wbeaton
This should be a dealbreaker for any solution. The only people who should have commit rights to a project are the people who have built karma and gone through a committer election process. If the security team can not get someone in a project to pay attention to a security issue the project should be put through whatever process there is for a misbehaving project.
Yes, this is fair and expected.
Most modules there will just come across and go for IP review very simply. Some of these outliers we'll sort out a better home for or bring to Eclipse as proper contributions.
Nope, all good there @wbeaton. Long ago, there was more confusion on what was an 'Eclipse Release', and for a long time, we were under the impression it was anything in an Eclipse-managed repository. This was just us clearing up that things like the original codebase that we chewed up into what would ultimately get vetted and approached to be Jetty 7 are acceptable to park and archive in an Eclipse-managed repository.
We are happy with consolidating old things into the 'jetty' organization.
Thanks!
https://github.com/jetty/.eclipsefdn/issues/18
We had some premature back and forth on the above issue but I think we need the above questions sorted first.
@wbeaton are you the one to ping on this?
We have had a large amount of repositories at https://github.com/jetty-project for years. The pre-eclipse jetty source is in there and other ancient things as well.
However, we also have a lot of small, one-off repositories for examples and things like that.
One such example:
https://github.com/jetty-project/jetty-helloworld-webapp
All of the commits are from Jetty committers, so this should be a formality, but I would like to understand the best way for us to contribute this to the new github.com/jetty organization.
Our current plan is to create a jetty-cookbook repository and do a many-to-one migration of this example content, but we presume you will need to vet it somehow.
Should we list every repo we want to migrate and let you loose on it? Or do you have a preferred approach?
This feature seemed obvious to me once I saw how Otterdog worked. Not everyone on a distributed development team needs to be well versed in repo configuration, and while ideally, much of the configuration will be worked out as time moves on, it would be useful to have a record of how got to where we get to. If things turn out the way we anticipate we'll have a lot of repositories in here.
- how many Jetty committers and contributors knew about the issue before the release? (did it change during the work?)
Initially, four, the rest once the scope and exposure were determined within the project, and we were moving on to determining the release process and testing.
Two different parties reached out via email, knowing we were implementors of an http/2 stack.
public/private build infrastructure we normally use and maintain ourselves
I suspect we would have started by forking into a private repository and working there with a subset of invited committers, shifting it into an advisory on the main repo once we were in the second phase, as described above.
@droy Certainly, you make fair points regarding Eclipse vs GitHub personnel and anonymity. Ultimately, I try and view it as a measure of mitigating risks. I understand why Eclipse staff have access to a project's repository. Ultimately, we are fine with the current levels of trust in a project-based CVE. Also fine with the structure, layout, and access that Eclipse Staff have, part and parcel of being in an open-source foundation. None of it is strictly necessary because we could manage the repo ourselves just fine, but we get it. Keeping the number of Eclipse Staff with access to a bare minimum would be optimal.
But for whatever reason, embargoed issues feel like a different beast and should maybe be treated differently. That is why I commented here in the first place.
Completely fair @mbarbero, and I will freely admit a lot is going on at Eclipse that is a mystery to me and likely many other committers. For example, I didn't know you could contact Eclipse Security to help determine CVSS rating. They are a pain in the arse and entirely too subjective. Is there a process to reach out and schedule a review for something like that?
I'd propose a thought: is it even advisable to employ GitHub for reporting such vulnerabilities? If the embargo is truly exclusive, the chosen individuals should operate on a platform wholly owned and regulated by them. Is that a feasible proposition? I doubt it.
The difference is in the tooling; GitHub personnel would have to use tools or permissions not available to the public to look through something like that, while Eclipse staff has access by default.
So, I'd like to ask, how can we make sure you're confident that the information under embargo stays safe? What steps, announcements, documents, or checks would make you trust the security team and the whole Eclipse Foundation team more?
I don't know what individuals have access to any given project repository. I know a couple of 'groups' do, but I don't know who all the webmasters are nor who the security group members really are. I suspect the information is somewhere in the mountain of Eclipse documentation. A quick look through the security policy page you linked and the EFDP, and nothing jumps out at me.
I can see who the eclipsefdn-security team is easiest since I can find them in our repository and follow a link to see the five members. Looking at their GitHub profiles, they look like a random group of people on GitHub. We even have 'Bob the Builder'! :)
I checked out https://www.eclipse.org/security/team/ under the Team Members, and the five people listed there as the staff are not the same five people who are in this eclipsefdn-security group. Fred G looks to be missing.
Having a clear Embargo section on /security may be warranted.
A single page listing everyone and their qualifications with access to project repositories would be welcome. Or since it is easy to find out who eclipsefdn-security are within the repository, would it be good to have a similar group for eclipsefdn-webmasters as well so you can easily determine who has access within the repository itself?
[edit] Lord knows I am the last person who should criticize keeping a website or documentation up to date, and I apologize for the nitpick.
@wbeaton linked me to this issue in response to a query I made to him.
A project is informed about an issue under widespread embargo, with knowledge of the vulnerability being restricted to a small set of implementors worldwide. In this scenario, a project is unable to make use of the project repository to deal with the issue. A security advisory on GitHub isn't sufficient to restrict access because some amount of Eclipse staff have access to the repository for management purposes.
I don't know that there is a way around this beyond making a private fork, but since this discussion is about handling vulnerabilities behind closed doors, it is important to consider the case where information should not be exposed either directly or via backchannels to people at Eclipse.
Not a common case, but one that exists.
@pstankie ^^^
No, we are ready to move these repositories. We will be ready this time next week.
We apologize, but some delayed releases require us to hold off a little longer.
This is important; we have worked to improve Google karma a lot, and this doesn't help.
I am able to get the sitemap.xml file so it might just be a PHP thing.
Yeah, it makes sense to get the main repositories in place soon. Then we can sort out some of the others as time goes on. Some I am sure will need to go through the IP donation process, which should be largely trivial for the majority of those.
I need a webhook put into the jetty-website repository, the same one as in the jetty.project repository pointing to jenkins.webite.net
Would be nice if you simply give me the rights to do it, like I have with the jetty.project repo.
We require this webhook to automate some updates to the jetty website.
@pstankie should we open a new issue to coordinate the move to the jetty organization on github?