HTTPS: Use HTTPS for downloading artifacts from Maven Central

[rtyley]

Sonatype have enabled HTTPS access for Maven Central:

http://central.sonatype.org/articles/2014/Aug/03/https-support-launching-now/

Note that the Ivy class IBiblioResolver contains the old http url (ie DEFAULT_M2_ROOT="http://repo1.maven.org/maven2/"):

http://svn.apache.org/viewvc/ant/ivy/core/trunk/src/java/org/apache/ivy/plugins/resolver/IBiblioResolver.java?revision=1557968&view=markup#l72

An alternative to this PR would be to wait for that artifact to update, but I can't think of any reason to not just include the url directly, as done with the other repository roots.

[typesafe-tools]

Can one of the admins verify this patch?

[rtyley]

Travis failures are all due to the build boxes failing to download scala, so far as I can see:

sbt.ResolveException: unresolved dependency: org.scala-lang#scala-library;2.10.2: not found

[eed3si9n]

The documentation moved to sbt/website repository.

[eed3si9n]

Hi Roberto. First of all, thanks for the contribution.

I'm somewhat conflicted about this pull request. Generally speaking, using HTTPS is a good thing, but I'm not sure if we should be changing this in the middle of 0.13.x silently. Anecdotally, JVM tends to have weird issues with certificates. There's at least one phone tethering app, which lets you use HTTP for free, but not HTTPS. Am I being too paranoid? If someone runs into some issue, it is possible override the repository list, but the person would be annoyed.

Ivy remembers the artifact locations. What's the user experience if the user switched between 0.13.5 and 0.13.6? Would it invalidate the Ivy cache each time for the relevant modules?

[gourlaysama]

Related note: the Travis failure has nothing to do with all this, there has been a problem with the 2.10.2 artifact on maven central for a few days (see the ML and ticket). See the ticket's comments for a workaround.

[jsuereth]

@gourlaysama Yeah, I'm talking with sonatype about the issue now.

[rtyley]

Thanks Eugene - personally, I think that since people can override the resolver to get back to the non-secure scheme, the preference should be to give the majority of users the convenience of being secure by default.

Other repos like oss.sonatype already use HTTPS, so I guess at least some of the issues regarding using sbt with HTTPS must have come out of the woodwork by now.

Ivy remembers the artifact locations. What's the user experience if the user switched between 0.13.5 and 0.13.6? Would it invalidate the Ivy cache each time for the relevant modules?

I tried this, switching between builds of sbt-launch-0.13.6-SNAPSHOT.jar built on current master sbt and on this branch https-maven-central. Executing clean compile showed the same results each time, with no fresh downloads, so far as I could see.

There's at least one phone tethering app, which lets you use HTTP for free, but not HTTPS.

Gak! That's evil!

[hrj]

One use-case I can think of is people behind restrictive firewalls that don't support https.

However, in spite of that, I think https by default is the better option. People who need http for any reason should get a chance to realize that they are using an insecure channel and consent to using it.

It would be nice if this could be controlled by a flag, atleast during the transitory period.

[rtyley]

It would be nice if this could be controlled by a flag, atleast during the transitory period.

Sonatype have provided some instructions on how to override the http root for the https one here:

http://central.stage.sonatype.org/pages/consumers.html#sbt

...the same config settings would apply if a user had to go the other way (https->http), so (although it's not as concise as a simple switch) I think there's enough support for the http-only user to be able to get by already.

[jroper]

Perhaps we could make a system property that will cause SBT to use http for maven central as an escape hatch in case it causes any problems - we don't want a repeat of the npm certificate debacle (though, hopefully sbt users aren't using sbt on production machines to deploy their app).

[softprops]

re: the travis failures. it's not just you :/ https://travis-ci.org/unfiltered/unfiltered/jobs/31621624

maven central is dog slow today. this slowness is most likely something wrong with their set up but I don't think its this pull causing the failure. the artifact exist and it apparently valid but it takes its like watching grass grow waiting to resolve it from maven central right now.

$ cat scala-compiler-2.10.2.pom.sha1
a5d33ef9ca1c6cc3f6bfd25c34993513e843d5c5
$ shasum scala-compiler-2.10.2.pom
a5d33ef9ca1c6cc3f6bfd25c34993513e843d5c5  scala-compiler-2.10.2.pom

[jswank]

@softprops @jsuereth @gourlaysama Re: slowness in downloading scala 2.10.2 library & compiler: Central has been contending with massive misuse related to these components for almost a year due to Minecraft Forge (basically, every time a minecraft forge user runs their game with specific mods, these components were downloaded). At one point, traffic related to these components was 8x greater than all of the rest of Central combined. We've since redirected (Feb?) all requests to ibiblio, which is "dog slow".

We're open to somehow identifying real/legit requests for these artifacts, but the attempts at using user-agent alone have been unsuccessful at mitigating the problem.

[rtyley]

Regarding build failures and the Scala 2.10.2 dependency, the Scala-project JIRA ticket to follow is SI-8772 ('Builds relying on Scala 2.10.2 artifact in Maven are failing').

The pull-request you're reading right now is for using the newly-enabled HTTPS access for Maven Central, which is a separate issue.

[jsuereth]

@rtyley Rightly said. I don't think moving to https will fix the issue either. We (sbt) are actively looking into possible resolutions for the 2.10.2 issue.

[jsuereth]

@eed3si9n Based on https://twitter.com/sonatype_ops/status/497366716406460416 I think perhaps we should merge this and see if we can fix the performance of 2.10.2 download issue.

[softprops]

@jsuereth 👍

[eed3si9n]

@jsuereth Yea. Scala 2.10.2/Minecraft Forge issue definitely pushes the scale towards using HTTPS by default. I still think we should have an escape hatch system property to revert to HTTP as @jroper suggested.

[soc]

What about reaching out to the Minecraft Forge people and make them aware of the issue so that they can fix this?

[jsuereth]

@soc, they are. The issue isn't the current version but all the people using the previously broken version. The Minecraft Forge + Minecraft people were super helpful/responsive. The community uptick in new version adoption, less so.

[soc]

Thanks for the info! Do you have a link to more details?

[mah0526]

"Fix" should be in place for Central at this point, which should resolve download timeout issues effecting builds. Move to default to HTTPS (per this PR) would still be ideal solution here (we're now carrying some bogus MineCraft Forge traffic again in order to limit impact to your legit stuff).

[jsuereth]

@mhansen-sonatype Thanks guys. PR #1507 duplicates this PR w/ the disable flag, so let's move the discussion over there. Very much appreciate your dedication to our community.

[paulp]

This failure suggests moving to https doesn't suffice to deal with the 2.10.2 timeouts.

[mah0526]

@paulp That link seems to point to a successful build?

edit -- never mind. found the failure (and see the comment below).

[gourlaysama]

@paulp not sure this has anything to do with that. It failed to download 2.11.2 (not 2.10.2) from the http (not https) resolver in your psp-std-root project. Probably just a transient issue.

[paulp]

There's something strange taking place at travis - that's not the link I sent. I don't know if I'm going nuts but I can't find the original build log. However lucky me, I have an excerpt from a gist. You will agree this is 2.10.2 and https.

[info] downloading https://repo1.maven.org/maven2/org/scala-lang/scala-compiler/2.10.2/scala-compiler-2.10.2.jar ...
[warn]  [FAILED     ] org.scala-lang#scala-compiler;2.10.2!scala-compiler.jar: Connection reset (3525ms)
[warn]  [FAILED     ] org.scala-lang#scala-compiler;2.10.2!scala-compiler.jar: Connection reset (3525ms)
[warn] ==== Secured Central Repository: tried
[warn]   https://repo1.maven.org/maven2/org/scala-lang/scala-compiler/2.10.2/scala-compiler-2.10.2.jar
[info] downloading https://repo1.maven.org/maven2/org/scala-lang/scala-reflect/2.10.2/scala-reflect-2.10.2.jar ...
[warn]  [FAILED     ] org.scala-lang#scala-reflect;2.10.2!scala-reflect.jar: Connection reset (3111ms)
[warn]  [FAILED     ] org.scala-lang#scala-reflect;2.10.2!scala-reflect.jar: Connection reset (3111ms)
[warn] ==== Secured Central Repository: tried
[warn]   https://repo1.maven.org/maven2/org/scala-lang/scala-reflect/2.10.2/scala-reflect-2.10.2.jar
[warn]  ::::::::::::::::::::::::::::::::::::::::::::::
[warn]  ::              FAILED DOWNLOADS            ::
[warn]  :: ^ see resolution messages for details  ^ ::
[warn]  ::::::::::::::::::::::::::::::::::::::::::::::
[warn]  :: org.scala-lang#scala-compiler;2.10.2!scala-compiler.jar
[warn]  :: org.scala-lang#scala-reflect;2.10.2!scala-reflect.jar

[paulp]

I know what happened - I restarted the build via the web interface. Apparently that overwrites the logs.

[jsuereth]

@paulp We're also seeing flaky tests for anything that tries to resolve from central. Latest failed downloads:

scalacheck
scala 2.9.2
scala 2.10.4

I think primarily we need some sort of caching in travis to help limit the amount of network bandwidth sucked up in each test, as starting with a fresh machine and no local proxy of packages/jars => hogging the interwebs.

However, if there's anything else we can do to make it less flaky, I'm more than wiling to try.

A side note: We found an inefficiency in Ivy's chain resolver where "take first" literally means "hit every url then ignore all but the first result", so maybe that'll help with the network latency transient failures? If you have any other ideas for Travis-specific solutions, I'm all ears. It's annoying having to click the restart button multiple times a day.

[paulp]

I don't understand how travis has made it this long without caching artifacts. Even if issues like this didn't arise, how many bits are dying needlessly.

[jsuereth]

Yeah. We've only been using it for a few months now, so I'm not one to complain much about free service, but I think Travis, initially, was focused on other communities. E.g. I think their ruby package caching is pretty good. This could just be an area that's a bit foreign to their initial domain.

In any case, I hope we see improvements here quickly. Configuring travis is way simpler than Jenkins.

[paulp]

I tried the suggestion from @fommil to do what they're doing in https://github.com/ensime/ensime-server . It's great. Either Dropbox can deliver 100 Mb to travis in 4 seconds or caching is kicking in somewhere. Doesn't matter, I'll take it.

See https://travis-ci.org/paulp/psp-std/jobs/32385984 for a log.

I created a fresh account and ran the tests on my project with java6, java7, java8, then tarred up ~/.ivy2 and ~/.sbt.

[jsuereth]

Wow, kudos to @fommil. We may add this as a quick FAQ/Guide for others ASAP (meaning during business hours tomorrow).

[eed3si9n]

@jsuereth @paulp @fommil There's another way that's hacky but less invasive (at least in terms of the lines of code). Add the following to project/plugins.sbt:

libraryDependencies += "org.scala-lang" % "scala-compiler" % "2.10.4"

Fighting fire with fire, eviction will kick in, and the graph will resolve to Scala 2.10.4 instead of 2.10.2.
Tested it with paulp/psp-std with custom Ivy path, and it shaved 44s off the bootup time:

Before: sbt exit  18.17s user 1.61s system 13% cpu 2:31.44 total
After:  sbt exit  17.52s user 1.37s system 17% cpu 1:47.75 total

For a more permanent fix, we should discuss in #1527.

[paulp]

@eed3si9n That was the first thing I tried. It downloaded 2.10.2 anyway. Yes it resolves to 2.10.4, but only after downloading the plugin dependencies. If I'm wrong about that I'm all ears, but I'm pretty sure I never would have gotten to the solution I did if that had worked.

[jsuereth]

@paulp @fommil I've tried to boil down creating local cache into the simplest possibel consumable form: https://gist.github.com/jsuereth/56bd6f63138f5877f9b8 Have a PR for sbt itself to use this for travis. Have you guys experienced any issues where you wouldn't recommend this for every TravisCI + sbt user?

[paulp]

It's been smooth sailing for me.

[jsuereth]

@paulp Dropbox just dropped my public file hosting. I think perhaps I need to pay them more $$$. How big is your cache jar (just curious).

[paulp]

It's 100 Mb. I looked it up, even free accounts are supposed to get 20Gb a day. But I do pay them.