1318456 - Stub installer with dummy cert for testing

Status: RESOLVED FIXED

(Release Engineering :: Release Requests, defect)

Description

[Cory Price [:ckprice] (bugmail disabled, NI me!)]

In bug 1261140 we created a mechanism to add attribution data to the Stub Installer. We're now ready to do some testing, and we'd like a build with the dummy cert uploaded and added to bouncer to test against.

Could we have this dummy build up by Monday? Feel free to ping (ckprice/oremj/mhowell) with any questions.

Comment 1

[Chris Cooper [:coop] (he/him)]

Monday seems ambitious, but I've cc-ed some people who may be able to help.

Comment 2

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

Happy to do the bouncer setup, but unsure how the build is done. From mozilla-release with some extra data included ? Are there any requirements on cert used for signing ? aka could we use try ? To force the generation and upload of the stub from there we'd have to adjust https://dxr.mozilla.org/mozilla-central/source/browser/confvars.sh#16

Comment 3

[Molly Howell (she/her) (mostly inactive)]

What needs to happen is an additional certificate (the "dummy certificate" attached to bug 1261140) gets included when the installer is signed by adding a -ac option to the existing osslsigncode invocation. That's the only thing to change vs. what's in mozilla-release now. The actual signing certificate used doesn't really matter, so using try should be fine.

Comment 4

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

So this is a one-off request to add the dummy cert when signing a stub installer, which can be any rev as long as it's v49 or higher, and the self-signed cert from try can be the main cert. The signing server doesn't support this mode at the moment, so I think we'll need to grab an unsigned instgen/setup-stub.exe (from a slave, or a signing server cache) and sign it manually. We're reproducing the code at
  https://hg.mozilla.org/build/tools/release/signing/signscript.py#108
  https://hg.mozilla.org/build/tools/file/default/lib/python/signing/utils.py#l75

In the longer term are we going to need to do this for every stub that gets signed ? Some subset ?

What do you guys need from a bouncer point of view ?

Comment 5

[Cory Price [:ckprice] (bugmail disabled, NI me!)]

(In reply to Nick Thomas [:nthomas] from comment #4)
> In the longer term are we going to need to do this for every stub that gets
> signed ? Some subset ?
I believe we implemented bug 1261140 in such a way that wouldn't require a re-signing every visit. But :mhowell would have to confirm.
 
> What do you guys need from a bouncer point of view ?

NI :oremj for this one.

Comment 6

[Molly Howell (she/her) (mostly inactive)]

That's correct. An additional certificate needs to get inserted at the initial signing, but that's the only change to the signing procedures. There is no re-signing after that. The attribution data is added by inserting it into an unused space inside the dummy certificate.

Comment 7

[Jeremy Orem [:oremj]]

From what I understand, all stub installers going forward will need this dummy cert, so it won't be a one off.

Nothing specific is needed on the bouncer side as long as the -stub, pointed at in bouncer, contain the dummy cert.

Comment 8

[Cory Price [:ckprice] (bugmail disabled, NI me!)]

+ a few folks

NI :nthomas - are you unblocked here? We'd like start end to end testing immediately after the U.S. holiday; can this be delivered Monday?

Comment 9

[Chris AtLee [:catlee]]

Matt, is it possible to modify the stub installer build process to insert the fake certificate prior to handing it off to the signing server?

Comment 10

[Molly Howell (she/her) (mostly inactive)]

IIRC, it should be possible in theory, but I wasn't able to make the tools (namely osslsigncode) append another certificate after initial signing.

Comment 11

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

(In reply to Cory Price [:ckprice] from comment #8)
> NI :nthomas - are you unblocked here? We'd like start end to end testing
> immediately after the U.S. holiday; can this be delivered Monday?

Yes, I'll start working on this today.

Comment 12

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

Attachment: Notes

https://download.mozilla.org/?product=test-stub&os=win&lang=en-US

See attached notes for commands used. I ended up using the nightly cert, to make the 'osslsigncode verify' output easier to digest. 

> $ osslsigncode verify test-stub.exe
> Current PE checksum   : 00041023
> Calculated PE checksum: 00041023
> 
> Message digest algorithm  : SHA1
> Current message digest    : 326E77F037AE6C9D1136C2966E1C3FF65AF29095
> Calculated message digest : 326E77F037AE6C9D1136C2966E1C3FF65AF29095
> 
> 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

Comment 13

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

Meant to say that's based on the 50.0 release stub (https://hg.mozilla.org/releases/mozilla-release/rev/dc617d65c9f0), so it'll pull in the latest release build when it's run.

We should have a separate discussion/bug for what we need longer term. It should be relatively straight forward to sign every stub installer, or every stub installer for a beta or release (by adding another signing target on the server, and calling it just for stubs; plus provisioning the dummy cert). It would be useful to know some use cases and any requirements from sec reviews.

Please reopen if the test needs adjusting.

Comment 14

[Cory Price [:ckprice] (bugmail disabled, NI me!)]

Thank you Nick!

(In reply to Nick Thomas [:nthomas] from comment #13)
> We should have a separate discussion/bug for what we need longer term. It
> should be relatively straight forward to sign every stub installer, or every
> stub installer for a beta or release (by adding another signing target on
> the server, and calling it just for stubs; plus provisioning the dummy
> cert). It would be useful to know some use cases and any requirements from
> sec reviews.
Just opened bug 1320773 (feel free to move to a more appropriate component, or change summary).

> Please reopen if the test needs adjusting.
:stephend - is this all good for your testing purposes?

Comment 15

[Cory Price [:ckprice] (bugmail disabled, NI me!)]

Also NI :mbrandt

Comment 16

[Stephen Donner [:stephend] Not actively reading bugmail]

(In reply to Cory Price [:ckprice] from comment #14)

<snip>

> :stephend - is this all good for your testing purposes?

Still evaluating that; for now, I think I'm awaiting the deployment of code changes from bug 1279291 to staging (https://stubattribution-default.stage.mozaws.net/), so I've need-info'd :oremj in that bug, while I continue trying to test.

Comment 17

[Stephen Donner [:stephend] Not actively reading bugmail]

Just commented over in bug 1279291 comment 37 - Bedrock isn't currently set up to deal with this "?product=test-stub" product name/value, which is blocking further testing.