-
-
Notifications
You must be signed in to change notification settings - Fork 7k
Changed ant build script to use http with launcher4j. #5772
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Due to sourceforge using a 307 temporary redirect, the build script now fails to retrieve the launcher package (windows/linux). This is because the build script uses the https protocol and the redirect uses http. Error from ant script "[get] Redirection detected from https to http. Protocol switch unsafe, not allowed." This is a simple fix as it now requests the download using http, so the redirect is allowed.
The build always worked for me. Why does this happen? We should not use http as a solution. |
This is my output:
so it seems that sourceforge doesn't redirect to http. |
I haven't actually tried the linux build, only windows. However the linux package is also redirected (307).
I didn't notice it until I re-built my repo from scratch (previously downloaded launcher/temp build files deleted). The redirect is only recent... I think. Here is the output:
Changing to http allows the redirect to occur. |
We better write sourceforge an email to provide https connections instead of using http. |
It seems that some of their mirrors supports only http. Internode mirror force http:
Netcologne mirror insteal allows https:
Are you going to write them? |
@cmaglie I suggest some protest. Such a big site should take their business serious. I can write them, but you as arduino.cc might have some more impact. But I will try. In the meantime you can generate your gpg key #5619 . It is really important, I cannot say it often enough. Please sign your sources. You do not need to use it yourself in the build script if you dont care, but please give others the chance to do so. And once more as an explanation:The download via https does not secure us from source tampering. The initial download can be tampered. The hash we generate from this initial download is trusted by us, but does not guarantee the origin of the source. Therefore we need to use GPG. The real solution here would be that launch4j signs their sources and we verify them. Then you can create a hash of that download and include it in your build script. But DO NOT blindly download sources, generate a hash and use this. The use of https (or sftp)over http helps us a bit in the first place of the download. It ensures the server is hopefully the server. While still a lot people do not trust the CA model. If you can trust the hash (it has to be sha256 at a minimum), then you can also download via http or ftp. The reason why we do not want to use http still is a reason of privacy. Which might not be that critical in europe (yet) but in other countries it is. So:
|
I still don't understand how can this improve things. |
Are you asking me to sign my commits? (probably not).
|
Is this a solution in search of a problem? In an alternate universe where everyone has an abundance of man-hours to implement everything, regarless of its actual value, great. But here in reality, where projects are constrained by a fixed number of developer hours, is this really worthwhile? Should the human time needed to implement even more than the already-good hashes, and continue doing this extra work on every release really be prioritized over hundreds of other goals, which create tangible benefits for users? Has there ever been any confirmed case of source tampering in Arduino's 10+ year history? |
While we wait for sourceforge to take action, I've mirrored the files to downloads.arduino.cc that have no problems with https. The files are already checksummed. |
Good compromise. |
Hello all, I am Director of Technology at SourceForge. Great discussion here regarding all the facets that make a download safe and trustworthy. At SourceForge we are in the final stage of moving all our mirrors to HTTPS. This is a bit like herding cats, not unlike managing an open source project. Nevertheless, we will be 100% HTTPS on our mirror network by January 15, 2017. This is part of our ongoing push to move our entire platform to the HTTPS protocol. My apologies if you got caught in the middle of the transition unprepared. Hope this clears things up, and please let me know if there's anything else we can do to help your project. P.S.: No use to DDoS us, won't get very far. ;-) |
@cmaglie A user can verify the signatures via GPG. But most users are to lazy to verify those. But we use them for packaging our software (not only arch, also debian (+ubuntu), rpm (suse, redhat) and others). It is the only way for us to provide secure packages of the software that we distribute because the author can be authenticated.
@cmaglie You need to write the full fingerprint on your website and also on github. You have two sources with https where the fingerprint is shown which should give you a good portion of trust. Also GPG is a public trust database. Users can sign other keys, so they get more trust. For example my key is signed with the ArchLinux master keys. So you can ensure that its me, nicohood. Otherwise they would not have signed my public key/fingerprint.
@Chris--A The more people sign their commits, the more authenticated the git history becomes. The more people join, the better it is. And its really simple to activate automated commit signing with git.
@PaulStoffregen You totally missed the point. GPG signing does not even take a minute for every release that happens every month or so. But the value we can gain is authenticated sources. Its the reason why you can trust your system. Security is not something that we do for fun. And yes i think especially the last 3 years showed that is is extremely important to protect the users with all the surveillance and hacks out there. It would not be the first service that got hacked. And if we have GPG signatures this would prevent this risk. @ChristophBWeber Thanks a lot for this statement, this really clarified things and helps the community. Thanks! |
Just to tie this up: All active SourceForge mirrors are running over HTTPS as of 11:30am PST today. No more HTTP downloads! Hope this helps you folks. |
Due to sourceforge using a 307 temporary redirect, the build script now fails to retrieve the launcher package (windows/linux).
This is because the build script uses the https protocol and the redirect uses http.
Error from ant script:
This is a simple fix as it now requests the download using http, so the redirect is allowed.