ToDo: Mercurial Repository

[JWPlatt]

TeleBit Trailblazer T2000.

Wait, wait... Isn't that one of them thar old HIGH SPEED modems discontinued in 1994? If I got this right, you're lucky because it supports synchronous links dude!

[Mac_Fife]

(If only you had an emoticon for pushing one's button )

[rarified]

Ok, this is in the Mercurial section here due to the imminent use for CWE.

I've altered the foundry HTTP portal to redirect all HTTP traffic to JIRA/Fisheye/Crowd/Hudson to HTTPS. It's been too much work right now to figure out if Atlassian's SSO model can tolerate using the same cookies across both domains, which it appears it can't for now.

I've also enabled HTTPS access (and kept HTTP) access for the Mercurial and Subversion repos. The reason for keeping HTTP access is that I've found that recent improvements to Mercurial (since 1.7.3, now 1.8.x is current) include checking HTTPS CA cert chains and disallowing by default unverifiable certificates.

1.8.x has a workaround, documented here. You'll need to either edit your personal mercurial startup file (~/.hgrc for Linux, mercurial.ini for Windows) manually, or -- with TortoiseHg 2.0.0 or later -- query the server with the graphic interface and have the tool fix your startup file.

The fix involves adding a new configuration section [hostfingerprints] which contains the X509 signature of Foundry's Cert. The actual lines that get added to the file are

Code: Select all

[hostfingerprints]
foundry.openuru.org = 32:1b:b2:1c:9a:fe:d9:17:b0:78:76:ea:87:68:ad:1a:34:ab:a8:8e

In TortoiseHg, you would (after upgrading to 2.0.0) open the TortoiseHg Workbench, and open the CWE repo at https://foundry.openuru.org/hg/CWE. You'll probably see an error message at the bottom that the command was aborted -- ignore that. In the middle section, showing the repository URL, there are buttons to select the protocol (keep it HTTPS), and then the lock icon for information about the Cert. Click on the lock icon, it brings up the Security popup. Click the button "Verify with stored host fingerprint (good)". Then click the "Query" button to obtain the cert signature from foundry.openuru.org. It should fill in the field with the fingerprint (and match what I show above). Fill in your User Authentication information and click "Save". Now your pull/push operations should succeed. You can verify the command succeeded by selecting "View -> Show Output Log" to show the output from the underlying Mercurial commands; they always should announce a successful completion.

Using HTTP for the access protocol will still be available and while it is much simpler, is transmitting your username and password over the internet in the clear, which may not be simpler in the long run

Sorry for the hassle. I need to make dinner and then find out what fun Subversion has in mind in similar circumstances.

@Mac: This definitely needs to go into the intro to using the repositories.

_R

[JWPlatt]

Using HTTP for the access protocol will still be available...

Remember that's it's a guiding principle to keep the barriers low so that newcomers are not turned away with complicated instructions. Let informed consent prevail. Folks can catch up to more secure methods once they're established along the easy path. I have noticed that even http changes to and sticks on https. I'll have to read this a couple of times to figure out how much applies to me. I have TortoiseHg - figures they'd release a new version just days after I installed the previous version. I'm guessing a'moaca's inexplicable (to me) preference for the command line is a bigger effort, though probably not for her of course.

Isn't it a lot of overhead, on cpu and/or bandwidth, to carry https over the entire site rather than just authentications? Or does targeting it at authentication-only get the same reaction as my general avoidance of customization?

[rarified]

Ok, sorry... I was a little terse in the earlier message as I wanted to get usable info out before I took a break. Here's the long version:

You're right that it would be desirable to apply http only to pages/forms with sensitive data. Unfortunately, the Atlassian suite does not seem structured for this. There is no way I've found to isolate the login pages for JIRA, Fisheye, and Crowd and only apply HTTPS to them. The Atlassian documentation appears to show the entire tool as accessed via one protocol or the other.

The problems Mac and I have seen happens when a browser switches context (i.e. the client authenticated in HTTPS, but then retrieves a page via HTTP as the Gadgets on various dashboards were inclined to do). As long as we stay in one protocol domain or the other, the authentication credentials (cookie/s) were valid.

Throwing fuel on the fire was that the Atlassian tools don't create self-referential URLs when manufacturing links or referencing other tools. The configuration specifies the public URL base for the tool, and only allows one URL specification. So when we enabled HTTPS access, but left the "public URL" for JIRA as an HTTP URL, we again ended up in mixed modes and having authentication errors.

So it's unlikely we can set up the tools to operate in both domains simultaneously, even if the user intends to stay in one domain or the other by their efforts.

Hence the decision to push everything for the tools through HTTPS.

Remember that's it's a guiding principle to keep the barriers low so that newcomers are not turned away with complicated instructions. Let informed consent prevail. Folks can catch up to more secure methods once they're established along the easy path.

Quite. I think it will be clearer now if we simply say "the URL to get to JIRA is https://foundry.openuru.org/jira". No choices, all browsers support that, people start doing what they want.

I have TortoiseHg - figures they'd release a new version just days after I installed the previous version. I'm guessing a'moaca's inexplicable (to me) preference for the command line is a bigger effort, though probably not for her of course.

That's why the complicated explanation. And why it's probably more appropriate to put the bulk of it here rather in the public forums. You are the only current Hg client besides myself, and I knew you had the older Hg, so you would encounter difficulties with the change.

I have no concern for A'moaca', if she is at all familiar with mercurial then the changes I described should be easy for her to implement. I suspect many of the other technically inclined folks that will be active with CWE are also savvy with mercurial.

Isn't it a lot of overhead, on cpu and/or bandwidth, to carry https over the entire site rather than just authentications?

Bandwidth, no. There is increased CPU loading but with any computer built in the last decade a client shouldn't have a problem processing power-wise. The server will encounter the worst of things, but the foundry is on an 8-way server and it's pretty quick, so until we get, oh say 50 simultaneous streams going, I wouldn't think things would get bogged down. And I have lots of knobs to keep the foundry from taking too much of the server when I want it.

Or does targeting it at authentication-only get the same reaction as my general avoidance of customization?

Answered above, if we tried to confine to authentication we definitely head down the customization road.

I don't think it will be too high a barrier to new users. I think the only surprise that users will encounter are the consequences of using a self-signed HTTP cert. The browser will pop up a warning that we will have to document as expected, and how to accept the cert into the browser store so the warning only occurs once. If we put secure access to the repo under the "Advanced topics" then a new user will not encounter any irregularities when accessing the repo.

Ok, I've gone on too long already. Let's see where your ruminations lead.

_R

[cjkelly1]

Another SSL thing I noticed - when you hit the openuru.org site via https, it uses the hosting provider's certificate, and first splashes the hosting panel link page, and then goes to the forum.

Also, the address changes as well to something like this:

Code: Select all

https://forums.openuru.org/~openuruo/forums/posting.php?mode=reply&f=91&t=476

[JWPlatt]

rarified, I remember you have your science fair to attend early in the morning. So all this help is very much appreciated. Just FYI, this is one of those things where you might enjoy the rest and I'm fine with being asked, or told, to hold off for further instructions. As I've mentioned, our real lives can come first. You took more time out than you probably anticipated to answer my questions. Thanks!

[JWPlatt]

Another SSL thing I noticed - when you hit the openuru.org site via https, it uses the hosting provider's certificate, and first splashes the hosting panel link page, and then goes to the forum.

Also, the address changes as well to something like this:

Code: Select all

https://forums.openuru.org/~openuruo/forums/posting.php?mode=reply&f=91&t=476

Whoa. Thanks, cjkelly1. I have to say I don't remember ever trying https here, nor making any attempt to support it on the non-foundry resources. Let's see what I can do to fix it.

[JWPlatt]

WIth shared hosting and cert, looks like the "fix" is going to have to be to force https to http everywhere except the foundry subdomain until I spring for a dedicated IP and private cert.

[Mac_Fife]

I'll play Devil's Advocate here, just to test the argument that HTTPS is a necessity: If using a secure connection is going to cause complications, then how greatly concerned should we (or other users) be concerned about sending authentication details in the clear? We don't do this for the forums or wiki, and nor do many other sites. The repos are maybe a little more sensitive than forums, but surely the only really unrecoverable damage, should an account be compromised, would be if someone got enough access to completely wipe a repo?