check whether the server supports HTTPS before making a PR

[monperrus]

some servers don't support https.

if you check for this before opening a PR, you will reduce the number of annoying PRs such as:

• https://github.com/INRIA/spoon/pull/3243
• https://github.com/SpoonLabs/coming/pull/206

[JLLeitschuh]

If your server you're depending upon doesn't support HTTPS I recommend reaching out to your server maintainer to get this resolved. You still have a security vulnerability and unfortunately in some cases, I only provide half the fix, you may need to work with your upstream supply chain to resolve the other half.

The other alternative is to vendor the libraries you depend upon directly inside of your repository.

[nielsbasjes]

First of all I think this is a great effort to make things better!

In some cases however it is not that easy.

Two examples I found:

• https://conjars.org/repo If you connect to it you get

  HTTP/1.1 301 Moved Permanently
  Location: http://conjars.org/repo/

  In my case https://github.com/nielsbasjes/logparser/pull/55 I simply removed this reference completely (apparently old code). Which in the case of conjars seems the best direction anyway.

• https://repository.mapr.com/nexus/content/groups/mapr-public/ Here they use "Go Daddy Secure Certificate Authority - G2" which when used in Maven gives you

  Could not transfer artifact org.kohsuke:libpam4j:pom:1.8-rev2 from/to MapR (https://repository.mapr.com/nexus/content/groups/mapr-public/): sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target -> [Help 1]

  Apparently a well known problem: https://tozny.com/blog/godaddys-ssl-certs-dont-work-in-java-the-right-solution/

So using https fails the build, using http makes the build insecure.

Which I reported here https://issues.apache.org/jira/browse/DRILL-7529

[JLLeitschuh]

I remember running into the issue with GoDaddy's certs at my last job when running with OpenJDK 10. Early versions of OpenJDK 10 didn't ship with the GoDaddy certs.

---

To further complicate the issue, there are some users that do this:

<url>http://my-custom-repo.example/repo/aaa/{custom.maven.variable}/m2</url>

For cases like that, this wouldn't have been able to check either without actually doing the maven variable resolution (not something I really wanted to attempt).

[PyvesB]

To further complicate the issue, there are some users that do this:

<url>http://my-custom-repo.example/repo/aaa/{custom.maven.variable}/m2</url>

For cases like that, this wouldn't have been able to check either without actually doing the maven variable resolution (not something I really wanted to attempt).

This seems like a rather obscure edge case, I've never seen it done in practice. How about simply dropping the extra check for those? I reckon it would still cover a vast majority of cases (probably >99%?).

I only provide half the fix, you may need to work with your upstream supply chain to resolve the other half.

Not quite. In a lot of cases the right answer is switch to a different Maven repository. If the check was performed beforehand, you could raise an issue instead of submitting an invalid pull request.

Regardless, thanks for raising awareness around some of these issues! 👍

[PyvesB]

As a side note, it may be useful contributing to Maven, for example to print out a warning when a non secure repository is being used. 😉

[JLLeitschuh]

I've already got an open issue with them. https://issues.apache.org/jira/browse/MNG-6673

I work for Gradle, we started doing this in Gradle 6.0 and will be dropping support for HTTP without explicit opt-in in Gradle 7.0.