Page MenuHomePhabricator

HTTPS redirects for git.wikimedia.org
Closed, ResolvedPublic

Description

Enabling this is trivial, the question is: is there any reason we *can't* enable this? Who's responsible for this service and might know of exceptions like mixed-content, or HTTPS-incapable tools which rely on it, etc? [note this a generic message being tacked into the description of several similar tickets]

Related Objects

StatusAssignedTask
Resolvedema
OpenBBlack
OpenBBlack
ResolvedBBlack
ResolvedArielGlenn
ResolvedChmarkine
ResolvedBBlack
ResolvedBBlack
ResolvedBBlack
ResolvedBBlack
ResolvedBBlack
ResolvedBBlack
ResolvedCCogdill_WMF
DeclinedBBlack
DuplicateBBlack
ResolvedBBlack
ResolvedBBlack
ResolvedBBlack
ResolvedBBlack
ResolvedBBlack
ResolvedBBlack
ResolvedBBlack
ResolvedBBlack

Event Timeline

BBlack created this task.Apr 12 2016, 3:42 PM

As gitblit is on the chopping block for deprecation anyways, my inclination is to go ahead and enable HTTPS for this soon and see if anyone screams, unless someone has a known reason we shouldn't!

greg edited projects, added Gitblit; removed Gitblit-Deprecate.Apr 13 2016, 2:52 PM

In lieu of anything more-concrete to go on, I've been monitoring the varnishlog live request flow for git.wikimedia.org this morning. The basic analysis of that is:

  • The traffic rate is *extremely* low. There are occasional bursts when some user hits the web UI with a browser, but not often (probably owing to the horrible UX because it's very very slow). Aside from rare browsers that should be able to cope with the redirect fine, we've got:
  • neon doing nagios check_http calls. I've look at that, and it will still return OK for the 301.
  • One oddball client on some hosting service provider, which has a UA string of Mozilla/8.0 (Windows 2008 SP32 + 3patch) and tends to occasionally access URLs of the form /blob/operations/dumps.git/ariel/xmldumps-backup/.... That UA string is pretty non-standard and uninformative. It may or may not be able to follow an HTTPS redirect, but can check logs after flipping the switch and see if it seems to or not.

Change 283233 had a related patch set uploaded (by BBlack):
git.wm.o HTTPS redirect T132460

https://gerrit.wikimedia.org/r/283233

Change 283233 merged by BBlack:
git.wm.o HTTPS redirect T132460

https://gerrit.wikimedia.org/r/283233

Change 283234 had a related patch set uploaded (by BBlack):
git.wm.o HTTPS redirect - part 2 - T132460

https://gerrit.wikimedia.org/r/283234

Change 283234 merged by BBlack:
git.wm.o HTTPS redirect - part 2 - T132460

https://gerrit.wikimedia.org/r/283234

BBlack closed this task as Resolved.Apr 13 2016, 5:52 PM
BBlack claimed this task.

Resolving for now, although I suspect this is the most likely of the bunch to trigger some kind of legitimate complaint -> revert

For the record: the oddball Mozilla/8.0 (Windows 2008 SP32 + 3patch) seems to be making it through the HTTPS redirect just fine in the logs.