Closed Bug 844527 Opened 7 years ago Closed 7 years ago

Update nsSTSPreloadList with latest Chromium additions (2013-03-20 edition)

Categories

(Core :: Security: PSM, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla22
Tracking Status
firefox20 + fixed
firefox21 + fixed
firefox22 --- fixed

People

(Reporter: reed, Assigned: reed)

References

Details

Attachments

(2 files, 2 obsolete files)

Attached patch patch - v1 (obsolete) — Splinter Review
In order to keep up with changes to Chromium's HSTS preload list, as well as ensure that gPreloadListExpirationTime stays up-to-date, security/manager/tools/getHSTSPreloadList.js occasionally needs to be run and changes committed. This is one of those such times. Once bug 836097 has been fixed, this process will no longer be required.
Attachment #717561 - Flags: review?(bsmith)
This patch also adds the first Mozilla-owned site to the HSTS preload list. Yay!
Assignee: nobody → reed
Status: NEW → ASSIGNED
Attachment #717561 - Flags: review?(honzab.moz)
We should make sure this lands on Aurora and Beta too, otherwise Firefox 20 and 21 will ship with the old, expired preload list.
Attached patch result of my runSplinter Review
a bit different, but it may be just that the situation changed in the mean time?

(BTW, some update to the preload js script, like some progress indication or at least a message "I'm working!" at the begining would be good.)
Should we clone this out already for 21/22 to update to the latest just in case bug 836097 isn't resolved/uplifted sooner?
(In reply to Honza Bambas (:mayhemer) from comment #3)
> a bit different, but it may be just that the situation changed in the mean
> time?

Can you run it again? I'm seeing factor.cc working for me.

> (BTW, some update to the preload js script, like some progress indication or
> at least a message "I'm working!" at the begining would be good.)

File a bug? :)
The result has changed from what I was getting 5 those days ago.

Today, most notably crate.io and jottit.com are not very reliable when connecting them, among others...    

I'm running the script on two machines in the same (local) net: win7 box and osx 10.7 box.  OSX has google's dns servers (8.8.8.8, 8.8.4.4), win7 has provider's (czech o2).

I'm running the script on both machines repeatedly (3 runs each).

Results on win7 machine gives the same list (regarding each other), however errors are a bit different (for the two hosts mentioned mainly).

The mac result are however more jittering.

The final .inc file is in all cases different for mac and for win.

Hard to say what to do.  The script might have an option to try to connect some hosts that are unreachable more times.  Also the batch size should be lowered to say 10 hosts at one moment tops.
Comment on attachment 717561 [details] [diff] [review]
patch - v1

For now, please run the script few times (like 4 times or so) and try to merge the results to a single one.

We must do the best to make the script stable automatically and give the same results all around the world under any configuration.  This should be done in a followup bug, we don't need to block this bug on it.  The script should do the best to reach the servers and give up only after a number of connection failure attempts.

Reed, do you agree?
Attachment #717561 - Flags: review?(honzab.moz) → review-
Duplicate of this bug: 836898
Reed, we're about to go to build on our second-to-last beta.  Can you do the manual parts needed here this week?
Need some of the work in bug 847621 first, though I can just run stuff manually...
Depends on: 847621
Attached patch patch - v2 (obsolete) — Splinter Review
Ran the script four times using keeler's patch in bug 847621, and here's the updated result.

One issue that needs to be worked out (but I don't think it should block landing this)... the script says https://mega.co.nz isn't reachable, but I can definitely connect to it using curl, and it does have a valid HSTS header.
Attachment #717561 - Attachment is obsolete: true
Attachment #717561 - Flags: review?(bsmith)
Attachment #727100 - Flags: review?(honzab.moz)
Attachment #727100 - Flags: review?(bsmith)
Summary: Update nsSTSPreloadList with latest Chromium additions (2013-02-23 edition) → Update nsSTSPreloadList with latest Chromium additions (2013-03-20 edition)
Since we're going to our last beta of FF20 without this being reviewed and we'll want to ensure proper testing both internally and externally occurs we'll have to push this back to FF21 and keep the FF19 list for FF20 unless someone can make a case that this will seriously break a significant number of users' experience. Our understanding is that this will just cause a slight delay in the redirection to https which is minor.
Changing the wontfix back to affected since Brian is working on getting this landed now.
https://hg.mozilla.org/integration/mozilla-inbound/rev/021d69679f43

I made one change to the patch: mega.co.nz was reachable and sending a two-year HSTS header when I tried it, so I added that site to the list.
Target Milestone: --- → mozilla22
Attachment #727100 - Attachment is obsolete: true
Attachment #727100 - Flags: review?(honzab.moz)
Attachment #727100 - Flags: review?(bsmith)
https://hg.mozilla.org/mozilla-central/rev/021d69679f43
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.