Closed Bug 493797 Opened 12 years ago Closed 11 years ago

write rel-automation signing scripts for WinMo releases

Categories

(Release Engineering :: General, defect, P3)

x86
Windows Mobile 6 Standard
defect

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: bhearsum, Unassigned)

References

Details

(Whiteboard: [winmo])

No description provided.
We definitely need to sign the .cab files we distribute, but we also may need to sign the internals of them - as we do for win32 builds.

I'm going to do some tests in an emulator to see where and when we get prompted or stalled in different configurations - this should help us figure out what we care about.

Stuart has mentioned that different devices can have different root stores on them, too, so we may need to get one or more additional certificates in order to make sure our builds are recognized everywhere - he will be looking into that.
Priority: -- → P2
So, I've done a bunch of testing in the "USA Windows Mobile 6.1 Classic Emulator" with Visual Studio 2008. Here's the results:
Locked mode, third party two-tier, third party one-tier: Could not install, got the following message: "Installation was unsuccessful. The program or setting cannot be installed because it is not digitally signed with a trusted certificate"

Prompt mode: Could install after clicking through security dialogue, "The program is from an unknown publisher. You shuold install it only if you trust its publisher. Do you want to continue?" -> "Yes". After installation it ran without further prompting.

Security off: installed and ran fine without errors or messages.


I tried all of the modes above with both an unsigned build and a signed build (with the appropriate certs installed on the emulator) - the results were the same in both cases.

I also tested running Fennec in Locked and Third Party mode after installing with security off - in both cases Fennec refused to run with the following error: "The file 'fennec' cannot be opened. Either it is not signed with a trusted certificate, or one of its components cannot be found. If the problem persists, try reinstalling or restoring this file."

So, I need to know which modes we want to support. If we only care about Prompt mode or Security Off mode we can sign only the cab (It would still be good to get a compatible cert, though). If we want to support Locked or Third Party we should sign the cab and the internals.
(In reply to comment #1)
> We definitely need to sign the .cab files we distribute, but we also may need
> to sign the internals of them - as we do for win32 builds.

Note: when signing the cab, what root certificate should we be using? The signature would say "Mozilla", either way. The question is about the root cert for the signing key: right now our signing key has a root cert from Thawte. Should we get another root cert as is used on the physical devices - and if so, which root cert?

Note: mechanically, signing the internals is more complicated then we first thought. We can still do this if its *needed*, but it will need either tricky cab-extract-reconstruct work, or else putting signing keys on all pool-o-build-slaves (scary!). If we only care about "Prompt" or "Security Off" modes, then we can skip this step, and only sign the cab files. 

Note: Signing cab files only is something we can do on keymaster using existing toolchain. Signing internals will require additional investigation and setup work.
OS: Mac OS X → Windows CE
Hardware: x86 → All
fwiw, I'm pretty sure we need signed builds (and maybe other things; not sure yet) to get crash reports from Microsoft. I'm currently emailing them about that.
(In reply to comment #4)
> fwiw, I'm pretty sure we need signed builds (and maybe other things; not sure
> yet) to get crash reports from Microsoft. I'm currently emailing them about
> that.

By "signed builds" you mean the internals, right? (Eg, fennec.exe, libxul.dll, et. al)
I worked through the ins and outs of doing internal signing today - we can do it if necessary. We'll want to get a cert that is included on the devices if we want to support Locked or Third Party modes though - even with the internals and cab file signed Fennec will not install in either of those modes.

I still need some
OS: Windows CE → Mac OS X
Hardware: All → x86
(hit commit too soon)

I worked through the ins and outs of doing internal signing today - we can do
it if necessary. We'll want to get a cert that is included on the devices if we
want to support Locked or Third Party modes though - even with the internals
and cab file signed Fennec will not install in either of those modes.

I still need someone to make a call on what signing we care about. Related, Stuart, you told me you were going to figure out which root we want to get a cert from for this - did you make any headway there?
Blocks: 473651
seems like signing the installer cab files with the right certs to allow installation on locked  devices is the first priority.  without that adoption of fennec will be hindered, espcially on latter releases of windows mobile.

application file signing is the second priority and it sounds like thats needed to get crash data back from microsoft.   so far I haven't seen any other "permissions" related stuff show up that might benefit application file signing.
I talked with Stuart and Jay about this last week, they're trying to figure out which cert needs to be used for signing. Moving to FUTURE until this is sorted out.
Assignee: bhearsum → nobody
Component: Release Engineering → Release Engineering: Future
OS: Mac OS X → Windows CE
Priority: P2 → P3
Summary: figure out what signing is needed for wince releases and make sure we have scripts to do it → write rel-automation signing scripts for WinMo releases
mid-quarter status check, no direction yet. 


(In reply to comment #4)
> fwiw, I'm pretty sure we need signed builds (and maybe other things; not sure
> yet) to get crash reports from Microsoft. I'm currently emailing them about
> that.
Sam, what did you hear back from Microsoft on this?
I have no heard back from them on that yet. I'll re-email.
(In reply to comment #5)
> By "signed builds" you mean the internals, right? (Eg, fennec.exe, libxul.dll,
> et. al)

I never answered this, but yes, that's what I meant.
(In reply to comment #11)
> I have no heard back from them on that yet. I'll re-email.

Any update on this?
(In reply to comment #11)
> I have no heard back from them on that yet. I'll re-email.

ss: ping?
It has been a while since I looked at this bug, and I am sorry now for not recording my thoughts earlier.  The security question for Windows Mobile devices breaks down into two distinct sections: installation security and execution security.  Each section is controlled using a separate certificate "store" within the device's Registry.   

There are a number of "root" certificates contained in each of these Registry certificate "stores".  The certificates in these stores are considered "root" certificates because an application signed with any of these certificates, or ANY certificates derived from these certificates, is provided the security "clearance" specified by the corresponding "root" certificate.  

That is, if you have an application signed using a certificate C derived from certificate B which is in the Registry "store", then your application gets the rights specified for the certificate B in the Registry "store".

When Windows Mobile devices were first rolled out, carriers were (and still are) very scared of Microsoft (or anyone else besides themselves) deciding to use a pre-installed certificate to sign some bit of code that the carrier did not want on handsets on their networks.  This fear caused a LOT of confusion and uncertainty as carriers tried to come to grips with a very complicated security model which was tacked onto the Windows CE operating system by the Windows Mobile team.

This confusion continues to this day, as a few carriers lock their Windows Mobile devices down - specifying that applications which wish to be installed on their Windows Mobile devices MUST go through a carrier-specific vetting process in order to be signed BY THE CARRIER.  These carriers sell Windows Mobile devices which do not allow 3rd party, unsigned applications to be installed or run.

The majority of carriers decided to ship their Windows Mobile devices with "User Prompt" turned on.  This means that the user can decide to install 3rd party, unsigned applications.  Depending upon EACH Windows Mobile device's security settings, a 3rd party application may or may not be able to access "Privileged" APIs on the device.  How does this show up for the user?

The user may be able to install a CAB file by answering a user prompt, but the application that is installed would NOT be able to be loaded by their handset.  The user would see a "This application is not signed with a certificate with enough privilege to run.  Please contact the software manufacturer for an update." (or some such prompt).

What are these Privileged APIs? As a good rule of thumb, any API that might end up costing the user some money has been made into a Privileged API.

I am not up-to-date upon whether Fennec/Xulrunner accesses any of these Privileged APIs.

As you might guess, getting signed with a certificate which has the ability to access these Privileged API is MUCH harder than getting signed with a certificate that does not.

Where does this leave Mozilla?  More in the next comment.
Microsoft finally responded to all the criticism surrounding certificate signing with the Mobile 2 Market program, which offers the ability for 3rd party applications to be signed with either a Privileged API certificate (VERY HARD TO GET), or an Unprivileged API certificate (which allows you to run on most Windows Mobile devices, but not access the Privileged APIs).

Most carriers responded to this Mobile 2 Market program positively, accepting an outside authority for vetting applications in return for a better developer eco-system.  Some carriers still remove the Microsoft Mobile 2 Market developer certificates from their devices, and continue to demand that 3rd party application developers go through their vetting process.

PLEASE NOTE: ALL signing programs that I know about require you to first build an installation CAB file, then submit that CAB file for approval and signing BY THE SIGNING AUTHORITY (like Microsoft's Mobile 2 Market) before a signed CAB file will be returned to you.

This will not work for nightly builds, alpha or beta releases - as it makes no sense to ship each build off to a developer program to get signed.  Also, anyone working with an interim build should have a for-development (or at least, user prompt) device.  

The best of these signing authorities is the Microsoft Mobile 2 Market program, which ultimately results in your CAB file being signed by certificates that are on almost all of the Windows Mobile devices sold today.


Since it is not practical to submit nightly builds to an external signing authority, what signing certificate should we use for nightly builds?  

Perhaps a Mozilla company certificate can be used to create a child certificate which can then be used to sign the nightly builds. 


A simple application can be built which will, for most Windows Mobile devices, allow a user to place a certificate into the precious "Privileged Execution Trust Certificate Store" and "SPC Certificate Store" on their device.  

This application could then be offered as a "run-me-first-and-hit-this-button-once" kind of application for those users considering installing a fennec build on their Windows Mobile devices.  

This application can even be inside source control, available for all to see and create for themselves.

This application depends upon certain security settings in order to work, and may not work with future devices -- depending upon the future devices' security settings.

I hope this information helps.
There is a tool which can break apart an existing CAB file, identify and sign all executables, then put the CAB file back together and sign the CAB file.  

That tool is CABSIGNTOOL.exe and is located within the Windows Mobile 6 SDK.

The Windows Mobile 6 SDK is typically installed at "C:\Program Files\Windows Mobile 6 SDK\Tools\Security\CabSignTool\cabsigntool.exe".

One caveat: You will need to have an application called signtool.exe on your shell's PATH environment variable.  

For Visual Studio 8, signtool.exe typically resides in "c:\Program Files\Microsoft Visual Studio 8\Common7\Tools\bin\signtool.exe"
(In reply to comment #16)
> Since it is not practical to submit nightly builds to an external signing
> authority, what signing certificate should we use for nightly builds?  
> 
> Perhaps a Mozilla company certificate can be used to create a child certificate
> which can then be used to sign the nightly builds. 
> 

What's the reason we need to sign nightly builds at all?
You are absolutely correct - my mistyping.  I meant to reference pre-release builds (like alpha and beta builds), not nightly builds.

Although some might make the argument that we should submit alpha and beta builds to whatever certificate signing process we envision for non-alpha/beta builds.

In any case, I think your point is that we should not sign nightly builds at all.  

Nightly builds are just convenient for development purposes.  Anyone who downloads and installs a nightly build should be a more sophisticated user (or developer) anyway.  Right?
(In reply to comment #19)
> You are absolutely correct - my mistyping.  I meant to reference pre-release
> builds (like alpha and beta builds), not nightly builds.
> 
> Although some might make the argument that we should submit alpha and beta
> builds to whatever certificate signing process we envision for non-alpha/beta
> builds.
> 

I fully agree with this. Consistency is better here, and there's no reason for us to bring up signing infrastructure if we're not using it for the majority of releases.

> In any case, I think your point is that we should not sign nightly builds at
> all.  

If there's no big downside to not signing nightly builds I don't think we should. This would be consistent with what we already do with Desktop Firefox builds, too.
(In reply to comment #13)
> (In reply to comment #11)
> > I have no heard back from them on that yet. I'll re-email.
> 
> Any update on this?

I was on vacation when you pang me here.

(In reply to comment #14)
> (In reply to comment #11)
> > I have no heard back from them on that yet. I'll re-email.
> 
> ss: ping?

I had just returned from vacation and was behind on email when you pang me here.

No update yet, which is not good. I've asked shaver for a better contact.
> (In reply to comment #14)
> > (In reply to comment #11)
> > > I have no heard back from them on that yet. I'll re-email.
> > 
> > ss: ping?
> 
> I had just returned from vacation and was behind on email when you pang me
> here.
> 
> No update yet, which is not good. I've asked shaver for a better contact.

ping?
Thanks to bhearsum for finding bug#529537 about possible change to WinMO installer... which would impact work in this bug about signing scripts.
Mass move of bugs from Release Engineering:Future -> Release Engineering. See
http://coop.deadsquid.com/2010/02/kiss-the-future-goodbye/ for more details.
Component: Release Engineering: Future → Release Engineering
Status: ASSIGNED → NEW
Whiteboard: [winmo]
Found during triage. 

blassey, stuart: a lot has changed since this was filed. Can you summarize what is needed here?
OS: Windows CE → Windows Mobile 6 Standard
Blocks: 554087
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → INCOMPLETE
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.