1225303 - archive.mozilla.org log links in builds-4hr should be HTTPS

Status: RESOLVED WONTFIX

(Release Engineering :: General, defect)

Description

[Daniel Holbert [:dholbert]]

STR:
 1. Install HTTPS Everywhere from
     https://www.eff.org/https-everywhere
  Direct link: https://www.eff.org/files/https-everywhere-latest.xpi

 2. Restart firefox to complete installation.

 3. Visit some TreeHerder page with a reftest failure, e.g. this one:
https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=91cfb76c82cd&filter-platform=Android

 4. Click the failing reftest job (R12 in this case), and then click the little picture of the graph towards the lower-left to open Reftest Analyzer.

ACTUAL RESULTS:
You end up at this page (promoted to HTTPS due to HTTPS Everywhere's rule for mozilla.org):
https://hg.mozilla.org/mozilla-central/raw-file/tip/layout/tools/reftest/reftest-analyzer.xhtml#logurl=http://archive.mozilla.org/pub/mobile/tinderbox-builds/mozilla-inbound-android-api-11/1447698713/mozilla-inbound_ubuntu64_vm_armv7_large_test-plain-reftest-12-bm53-tests1-linux64-build307.txt.gz&only_show_unexpected=1

That page (as you'll see if you visit it) just stays stuck on "Loading log..." forever.

The problem is that it's an HTTPS page, but it tries to load in an HTTP resource -- the URL provided in #logurl=http://[...].

EXPECTED RESULTS:
TreeHerder should put #logurl=https://[...] when constructing this URL, not HTTP. Then it works, regardless of whether the top-level hg.m.o URL is HTTP or HTTPS.

Comment 1

[Daniel Holbert [:dholbert]]

Also worth mentioning -- the HTTP log load gets blocked because it's "mixed active content" on an HTTPS page (the hg.m.o/.../reftest-analyzer page).  Browser console says:
{
Blocked loading mixed active content "http://archive.mozilla.org/pub/mobile/tinderbox-builds/mozilla-inbound-android-api-11/1447698713/mozilla-inbound_ubuntu64_vm_armv7_large_test-plain-reftest-12-bm53-tests1-linux64-build307.txt.gz"[Learn More]
}

If we make that log URI use *https* instead of HTTP when including it as an argument to our reftest-analyzer mega-URL, then everything works perfectly.

Comment 2

[Ed Morley [:emorley]]

We use the URL that buildbot gives us via builds-4hr, verbatim.
The taskcluster URLs are HTTPS, I would say the ones in builds-4hr pointing to archive.m.o should be too.

Nick, is this something you'd be able to take a look at? :-)

Comment 3

[Nick Thomas [:nthomas] (UTC+12)]

In turn buildbot is just passing on what the upload host declares. The log upload follows the same path as this upload of the apk in Android job:

eg in http://archive.mozilla.org/pub/mobile/tinderbox-builds/mozilla-inbound-android-api-9/1447698713/mozilla-inbound-android-api-9-bm91-build1-build2357.txt.gz:

10:49:58     INFO -  Uploading /builds/slave/m-in-and-api-9-000000000000000/build/src/obj-firefox/dist/fennec-45.0a1.en-US.android-arm.apk
...
10:50:18     INFO -  Running post-upload command: post_upload.py --tinderbox-builds-dir mozilla-inbound-android-api-9 -p mobile -i 20151116103153 --revision 91cfb76c82cd2f12029a44da35226ca4ddb7eb74 --release-to-tinderbox-dated-builds --release-to-latest-tinderbox-builds
10:50:44     INFO -  http://archive.mozilla.org/pub/mobile/tinderbox-builds/mozilla-inbound-android-api-9/1447698713/fennec-45.0a1.en-US.android-arm.apk
------

In principle I'm on board with joining the modern age and using https everywhere. There are some practical details we need to take care of first, namely making sure everything (or at least the most important systems) will not hit certificate errors. Typically this happens when you're using an old wget/curl and the cert bundle doesn't have recent CAs.

Ed, treeherder could be one of those systems. Is the cert on archive OK for the log digester ?

On the RelEng side we'd need to look at
 https://dxr.mozilla.org/mozilla-central/search?q=archive.mozilla.org&redirect=false&case=true
At least the matches on balrog/docker-worker.py and balrog/production.py would need updating across several trees. While I'm working in this space at the moment I don't have time right now to bite off another chunk of work.

Comment 4

[Nick Thomas [:nthomas] (UTC+12)]

BTW, when we're ready to make the change it's a request to oremj in Cloud Services: Operations, to modify post_upload to return https urls instead of http.

Comment 5

[Ed Morley [:emorley]]

Thank you for the extra info.

Treeherder is fine with the certs:

[[e-mail]3 treeherder-service]$ ../venv/bin/python
Python 2.7.8 (default, Jul  3 2014, 17:42:16)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import urllib2
>>> r = urllib2.urlopen('https://archive.mozilla.org/pub/mobile/tinderbox-builds/mozilla-inbound-android-api-9/14476987 13/mozilla-inbound-android-api-9-bm91-build1-build2357.txt.gz')
>>> d = r.read()
>>> d[0]
'\x1f'

Daniel, perhaps a shorter term workaround is to get the reftest analyser to make requests to '://' (or rewrite entirely)?

Comment 6

[Daniel Holbert [:dholbert]]

Maybe. Or to get archive.m.o added to HTTPS Everywhere's list of auto-promoted domains (if it gets a chance to kick in for reftest-analyzer's log-load operation, which I imagine it does)

Comment 7

[Daniel Holbert [:dholbert]]

Filed https://github.com/EFForg/https-everywhere/issues/3224 on adding archive.mozilla.org to HTTPS Everywhere's list.

Comment 8

[Daniel Holbert [:dholbert]]

Just kidding, HTTPS Everywhere is already active for archive.mozilla.org; we apparently perform the security-check for this resource & block the HTTP load before HTTPS Everywhere gets see it.

So, the workaround that edmorley suggested in comment 5 (making reftest-analyzer rewrite its provided URL) would be a decent short-term fix here.

Not sure whether or not that's worth it, though;  to the extent possible, it's probably best for reftest-analyzer to just use the URL that the user provided, just as TreeHerder does (because you can really invoke reftest-analyzer with any arbitrary URL, and URL-rewriting could be fragile if the URL is from a domain that doesn't support HTTPS).  So I'm a bit hesitant to add extra complexity there.

If we're shifting to HTTPS log urls (per middle of comment 3), maybe this can just wait until that happens. (and affected users like myself can just disable HTTPS Everywhere's mozilla.org rule, as a local workaround in the meantime)

Comment 10

[Mihai Tabara [:mtabara]⌚️GMT]

BB is now dead, we're no longer relyinf on build-4hrs files in our CI automation.
I think this bug outlived its usefulness.
Closing this, feel free to reopen if I'm wrong.