Community
Participate
Working Groups
Projects can host two types of application-like resources on the eclipse.org domain, in which the project committers are the content owners: - websites, at eclipse.org/projectname - virtual servers, at projectname.eclipse.org This practice of using the eclipse.org domain is outdated by virtue of being insecure. It facilitates cross-site scripting, cross-site forgery requests and, above all, it enables these applications to access domain-wide cookies, such as those used for certain types of authentication. While we trust our committers, we feel this outdated practice creates unnecessary exposure and is a security auditing nightmare for the Foundation. In bug 543323 we acquired the domain "eclipseprojects.io" and we'll tackle migration over an extended period of time. ** Our primary objective is to improve security. Secondary objective is to ** create as little burden on committers as possible. Third objective is to ** minimize breakage. Here is the proposed timeline: Now: Phase I : existing project vservers, and new ones, get a mapping on eclipseprojects.io, in the form of (servicename).(projectname).eclipseprojects.io Q2 2020: Phase II : Sandbox all eclipse.org project pages onto (projectname).eclipseprojects.io Projects can opt out of a website if they wish, and can use the PMI as their default web presence: (https://projects.eclipse.org/projects/technology.babel) Q2+ '20: Phase III: Work with projects to fix broken elements in the above sandbox Q1 2021: Phase IV : Migration Redirect (301 Moved) eclipse.org/projectname/* to projectname.eclipseprojects.io/* This should avoid broken links All new projects would get an eclipse.org/projectname redirect to their eclipseprojects.io presence.
We'll need to rethink the timeline and/or (sub-)domain as the collision of virtual servers and websites within the eclipseprojects.io domain is non-ideal(see bug: 551282). Lets start by getting all of the vservers moved into eclipseprojects.io, and then we can sort out where the project websites will go. -M.
I have a question regarding the plan, what happens if a projects has both: a) a website at eclipse.org/projectname b) and a virtual server (e.g. a sandbox/demo installation) at projectname.eclipse.org providing an HTTP/HTTPS endpoint? For example, our Eclipse Ditto project's vserver now has been migrated: https://ditto.eclipseprojects.io (we're using LetsEncrypt for providing a valid certificate). What happens when in Q1 2021 our website at https://www.eclipse.org/ditto/ is migrated as well to https://ditto.eclipseprojects.io ? I assume that it will no longer be possible to serve HTTP requests on the virtual server then, right? Is there any way to mitigate that?
(In reply to Thomas J??ckle from comment #2) At this time we have been working to migrate vservers, and dealing with the project websites has been pushed out at least a couple of quarters. We'll let the community know when we have a plan for the project websites, but for now they will continue to live on www.eclipse.org/projectname . -M.
Matt, what is the status here?
All project vservers have been moved. We still don't have an answer for project websites, but I'm hoping to use some of the quieter time in the next week or so to try a PoC for some ideas. -M.
Bug 549360, gotcha.
This issue has been migrated to https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/433.
