Decommissioning HTTP for Gradle Services
Table of Contents
Introduction
Starting in January 2020, Gradle services will only serve requests made with HTTPS. From that point on, all requests made with HTTP will be denied and any builds and artifact mirrors that use a Gradle URL with the non-secure HTTP protocol will fail.
If you are proxying our services through your own artifact servers like Artifactory or Nexus, you will need to ensure that you update your mirror configurations so they are using HTTPS instead of HTTP.
Gradle Services #
This change will impact the following services.
Plugin Portal #
By default, the Gradle build tool uses HTTPS when resolving plugins from the Plugin Portal. You should be unaffected if you do not declare a custom plugin repository.
If your organization mirrors the Plugin Portal
from URL plugins.gradle.org/m2/*, you should check that your mirror is using HTTPS.
Gradle Distributions #
Since Gradle 1.2, the Gradle wrapper has used HTTPS to download Gradle distributions. You should be unaffected if your gradle-wrapper.properties uses a HTTPS URL.
Gradle distributions are served from the following URLs:
services.gradle.orgdownloads.gradle.orgdownloads.gradle-dn.com
If your organization mirrors Gradle distributions from any of these URLs, you should check that your mirror is using HTTPS.
Other Gradle software #
Other Gradle, Inc. produced software is published to an Artifactory repository, such as the Gradle Tooling API. Most builds do not use this repository unless they are building tooling that integrates with Gradle (like IntelliJ IDEA).
The Gradle Artifactory repository is available at repo.gradle.org.
Gradle Build Tool #
Gradle 6.0 deprecates the use of HTTP in build scripts to download resources and artifacts without an an explict opt-in.
For users that require the use of HTTP, Gradle has several new APIs to continue to allow HTTP on a case-by-case basis.
Timeline #
To ease the transition for our users, this change is coming in a few phases.
| When | What’s changing? |
|---|---|
| Gradle will begin redirecting from HTTP to HTTPS. | |
| Disable HTTP for 24 hours and permanently drop support for TLSv1. Postmortem. | |
| HTTP requests to Gradle resources will be denied. Only HTTPS will be supported. | |
Enable HSTS for gradle.com and gradle.org. This change will only impact browsers. |
Users most likely to be impacted #
As a part of this effort, we spent some time analyzing the data from our CDN logs to determine the size of the impact this change would have on our users.
These percentages represent a sampling of our traffic over a 72 hour period.
| Service | HTTP % |
|---|---|
| plugins.gradle.org/m2/* | 0.72% |
| services.gradle.org | 5.77% |
| downloads.gradle.org | 23.87% |
| downloads.gradle-dn.com | 9.76% |
| repo.gradle.org | 9.53% |
Breaking down the traffic for services.gradle.org by user agent, we can clearly see that users of JFrog’s Artifactory are most likely to be impacted by this change.
Similarly, we can see while our biggest user of services.gradle.org is a Java user agent, Artifactory is our
second largest and is more likely to be using HTTP than any other User Agent.
Using this data, we’ve determined that 16% of all Nexus requests, and 11% of all Artifactory requests are using HTTP instead of HTTPS.
We recommend that you audit your corporate artifact mirrors to ensure that they are using HTTPS instead of HTTP.
Why are we doing this? #
At the beginning of June 2019, before joining the Gradle team, I publicly disclosed my research into how many of the most popular projects across the JVM ecosystem had been resolving their dependencies over HTTP instead of HTTPS.
When Sonatype, the maintainers of Maven Central, analyzed their traffic over a month, they determined that 25% of Maven Central downloads were still using HTTP.
As a result of these findings, Gradle is participating in an industry-wide initiative to decommission support for HTTP from all major artifact servers starting on or near January 15th, 2020.
As of the publication of this blog post, these organizations are also participating and have posted announcements: