Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Artifacts are downloaded over (unencrypted) HTTP #248

Closed
Marcono1234 opened this issue Aug 27, 2021 · 3 comments
Closed

Artifacts are downloaded over (unencrypted) HTTP #248

Marcono1234 opened this issue Aug 27, 2021 · 3 comments
Milestone

Comments

@Marcono1234
Copy link

Hello,
in the recent years supply chain attacks have gotten a lot of attention, and recently Maven got a CVE with base score 9.1 assigned because it allowed fetching artifacts over (unencrypted) HTTP by default.
Newer Maven versions will not download Maven artifacts over unencrypted HTTP anymore by default (see mailing list post).

However, this does not seem to affect Tycho / p2 due to its different repository layout (p2) and unfortunately using http URLs as repository seems to be somewhat common for Tycho users (just have a look at the tests and demos of this project).
Please correct me here if Tycho or p2 is providing any additional integrity protection (by default!) for artifacts downloaded over HTTP. Even the p2 files published on the release sites of the Eclipse IDE use HTTP links, e.g. https://download.eclipse.org/releases/2021-06/202106161001/artifacts.xml.xz has a HTTP URL as p2.mirrorsURL.

Maybe as temporary solution it would therefore be good if Tycho automatically replaced all http: repositories the user specifies (or which are used as mirrors) with https: and emitted a warning. In the future it might be reasonable to completely disallow http: unless the user explicitly enables it in the Maven settings (similar to how Maven handles it now for Maven artifacts).

A similar topic are also mirror sites: Consider for example this Eclipse list of mirrors. While I don't want to discredit any of the sites, I want to note that I have never heared of some of the companies or universities before. In case there is indeed no additional integrity protection in place (again please correct me if I am wrong here), then this widens the attack surface for an attacker a lot. Also the Eclipse site for becoming a mirror does not mention any security requirements or audits; though I assume the Eclipse Foundation might not have the resources and capacity for this. My main point here is that without any additional protection (enabled by default), mirrors might impose a security risk as well.

What do you think?


Note that this is about supply chain attacks during development and building using Tycho. I am aware that products which use the created bundles (such as Eclipse IDE) may implement additional integrity protection such as signature checks and are therefore not (completely) affected.

Also a workaround can be to specify an internal repository as Maven repository mirror, though this is most likely not an option for small companies or hobby projects.

Mirror settings example
<settings>
  ...
  <mirrors>
    <mirror>
      <id>internal-repository</id>
      <url>https://example.com/repo</url>
      <layout>p2</layout>
      <mirrorOfLayouts>p2</mirrorOfLayouts>
      <mirrorOf>*</mirrorOf>
    </mirror>
  </mirrors>
  ...
</settings>
@mickaelistria
Copy link
Contributor

Automatically replacing URLs is IMO a bad workaround that would cause confusion.
Disabling http p2 repositories by default should forst be considered by p2,; so please open a bug to p2 and then.Tycho will adapt to it when p2 changes the behavior.

@Marcono1234
Copy link
Author

Created https://bugs.eclipse.org/bugs/show_bug.cgi?id=575688 for this, I hope I chose the correct Component.

@akurtakov
Copy link
Member

This is handled on p2 level side. As p2 warns about such usage now I consider this one done.

@laeubi laeubi added this to the 3.0 milestone Sep 21, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants