1. 13
  1.  

  2. 13

    This is really concerning how widespread unencrypted repository connections still are. I’m the creator of Leiningen, which is the most common tool used in the Clojure ecosystem to download dependencies from remote repositories, and we have blocked non-TLS HTTP repositories since 2014 or 2015. I hope the same fix for Maven and Gradle arrives quickly, but unfortunately it looks like right now they’re talking about only emitting a warning rather than disabling it entirely.

    1. 2

      This isn’t entirely accurate: we’ve deprecated HTTP access with intent of disabling it entirely Jan 15, 2020 (link).

      It’s very disconcerting 1) how many Java 1.6(!) build agents utilize Central (which won’t work w/ modern TLS); 2) how many major projects are still using HTTP as part of their build pipelines; and 3) (as you mention) how widespread unencrypted repo connections still are… I believe Maven and SBT changed defaults re: non-TLS connections around the same time as Leiningen.

      Regardless of how much notice and outreach is done around this change, things are going to break for a lot of people. Like so much in software/tech, CI infrastructure really seems to age more like milk than wine…

      1. 1

        I believe Maven and SBT changed defaults re: non-TLS connections around the same time as Leiningen.

        Changing the default repository to use TLS is not really the same as completely refusing to load non-TLS repos out of the box; can you clarify which one Maven and SBT did?

        Regardless of how much notice and outreach is done around this change, things are going to break for a lot of people.

        I think of it differently: it’s already broken. This just makes the brokenness visible rather than hidden.

        1. 1

          Changing the default repository to use TLS is not really the same as completely refusing to load non-TLS repos out of the box; can you clarify which one Maven and SBT did?

          You’re absolutely right- the changes I’m referring to involved those tools using TLS to access Maven Central, not removing support for non-TLS repositories.

          The point I meant to illustrate is that even though default configuration of Maven & SBT wrt/ Maven Central changed several years ago, a large portion of traffic is still using old build tools and the non-TLS endpoint. Even if Maven, SBT, etc followed the example of Leiningen, the situation would be the same….

          I think of it differently: it’s already broken. This just makes the brokenness visible rather than hidden.

          It’s certainly broken, and has been for a long time: apathetic or ignorant organizations who don’t bother to update their build environments are vulnerable to tampering of their software supply chain… assuming they are targeted, vulnerable to MITM attacks, other security / technical controls are insufficient to prevent / make such manipulation visible, etc, etc.

          That is a different flavor of broken than causing these organizations builds to fail.

          The bandaid needs to be pulled off, and it will be: Maven Central is disabling its non-TLS endpoints. But making sure this happens in a responsible fashion given the disparate / mature ecosystem is a challenge. The approach being taken involves an ultimate deadline preceded by outreach to users & coordination with other parts of the Java ecosystem- build tool developers, repository administrators, SaaS providers, etc.

      2. 1

        Speaking of lein, how is my PR to make the suggested install script actually check the checksum of the downloaded file? ;)

        Separately, Java moves slowly. It has to.