Proposal: Improve security by using a new domain for all future project websites.

Based on the  community’s feedback on issue #732 (closed), we've gone back to the drawing board, and we’ve created a new proposal for Eclipse project websites, based on these specific criteria:

• A long domain name, such as websites.eclipseprojects.io is not desirable
• SEO is important
• Existing Eclipse.org/projectname URLs are important assets and must be preserved
• Projects should be able to choose to transition or not.
• Security is a journey, not a destination

This domain choice will have no impact on existing project websites, which will continue to be hosted at eclipse.org/projectname. Only new projects that come onboard after the community has decided will be in this new domain.

That doesn’t mean existing projects can’t also use this new domain, only that any such domain transition will be up to the project.  

At this time the Foundation currently owns the following ‘Eclipse’ domains:

• Eclipse.dev
• Eclipse.run
• Eclipse.team
• Eclipse.zone
• Eclipseprojects.io

We'd like to set November 15th 2022 as the deadline to conclude the selection, as it gives everyone attending EclipseCon a chance to discuss it in person, and also allows us to keep moving forward.

changed due date to November 15, 2022

added IT-prioritymedium IT-severitynormal Infra ~40426 team:infra labels

assigned to @mward

added to epic &1 (closed)

mentioned in issue #732 (closed)

It is unclear why you want to move projects to a different domain. Can this please be explained?

Eclipse.org/projectname URLs are important assets and must be preserved

This may not be correctly formulated. I think you mean "existing eclipse.org/projectname"?

From #433 (closed)

"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."

Thanks @jkangrnn for finding and posting that.

@wjongman, You're right, that is better, I've updated the description.

@mward, just to be sure, this separation will limit the risk of this kind of attack between "eclipse foundation resources" vs "eclipse projects resources.

But not between different "eclipse projects resources" as they will all be hosted under same domain.

Is that correct ?

I would think that the projects domain are static websites only and therefore do not have that risk. @mward?

@sbernard You've got it right, which leads me to:

@wjongman We're encouraging projects(when asked) to adopt static websites(we even have a Hugo based skin to get them started) as they update their websites. And yes longer term as more project websites adopt static pages the 'inter-project' risk will drop.

We're certainly open to a conversation about deprecating PHP support in future, but that's outside the scope of this issue.

We're encouraging projects(when asked) to adopt static websites(we even have a Hugo based skin to get them started) as they update their websites. And yes longer term as more project websites adopt static pages the 'inter-project' risk will drop.

But will the new subdomain be shared with vserver which hosts demos. E.g. We currently have a Leshan demo hosted at : https://leshan.eclipseprojects.io (which is not static at all) So in this case, we are exposed again to those kind of cross-(sub)domain attacks, right ?

We are also using https://app4mc.eclipseprojects.io for demo cloud application.

changed the description

@mward Is the goal of this process to determine one particular domain from among the domains that the EF owns and use that one as the domain for future projects (and existing projects that decide to move)?

If so, then I think that eclipse.dev might cause users to believe that the content hosted there is temporary only and is part of some tests (during development).

In general, all these domain names seem to share the same problem of raising suspicions that someone might have claimed a domain close to the original (eclipse.org) with the intent of luring people into some fraudulent activities. One of the reasons for this might be that the TLDs used (dev, team, run, zone) are quite exotic FMPOV and are seldomly encountered with any official offerings.

.dev is not unheard of, especially in the frontend community, see for example https://vitejs.dev/, https://svelte.dev/ or https://lexical.dev/ (an official Facebook project).

@khudalla Yes. I'm not sure there's much we can do about the issue of 'this seems suspicious' with these TLDs, aside from starting to use them.

Something I happen to like about .dev or .run is that the domain length is the the same as it is now.

Tycho has chosen to transition to https://tycho.eclipseprojects.io/ what gives a nice domain, so my vote (if there is any) would be

eclipseprojects.io

Yes, I like that too.

BIRT is currently hosting at https://eclipse.github.io/birt-website/

https://birt.eclipseprojects.io is a great location.

@wjongman you just need to open a Ticket for EF Infra so the "connect" https://eclipse.github.io/birt-website/ to https://birt.eclipseprojects.io so there is even no need to change anything.

Just a note of caution around subdomains and eclipseprojects.io . We are currently using that notation to indicate a project vserver is running, so potentially there are a handful of projects that will experience a collision. We will certainly work with those projects to get around that should this path be chosen.

"a project vserver"

What is that? An opportunity to run nodejs and other services?

While outside the scope of this issue, in the past when a project needed something extra(usually a demo service of some kind) we tried to help out by deploying a small vm that is managed by the project(the Infra teams support is limited to "we'll pave it for you, and you can start over"). They've generally fallen out of fashion, so there are only a few still active.

"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.

If that is the main problem which should be solved, the problem still remains when all projects move to (the same) other domain.

So I suppose that the EF's target is more to split up project sites and the EF website to be served from different domains. If that is the case, I suggest (as it also was already suggested somewhere else) to just move the EF website to another domain, e.g.:

eclipse-foundation.org

And leave all of the project sites at eclipse.org/<project>

The eclipse.org domain is for both existing projects and the Foundation. Any change to that is over my pay grade, and would require the membership to provide that direction.

The specific question is: where should all new projects go from this point forward? To better collect the results I've created https://www.surveymonkey.com/r/QNMJP8L ,

The survey misses one essential option : eclipse.org

Any change to that is over my pay grade, and would require the membership to provide that direction.

So what, let add EF into this discussion. I think almost all projects want eclipse.org/project shema remain.

I think the best option would be to keep eclipse.org/<project> forever. There is just too much history for this to be thrown over board. The organisation can move to eclipse-foundation.org, which I think makes more sense. Especially given that employees of the Foundation are already using nn@eclipse-foundation.org. The redirect from https://eclipse-foundation.org to https://www.eclipse.org/org/ should be swapped. I think this would be the least disruptive solution.

The eclipse.org domain is for both existing projects and the Foundation. Any change to that is over my pay grade, and would require the membership to provide that direction

As a member of the Board representing the Contributing members, I would like to raise this as a Board issue.

mentioned in issue #1850 (closed)

Seeing as #732 (closed) is now closed (as wontfix) can its dependent bugs be closed since eclipse.org/<project> is being preserved for existing projects? e.g. #1850 (closed)?

While the website location has been 'settled', that was only part of those issues.

The other part(about moving repositories to Gitlab/Github) is still ongoing, and in line with the https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Gerrit/Gerrit-and-Bugzilla-deprecation-and-migration-plan .

mentioned in issue #1849 (closed)

mentioned in issue #1777 (closed)

mentioned in issue #1877 (closed)

Hi Mat,

I also share the concerns raised above with splitting the projects into old and new. The cleanest solutions seems the introduction of eclipse-foundation.org for the critical assets, as raised before and again by Thomas above. It seems to be the most popular option by the community, too. Would you mind commenting on this option?

Best regards, Jonas

mentioned in issue #1757 (closed)

mentioned in issue #1899 (closed)

Hey, Paranoid Matthew is Paranoid. Could you register eclipse-foundation.org even if you aren't going to use it... since these conversations are archived, I'm afraid a bot will register it first.

I think the EF already have it, they use eclipse-foundation.org for email already.

Yep, we do own the domain, as Jonah said.

https://www.eclipse-foundation.org is currently not redirecting to https://www.eclipse.org, but that can be fixed.

I've been meaning to fix that....

Yes, Eclipse Foundation staff is using eclipse-foundation.org for their emails for quite some time now, so imho it would be quite consistent with this practice to also use the eclipse-foundation.org domain for everything apart from Eclipse project content.

This point may have been lost in the process thus far, but as the premise is for improved security, the topic is not specifically about EF static content pages on eclipse.org. This is about EF-operated apps on the domain that require user authentication and session management, which makes a single domain a security issue when mixed with code/content that is not managed by EF staff, is old, unmaintained, abandoned or otherwise written by people who are/were not security-conscious at the time.

With the above proposal, we'd likely consider the following moves:

• gitlab.eclipse.org to gitlab.eclipse-foundation.org
• download.eclipse.org to download.eclipse-foundation.org
• archive.eclipse.org to archive.eclipse-foundation.org
• projects.eclipse.org to projects.eclipse-foundation.org
• accounts.eclipse.org to accounts.eclipse-foundation.org
• bugs.eclipse.org to bugs.eclipse-foundation.org
• wiki.eclipse.org to wiki.eclipse-foundation.org
• eclipse.org/downloads to eclipse-foundation.org/downloads
• eclipse.org/forums to eclipse-foundation.org/forums
• events.eclipse.org to events.eclipse-foundation.org
• marketplace.eclipse.org to marketplace.eclipse-foundation.org .. and likely more.

We felt it was less disruptive to move project websites (with permanent redirects to preserve precious URLs), but as this topic has been brought to the Board level, we will resume discussion there.

Thank you @droy for the information and taking this to the board.

This is about EF-operated apps on the domain that require user authentication and session management

I hadn't understood this aspect. Which is why I suppose you have download.eclipse.org and archive.eclipse.org as contenders to move to the eclipse-foundation.org domain, even though they contain project content rather than EF content.

I imagine anyone objecting to eclipse.org/<project> being moved elsewhere is likely to be affected by download.eclipse.org/<project> moving too.

@jograham True, but from my POV download.eclipse.org (and others) is not a URL that is really "user visible" nor SEO relevant for most projects. It is rather linked from a project homepage. Setting redirects for the above mentioned assets would also solve the issue of broken links. It also seems to me like a more contained/manageable list compared to the project web sites, so it might be easier to handle the redirects for these assets.

Hi @jograham . For completeness, I am not the one bringing this to the board's attention, but EF staff will happily explain when asked to do so.

download/archive.e.o are particularly scary cases - the 404 handler page (PHP) uses the single-sign-on session cookie to manage committers' access to archiving/deleting content. In this regard, anyone with write access [including: a compromised build or CI system] to archive.e.o could craft something to intercept that session cookie to schedule deletions.

The threats are real. @mbarbero could share more with you. It's the stuff that keeps me awake at night.

@jonas I agree that many of the mentioned URLs are not really "user visible", but from my POV download.eclipse.org and archive.eclipse.org are the main places to store update sites and larger content with a stable address. At least in our products there are predefined links to update sites.

@jograham The relatively new possibility to allow committers' access to archiving/deleting content is nice to have. As long as the build servers can access the content, it is fine for me to handle archiving/deleting via build jobs. Perhaps it is an alternative to drop the PHP handlers and keep the stable location.

@hmackamul : I agree, but if downloads is moved to downloads.eclipse-foundation.org, I guess a "product" would not care to be redirected from downloads.eclipse.org to the new address (compared to a user). This way, the address could be kept stable.

mentioned in issue #2020 (closed)

mentioned in issue eclipsefdn/emo-team/emo#360 (closed)

mentioned in issue #1885 (closed)

mentioned in issue #1259 (closed)

mentioned in issue #1789 (closed)

mentioned in issue #1755 (closed)

mentioned in issue #1880 (closed)

mentioned in issue #1862 (closed)

mentioned in issue #1895 (closed)

mentioned in issue #1892 (closed)

mentioned in issue #1873 (closed)

mentioned in issue #1868 (closed)

mentioned in issue #1857 (closed)

mentioned in issue #1843 (closed)

mentioned in issue #1823 (closed)

mentioned in issue #1821 (closed)

mentioned in issue #1811 (closed)

imo it shall be consistent for all projects, and mixing domains for old/new seems confusing,

so i guess the eclipse-foundation.org / eclipse.org/<project> separation as suggested by Thomas ( #1991 (comment 1020172) ), even for new projects fits well.

Given that project vservers are already using the eclipseprojects.io domain, I removed it from the choices here: https://www.surveymonkey.com/r/QNMJP8L .

As pointed out by others earlier, the survey does not list eclipse.org as a possible reply option. Also imho any survey should have an "other" option that allows to specify another reply to make sure all voices are heard.

good point. e.g., eclipse.org/projects/xxx

mentioned in issue #1799 (closed)

mentioned in issue #1779 (closed)

mentioned in issue #1739 (closed)

mentioned in issue #1745 (closed)

mentioned in issue #1756 (closed)

mentioned in issue #1781 (closed)

mentioned in issue #1832 (closed)

mentioned in issue #1875 (closed)

mentioned in issue #1879 (closed)

mentioned in issue #1754 (closed)

mentioned in issue #1845 (closed)

mentioned in issue #2024 (closed)

mentioned in issue #1865 (closed)

mentioned in issue #1827 (closed)

mentioned in issue #1884 (closed)

mentioned in issue #1743 (closed)

mentioned in issue #1890 (closed)

mentioned in issue #1759 (closed)

mentioned in issue #1767 (closed)

I'm mixed up.

FMPOV, we first need to see, which kind of "domains" we are using.

As @sbernard already pointed out, "leshan.eclipseprojects.io" or "hono.eclipseprojects.io" or "californium.eclipseprojects.io" are no web-sites, that are sandboxes, even serving other protocols than http/https.

We have for now two kind of web-sites for projects:

https://www.eclipse.org/californium/

https://projects.eclipse.org/projects/iot.californium

With that, it looks like we need 3 domains per project.

If "project.eclipseprojects.io" is used for sandboxes, I don't think it makes sense to use it for the project website. otherwise that causes pain (again, we have moved them 2-3 years ago) on the sandboxes.

mentioned in issue #1741 (closed)

mentioned in issue #2171 (closed)

mentioned in issue #1848 (closed)

mentioned in issue #1793 (closed)

mentioned in issue #1923 (closed)

I support Denis's proposition (#1991 (comment 1025401)) to move any Eclipse Foundation website which required credential to a new root URL, and to let existing and new projects web page under the eclipse.org/ umbrella. If there isn't any more login capability with eclipse.org websites, the security risk will become dramatically lower. As Maximilian said, the survey doesn't reflect the discussions at EclipseCon as it forces the move (or the split) of project pages to a new url root, which is not our preferred path.

Just to clarify - I was not proposing anything. The language from my above comment ("With the above proposal, we'd likely consider the following moves:" ) may be unclear.

The "above proposal" was a reference to Maximilian's suggestion: "use the eclipse-foundation.org domain for everything apart from Eclipse project content."

My comment was to state that, "[moving] everything apart from Eclipse project content" to a new domain also means moving Wiki, GitLab, Bugzilla, Forums, Projects, and all the other sites I've listed. Not just eclipse.org/ Foundation pages.

In other words, moving everything apart from Eclipse project content is immense.

We are still in internal discussion about this. More to come.

changed due date to November 30, 2022

Apart from the technical / security considerations, IMHO separating the Foundation website from project content opens up opportunities to strengthen the Foundation's brand.

To clarify what I mean: go to https://www.eclipse.org – you see the Eclipse Foundation logo on the left and a big orange Download button on the right. Click that button and you see "Get Eclipse IDE 2022‑09". This emphasizes a direct link between "Eclipse Foundation" and "Eclipse IDE". As I perceive the Foundation today, it should rather be presented as an umbrella for all sorts of technologies, however I still see widespread confusion of what the Foundation is because the link to Eclipse IDE is is burned into the minds of many folks out there.

@droy

May I ask what might be a totally stupid question? So please excuse my ignorance!! It is possible to establish cookies/passwords on each subdomain (and only those that need it) separately rather than at the eclipse.org domain level? I know that means no single sign-on, but I think most of us could live fine with that; it seems I have to sign-in separately for every ci instance already (and then I sometimes reach my cookie limit for eclipse.org and have to clear them all).

@emerks Not stupid at all. The answer is yes. subdomains help.

The domain session cookie is a security issue the EF needs to resolve, independently of everything else. For that, we need to alter the authentication for Forums, Wiki, download/archive.eclipse.org and perhaps others. But that will take a lot of time and testing, and during that time, the security exposure does not go away.

The issue at hand is more than just a cookie, or cookies. XSS and CSRF are also part of the issue. Unmaintained and insecure project website code is a huge part of the issue, and there is so much of it. Not to pick on a project, but there's all kinds of legacy happening here:

https://git.eclipse.org/c/www.eclipse.org/modeling.git/tree/includes/scripts.php

As the purpose of this Issue was to choose a potential new domain for project websites, eclipse.dev has emerged as the best alternate domain.

There is still more to come. I'd like to thank everyone for the feedback and for the discussion so far. Everything is read, everything is considered.

I will create another issue later this week, or early next week, with more information. I will link to it on this issue, and also on issue #732 (closed), so that no one misses out on anything. We will also post an update on eclipse.org-committers at that time.

Stay tuned.

closed

mentioned in issue #1775 (closed)

A new HelpDesk issue has been filed, here: #3069 (closed)

mentioned in issue #3493 (closed)

changed epic to eclipsefdn/it/websites&72