-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
WIP: Rewrite git://github.com to https://github.com in package URLs. #11312
Conversation
@@ -148,11 +148,12 @@ function status(io::IO, pkg::AbstractString, ver::VersionNumber, fix::Bool) | |||
end | |||
|
|||
function clone(url::AbstractString, pkg::AbstractString) | |||
info("Cloning $pkg from $url") | |||
normalized_url = Git.normalize_url(url) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this also rewrite urls when users explicitly use ssh, for example? If the user explicitly provides a url, it shouldn't be rewritten.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
colne
is done by user. Do not mess with user's url.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This won't rewrite SSH URLs, only git and https, but you're right, if the user manually provides a URL to clone(), it shouldn't be rewritten. I'll remove the normalisation from this function. For reference, the regex (which I've not touched) is:
r"^(?:git@|git://|https://(?:[\w\.\+\-]+@)?)github.com[:/](([^/].+)/(.+?))(?:\.git)?$"i
This used to be the default, but then got changed because it turned out more users had https blocked than git://. We really need to provide a way to have the user be able to configure it (or try to autodetect). |
I would really like to see everything (but especially METADATA.jl) use https by default. The current setup is really not very secure. |
Not to mention SSH keys are a completely foreign beast on Windows, ref #10892 |
To keep everyone happy, why not modify the function arguments with a kwarg for selecting the URL type? |
That seems like the best idea---my thinking is to make HTTPS the default, but allowing the user to use git:// or to disable rewriting altogether with an option to Pkg.init. Any thoughts? |
@LachlanGunn +1 |
+1 |
Ok, the first of these issues is dealt with---Pkg.clone() won't do any rewriting anymore. Making all rewriting optional/configurable will be a few days more. |
So is this still WIP then? |
Yes. I've changed the title to reflect this. |
I too like the idea of |
I don't think Pkg should automatically fall back to |
I think @simonster is correct, these days the security issues are extremely important... |
I would suggest |
Yes, you are correct. This change was reasonably close to being finished before I was interrupted by other things, I must really knock off the final interface. Since to my knowledge there is no cryptographic verification of the packages beyond the checksum, I agree that this really is important. |
awesome |
Ok, so I have merged the changes forward and finally gotten around to making the protocol configurable---"https", "git", etc., or "" to make it not change anything. Default is HTTPS. Moving to an apartment whose internet connection has git:// blocked gave me a bit of encouragement :) After this, I'm planning to look at changing the git:// URLs in the build system to https://. |
Just in case this isn't obvious from previous conversations about git vs https, as strange as it may seem, there have been reports of the opposite problem--that https (to GitHub at least) was blocked, but that the git protocol worked. So while one might be good as a default, it should be possible to use the other. |
Yes, that capability is there---I have added a new function to Pkg.git that allows the protocol to be changed. |
Cool, thanks for the clarification. |
LibGit2? |
@@ -2,7 +2,7 @@ | |||
|
|||
module Cache | |||
|
|||
import ...LibGit2, ..Dir, ...Pkg.PkgError | |||
import ...LibGit2, ..Dir, ...Pkg.PkgError, ..Git |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do not use Git
module. It will be removed. LibGit2
has normalization function.
I'm not sure that LibGit2 is the right place though, since it's supposed to be a wrapper library as I understand it, and adding a bunch of github-specific functionality seems a bit out of place. But if that's the consensus or I've misunderstood the purpose of LibGit2, then I'll go with the majority and put it there. |
Look around the LibGit2 module or the Pkg module (maybe in Pkg.Read?), there are already likely a few places that deal with urls. |
@@ -112,13 +114,27 @@ function set_remote_url(url::AbstractString; remote::AbstractString="origin", di | |||
run(`config remote.$remote.url $url`, dir=dir) | |||
m = match(GITHUB_REGEX,url) | |||
m === nothing && return | |||
push = "[email protected]:$(m.captures[1]).git" | |||
push = "$rewrite_url_to://[email protected]:$(m.captures[1]).git" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You should put git@
prefix only for git
protocol.
Righto; thanks for all of your comments, I've tried to address them all in this next iteration. The URL normalisation is now in Pkg.Cache, and the configuration function has been referenced into the top level Pkg module. What do you guys think? |
@@ -105,20 +105,18 @@ function is_ancestor_of(a::AbstractString, b::AbstractString; dir="") | |||
readchomp(`merge-base $A $b`, dir=dir) == A | |||
end | |||
|
|||
const GITHUB_REGEX = | |||
r"^(?:git@|git://|https://(?:[\w\.\+\-]+@)?)github.com[:/](([^/].+)/(.+?))(?:\.git)?$"i | |||
|
|||
function set_remote_url(url::AbstractString; remote::AbstractString="origin", dir="") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this version of the function is obsolete and subject to being deleted - see the version in libgit2.jl
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
First of all, no changes to git.jl
, all modifications should go to libgit2.jl
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I'll leave it in its previous state then. I was a bit antsy about the potentially inconsistent behaviour, even if it's slated for removal and not being used at the moment.
On naming, I think |
@tkelman Yes, you're right, I'm retrospect it isn't very idiomatic. I'll definitely be changing that. |
I've reverted Pkg.Git to its original state now as well. Any further thoughts? |
export dir, init, rm, add, available, installed, status, clone, checkout, | ||
update, resolve, test, build, free, pin, PkgError | ||
update, resolve, test, build, free, pin, PkgError, set_git_proto |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fix name here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ack, that is really embarrassingly stupid! Sorry to keep wasting your time on such things.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no big deal, this is why code review is a thing
Righto, the proper function name has now been exported. |
With those changes made, are there any further comments? Apologies for the bump. |
This looks good, the bump was warranted. I think we should document the new protocol setting API. |
Righto, thanks---now that it's settled I'll do documentation/tests/etc. The fact that the URLs are going to be fiddled with is itself probably something to make clear in the documentation of PkgDev/METADATA as well. |
LGTM |
If PkgDev is depending on this shall I get this squashed up and make a second pull request for the tests? |
works for me |
WIP: Rewrite git://github.com to https://github.com in package URLs.
Introduction
As git:// URLs cannot be loaded behind proxies, the current package manager is broken for many institutional users without manual configuration of Git using the "git://".insteadOf workaround. This is a major usability problem, and leaves a bad first impression for new users who are used to the polished installer of Matlab.
As discussed in #7005, the git:// protocol also provides no security against man-in-the-middle attacks, to which the current system is vulnerable due to the lack of digital signatures in the process.
The Pkg package has therefore been made to automatically change all git://github.com URLs to https://github.com. URLs pointing to other domains will be unaffected. If a complete change from git:// to https:// is made, then it is anticipated that existing URLs in METADATA.jl will be changed from git:// to https://. This may render the URL normalisation part of these changes unnecessary, however it would still be necessary to change the METADATA.jl URL to use HTTPS.
Changes
Together, these changes allow packages to be installed without access to the git:// port.
Test procedure