Closed Bug 614587 Opened 9 years ago Closed 9 years ago
.py should allow to clone from HG via HTTPS
Fetching the sourcecode via HTTPS works well and with current Python and Mercurial installed, certificate and hostname is checked. I prefer to use HTTPS, as I'm not on trusted networks all the time. So far, I patched client.py manually to default to HTTPS URLs. Unfortunately it's possible that this file changes on server and I get this change by updating my HG tree. I had this with the new LDAP SDK, where I've seen that HG thought it has to fetch files unprotected. As many people prefer speed over security, I think HTTP should be kept as default, but in some way it should be possible to switch all HTTP URLs to HTTPs URLs. I could try to create a patch (don't know anything about python!) but at first I think I need to know how to fix this. I would prefer if it would be possible to be able to save this setting to some kind of configuration file, so I don't have to specify a command line parameter all the time. Maybe client.py should read .mozconfig to be able to read out options from there?
mozconfig is, believe it or not, a shell script, and I really don't like to get into running/parsing a shell script from client.py if in any way possible. What I think would make sense, though, is to have a --secure-clone option on client.py and parameterize the scheme+domain part of the repo references used for cloning (might come in handy in other places as well), pointing to http://hg.mozilla.org by default and https://hg.mozilla.org when the option is specified.
I've attached a patch, which does what I would expect when checking out. To be able to use "client.py", the comm-central repo has to be cloned first. My patch makes client.py use whatever protocol the user used to do this inital checkout. I've dropped "SWITCH_MOZILLA_REPO_REPLACE", as this, with my changes, now is a clone of DEFAULTS['MOZILLA_REPO']
Assignee: nobody → Manuel.Spam
Status: NEW → ASSIGNED
Attachment #493287 - Flags: review?(kairo)
... and it would be easy to add "ssh" as supported protocol. Do we want this?
Comment on attachment 493287 [details] [diff] [review] Patch which reads protocol used when checking out comm-central Feels a bit fragile and obscure to me, but I'll leave this up to Callek, he more or less owns this file nowadays.
Attachment #493287 - Flags: review?(kairo) → review?(bugspam.Callek)
Comment on attachment 493287 [details] [diff] [review] Patch which reads protocol used when checking out comm-central Ok, I'm not fond of this approach, but will take it if Mark ok's the concept. My one reason for r- (other than concept) is actually a review issue, I don't want to have to poll the c-c .hg/hgrc every time we run get_DEFAULT_repo [config-parser is not the cheapest util]. I would want it cached in some way, my brief idea is creating a brief-class for the Defaults, and using some py-magic to support __dict__ lookups, (and then we can use DEFAULTS = new default_values(). and DEFAULTS[foo]. but I don't know if that is too complex/out of scope for your mindset here. So as long as we cache the value I'm happy.
I just moved the "get path of comm-central"-part to global context. This way, the path is only read once from config. As this also globalizes "config" and "ConfigParser", this would mean, we could use this global instance in all the other sub-functions as well and I could drop all those "import ConfigParser" and "config = ConfigParser.ConfigParser()" lines from all the other function definitions? It someone has a better idea how to fix this (so far the feedback seems to be a bit negative for me), then just tell me and I'll try to implement it. I just thought it is a good idea to use the comm-central path for this, as if I check out comm-central using https, then at least I think that the user expects client.py to use https for the other checkouts as well.
Manuel, given that we'll be moving c-c to be under mozilla-central soon, and that I wasn't fond of this as it stood either, I'm WONTFIXING for now anyway. We can revisit at some point after we get moved and figure out our collective solution.
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
Attachment #495349 - Flags: feedback?(bugspam.Callek) → feedback-
You need to log in before you can comment on or make changes to this bug.