Ben Hearsum (Posts about signing)

A Brief History of Code Signing at Mozilla

Ben Hearsum — Thu, 30 Jan 2025 16:18:15 GMT

Shipping large software to end-user devices is a complicated process. Shipping large software securely to end-user devices is even more complicated. Signing the things that ship to end-user devices is one of those complications, and it gets even more complicated when you sign thousands of artifacts per day.

Mozilla has been signing Firefox in some form beginning with Firefox 1.0. This began with detached GPG signatures for builds, and progressed to Authenticode signing for Windows installers in Firefox 1.0.1. Since then it has evolved over time to encompass other platforms, other types of files within our products, and other ways that we ship (such as our own update packages). This post will provide a overview of the what, when, why, and how of code signing at Mozilla over the past ~20 years.

What, when, and why

Early GPG & Authenticode Signing

When we first began signing, it happened on a Windows machine. Late in the release process, after Windows installers had been built, we would download all of the release artifacts to this machine, sign the Windows installers, and generate detached GPG signatures for those before pushing the artifacts elsewhere.

At this time, the private keys and certificates were held on a USB stick that was kept removed from the machine at-rest. A Release Engineer needed to be physically present in Mountain View to perform this step. Once inserted, signing could be done via Remote Desktop rather than at the physical machine (but don't forget to remove the USB stick afterwards!).

GPG signing was done with the standard GPG tools, running in cygwin. Authenticode signing was also done with the standard (at the time) Microsoft 'signcode.exe' tool. An annoying fact about that tool, is that it only accepted the necessary passphrase from a GUI dialog. To work around this, we had an AutoIt script running in the background that injected the passphrase into this dialog whenever it popped up. This interesting way of automating the process meant that mouse movements or keyboard interaction at the wrong time could interfere with the signing process.

This process was partly scripted, but there was still a series of ~15 commands someone had to run by hand (and not mess up) to get everything done. You can see these commands for yourself in our now-ancient Unified Release Process documentation.

Windows internal file signing

Careful readers may have noted that early Authenticode signing only covered the Firefox installer itself, not the EXEs and DLLs inside of it. At some point (I haven't gone to the effort of tracking down exactly where...) we started signing these inner files as well. This process seems to have been lost to the sands of time, but I seem to recall it worked very similarly to the installer signing process, but without the GPG parts.

Improved signing on Windows

The first notable improvement we had to this process was to automate most of the copy/pasting that was done from the wiki. This came in the form of a Makefile that with a few mere inputs, would download, sign, and re-upload the signed builds. The main benefit of this was reduced opportunity for human error.

Not long after that, we had our first real game-changing improvements. Chris AtLee wrote a nice post about it back in 2009, and how his changes took signing time from 8 hours all the way down to sub-15 minutes. This was accomplished through a combination of faster hardware, parallelized signing, in-process compression & decompression, and better caching. His changes also introduced a hefty amount of python into the signing process, which paved the way for the next big improvement...

Automatic signing

Despite the signing process now being very quick once it gets started, it could still sometimes take hours or longer to begin the process. Typically this would happen if our build and repack processes finished at a time when no Release Engineer was around to begin signing. This was solved with what we called "autosign". Rather than require a Release Engineer to be around at the right moment, we adjusted our scripts to allow them to be started ahead of time, and be smart enough to know when all of the files it needs to sign are ready. This work eliminated all wait time between builds being ready and signing running.

Signing Windows builds...on Linux!

In 2011, signing was rearchitected altogether. In short, the idea was to move signing to a highly secured Linux server, and sign builds through an API as part of the build process. This allowed builds to be signed as they were produced, and reduced the number of times builds had to move from one server to another before they shipped. An obvious question here is how we would manage to sign Windows binaries on Linux...as it turns out, the mono project had its own version of signcode that ran natively on Linux that we were able to make use of.

MAR Signing

Shortly after (and perhaps even motivating - I'm not sure at this point) the aforementioned signing server work, we began signing our MAR (Mozilla ARchive) packages that update users from an older version of Firefox to a newer version. Thanks to the earlier work, it was fairly trivial to use the same architecture to sign these files.

macOS .app signing

The idea of signing .app bundles for macOS was filed all the way back in 2007. There was some initial work on this in 2010, but we were unable to land it at that time. Around the same time that MAR signing was happening in 2012, we picked up this work again and managed to drive it home this time.

Unfortunately, there were no tools available at the time to sign macOS builds on anything except a fairly modern macOS machine. For this reason, we had to run additional copies of our signing server on macOS and sign those builds with them. (If you've ever had to run macOS as a server you'll know just how unfortunate this was...)

Taskcluster/signingscript/iscript

In 2018, Mozilla migrated its CI and Release automation from our aging Buildbot systems to Taskcluster. As part of this, signing tasks moved to specialized Taskcluster workers known as "signingscript" and "iscript", used for signing non-macOS and macOS builds respectively. These specialized workers continued to outsource the actual work of signing to the previously discussed signing servers.

An important part of this change is the introduction of Chain of Trust, a significant security enhancement that helps ensure that only authentic artifacts are signed to this day.

Introducing...Autograph!

Autograph is Mozilla's modern code signing service. It was built specifically to provide a signing service that allowed us to keep private key material in Hardware Security Modules (HSMs). Migrating release signing to it was a huge improvement over the existing signing server where Release Engineers had direct access to such things. It was initially used for signing XPIs and APKs, but by the end of 2019 we had migrated all non-macOS signing to it and retired the old Linux signing servers.

In addition to the security enhancements it brought, we saw great performance wins with it as well, largely in thanks to it's support for only requiring a hash of the bytes being signed to be sent over the wire. (This requires that the client has some advanced knowledge of the file being signed, but it saves a tremendous amount of network traffic at our scale.)

Notarization with rcodesign

In 2023 we started making use of rcodesign to notarize and staple our macOS builds. While actual macOS code signing itself continues to happen on macOS machines, this allowed us to move at least some of our operations into the cloud and reduce our reliance on mac hardware.

Tools and tech

I've mentioned a number of tools and technology that we use as part of signing, but I've purposely glossed over some details in the interest of brevity. The following section is a glossary of sorts, and introduces some more under the hood tools that we use as part of signing. If you're interested in the gory details, the links below should be enough to find them for yourself! Or you can stop by #firefox-ci on Matrix to ask questions!

osslsigncode

osslsigncode is a tool that implements parts of Microsoft's signtool.exe. In the past, we used it to directly sign PE files. These days, we use it's support for attaching the signatures that Autograph makes to them.

winsign

Winsign is a python library for signing and manipulating Authenticode signatures. It relies on osslsigncode for writing signatures, and supports signing directly with a private key, or outsourcing the signing process to a passed in function. The latter is what we use, and it's how we inject a call to Autograph into the signing process.

msix-packaging

In 2021 we began shipping Firefox as an MSIX package. As part of this we discovered that osslsigncode does not support signing MSIX packages. Luckily for us, Microsoft's MSIX packaging tools are open source and run on Linux, and we found a fork that contained most of what was needed to support signing. With a few additional modifications, we were able to support signing these packages in our existing systems.

apple-codesign

apple-codesign is a very exciting project from Gregory Szorc which provides 3rd party tools capable of signing, notarizing, and stapling .app bundles and other Apple formats such as .pkg and .dmg. These tools run on Linux, and as noted above, we're already making use of them to notarize and staple our .app bundles. We're extremely excited about this project, and grateful to Gregory Szorc for all the effort he's bit into it. In the future we're looking forward to migrating our actual code signing to these tools which would (finally) allow us to retire our dedicated macOS signing machines.

mardor

mardor is a python tool to manage, and most importantly, sign, MAR files. In the days before Autograph it was used to directly sign MAR files. These days we only use it to inject signatures made by Autograph into the files, similar to our usage of osslsigncode.

signingscript

signingscript is the glue between our CI system (Taskcluster) and Autograph. Through a combination of the tools listed above, custom code in signingscript itself, and communication with Autograph it produces signed builds. It is additionally responsible for notarizing and stapling our macOS builds.

iscript

iscript is essentially a pared down version of signingscript (in fact their code is both derived from our early signing server code), and is responsible for signing our macOS builds. iscript runs on a small cluster of mac minis, which are a huge pain in the butt to manage.

autograph

As noted in an earlier section Autograph is our modern code signing service. It has a simple HTTP API that accepts signing requests and returns signed data or files. In addition to signing various artifacts that we ship it also makes Content Signatures on behalf of addons.mozilla.org, aus5.mozilla.org/Balrog (our update server), and some other backend services that Firefox communicates with, helping to ensure the security and integrity of requests made between Firefox and Mozilla-run services.

Conclusion

What a ride it's been over the last 20 years! We've gone from signing nothing to signing nearly everything in some form. Signing started off as a very manual process, and now happens seamlessly thousands of times per day.

I don't think it would be possible to name everyone that contributed to this, but it took the ideas and efforts of tens, if not hundreds, of people to get to this point: release engineers, build system experts, security folks, and many others were all critical to getting us where we are today.

I've got this post as brief as possible, but if you're interested in more details on any parts here feel free to reach out!

Mozilla Software Release GPG Key Transition

Ben Hearsum — Tue, 21 Jul 2015 18:45:18 GMT

Late last week we discovered the expiration of the GPG key that we use to sign Firefox, Fennec, and Thunderbird nightly builds and releases. We had been aware that this was coming up, but we unfortunately missed our deadline to renew it. This caused failures in many of our automated nightly builds, so it was quickly noticed and acted upon.

Our new GPG key is as follows, and available on keyservers such as gpg.mozilla.org and pgp.mit.edu:

pub   4096R/0x61B7B526D98F0353 2015-07-17
      Key fingerprint = 14F2 6682 D091 6CDD 81E3  7B6D 61B7 B526 D98F 0353
uid                            Mozilla Software Releases 
sub   4096R/0x1C69C4E55E9905DB 2015-07-17 [expires: 2017-07-16]

The new primary key is signed by many Mozillians, the old master key, as well as our OpSec team's GPG key. Nightlies and releases will now be signed with the subkey (0x1C69C4E55E9905DB), and a new one will be generated from the same primary key before this one expires. This means that you can validate Firefox releases with the primary public key in perpetuity.

We are investigating a few options to make sure key renewal happens without delay in the future.

Signing Software at Scale

Ben Hearsum — Wed, 28 Jan 2015 16:45:21 GMT

Mozilla produces a lot of builds. We build Firefox for somewhere between 5 to 10 platforms (depending how you count). We release Nightly and Aurora every single day, Beta twice a week, and Release and ESR every 6 weeks (at least). Each release contains an en-US build and nearly a hundred localized repacks. In the past the only builds we signed were Betas (which were once a week at the time), Releases, and ESRs. We had a pretty well established manual for it, but due to being manual it was still error prone and impractical to use for Nightly and Aurora. Signing of Nightly and Aurora became an important issue when background updates were implemented because one of the new security requirements with background updates was signed installers and MARs.

Enter: Signing Server

At this point it was clear that the only practical way to sign all the builds that we need to is to automate it. It sounded crazy to me at first. How can you automate something that depends on secret keys, passphrases, and very unfriendly tools? Well, there's some tricks you need to know, and throughout the development and improvement of our "signing server", we've learned a lot. In the post I'll talk about those tricks and show you how can use them (or even our entire signing server!) to make your signing process faster and easier.

Credit where credit is due: Chris AtLee wrote the core of the signing server and support for some of the signature types. Over time Erick Dransch, Justin Wood, Dustin Mitchell, and I have made some improvements and added support for additional types of signatures.

Tip #1: Collect passphrases at startup

This should be obvious to most, but it's very important not to store the passphrases to your private keys unencrypted. However, because they're needed to unlock the private keys when doing any signing the server needs to have access to them somehow. We've dealt with this by asking for them when launching a signing server instance:

$ bin/python tools/release/signing/signing-server.py signing.ini
gpg passphrase: 
signcode passphrase: 
mar passphrase:

Because instances are started manually by someone in the small set of people with access to passphrases we're able to ensure that keys are never left unencrypted at rest.

Tip #2: Don't let just any machine request signed files

One of the first problems you run into when you have an API for signing files is how to make sure you don't accidentally sign malicious files. We've dealt with this in a few ways:

You need a special token in order to request any type of signing. These tokens are time limited and only a small subset of segregated machines may request them (on behalf of the build machines). Since build jobs can only be created if you're able to push to hg.mozilla.org, random people are unable to submit anything for signing.
Only our build machines are allowed to make signing requests. Even if you managed to get hold of a valid signing token, you wouldn't be able to do anything with it without also having access to a build machine. This is a layer of security that helps us protect against a situation where an evil doer may gain access to a loaner machine or other less restricted part of our infrastructure.

We have other layers of security built in too (HTTPS, firewalls, access control, etc.), but these are the key ones built into the signing server itself.

Tip #3: Use input redirection and other tricks to work around unfriendly command line tools

One of the trickiest parts about automating signing is getting all the necessary command line tools to accept input that's not coming from a console. Some of them are relative easy and accept passphrases via stdin:

proc = Popen(command, stdout=stdout, stderr=STDOUT, stdin=PIPE)
proc.stdin.write(passphrase)
proc.stdin.close()

Others, like OpenSSL, are fussier and require the use of pexpect:

proc = pexpect.spawn("openssl", args)
proc.logfile_read = stdout
proc.expect('Enter pass phrase')
proc.sendline(passphrase)

And it's no surprise at all that OS X is the fussiest of them all. In order to sign you have to unlock the keychain by hand, run the signing command, and relock the keychain yourself:

child = pexpect.spawn("security unlock-keychain" + keychain)
child.expect('password to unlock .*')
child.sendline(passphrase)
check_call(sign_command + [f], cwd=dir_, stdout=stdout, stderr=STDOUT)
check_call(["security", "lock-keychain", keychain])

Although the code is simple in the end, a lot of trial, error, and frustration was necessary to arrive at it.

Tip #4: Sign everything you can on Linux (including Windows binaries!)

As fussy as automating tools like openssl can be on Linux, it pales in comparison to trying to automate anything on Windows. In the days before the signing server we had a scripted signing method that ran on Windows. Instead of providing the passphrase directly to the signing tool, it had to typed into a modal window. It was "automated" with an AutoIt script that typed in the password whenever the window popped up. This was hacky, and sometimes lead to issues if someone moved the mouse or pressed a key at the wrong time and changed window focus.

Thankfully there's tools available for Linux that are capable of signing Windows binaries. We started off by using Mono's signcode - a more or less drop in replacement for Microsoft's:

$ signcode -spc MozAuthenticode.spc -v MozAuthenticode.pvk -t http://timestamp.verisign.com/scripts/timestamp.dll -i http://www.mozilla.com -a sha1 -tr 5 -tw 60 /tmp/test.exe
Mono SignCode - version 2.4.3.1
Sign assemblies and PE files using Authenticode(tm).
Copyright 2002, 2003 Motus Technologies. Copyright 2004-2008 Novell. BSD licensed.

Enter password for MozAuthenticode.pvk: 
Success

This works great for 32-bit binaries - we've been shipping binaries signed with it for years. For some reason that we haven't figured out though, it doesn't sign 64-bit binaries properly. For those we're using "osslsigncode", which is an OpenSSL based tool to do Authenticode signing:

$ osslsigncode -certs MozAuthenticode.spc -key MozAuthenticode.pvk -i http://www.mozilla.com -h sha1 -in /tmp/test64.exe -out /tmp/test64-signed.exe
Enter PEM pass phrase:
Succeeded

$ osslsigncode verify /tmp/test64-signed.exe 
Signature verification: ok

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

Number of certificates: 3
    Cert #0:
        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 #1:
        Subject: /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Assured ID Code Signing CA-1
        Issuer : /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Assured ID Root CA
    Cert #2:
        Subject: /C=US/ST=CA/L=Mountain View/O=Mozilla Corporation/CN=Mozilla Corporation
        Issuer : /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Assured ID Code Signing CA-1

In addition to Authenticode signing we also do GPG, APK, and couple of Mozilla-specific types of signing (MAR, EME Voucher) on Linux. We also sign our Mac builds with the signing server. Unfortunately, the tools needed for that are only available on OS X, so we have to run separate signing servers for these.

Tip #5: Run multiple signing servers

Nobody likes a single point of failure, so we've built support our signing client to retry against multiple instances. Even if we lose part of our signing server pool, our infrastructure stays up:

$ python signtool.py --cachedir cache -t token -n nonce -c host.cert -H dmgv2:mac-v2-signing1.srv.releng.scl3.mozilla.com:9120 -H dmgv2:mac-v2-signing2.srv.releng.scl3.mozilla.com:9120 -H dmgv2:mac-v2-signing3.srv.releng.scl3.mozilla.com:9120 -H dmgv2:mac-v2-signing4.srv.releng.scl3.mozilla.com:9120 --formats dmgv2 Firefox.app
2015-01-23 06:17:59,112 - ed40176524e7c197f4e23f6065a64dc3c9a62e71: processing Firefox.app.tar.gz on https://mac-v2-signing3.srv.releng.scl3.mozilla.com:9120
2015-01-23 06:17:59,118 - ed40176524e7c197f4e23f6065a64dc3c9a62e71: connection error; trying again soon
2015-01-23 06:18:00,119 - ed40176524e7c197f4e23f6065a64dc3c9a62e71: processing Firefox.app.tar.gz on https://mac-v2-signing4.srv.releng.scl3.mozilla.com:9120
2015-01-23 06:18:00,141 - ed40176524e7c197f4e23f6065a64dc3c9a62e71: uploading for signing
2015-01-23 06:18:10,748 - ed40176524e7c197f4e23f6065a64dc3c9a62e71: processing Firefox.app.tar.gz on https://mac-v2-signing4.srv.releng.scl3.mozilla.com:9120
2015-01-23 06:19:11,848 - ed40176524e7c197f4e23f6065a64dc3c9a62e71: processing Firefox.app.tar.gz on https://mac-v2-signing4.srv.releng.scl3.mozilla.com:9120
2015-01-23 06:19:40,480 - ed40176524e7c197f4e23f6065a64dc3c9a62e71: OK

Running your own signing server

It's easy! All of the code you need to run your own signing server is in our tools repository. You'll need to set-up a virtualenv and create your own config file, but once you're ready you can attempt to start it with the following command:

python signing-server.py signing.ini

You'll be prompted for the passphrases to your private keys. If there's any problems with your config file or the passphrases the server will fail to start. Once you've got it up and running you can use try signing! get_token.py has an example of how to generate a signing token, and signtool.py will take your unsigned files and give you back signed versions. Happy signing!

Upcoming changes to Mac package layout, signing

Ben Hearsum — Tue, 12 Aug 2014 16:05:31 GMT

Apple recently announced changes to how OS X applications must be packaged and signed in order for them to function correctly on OS X 10.9.5 and 10.10. The tl;dr version of this is "only mach-O binaries may live in .app/Contents/MacOS, and signing must be done on 10.9 or later". Without any changes, future versions of Firefox will cease to function out-of-the-box on OS X 10.9.5 and 10.10. We do not have a release date for either of these OS X versions yet. Changes required: * Move all non-mach-O files out of .app/Contents/MacOS. Most of these will move to .app/Contents/Resources, but files that could legitimately change at runtime (eg: everything in defaults/) will move to .app/MozResources (which can be modified without breaking the signature): https://bugzilla.mozilla.org/showdependencytree.cgi?id=1046906&hide_resolved=1. This work is in progress, but no patches are ready yet. * Add new features to the client side update code to allow partner repacks to continue to work. (https://bugzilla.mozilla.org/show_bug.cgi?id=1048921) * Create and use 10.9 signing servers for these new-style apps. We still need to use our existing 10.6 signing servers for any builds without these changes. (https://bugzilla.mozilla.org/show_bug.cgi?id=1046749 and https://bugzilla.mozilla.org/show_bug.cgi?id=1049595) * Update signing server code to support new v2 signatures. Timeline: We are intending to ship the required changes with Gecko 34, which ships on November 25th, 2014. The changes required are very invasive, and we don't feel that they can be safely backported to any earlier version quickly enough without major risk of regressions. We are still looking at whether or not we'll backport to ESR 31. To this end, we've asked that Apple whitelist Firefox and Thunderbird versions that will not have the necessary changes in them. We're still working with them to confirm whether or not this can happen. This has been cross posted a few places - please send all follow-ups to the mozilla.dev.platform newsgroup.

Update on Mac Code Signing #2

Ben Hearsum — Fri, 25 May 2012 17:45:05 GMT

In my previous post I said that Mac signing had been turned on, and that it would stay on. Unfortunately, the following morning we caught some issues that only came up after updating. It took a bit of time to resolve those, but as of this morning we got them worked out, and signed mac builds are back. There are a couple of follow-up issues to address, but we're in a good enough state to backport signing to Aurora and Beta, and ship it in Firefox 13.0. On Saturday evening I'll be enabling it on Aurora, and on Monday morning on Beta - assuming no new issues come up. If you see ANY issues related to updating on Mac please file a bug and cc me (:bhearsum). It's very important that any issues are brought up immediately, as we intend to ship this to the release channel on June 5th. Huge thanks (again) to Steven Michaud, Ted Mielczarek, Erick Dransch, and anyone else that helped make this happen.

Update on Mac Code Signing of Firefox

Ben Hearsum — Tue, 22 May 2012 21:11:07 GMT

Last week I talked about our plans around Mac build signing. In it, I said that I intended to have signed dep/try builds by the end of last week and signed Nightly builds early this week. Unfortunately, shortly after publishing I realized that due to some complicated infrastructure reasons, we couldn't turn on dep/try build signing prior to Nightly. However, I'm pleased to announce that all the necessary work for Mac builds signing is landed and in production. From now on, mozilla-central based builds will be signed. As other branches merge the necessary patch, they will be signed too. Nightly updates have been disabled for now, to give QA a chance to verify everything. Nightly updates should be re-enabled sometime tomorrow. This should be an invisible change to everyone, but please file bugs on any issues (especially those related to new installs or updates) and cc me (bhearsum@mozilla.com). Additionally, I want to correct one thing in my previous post. I said that applications 'will not run on 10.8 unless the user has allowed “applications downloaded from anywhere” to run'. However, it has come to my attention that this isn't entirely true. You _can_ except specific applications from this policy if you ctrl+click the application and hit "open". This works for unsigned apps, self signed apps, and those signed with a Mac Development certificate.

Code signing coming to Firefox Mac builds

Ben Hearsum — Thu, 17 May 2012 12:42:08 GMT

A few weeks ago a new Developer Preview of OS X 10.8 was released and it was discovered that as things stand now, Firefox will not run on it. With the current default settings, 10.8 will not allow any software to run unless it's signed with an Apple Developer ID (essentially, a certificate issued by a particular Apple Root CA). We don't know exactly when 10.8 will be released to the public but some have speculated that it could be as early as the week of June 11th at WWDC 2012. We must have a signed and released Firefox out there before the general public starts upgrading and we've been working hard to make that happen as soon as possible. This post will give a short history of Mac signing at Mozilla and talk about our timeline for enabling it.

Background

Code signing of Mac builds has been on our radar for a long time. Bug 400296 was originally filed in 2007. In late 2010 Syed Albiz did a ton of great work figuring out the Apple tools and how we can integrate them into our automation. That work didn't quite get finished before his internship was completed and the bug stagnated for some time afterwards. At the start of this year there was renewed energy when Erick Dransch picked up the bug. We attempted to land his work and enable signing on nightlies in mid-April, but that ended up bouncing due to some conflicts with our upgrade to 10.7-based build machines. Erick's internship expired before everything could be fixed up, and the bug fell to me. After gaining access to Mozilla's Apple Developer account on Monday there was a lot of early iteration before we got to the point where we could sign a build in a way that Mountain Lion liked. There's multiple certificates types that one can get from Apple ("Development Certificate", "Mac App Certificate", "Developer ID Certificate") and multiple versions of OS X and XCode (each with their own quirks) that one can sign with. Mostly thanks to Steven Michaud's knowledge and assistance we figured out exactly what combination of these we'll need to use to have signed Firefox builds that work everywhere.

Where we're at now

At this point in time we've got all the tools we need to sign all Mac Firefox builds. The only blocking issue at this point is figuring out access restrictions to our Apple Developer Account, so that we can generate our final Developer ID certificates.

Endgoal

Like with Windows Authenticode signing we will have 3 different certificates for different types of Firefox builds. Dep and try builds are at the lowest level of trust and have no regular users and therefore will be signed with a self signed certificate. This means that they will not run on 10.8 unless the user has allowed "applications downloaded from anywhere" to run (which is not the default). Nightly and Aurora are at an elevated level of trust and have a userbase. These will be signed with their own Developer ID certificate. Finally, Beta and Release builds are at the highest level of trust and oversight, and represent the majority of our users. They will be signed with a separate Developer ID certificate. From a user standpoint, Nightly, Aurora, Beta and Release will all look the same but using separate certificates gives us some degree of isolation in terms of certificate revocation.

Timeline

I intend to have dep and try builds signed by the end of the week. After we figure out the access restrictions to our Developer Account we will turn on signing of Nightly builds, hopefully early/mid next week. After letting those settle for a day or two we will turn on signing of Aurora and Beta builds, hopefully by the end of next week.

If you're interested in the technical details of signing Mac builds Erick wrote an excellent blog post detailing the trials and tribulations of writing tools around them.

Using Authenticode Code Signing Certificates with OS X's Signing Tools

Ben Hearsum — Tue, 28 Feb 2012 16:15:55 GMT

Our intern Erick has been doing some great work reviving, polishing and finalizing the patches that will allow us to start signing OS X builds (more to come on that in his blog!). When we do start signing them we're planning to use our existing set of code signing certificates for them rather than buy new ones. I thought it would be a simple task to convert them so I set off to convert our internal, self-generated ones. After hours and hours of head scratching and frustration I learned that some versions of Microsoft's "makecert" tool are broken, and generate invalid PKCS7 certs that openssl can't cope with properly. From the OpenSSL PKCS#12 FAQ: Q. What are SPC files? A. They are simply DER encoded PKCS#7 files containing the certificates. Well they are in the newer versions of the tools. The older versions used an invalid PKCS#7 format. The end result of all my attempts ended up being a PKCS#12 certificate that Apple's codesign tool claimed couldn't be used to do code signing. After finding that FAQ, I decided to try to convert our Nightly code signing certificate instead. Following the great instructions found on Marc Liyanage's blog I managed to successfully convert the certificate, import it into a Keychain, and successfully sign something! Here's the shortened version of what I did. Note that it requires the PVK tool found here: ~/pvk.exe -in Nightly.pvk -out Nightly.key.pem openssl pkcs7 -inform der -print_certs Nightly.cert.pem openssl pkcs12 -export -inkey Nightly.key.pem -in Nightly.cert.pem -out Nightly.p12 I hope this helps someone else avoid the same frustration!