Community
Participate
Working Groups
After much discussion over the merits of using SHA512 (See bug 423714 comment 17 for beginning of constructive discussion leading to this request) ... it came up that one "weakness" of the system is that the checksums (directly from download.eclipse.org) are delivered over an "insecure connection" (i.e. http://). I then noticed the ones delivered from "mirror page" are delivered via https. So, I'm wondering if it's possible to configure download.eclipse.org/*/checksum/* to always go through https? (or, some sort of redirect rule ... maybe based on fileextension? I realize the downloads themselves (the large artifacts) might be too expense to "encrypt" ... but ... seems pages related to checksums could be.
Well, we could, but we'd have to confect a bunch of rules to prevent the bulk of our traffic from escaping through https. You can get them today from https using the central service: https://www.eclipse.org/downloads/sums.php?file=/technology/epp/downloads/release/kepler/SR2/eclipse-standard-kepler-SR2-linux-gtk.tar.gz&type=sha512 We don't force https on the sums, but maybe we should at least make the links https:// instead of http.
> We don't force https on the sums, but maybe we should at least make the > links https:// instead of http. I was wrong. Looking at a link in a related change, the links for the central checksum service are hard-coded to https. https://git.eclipse.org/r/#/c/26936/1/content/en_download.php
(In reply to Denis Roy from comment #1) > > You can get them today from https using the central service: This is worth considering ... let me give it some thought, discuss with others. Do (nearly) all other projects use this service, or ... primarily EPP? Is Platform last to the party? :)
(In reply to David Williams from comment #3) > Do (nearly) all other projects use this service, or ... primarily EPP? Most projects don't compute their checksums since we provide them for free on the Pick A Mirror page. > Is Platform last to the party? :) Platform has been part of the party for years... If you follow any of the http links on this page, you'll be sent to the Pick a Mirror page that features the same central checksum service :) http://download.eclipse.org/eclipse/downloads/drops4/R-4.3.2-201402211700/
Here's a few observations: a) if you do "save as" on the check sum link, the name of the file (that's filled in automatically) is simply "sums.php" instead of something more like eclipse-SDK-4.4RC2-linux-gtk-x86_64.tar.gz.sha512. The contents of "sums.php" is correct and it actually works, as is ... but often if someone is downloading more than one thing, into same directory, they couldn't leave them all named "sums.php". b) Worse, I've found the checksums on mirror page don't show up for a while. Sometimes, it seems a great while ... like a day! While it might be my "imagination" is seems that a file must be "requested" once or even twice? before the checkums start to show up. c) Just curious, I assume there's no way to get these this rsync? That a person literally has to go through the https: protocol, such as with "wget" or similar? Only 'b' is a "show stopper" (from a releng/committer point of view) since we often need them "immediately". 'a' might be solvable with improved php/html? and 'c' is more a "curious" thing ... but ... lots of committers are used to rsync, so they'd all have to "educated", make sure they have wget instlled, etc. So, for now, I will keep producing our own checksums. I could maybe see some "mix" of the two ... if you really really don't want to implement the https protocol there ... but, it'd be simpler for us just to have them protected with https.
If I may make another suggestion, is that perhaps all of "download.eclipse.org" should be protected by https, just like https://www.eclipse.org/downloads/ is, and -- if I understand this security stuff at all -- that gives the user a little more confidence, if they care to look, that they really are looking at an "eclipse.org" page ... instead of some spoofed paged. Then, I believe your technical problem is sort of "reversed" ... only the literal "download artifacts" would not go through 'https' (I'm assuming that would be just too expensive, computationally). And it doesn't seem like that would be hard, if everyone used the "download from a mirror" script. And, if they didn't use that script ... well ... maybe assign those a real low bandwidth priority :)
To "strengthen" the argument for https on downloads, I looked at a few other popular sites. While hardly comprehensive search, it's seems pretty common to use https (either "by forced redirection" or to at least "allow"). Here's a brief summary: Ant download page: requires (redirects) to https: download artifacts: typically http (some mirrors appear to allow https) download check sums allows both http: and https: kernel.org download page: requires (redirects) to https: download artifacts: defaults to https, but allows http download checksums (PGP) defaults to http, but allows https open office https is used in examples shown in http://www.openoffice.org/download/checksums/3.4.0_checksums.html#howto actual links seem to default to http: but allow https
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
Removing "stale bug" as I think this is still an issue. I am not saying large artifacts need to be "https", but I think things under "*/checksum*" should be redirected to https. The objective isn't so much to "encrypt the value, but to "prove" that the checksum is coming from "Eclpse.org". See examples "from the industry" in comment 7. Also see comments in bug 423714#c17 and bug 423714#c18
See also bug 444350.
https://download.eclipse.org for the first time.
(In reply to Denis Roy from comment #12) > https://download.eclipse.org for the first time. Looks good. Thanks! I checked a number of 'download' and the "SHA" sites and all seemed to support HTTPS. = = = = I did not try the "main downloads", but one "direct" URL supported both HTTPS and HTTP which I suspect is what some would want, in case they are doing a huge number of (secure) downloads and HTTPS might take a little longer. I tried one file and did not see much difference so suspect to demonstrate any difference would require a number of runs to balance out random differences. For example, I tried $ time wget http://download.eclipse.org/eclipse/downloads/drops4/R-4.9-201809060745/eclipse-SDK-4.9-linux-gtk-x86_64.tar.gz and $ time wget https://download.eclipse.org/eclipse/downloads/drops4/R-4.9-201809060745/eclipse-SDK-4.9-linux-gtk-x86_64.tar.gz The results for 'http' was 2018-11-13 10:56:16 (8.11 MB/s) - ‘eclipse-SDK-4.9-linux-gtk-x86_64.tar.gz’ saved [242544890/242544890] real 0m29.397s user 0m0.353s sys 0m2.553s and the result for 'https' was 2018-11-13 10:57:04 (8.11 MB/s) - ‘eclipse-SDK-4.9-linux-gtk-x86_64.tar.gz.1’ saved [242544890/242544890] real 0m29.137s user 0m0.320s sys 0m2.567s = = = = = = Thanks again
