Proposal: deprecate PHP for project websites

This is no longer a proposal, and has been adopted. The proposal text is below.

1. PHP on project websites on eclipse.dev: projects must migrate to static content by Dec 31, 2024 (in 8 months). Migration paths include using the PMI project page as their home page [1] or migrating to a Hugo-based static site using the EF boilerplate [2] or using your own static website, provided it conforms to the EF guidelines [3]

2. PHP used for download/archive pages: projects must migrate to static content by Dec 31, 2025. (in 20 months). The boilerplate [1] has a section on using Jenking and GitLab CI for this purpose.

3. PHP in EF-backed initiatives: These will be considered individually. In most cases, PHP will remain; these properties would therefore be owned and managed by the EF's WebDev team to ensure a consistent application of a code review/deployment processes across all the code that runs on EF websites. All current authors would be expected to follow this process, which we consider simple in nature, unobtrusive and standard practice for software development. Regardless of the case, we expect these transitions to be complete by Dec 31, 2025.

[1] https://gitlab.eclipse.org/eclipsefdn/it/webdev/hugo-eclipsefdn-website-boilerplate/-/blob/main/README.md?ref_type=heads

[2] https://projects.eclipse.org/projects/

[3] https://www.eclipse.org/projects/handbook/#resources-website

==- Original proposal text:

We've traditionally allowed server-side PHP on project websites. We've always discouraged PHP from executing on download.eclipse.org, but have never enforced it[1]. From a security standpoint, this is a disaster waiting to happen, as there is a lot of old code, written by developers who were not security-aware at the time, still on our servers.

Within 2 minutes, @cguindon was able to find a script, authored in 2008 by a committer who was deactivated in 2009, which gathers info from a form and outputs $_POST back, unfiltered. Over the years, we've discovered many instances of such scripts.

The TPTP project website, long ago, had a hole that allowed an attacker to install a shell and a rootkit. Fortunately, no damage was done.

In the last several years, most project websites have taken the form of static HTML. The EF Webdev team provides UI templates, samples and support for static HTML using Hugo, deployed by a Jenkins CI.

I am hereby proposing that we deprecate and ultimately remove all project-authored PHP from project websites, download/arcvhive.e.o and all eclipse.org servers, over a reasonable span of time.

There are instances where PHP code, written by committers and running on our servers, performs a valuable task for the community: either in the Simrel process, EPP, JustJ, Orbit or others. These cases would be identified, and we'd likely propose working with the authors of such code towards reorganizing those assets in a more traditional software development and deployment environment: code review by EF WebDev team becomes a requirement, a release process is established, and EF Infra team deploys new releases on request.

There is no plan right now, and no immediate action item. Authored here is the problem statement and a proposed solution. The EF will work on communicating this issue, gathering feedback and working with a community on a plan to resolve the problem while focusing on minimizing disruptions to the community.

Unfortunately, this is a current security risk, and doing nothing is not an option.

[1] https://wiki.eclipse.org/IT_Infrastructure_Doc#Use_PHP_on_my_website.3F