Improve the handling of http and ftp protocol by the p2 framework.

The following links provide background detail:

• https://nvd.nist.gov/vuln/detail/CVE-2021-41033
• https://bugs.eclipse.org/bugs/show_bug.cgi?id=575688

Some work has been done to log warnings when the use of http protocol is detected in some limited contexts:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=576428

Such warnings were considered undesirable in some environments, e.g., inside a corporate firewall, so support was provided to allow logged warnings to be disabled:

#123

To provide both maximum flexibility and maximum security, we expand the current approach to fully address CVE-2021-41033 and beyond. This description below has been edited to reflect the final design.

We focus on guarding/monitoring p2's transport layer as a whole such that all internet access is taken into consideration, including the following mainstream use cases:

• p2 repository content metadata and artifact metadata, composite children, and repository reference URLs, e.g.,
  • https://download.eclipse.org/releases/2023-03/202303151000/p2.index
• mirror server URLs, i.e., the p2.mirrorsURL property in the artifact metadata, e.g.,
  • https://www.eclipse.org/downloads/download.php?format=xml&file=/releases/2023-03/202303151000
• mirror URLs, e.g.,
  • https://ftp.fau.de/eclipse/releases/2023-03/20230315100
• artifacts URLs, e.g.,
  • https://ftp.fau.de/eclipse/releases/2023-03/202303151000/plugins/bcpg_1.72.2.jar

There are three modes of http/ftp handling:

1. allow -Dp2.httpRule=allow -Dp2.ftpRule=allow

• This is basically what we have now, i.e., log a warning but allow that warning to be suppressed via p2.skipRepositoryProtocolCheck. The warning will be logged for all http/ftp access, not simply once per repository and only for repository URLs.

3. redirect -Dp2.httpRule=redirect -Dp2.ftpRule=redirect

• Any http/ftp URI will be redirected/written to use https/ftps such that no http/ftp request ever reaches out into the network.

5. block -Dp2.httpRule=block -Dp2.ftpRule=block

• Any http/ftp URI will be blocked as if the network were down/inaccessible.

One important question is "what should be the default behavior in the absence of an explicit choice of one of those three"? I propose the framework defaults to block http access. Product/application builders (or even users) can then choose whether to allow such access or redirect such access; they will be alerted to that choice by the exception that blocks the access. (Note that within a corporate firewall, it might well be the case that redirection to https causes failures due to missing root certificates so allow, while not ideal, may be needed in some limited environments where security is ensured via external mechanisms.) In the end though, we decided to make redirect the default because this is assumed to be what most people will want.

Comments on the proposal are welcome!