Robert Helmer [:rhelmer] Reporter
	Description • 13 years ago

The new dev/stage/prod servers for tbpl use HTTPS. Many of the links and resources loaded by tbpl have "http://" hardcoded:

* google calendar (causes mixed http/https warnings)
* wooBugURL (this one is used in an xhr call which runs afoul of the same-origin-policy, since the initial http:// call is going to result in a redirect which does not have xs-xhr headers)

I *think* the rest are just links or inactive code (like Tinderbox support), we might as well convert anything we can (looks like Tinderbox doesn't support HTTPS ATM, should fix that).

	Corey Shields [:cshields]
	Comment 1 • 13 years ago

(In reply to Robert Helmer [:rhelmer] from comment #0)
> I *think* the rest are just links or inactive code (like Tinderbox support),
> we might as well convert anything we can (looks like Tinderbox doesn't
> support HTTPS ATM, should fix that).

hrmm..  I thought TBPL was going to allow us to decommission Tinderbox..  I get the impression here that TBPL relies on Tinderbox??

	Robert Helmer [:rhelmer] Reporter
	Comment 2 • 13 years ago

(In reply to Corey Shields [:cshields] from comment #1)
> (In reply to Robert Helmer [:rhelmer] from comment #0)
> > I *think* the rest are just links or inactive code (like Tinderbox support),
> > we might as well convert anything we can (looks like Tinderbox doesn't
> > support HTTPS ATM, should fix that).
> 
> hrmm..  I thought TBPL was going to allow us to decommission Tinderbox..  I
> get the impression here that TBPL relies on Tinderbox??

Looks like status comes from Tinderbox, not sure what else. I am sure the other people CC:'d on this bug will have more up-to-date knowledge than I.

	Phil Ringnalda (:philor) Assignee
	Comment 3 • 13 years ago

Status comes from Tinderbox, until rhelmer and his cohorts take over bug 630534 and ram it through to a happy conclusion. And until we fix a few regressions so we can make &usebuildbot=1 the default, and then a bit later the only, tbpl has two faces, one which doesn't depend on Tinderbox for anything but tree status, and another which depends on it for results data and logs.

And even at the happy end of this, we don't get to decommission Tinderbox, we only get to unload it to the point where it's not a constant misery. Thunderbird and SeaMonkey don't yet have the buildbot backend deployed to do without Tinderbox, and projects like NSS and NSPR and Camino probably never will switch away from it, while others like Bugzilla may be willing to, but will need considerably more time. The goal of the rush away from it is to get the Firefox trees to stop sending mail to it, so it will go back to being perfectly capable of handling the load like it has for the last 12 years (and however long before that, as an internal Netscape tool).

	Phil Ringnalda (:philor) Assignee
	Comment 4 • 13 years ago

And as to this bug, the Google calendar URLs are all happy with https, but we get two-thirds of our job status info from build.mozilla.org, and https://build.mozilla.org/builds/builds-pending.js and https://build.mozilla.org/builds/builds-running.js want LDAP auth.

And to make using https anything other than pointless security theater, we would need the final third, from import-buildbot-data.py, to both use https for hg.m.o/ftp.m.o/build.m.o, and also to actually check the certs, which is a surprisingly iffy thing with Python.

	Robert Helmer [:rhelmer] Reporter
	Comment 5 • 13 years ago

(In reply to Phil Ringnalda (:philor) from comment #4)
> And as to this bug, the Google calendar URLs are all happy with https, but
> we get two-thirds of our job status info from build.mozilla.org, and
> https://build.mozilla.org/builds/builds-pending.js and
> https://build.mozilla.org/builds/builds-running.js want LDAP auth.
> 
> And to make using https anything other than pointless security theater, we
> would need the final third, from import-buildbot-data.py, to both use https
> for hg.m.o/ftp.m.o/build.m.o, and also to actually check the certs, which is
> a surprisingly iffy thing with Python.

I do agree that https://build.m.o/builds should be public (unless there's a reason for it not to be, since http is I assume it's just an oversight), but I don't think it's pointless security theater to have the URLs called by JS to be HTTPS while the ones called by the server are not, especially since both the tbpl.m.o and builds.m.o servers are hosted by Mozilla now. 

There's no reason not to have TBPL be all-https for anything served up by tbpl (or any xhr loads caused by script from there) in the meantime. We're pretty close as-is, but you can see mixed content symtpoms in Firefox/Chrome on tbpl prod right now due to the google calendar calls being unencrypted.

	Corey Shields [:cshields]
	Comment 6 • 13 years ago

pulling mcoates in, without his word I'm not going to be serving this via non-https.

	Phil Ringnalda (:philor) Assignee
	Comment 7 • 13 years ago

I'm willing to put aside the question of being attacked in the json between import-buildbot-data.py and its sources, since I can't see how to do it, but if anyone ever did, the I Told You So would be delicious :)

That leaves us with four things:

* Google calendar, which should really be pushed into production as critical, since any script kiddie worthy of the name who's pwning the wifi in a coffee shop, airport, hotel, or convention center is going to be targeting http Google URLs; fixed

* hg.m.o, easy to fix since it works; fixed

* build.m.o for running.js and pending.js, which requires I don't know how much sorting-out on releng's side, since there's I don't know how much behind it

* tinderbox.m.o for status.html, or bug 630534 for not needing it, no idea which is easier since both are outside my purview.

	Phil Ringnalda (:philor) Assignee
	Comment 8 • 13 years ago

(In reply to Corey Shields [:cshields] from comment #6)
> pulling mcoates in, without his word I'm not going to be serving this via
> non-https.

I'm not sure anyone's really suggesting that, but it would be a fun security question: "what's more risky, transferring a password over http which has been transferred over http since before Netscape open-sourced Tinderbox and which continues to be transferred over http on Tinderbox, one which for 10 years could wind up in the cookie you sent to Tinderbox with every single request, or, encouraging developers to turn off the mixed-content warning because they're sick of seeing it on one of their primary tools?"

	Phil Ringnalda (:philor) Assignee
	Comment 9 • 13 years ago

I think the build.m.o part is mostly bug 657359, and bits up and down its dependency chain to have a cert for *.pub.build.m.o and have pub be pub.

	Phil Ringnalda (:philor) Assignee
	Comment 10 • 13 years ago

http://hg.mozilla.org/users/mstange_themasta.com/tinderboxpushlog/rev/1ab2d7a2df59 and amusingly enough, I was just assuming that the mixed-content of having http://tinderbox.mozilla.org/Firefox/status.html and the build.m.o URLs, through which you can be totally pwned, did trigger the mixed-content warning, but in fact it seems that tbpl-dev now doesn't. Silly half-warning theater :)

	Robert Helmer [:rhelmer] Reporter
	Comment 11 • 13 years ago

(In reply to Phil Ringnalda (:philor) from comment #10)
> http://hg.mozilla.org/users/mstange_themasta.com/tinderboxpushlog/rev/
> 1ab2d7a2df59 and amusingly enough, I was just assuming that the
> mixed-content of having http://tinderbox.mozilla.org/Firefox/status.html and
> the build.m.o URLs, through which you can be totally pwned, did trigger the
> mixed-content warning, but in fact it seems that tbpl-dev now doesn't. Silly
> half-warning theater :)

Pretty sure that xhr http->https calls simply fail, but I guess the reverse is OK and doesn't generate a warning.

	Robert Helmer [:rhelmer] Reporter
	Comment 12 • 13 years ago

(In reply to Corey Shields [:cshields] from comment #6)
> pulling mcoates in, without his word I'm not going to be serving this via
> non-https.

Agreed we should be https-only, the things holding us back are:

* tinderbox.mozilla.org
** goes to xhr, guess it's a vhost on the same box? https://tinderbox.mozilla.org/
* build.mozilla.org
** http://build.mozilla.org/builds/ works 
** https://build.mozilla.org/builds/ asks for LDAP auth

	Robert Helmer [:rhelmer] Reporter
	Comment 13 • 13 years ago

(In reply to Robert Helmer [:rhelmer] from comment #12)
> (In reply to Corey Shields [:cshields] from comment #6)
> > pulling mcoates in, without his word I'm not going to be serving this via
> > non-https.
> 
> Agreed we should be https-only, the things holding us back are:
> 
> * tinderbox.mozilla.org
> ** goes to xhr, guess it's a vhost on the same box?

Sorry meant to say this goes to *mxr*, sorry acronym soup on the brain.

	Phil Ringnalda (:philor) Assignee
	Comment 14 • 13 years ago

That's even more confusing for people who aren't on whichever VPN you're on, since from the outside world https://tinderbox.mozilla.org/ times out, it doesn't go anywhere.

	Robert Helmer [:rhelmer] Reporter
	Comment 15 • 13 years ago

(In reply to Phil Ringnalda (:philor) from comment #14)
> That's even more confusing for people who aren't on whichever VPN you're on,
> since from the outside world https://tinderbox.mozilla.org/ times out, it
> doesn't go anywhere.

Yeah good point, am on mpt-vpn ftr.

	Phil Ringnalda (:philor) Assignee
	Comment 16 • 13 years ago

Farmed off the blocked parts to dependent bugs, I've got one more little bit of cleanup to do here and then we can call this fixed.

	Phil Ringnalda (:philor) Assignee
	Comment 17 • 13 years ago

The Config.js parts must be getting rid of conflicts between patches on prod and the repo, since prod does comment on bmo with "https://...". The rest is just prettying up the README, and encouraging avoiding redirects in client-only installs.

	Phil Ringnalda (:philor) Assignee
	Comment 18 • 13 years ago

http://hg.mozilla.org/users/mstange_themasta.com/tinderboxpushlog/rev/b646a0721da5