HTTPS: Change default repositories to use HTTPS

[jrudolph]

summary

• Maven Central from launcher HTTPS: Various HTTPS related changes #1548
• Maven Central from sbt HTTPS: Use HTTPS for downloading artifacts from Maven Central #1494
• Typesafe repo from launcher HTTPS: Fetch typesafe artifacts using https #1536/HTTPS: Various HTTPS related changes #1548
• Java.net Maven 1 repo from sbt (There's no HTTPS alternative) HTTPS: Various HTTPS related changes #1548/HTTPS: Change insecure URL to java.net repository #1549
• Java.net Maven 2 repo from sbt HTTPS: Various HTTPS related changes #1548/HTTPS: Change insecure URL to java.net repository #1549
• Typesafe repo from sbt HTTPS: Various HTTPS related changes #1548
• (Pending) scala-sbt.org repo from sbt #1541. Use HTTPS for sbt plugin repository #1555

original report

See http://blog.ontoillogical.com/blog/2014/07/28/how-to-take-over-any-java-developer/ for the background.

This should now be easy for Maven central, not sure which typesafe repositories already support https.

There are already pending PRs (#1526, #1536) that change some defaults but the potential impact may warrant a more thorough check through all of sbt's code.

[eed3si9n]

0.13.6 will use HTTPS by default for Maven Central (#1494). There's an ongoing effort to support HTTPS for other repositories repo.typesafe.com and repo.scala-sbt.org.

[jrudolph]

Thanks, I missed that one.

Is the launcher already using https as well? It seems that in https://github.com/rtyley/sbt/blob/c5704d03c1e0648bed999dbccd8b8f4191518a32/launch/src/main/scala/xsbt/boot/Update.scala#L317 it is still using the predefined URL in ivy for the mavenCentral repository, isn't it?

[eed3si9n]

Yes, it looks that way. I guess we need another change that'll read -Dsbt.repository.secure=true|false and switch the launcher repo. PR is welcome :)

[jrudolph]

Of course, there's the technical issue which can be solved by someone providing a fix. However, there's also the overarching issue where the sbt team needs to decide to if and how to make sbt more secure and takes responsibility to make sure that it really is.

It seems some part of the discussion has already taken place in the mentioned tickets. As we all know, the whole issue is not new at all, e.g. Redhat is collecting hashes of compromised jars since years (https://victi.ms/). Still, there's now a simple proof-of-concept (see the top link) exploit and also Sonatype's decision to change their long-standing SSL-policy shows rising awareness that something should be done about it in the near future.

My wish would be that a process is started now where the sbt team acknowledges the issues, enumerates what needs to be done and aims for one of the next releases to provide some assurance that those issues are fixed by then so that the release notes can contain a claim with some confidence that sbt is now secure to the best of one's knowledge. As security issues are usually infinite it may be useful if it contained a list of known remaining attack vectors that still cannot be prevented (or that need attention of the user, like user defined repositories).

I would propose at least this:

• make sure that all repositories predefined by sbt are accessed using HTTPS
• What to do about user-defined repositories? It needs to be decided if users should at least be warned about the issue if someone is declaring an http-based repository.
• Decide whether a project can override the security setting or only a user (on the one hand, one declared http-repository is enough to compromise the security of the user who builds a project, on the other hand, you always need to trust the code of a project before building it)

[eed3si9n]

I'd like to limit the scope of this Github issue to just the first bullet point targeting the next sbt release 0.13.6.

• make sure that all repositories predefined by sbt are accessed using HTTPS

For more broader solutions, we should discuss with the community on sbt-dev list on what sbt project should do.

[jrudolph]

👍 Thanks, Eugene, LGTM AFAICS.