Closed Bug 1320773 Opened 3 years ago Closed 3 years ago

Update stub installer build to include dummy certificate for Stub Attribution data

Categories

(Release Engineering :: General, defect, P1)

defect

Tracking

(firefox51+ fixed, firefox52 fixed, firefox53 fixed)

RESOLVED FIXED
Tracking Status
firefox51 + fixed
firefox52 --- fixed
firefox53 --- fixed

People

(Reporter: ckprice, Assigned: nthomas)

References

(Blocks 1 open bug)

Details

Attachments

(8 files, 4 obsolete files)

1.78 KB, patch
Details | Diff | Splinter Review
7.39 KB, patch
catlee
: review+
Details | Diff | Splinter Review
2.46 KB, patch
catlee
: review+
Details | Diff | Splinter Review
4.28 KB, patch
catlee
: review+
Details | Diff | Splinter Review
25.29 KB, patch
rail
: review+
Details | Diff | Splinter Review
1.88 KB, patch
mshal
: review+
Details | Diff | Splinter Review
819.85 KB, image/png
Details
650.76 KB, image/png
Details
In bug 1318456 we built a version of this for testing. This bug is opened to create a permanent solution (ref bug1318456 comment 13).

See bug 1222258 for original specifications and use cases. The meta bug this is blocking also links to bouncer, moz.org and stub installer bugs that have been executed on behalf of this project.

We'd like to see this live in early January.
Bringing over and enhancing my comment from bug 1318456 ...

It should be relatively straightforward to add the dummy cert at build time, by adding a new signing mode to the signing servers and teaching the build system about it. We could use that for every stub, which means nightly, aurora, beta & release, or just a subset of that. I'd like to avoid blocking on manual work by RelEng if we can, given the rest of the work done on bouncer et al. It would be useful to know some use cases and any requirements from sec reviews/EIS though.
Bug 1222258 and bug 1259612 provide some useful context on motivation. They only talk about release builds and there are no comments about beta/aurora/nightly. Experience says it's dangerous to have features off for all branches except release, due to breakage that turns up at just the wrong moment (chemspill anyone ?). So how about we include the dummy cert for stubs on beta & release ?

What is the timeline for being able to use this in production ?
(In reply to Nick Thomas [:nthomas] from comment #2)
> So how about we include the dummy cert for
> stubs on beta & release ?

I don't think there is an issue with this, thanks.

> What is the timeline for being able to use this in production ?

Per comment 0, we're aiming for early January.
Moving this to RelEng:: Tools. Here's one possible implementation

1) (RelEng) provision the dummy cert (attachment 8748193 [details]) on the signing servers

2) (RelEng) add a new signing target near 
  https://dxr.mozilla.org/build-central/source/tools/release/signing/signscript.py#108
and modify osslsigncode_signfile() to take an optional argument at 
  https://dxr.mozilla.org/build-central/source/tools/lib/python/signing/utils.py#75
to use the dummy cert

3) (Releng) adjust the configs to enable the new target, eg
  https://dxr.mozilla.org/build-central/source/puppet/modules/signingworker/templates/passwords.json.erb#25

4) (mhowell?) adjust the build system to use the new target at
  https://dxr.mozilla.org/mozilla-central/source/toolkit/mozapps/installer/windows/nsis/makensis.mk#43
We'll need different values for MOZ_EXTERNAL_SIGNING_FORMAT for the full and stub installer, currently defined at
  https://dxr.mozilla.org/mozilla-central/source/toolkit/mozapps/installer/signing.mk#10


mhowell, does this this plan look OK to you ? And is attachment 8748193 [details] for testing or final ?
Component: Release Automation → Tools
Flags: needinfo?(mhowell)
QA Contact: rail → hwine
(In reply to Nick Thomas [:nthomas] from comment #4)
> mhowell, does this this plan look OK to you ?

Yeah, looks reasonable. You've already caught the one wrinkle I can see, to keep the full installer from trying to use the new signing format; should be pretty simple otherwise.

> And is attachment 8748193 [details] for testing or final ?

It should be usable as the final dummy certificate.
Flags: needinfo?(mhowell)
(In reply to Nick Thomas [:nthomas] from comment #4)
> 1) (RelEng) provision the dummy cert (attachment 8748193 [details]) on the
> signing servers

This is a manual process, the location depends on the target name chosen in 2). Deferring until later.

> 2) (RelEng) add a new signing target near 

Going to start working on this now.

> 3) (Releng) adjust the configs to enable the new target, eg

Depends on choice of target in 1), deferring.
 
> 4) (mhowell?) adjust the build system to use the new target at

Would appreciate some help with this. mhowell do you have time before your PTO ? Maybe in a separate bug for clarity.
Assignee: nobody → nthomas
Needs testing. New target name is sha2signcodestub; the dummy cert lives at secrets/sha2signcode/StubDummy.cert.
Attachment #8820133 - Attachment is obsolete: true
Status update - need to talk to rail/catlee/releng about the best way to test the tools patch, and double check the puppet patch is fine. In theory this is a relatively simple extension, so we might be able to land it before Christmas - depends a bit on how risk averse we are around the holidays.

I'm less confident about changing the build system to use different signing targets for full and stub installers, aka point 4) in the comment 4, because I don't grok how the packaging code works and it could take a while to iterate on changes.
(In reply to Nick Thomas [:nthomas] from comment #11)
> I'm less confident about changing the build system to use different signing
> targets for full and stub installers, aka point 4) in the comment 4, because
> I don't grok how the packaging code works and it could take a while to
> iterate on changes.

I think you found the two relevant spots in comment 4. Under
https://dxr.mozilla.org/mozilla-central/source/toolkit/mozapps/installer/signing.mk#10
there needs to be a new define, something like
MOZ_EXTERNAL_STUB_SIGNING_FORMAT := sha2signcodestub

Then, change
https://dxr.mozilla.org/mozilla-central/source/toolkit/mozapps/installer/windows/nsis/makensis.mk#57
to use that instead of the normal MOZ_EXTERNAL_SIGNING_FORMAT. We only need to change line 57, not line 51 or any of the other signing commands (which are for the full installer).
cc'ing a couple of relman folks to get this on the radar. We'll likely request an uplift (to 51 release =/) for the updates referenced in comment 12.
+1 to uplifted to 51.
Tracking for 51 since we're talking about uplifting for beta 51. We are gtb today for beta 10, and the next beta build will be on Jan. 2 for Jan 3 release.
Attached patch [tools] Signing server support (obsolete) — Splinter Review
Improved the comment as requested on IRC, verified the new sha2signcodestub works and doesn't bust sha2signcode.
Attachment #8820134 - Attachment is obsolete: true
Attachment #8821351 - Flags: review?(catlee)
Also sets max_filesize_sha2signcodestub in signing.ini.template.
Attachment #8821351 - Attachment is obsolete: true
Attachment #8821351 - Flags: review?(catlee)
I've broken the puppet patch up to allow incremental deployment/backout. This one just enables the new signing target, ignoring the signingworkers and signing_scriptworker until later.
Attachment #8820141 - Attachment is obsolete: true
Attachment #8821361 - Flags: review?(catlee)
Attachment #8821358 - Flags: review?(catlee)
This is the patch mhowell outlined at comment #12. It would affect nightly builds on mozilla-central and aurora, and all builds on beta and release (which is more than the plan earlier in bug). I haven't found a useful variable to restrict to beta & release, but we might be able to test MOZ_UPDATE_CHANNEL like browser/confvars.sh does (near line 20). 

When pushing to try MOZ_UPDATE_CHANNEL is not set, so we need a little more hacking to make sure the stub is built (browser/confvars.sh again). An additional test on MOZ_UPDATE_CHANNEL is a bit of a  pain then.
Attachment #8821362 - Attachment description: [puppet] Enable sha2signcodestub on try → [puppet] Enable sha2signcodestub on try and dep builds
Status - patches up for review (signing server is well tested)

Assuming r+ the next steps are:
* land tools change (attachment 8821358 [details] [diff] [review]), move SIGNING_SERVER tag to new rev
* update one dep instance (eg signing4.srv.releng.scl3) by 
** downloading attachment 8748193 [details] to secrets/sha2signcode/StubDummy.cert
** pulling in tools changes
** restarting the signing server (to pick up the code changes in utils.py)
* monitor for bustage on sha2signcode, if all is well ...
* update rest of dep instances with code & cert
* land puppet change to enable sha2signcode2stub in signing server (attachment 8821361 [details] [diff] [review])
* monitor for bustage, if all is well ...
* deploy puppet change to enable sha2signcodestub in buildbot (attachment 8821362 [details] [diff] [review])
* push gecko change to try (attachment 8821401 [details] [diff] [review]), along with removing the MOZ_UPDATE_CHANNEL tests at 
    https://hg.mozilla.org/mozilla-central/file/default/browser/confvars.sh#l19
* check resulting stub with 'osslsigncode verify <stub.exe>', looking for a Dummy cert like at 
    https://gist.github.com/nthomas-mozilla/98a6137d33a800dffdbb14bbd313ff8a#file-gistfile1-txt-L16-L18
* update code & cert and restart nightly & release signing servers
* deploy puppet change to enable sha2signcodestub in buildbot for nightly & release (attachment 8821363 [details] [diff] [review])
* get review of gecko change (attachment 8821401 [details] [diff] [review]), mhowell can suggest someone
* if stub nightly is OK on m-c then ask for uplift (more testing here?? stub isn't used much on nightly)
* once the gecko patch is in the beta repo then stubs for beta releases should have the dummy cert without any extra work
* update offline cert stores with dummy certificate

I'm out until January 9th. See Chris AtLee and Rail Aliev as RelEng people who are familiar with the signing servers (more than me even).
Assignee: nthomas → nobody
Attachment #8821358 - Flags: review?(catlee) → review+
Attachment #8821361 - Flags: review?(catlee) → review+
Attachment #8821362 - Flags: review?(catlee) → review+
:catlee -- any recommendations on who we can get to r? the remaining patches here? Also will we need nthomas to go to production for this? Looks like he's OOO until the 9th.
Flags: needinfo?(catlee)
Also NI :rail as he was mentioned in comment 22. Note: for the gecko patch mhowell was mentioned in the comment for review, but he is on PTO.
Flags: needinfo?(rail)
I haven't been following this closely, sorry. catlee may have more info.
Flags: needinfo?(rail)
We talked with catlee about this and I'm going to look at landing this asap.
Flags: needinfo?(catlee) → needinfo?(rail)
Comment on attachment 8821401 [details] [diff] [review]
[gecko] Specify sha2signcodestub for stub installer

This looks fine to me, though we'll still need to double-check on try per #c22.
Attachment #8821401 - Flags: review+
(In reply to Nick Thomas [:nthomas] (PTO until January 9) from comment #22)
> Status - patches up for review (signing server is well tested)
> 
> Assuming r+ the next steps are:
> * land tools change (attachment 8821358 [details] [diff] [review]), move
> SIGNING_SERVER tag to new rev
> * update one dep instance (eg signing4.srv.releng.scl3) by 
> ** downloading attachment 8748193 [details] to
> secrets/sha2signcode/StubDummy.cert
> ** pulling in tools changes
> ** restarting the signing server (to pick up the code changes in utils.py)
> * monitor for bustage on sha2signcode, if all is well ...
> * update rest of dep instances with code & cert
> * land puppet change to enable sha2signcode2stub in signing server
> (attachment 8821361 [details] [diff] [review])

^^^^^ Done ^^^^^^

TODO:

> * monitor for bustage, if all is well ...
> * deploy puppet change to enable sha2signcodestub in buildbot (attachment
> 8821362 [details] [diff] [review])
> * push gecko change to try (attachment 8821401 [details] [diff] [review]),
> along with removing the MOZ_UPDATE_CHANNEL tests at 
>    
> https://hg.mozilla.org/mozilla-central/file/default/browser/confvars.sh#l19
> * check resulting stub with 'osslsigncode verify <stub.exe>', looking for a
> Dummy cert like at 
>    
> https://gist.github.com/nthomas-mozilla/
> 98a6137d33a800dffdbb14bbd313ff8a#file-gistfile1-txt-L16-L18
> * update code & cert and restart nightly & release signing servers
> * deploy puppet change to enable sha2signcodestub in buildbot for nightly &
> release (attachment 8821363 [details] [diff] [review])
> * get review of gecko change (attachment 8821401 [details] [diff] [review]),
> mhowell can suggest someone
> * if stub nightly is OK on m-c then ask for uplift (more testing here?? stub
> isn't used much on nightly)
> * once the gecko patch is in the beta repo then stubs for beta releases
> should have the dummy cert without any extra work
> * update offline cert stores with dummy certificate
>
Comment on attachment 8821362 [details] [diff] [review]
[puppet] Enable sha2signcodestub on try and dep builds

remote:   https://hg.mozilla.org/build/puppet/rev/5ed30bf396b3479f0e11e29a2d6aa5af6ce80aea
remote:   https://hg.mozilla.org/build/puppet/rev/869a4dc71d33b5e00bd009ead09272162f2f4597


Need to reconfig the masters to pick up this change.
Attachment #8821362 - Flags: checked-in+
(In reply to Nick Thomas [:nthomas] (PTO until January 9) from comment #22)
> Status - patches up for review (signing server is well tested)
> 
> Assuming r+ the next steps are:
> * land tools change (attachment 8821358 [details] [diff] [review]), move
> SIGNING_SERVER tag to new rev
> * update one dep instance (eg signing4.srv.releng.scl3) by 
> ** downloading attachment 8748193 [details] to
> secrets/sha2signcode/StubDummy.cert
> ** pulling in tools changes
> ** restarting the signing server (to pick up the code changes in utils.py)
> * monitor for bustage on sha2signcode, if all is well ...
> * update rest of dep instances with code & cert
> * land puppet change to enable sha2signcode2stub in signing server
> (attachment 8821361 [details] [diff] [review])
> * monitor for bustage, if all is well ...
> * deploy puppet change to enable sha2signcodestub in buildbot (attachment
> 8821362 [details] [diff] [review])
> * push gecko change to try (attachment 8821401 [details] [diff] [review]),
> along with removing the MOZ_UPDATE_CHANNEL tests at 
>    
> https://hg.mozilla.org/mozilla-central/file/default/browser/confvars.sh#l19

^^^ DONE ^^^

https://treeherder.mozilla.org/#/jobs?repo=try&revision=d49a1abfc1293fdcac84c9f571625cf0eaf75c41

TODO:

> * check resulting stub with 'osslsigncode verify <stub.exe>', looking for a
> Dummy cert like at 
>    
> https://gist.github.com/nthomas-mozilla/
> 98a6137d33a800dffdbb14bbd313ff8a#file-gistfile1-txt-L16-L18
> * update code & cert and restart nightly & release signing servers
> * deploy puppet change to enable sha2signcodestub in buildbot for nightly &
> release (attachment 8821363 [details] [diff] [review])
> * get review of gecko change (attachment 8821401 [details] [diff] [review]),
> mhowell can suggest someone
> * if stub nightly is OK on m-c then ask for uplift (more testing here?? stub
> isn't used much on nightly)
> * once the gecko patch is in the beta repo then stubs for beta releases
> should have the dummy cert without any extra work
> * update offline cert stores with dummy certificate
Hmmm, the build failed for some reason. I inspected the signing server logs and see this:

2017-01-05 14:02:58,804 - DEBUG - 4338: ['/builds/signing/dep-key-signing-server/bin/python2.7', '/builds/signing/dep-key-signing-server/tools/release/signing/signscript.py', '-c', '/builds/signing/dep-key-signing-server/signscript.ini', 'sha2signcodestub', u'/builds/signin
g/dep-key-signing-server/unsigned-files/5b6315a803cd169b2477478f87f41b6da7f03aab', u'/builds/signing/dep-key-signing-server/signed-files/sha2signcodestub/5b6315a803cd169b2477478f87f41b6da7f03aab', u'stub.exe']
2017-01-05 14:02:59,308 - INFO - 4338: run_signscript: Failed with rc 1; retrying in a bit

Running the same command manually returns 0 and generates /builds/signing/dep-key-signing-server/signed-files/sha2signcodestub/5b6315a803cd169b2477478f87f41b6da7f03aab

and the generated file looks fine:

osslsigncode verify /builds/signing/dep-key-signing-server/signed-files/sha2signcodestub/5b6315a803cd169b2477478f87f41b6da7f03aab
Current PE checksum   : 0007C72D
Calculated PE checksum: 0007C72D

Message digest algorithm  : SHA1
Current message digest    : 3E0D1AD54D83F647B7CA734D17252AADF64B78DA
Calculated message digest : 3E0D1AD54D83F647B7CA734D17252AADF64B78DA

Signature verification: ok

Unfortunately exit code 1 is very generic. I'll try to dig more into this today.

Number of signers: 1
        Signer #0:
                Subject: /CN=Mozilla Fake SPC
                Issuer : /CN=Mozilla Fake CA

Number of certificates: 2
        Cert #0:
                Subject: /CN=Dummy
                Issuer : /CN=Dummy
        Cert #1:
                Subject: /CN=Mozilla Fake SPC
                Issuer : /CN=Mozilla Fake CA

Succeeded
Looks like I needed to restart the signing servers again after deploying the puppet change to enable sha2signcode2stub in signing server (attachment 8821361 [details] [diff] [review]). This change enables the new signing format and only after that the signing server asks for the passphrase for this format.

Rerunning the try build third time.
yay, https://archive.mozilla.org/pub/firefox/try-builds/raliiev@mozilla.com-d49a1abfc1293fdcac84c9f571625cf0eaf75c41/try-win32/firefox-53.0a1.en-US.win32.installer-stub.exe

osslsigncode verify firefox-53.0a1.en-US.win32.installer-stub.exe
Current PE checksum   : 00087BDB
Calculated PE checksum: 00087BDB

Message digest algorithm  : SHA1
Current message digest    : 81662F557FE4424A8A455D7D7EAF41E293C0B643
Calculated message digest : 81662F557FE4424A8A455D7D7EAF41E293C0B643

Signature verification: ok

Number of signers: 1
        Signer #0:
                Subject: /CN=Mozilla Fake SPC
                Issuer : /CN=Mozilla Fake CA

Number of certificates: 2
        Cert #0:
                Subject: /CN=Dummy
                Issuer : /CN=Dummy
        Cert #1:
                Subject: /CN=Mozilla Fake SPC
                Issuer : /CN=Mozilla Fake CA

Succeeded
Comment on attachment 8821401 [details] [diff] [review]
[gecko] Specify sha2signcodestub for stub installer

This still needs check in, but putting the request in.

Approval Request Comment
[Feature/Bug causing the regression]:
This bug supports the Stub Attribution project - bug 1222258.

[User impact if declined]:
Attribution efforts and campaigns for monitoring growth and acquisition will be delayed.

[Is this code covered by automated tests?]:
I am not sure.

[Has the fix been verified in Nightly?]:
No.

[Needs manual test from QE? If yes, steps to reproduce]:
I don't think so, see comment 35.

[List of other uplifts needed for the feature/fix]:
None.

[Is the change risky?]:
Moderately.

[Why is the change risky/not risky?]:
The change itself is small (changing variable names), but it will touch every stub download.

[String changes made/needed]:
None.
Attachment #8821401 - Flags: approval-mozilla-release?
Attachment #8821401 - Flags: approval-mozilla-beta?
Attachment #8821401 - Flags: approval-mozilla-aurora?
(In reply to Cory Price [:ckprice] from comment #38)
> Checkin needed for attachment #8821401 [details] [diff] [review] [diff] [review].

I'm going to land it in a bit to m-i. Just need to finish some remaining steps in the TODO.
Pushed by raliiev@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/ccc536cc6d4d
Update stub installer build to include dummy certificate for Stub Attribution data; r=mshal
(In reply to Nick Thomas [:nthomas] (PTO until January 9) from comment #22)
> Status - patches up for review (signing server is well tested)
> 
> Assuming r+ the next steps are:
> * land tools change (attachment 8821358 [details] [diff] [review]), move
> SIGNING_SERVER tag to new rev
> * update one dep instance (eg signing4.srv.releng.scl3) by 
> ** downloading attachment 8748193 [details] to
> secrets/sha2signcode/StubDummy.cert
> ** pulling in tools changes
> ** restarting the signing server (to pick up the code changes in utils.py)
> * monitor for bustage on sha2signcode, if all is well ...
> * update rest of dep instances with code & cert
> * land puppet change to enable sha2signcode2stub in signing server
> (attachment 8821361 [details] [diff] [review])
> * monitor for bustage, if all is well ...
> * deploy puppet change to enable sha2signcodestub in buildbot (attachment
> 8821362 [details] [diff] [review])
> * push gecko change to try (attachment 8821401 [details] [diff] [review]),
> along with removing the MOZ_UPDATE_CHANNEL tests at 
>    
> https://hg.mozilla.org/mozilla-central/file/default/browser/confvars.sh#l19
> * check resulting stub with 'osslsigncode verify <stub.exe>', looking for a
> Dummy cert like at 
>    
> https://gist.github.com/nthomas-mozilla/
> 98a6137d33a800dffdbb14bbd313ff8a#file-gistfile1-txt-L16-L18
> * update code & cert and restart nightly & release signing servers
> * deploy puppet change to enable sha2signcodestub in buildbot for nightly &
> release (attachment 8821363 [details] [diff] [review])
> * get review of gecko change (attachment 8821401 [details] [diff] [review]),
> mhowell can suggest someone

^^^^ DONE ^^^^

TODO:

> * if stub nightly is OK on m-c then ask for uplift (more testing here?? stub
> isn't used much on nightly)
> * once the gecko patch is in the beta repo then stubs for beta releases
> should have the dummy cert without any extra work
> * update offline cert stores with dummy certificate


Once the commit above lands on m-c and generates a nightly build, we can verify and proceed with m-a and m-b.

BTW, I doubt we need to land this in m-r, because we are going to uplift beta to release on Jan 16.
Comment on attachment 8821401 [details] [diff] [review]
[gecko] Specify sha2signcodestub for stub installer

(In reply to Rail Aliiev [:rail] ⌚️ET from comment #42)
> BTW, I doubt we need to land this in m-r, because we are going to uplift
> beta to release on Jan 16.

Removing m-r request.
Attachment #8821401 - Flags: approval-mozilla-release?
Comment on attachment 8821401 [details] [diff] [review]
[gecko] Specify sha2signcodestub for stub installer

(In reply to Rail Aliiev [:rail] ⌚️ET from comment #42)
> Once the commit above lands on m-c and generates a nightly build, we can
> verify and proceed with m-a and m-b.
Re-reading this, it sounds like we should wait on requesting uplifts until we've verified on a Nightly build.
Attachment #8821401 - Flags: approval-mozilla-beta?
Attachment #8821401 - Flags: approval-mozilla-aurora?
https://hg.mozilla.org/mozilla-central/rev/ccc536cc6d4d
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Still need to verify in a nightly build.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Has there been any progress on verifying this in Nightly? Can we initiate the uplift request?
The nightly stub installer's signature looks good to me:

$ wget https://archive.mozilla.org/pub/firefox/nightly/latest-mozilla-central/firefox-53.0a1.en-US.win32.installer-stub.exe

$ osslsigncode verify firefox-53.0a1.en-US.win32.installer-stub.exe 
Current PE checksum   : 0008C390
Calculated PE checksum: 0008C390

Message digest algorithm  : SHA1
Current message digest    : 9804C930AA961F0A70DF30D0495835C05B818693
Calculated message digest : 9804C930AA961F0A70DF30D0495835C05B818693

Signature verification: ok

Number of signers: 1
        Signer #0:
                Subject: /C=US/ST=California/L=Mountain View/O=Mozilla Corporation/CN=Mozilla Corporation
                Issuer : /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 Assured ID Code Signing CA

Number of certificates: 6
        Cert #0:
                Subject: /CN=Dummy
                Issuer : /CN=Dummy
        Cert #1:
                Subject: /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Assured ID Root CA
                Issuer : /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Assured ID Root CA
        Cert #2:
                Subject: /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 Assured ID Code Signing CA
                Issuer : /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Assured ID Root CA
        Cert #3:
                Subject: /C=US/ST=California/L=Mountain View/O=Mozilla Corporation/CN=Mozilla Corporation
                Issuer : /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 Assured ID Code Signing CA
        Cert #4:
                Subject: /C=US/O=Symantec Corporation/CN=Symantec Time Stamping Services Signer - G4
                Issuer : /C=US/O=Symantec Corporation/CN=Symantec Time Stamping Services CA - G2
        Cert #5:
                Subject: /C=US/O=Symantec Corporation/CN=Symantec Time Stamping Services CA - G2
                Issuer : /C=ZA/ST=Western Cape/L=Durbanville/O=Thawte/OU=Thawte Certification/CN=Thawte Timestamping CA

Succeeded

(In reply to Cory Price [:ckprice] from comment #47)
> Has there been any progress on verifying this in Nightly? Can we initiate
> the uplift request?

Do we have any testing plan for QA or the output from above is sufficient?
Thanks for landing the signing server changes Rail. 

Perhaps we can look at telemetry data for the nightly stub installer ? Might need to wait for a little longer if the stub is not used by a lot of users, but we do serve it via nightly.mozilla.org/www.mozilla.org (by pointing at the url in comment #48).
Comment on attachment 8821401 [details] [diff] [review]
[gecko] Specify sha2signcodestub for stub installer

Approval Request Comment
[Feature/Bug causing the regression]:
This bug supports the Stub Attribution project - bug 1222258.

[User impact if declined]:
Attribution efforts and campaigns for monitoring growth and acquisition will be delayed.

[Is this code covered by automated tests?]:
I am not sure.

[Has the fix been verified in Nightly?]:
No.

[Needs manual test from QE? If yes, steps to reproduce]:
I don't think so, see comment 35.

[List of other uplifts needed for the feature/fix]:
None.

[Is the change risky?]:
Moderately.

[Why is the change risky/not risky?]:
The change itself is small (changing variable names), but it will touch every stub download.

[String changes made/needed]:
None.
Attachment #8821401 - Flags: approval-mozilla-beta?
Attachment #8821401 - Flags: approval-mozilla-aurora?
NI :stephend to see if this completes his end to end testing.
Flags: needinfo?(stephen.donner)
Comment on attachment 8821401 [details] [diff] [review]
[gecko] Specify sha2signcodestub for stub installer

stub installer signing change, aurora52+
Attachment #8821401 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Any verification, testing we can do here?
Flags: needinfo?(andrei.vaida)
(In reply to Cory Price [:ckprice] from comment #51)
> NI :stephend to see if this completes his end to end testing.

I can and will spot-check the nightly stub installer for basic functionality, but I think in order for me to test and verify that the Stub Attribution-specific capability is working, we'd need to hook it into Bouncer and Jeremy's Stub Attribution Service (like we did for the current test binary: /product=test-stub).

need-info? on :oremj - something we can and probably should discuss/confirm in today's Stub Attribution Checkin meeting, too.
Flags: needinfo?(stephen.donner) → needinfo?(oremj)
From talking with Matt it sounds like this was verified as far as it could be in nightly, and the main risk is that new installs don't work. Let's go ahead and uplift to beta then.
Comment on attachment 8821401 [details] [diff] [review]
[gecko] Specify sha2signcodestub for stub installer

Let's try to get this into m-b for today's beta 14 build.
Attachment #8821401 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
We have bouncer products for Nightly that might be useful:
 https://download.mozilla.org/?product=firefox-nightly-stub&os=win&lang=en-US    (for en-US)
 https://download.mozilla.org/?product=firefox-nightly-stub-l10n&os=win&lang=de  (for locales)
Verified both of those return a stub with the dummy cert included.
(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #54)
> Any verification, testing we can do here?

(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #56)
> From talking with Matt it sounds like this was verified as far as it could
> be in nightly, and the main risk is that new installs don't work. Let's go
> ahead and uplift to beta then.

We'll sign off 51.0b14 today using stub-installers, on Windows. I'm not sure if there's much else we can do, other than paying attention to how builds behave during and after installing them this way.
Flags: needinfo?(andrei.vaida)
Sorry; I had a comment ready last night, but forgot to post it (right before I headed to a meetup).

I've verified that the Stub Attribution service works on both Windows 7 and Windows 8.1 builds, with the nightly stub installer.

Build ID: Build identifier: Mozilla/5.0 (Windows NT 6.1; rv:53.0) Gecko/20100101 Firefox/53.0
We've also tested the stub installer for Firefox Beta 14, and encountered no issues. As far as testing the actual stub attribution goes, I was not able to get the same results as Stephen, but I guess I must be missing something, as I'm not aware of the actual test steps here.
(In reply to Stephen Donner [:stephend] from comment #55)
> (In reply to Cory Price [:ckprice] from comment #51)
> > NI :stephend to see if this completes his end to end testing.
> 
> I can and will spot-check the nightly stub installer for basic
> functionality, but I think in order for me to test and verify that the Stub
> Attribution-specific capability is working, we'd need to hook it into
> Bouncer and Jeremy's Stub Attribution Service (like we did for the current
> test binary: /product=test-stub).
> 
> need-info? on :oremj - something we can and probably should discuss/confirm
> in today's Stub Attribution Checkin meeting, too.

Correct, releng will need to add the product to bouncer for this to work.
Flags: needinfo?(oremj)
We are scheduled for a launch on February 2nd to release. Pinging a few folks (understanding that nthomas is away at the moment) to confirm that this hit release okay.
Flags: needinfo?(nthomas)
Flags: needinfo?(florin.mezei)
(In reply to Cory Price [:ckprice] from comment #66)
> We are scheduled for a launch on February 2nd to release. Pinging a few
> folks (understanding that nthomas is away at the moment) to confirm that
> this hit release okay.

Cory, what is needed from QA here? 
Do we want a sanity check of the stub installer (and only after February 2nd)?
Do we want to also check that stub attribution works as expected? If yes, note that when I've tried this in comment 64 I couldn't find any attribution values on the about:telemetry page - are there any specific steps needed to see these values?

Adding Andrei so he's aware of this request.
Flags: needinfo?(florin.mezei) → needinfo?(andrei.vaida)
I've verified that the 51.0.1 stub installer contains the dummy certificate (en-US & de locales, which covers both code paths) so there's nothing left to do on my side.
Flags: needinfo?(nthomas)
(In reply to Florin Mezei, QA (:FlorinMezei) from comment #67)
> (In reply to Cory Price [:ckprice] from comment #66)
> > We are scheduled for a launch on February 2nd to release. Pinging a few
> > folks (understanding that nthomas is away at the moment) to confirm that
> > this hit release okay.
> 
> Cory, what is needed from QA here? 
> Do we want a sanity check of the stub installer (and only after February
> 2nd)?
> Do we want to also check that stub attribution works as expected? If yes,
> note that when I've tried this in comment 64 I couldn't find any attribution
> values on the about:telemetry page - are there any specific steps needed to
> see these values?
> 
> Adding Andrei so he's aware of this request.

Cory, did you get the chance to look into this?
Flags: needinfo?(cprice)
Hi Andrei, I should have followed up. Comment 68 provided verification for this. Thanks.
Flags: needinfo?(cprice)
Flags: needinfo?(andrei.vaida)
Nick, do you think we can close this?
Flags: needinfo?(nthomas)
Priority: -- → P1
Yes, we're using this in production now.
Assignee: nobody → nthomas
Flags: needinfo?(nthomas)
Status: REOPENED → RESOLVED
Closed: 3 years ago3 years ago
Resolution: --- → FIXED
Component: Tools → General
You need to log in before you can comment on or make changes to this bug.