-
-
Notifications
You must be signed in to change notification settings - Fork 5.6k
Pkg.add: provide a way to download over https instead of git #7005
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
Comments
(sorry, stupid button. please re-open if this does not solve the problem) |
@ihnorton that helped, thanks! |
This seems to be a common problem. Would it make sense to make Pkg aware of the problem, so that it can retry over https:// if git:// fails? |
One could also imagine making |
Is there any issue to making Please, I don't want to watch Julia make CPAN's and pip's mistakes all over again. Please fix this issue! |
We could potentially modify the gitconfig in the copy of git that we bundle with the Mac and Windows binaries to always prefer https. For tagged package versions we're typically fetching a known sha, so it seems like a mitm attack would be quickly apparent? Though I suppose the content of metadata itself could be spoofed? Could be worth changing Line 8 in 444c60e
|
See also similar issues with Tangentially related is an issue in Perl's Net::HTTPS API (CVE-2011-0633) which regards TLS certificate verification, and which was assigned some time after they enabled TLS for downloads during module installations with CPAN.pm. (I can't find the original CVE I was remembering regarding CPAN.pm switching to TLS/SSL by default, so I may be misremembering.) |
@StefanKarpinski, @staticfloat, thoughts? |
I'm not sure I fully understand what you meant by "spoofed". Please let me try to explain. Yes, you are correct; the primary issue is that the list of "known" SHA digests could be altered/updated/filtered by an attacker because the connection is not authenticated. There is also the secondary issue that the objects themselves are not authenticated, but rather than the SHA-1 digests of the contents of those objects merely constitutes a checksum. To elucidate on the primary issue, the original fetch of the METADATA.jl repo could be MITMed (possibly even MOTSs), or any subsequent fetch/pull of it, to allow arbitrary code execution. An example would be: Alice has already installed the Julia REPL and some Julia packages installed. She does For the second issue, the problem is that — even if Hopefully these explanations help to clarify the problems. If I failed to explain something, or you have more questions, please let me know! |
@isislovecruft it seems like that second issue is a really tough nut to crack, I'd almost say its in the "too hard" pile actually, at least for Julia right now. Obviously its also a tougher attack to execute. What in your opinion are the most bang-for-buck changes we can make - like would default https address the 99.9% of scenarios? |
Using HTTPS is a good idea. Doing signed git tags for package versions may also be a good idea. To some extent, having signed git tags mitigates the need for HTTPS, but doing both doesn't hurt. However, the deeper issue is how one establishes trust in open source packages in the first place. If there are going to be signed versions, we need to know who can be trusted to sign versions. How do I know if I should trust someone who wrote a package or not? Is this going to be an individual decision or will there be an official list? Who decides who to trust? If we're going to just trust anyone, authentication is useless. |
That being said, changing to HTTPS is a significant improvement since then only people who have had changes to METADATA accepted are being trusted, whereas without HTTPS anyone on any network between you and GitHub is being trusted. |
After the briefest of discussions on julia-dev, I have submitted pull request #11312 to use HTTPS for all Github URLs. This applies to both METADATA.jl and to the individual package URLs, whose protocols are automatically changed to https://. |
👍 |
This was implemented by #11312 edit: at least for github-hosted packages - we may want to add an API for accepting different url normalization regexes but I think that can be a new issue |
Hello,
I am using Windows 7 64-bit, Julia-0.3.0-prerelease, version latest as of today.
I am trying to install packages.
The thing is I am sitting behind the proxy and could not connect to git:// type of links (https:// works fine).
For Pkg.init() there is a workaround by passing full URL of METADATA github repo. I mean below command works just fine
Pkg.init("https://github.com/JuliaLang/METADATA.jl")
But I couldn't find a way to tell Pkg.add to use https instead of git for downloading packages (other than manually replace links in package description files, of course).
The text was updated successfully, but these errors were encountered: