Include sha256sums on the download page

[30atm]

Hi,

The page http://www.scala-lang.org/download/ does not have the md5/sha256sum values for the download packages.

Please can these be added to the site so that I can check my downloads

Aside, for now, please could you confirm if this is correct

d7335d2448cfed038f0cd79ed946ce82883651b80e4b698031261df23d9cb662 scala-2.11.8.deb

thank you

[jarrodu]

That is what I got when I downloaded it just now.

The download files are hosted by Lightbend and I don't have access to their servers. If I did I would check there.

[SethTisue]

This would be a nice enhancement. There would need to be corresponding changes in https://github.com/scala/make-release-notes

[jarrodu]

I am still thinking that the initial work needs to be done by Lightbend when the artifacts are uploaded to the server. When the hashs are available on the download server then links to them can be added to the download pages.

[SethTisue]

the initial work needs to be done by Lightbend when the artifacts are uploaded to the server

well, the scripts that do that are public and in version control, so anyone can do a pull request against them. but there's still truth in your statement, in that Lightbend folks will be needed to help test.

we're currently in the process of attempting to relocate our publishing process from Jenkins to Travis-CI (free or hosted, not sure which yet). let's come back to this once that effort has either succeeded or failed

[SethTisue]

the transition to Travis-CI is now complete. https://github.com/scala/scala-dist/blob/2.12.x/scripts/jobs/release/website/archives actually uploads the distribution packages to the server; the downloads page is still generated by https://github.com/scala/make-release-notes, as before.

[SethTisue]

I think the work needed for this may be confined to https://github.com/scala/make-release-notes, at least, if that isn't true, I don't see why.

[SethTisue]

to understand how this stuff works overall, it may be useful to consult e.g. scala/scala-dev#490 (the release steps we followed for 2.12.6)

[jarrodu]

Thanks for the extra resources. Just an extra thought. Do you think that gpg signatures would be a good thing to add at the same time? The hashes only provide a way to see if the download succeeded without corruption or tampering. The gpg signatures would allow for some assurance that the site its self was not compromised. The TLS certificates help with this but do not completely solve the problem.

Maybe I am over thinking this. Does anyone know if people have these concerns? I generally let sbt do whatever it wants and don't think much about it.

[ashawley]

Just an extra thought. Do you think that gpg signatures would be a good thing to add at the same time?

+1, but should probably be a new issue?

[SethTisue]

yeah I mean if somebody wanted to tackle both at the same time, awesome, but nobody should hold back from doing just the sums, that would still be awesome all by itself

[NthPortal]

What's the value of adding a checksum?

• if it's served over HTTP, the attacker can change the displayed checksum
• if it's served over HTTPS, you have assurance that no one has tampered with the file

There is the case where the page is served over HTTPS, but the download link is served over HTTP where this would help slightly, BUT:

• the download needs to be served over HTTPS anyway
• most people don't verify the checksum, so it's not a solution

In any case, both the page and the Lightbend download links are served over HTTPS at this point, so it's moot.

Also, fun fact: you're browser validates download integrity on its own (as part of TLS)

[ashawley]

What's the value of adding a checksum?

Layered security?

[NthPortal]

I'm not overly convinced of the added security - it's the same layer in most cases.

• if it's served over HTTP, the attacker can change the displayed checksum
• if it's served over HTTPS, you have assurance that no one has tampered with the file

If it's served over HTTP, the checksum is no more reliable than the download, so it adds no value. If it's served over HTTPS, the integrity of the checksum is the same as that of the download, so it adds no value.

Perhaps there is value added if the webpage is hosted separately from the download, so that the compromise of one would not affect the other. However, not a lot of value, because

most people don't verify the checksum

---

If someone wants to do the work to automate this, I won't object to it, but I don't think it should be very high priority

[SethTisue]

sounds convincing to me. I'm not very savvy about this stuff.

should we close this ticket and open a new one on the gpg issue?

[ashawley]

If it's served over HTTP, the checksum is no more reliable than the download, so it adds no value.

By "layered", I mean that the checksum provides verification for data at rest, while HTTPS only provides data in motion.

should we close this ticket and open a new one on the gpg issue?

fine with me.

[NthPortal]

I want to clarify my thoughts/stance on this, particularly in light of this comment.

I don't think this is hugely valuable, because (among other things) most people don't verify checksums. Consequently, I don't think it's something the Scala team, which is already stretched somewhat thin, should put effort into. Nor do I think newcomers who are looking for something to do to help out should pick this issue to work on.

That being said, if someone IS strongly invested in this, and wants to put the work in to modify the release scripts and generate checksums on the release page automatically, by all means have at it.