Closed Bug 1300305 Opened 8 years ago Closed 8 years ago

No HSTS/HPKP/blocklist updates on Trunk

Categories

(Core :: Security: PSM, defect, P1)

defect

Tracking

()

RESOLVED FIXED
mozilla51
Tracking Status
firefox51 --- fixed

People

(Reporter: RyanVM, Assigned: keeler)

References

Details

(Whiteboard: [psm-assigned])

Attachments

(1 file)

Looks like Aurora updated fine today, which indicates that bug 1298056 worked to solve that issue. However, no updates on trunk indicates that something seems awry still.
Well, it looks like the HSTS update succeeded just fine, but then the HPKP update failed. :catlee, I was under the impression that these jobs ran separately (so that if one failed, it wouldn't necessarily keep the others from succeeding). Is that no longer the case? Was it ever the case? In the meantime, I'll keep investigating the HPKP failure.
Flags: needinfo?(catlee)
This was my fault. Kathleen told me there were some root removals in bug 1296689 that might affect pinning. Lo and behold, they affected pinning.
Assignee: nobody → dkeeler
Blocks: 1296689
Component: General Automation → Security: PSM
Product: Release Engineering → Core
QA Contact: catlee
Whiteboard: [psm-assigned]
Comment on attachment 8788557 [details] bug 1300305 - update preloaded HPKP information to deal with "Equifax Secure CA" removal DONTBUILD NPOTB https://reviewboard.mozilla.org/r/77008/#review75332 Looks good, although we probably need some way of catching root certs that were previously present when we ran dumpGoogleRoots.js from being removed if they are still listed in PreloadedHPKPins.json. Maybe for another bug. ::: security/manager/tools/dumpGoogleRoots.js:61 (Diff revision 1) > } > return roots; > } > > +function makeFormattedNickname(cert) { > + if (root.nickname.includes("Builtin Object Token:")) { This line and the ones below all need to refer to ```cert``` instead of ```root```. Also, I guess technically ```includes(...)``` should be ```startsWith(...)``` instead, but it doesn't really matter.
Attachment #8788557 - Flags: review?(cykesiopka.bmo) → review+
(In reply to Phil Ringnalda (:philor) from comment #1) > http://archive.mozilla.org/pub/firefox/tinderbox-builds/mozilla-central- > linux64/mozilla-central-linux64-periodicupdate-bm91-build1-build0.txt.gz - > opaque as always. The error message shows up locally, but not in automation for some reason. Maybe the automation script doesn't redirect the error messages to the log or something.
Status: NEW → ASSIGNED
Priority: -- → P1
Comment on attachment 8788557 [details] bug 1300305 - update preloaded HPKP information to deal with "Equifax Secure CA" removal DONTBUILD NPOTB https://reviewboard.mozilla.org/r/77008/#review75332 Thanks! This is a manual step anyway, so I think we can just review any changes as we see them. > This line and the ones below all need to refer to ```cert``` instead of ```root```. > Also, I guess technically ```includes(...)``` should be ```startsWith(...)``` instead, but it doesn't really matter. Heh - whoops. Fixed that and updated includes to startsWith.
Pushed by dkeeler@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/55ad430c18f0 update preloaded HPKP information to deal with "Equifax Secure CA" removal DONTBUILD NPOTB r=Cykesiopka
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla51
(In reply to David Keeler [:keeler] (use needinfo?) from comment #2) > Well, it looks like the HSTS update succeeded just fine, but then the HPKP > update failed. :catlee, I was under the impression that these jobs ran > separately (so that if one failed, it wouldn't necessarily keep the others > from succeeding). Is that no longer the case? Was it ever the case? > > In the meantime, I'll keep investigating the HPKP failure. I'm really not sure. These are implemented here: https://dxr.mozilla.org/build-central/source/tools/scripts/periodic_file_updates/periodic_file_updates.sh
Flags: needinfo?(catlee)
Ah - thanks for the pointer. It looks like if multiple of {--hsts, --hpkp, --blocklist} are specified when running that, if one of the steps involved in generating the new files fails, then none of the commit steps (at the bottom) will run, even if a different subtask succeeded.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: