See the Apple docs in the URL field and bug 400296. At some point, we should sign our code. Signing needs to be done on a Leopard box, but we might not want to sign from within the tinderbox anyway, it might be something we do as we release a QA-ified build. Sam, do you know what it would take to get a code signing certificate? Does mo[fc]o already have one that could be used for Camino? Would they let us use theirs?

(In reply to comment #0) > Sam, do you know what it would take to get a code signing certificate? Does > mo[fc]o already have one that could be used for Camino? Would they let us use > theirs? The Mozilla Corporation has their own code signing cert. It's a "VeriSign ‘Microsoft Authenticode’ Code Signing Digital ID". We use that cert to sign Firefox and Thunderbird installers/binaries on Windows. I'm unclear if that cert will work on Mac as well, but I assume so based on this document: http://developer.apple.com/documentation/Security/Conceptual/CodeSigningGuide/Procedures/chapter_3_section_2.html The Mozilla Corporation cert is highly guarded and protected and only a few people (build) have access to it, for obvious reasons. The machine that signs the builds is also protected well, for the same reasons. Regardless of whether a Mozilla Corporation cert *can* be used or not (and I think it *can*, just that it'd be hard to work out details for), I think we want a Mozilla Foundation cert for signing purposes. Such a cert could also sign SeaMonkey, calendar, and other mozilla.org / Mozilla Foundation-represented projects. I'm not sure who to CC on that... Frank, David, would one of you know if it would be possible to get a code-signing cert for the Foundation? I'll be happy to file a bug specifically for that (and add a dependency to this bug).

After reading the "copious" documentation on this, it's not clear to me what happens wrt to the Keychain (since that's what Apple mentions specifically) if I: 1) Switch from a signed release to a nightly or milestone build 2) Try to access the Keychain from one of my development builds, which have custom mozProfileDirName values set so they always use dev profiles 3) Remove the bundled JEP from a release in order to test a new beta or test JEP version 4) Do anything else along those lines that is a legitimate development/testing/troubleshooting task Will I be "locked out" of Camino's Keychain entries (which is implied some places in the docs) until I return to a codesigned release build, or will I simply "bothered with obscure dialogs asking them to give permission to the keychain" (as implied elsewhere in the docs)?

I don't think you'll be locked out, I think you'll just need to acknowledge that a specific (unsigned) Camino is allowed to access the keychain entries, much like today's unsigned world. When you switch back to a signed build, you'd need to click through to grant it access to entries created by unsigned builds, too. Note that the Apple docs do say stuff like "we don't do much with signatures today, but that might change," so what happens in the future is anyone's guess. That said, there's a distinction between unsigned and signed-but-the-signature-doesn't-match code, according to the docs. Scenario 3 above would be a signed-but-the-signature-doesn't-match situation given the all-inclusive signing approach I've taken here. Signing is easily reversed, but Apple doesn't supply any tools to do it. I could probably show you a simple way to make an executable appear unsigned by finding making simple alterations to the Mach-O load commands if I had to.

Scenario 3 is a real concern for our (and Firefox's, but this really shouldn't affect them until they start using the Keychain, I guess) end-users, since the only way to test and see if Steven's development JEPs fix their particular bugs (since Steven often cannot access the particular problem sites) before a new JEP version is finalized and trickles down to release builds is to remove the JEP from the bundle. If we can reasonably work around it, say by directing users of releases to grab a 1_5 branch nightly and do the replace-the-JEP on it, and have their access to the Keychain not be impaired, that's good :-)

I bet it'll still be clickthroughable, but maybe scary and red and throbbing and lickable instead of the run-of-the-mill keychain access dialog we're all used to. We can test it, of course.

Another idea is that we can treat certain plug-in code like the JEP as optional. It doesn't have to exist in the Camino bundle, but if it does, the signature needs to match what was present when the app was signed in order for the app as a whole to pass validation. By default, this is how codesign sets up lproj directories, and I've carried this into the rules plist attached. There's no reason we can't do the same for other optional loadable stuff. The contents of Contents/MacOS/plugins is probably sufficient. We also have dynamically loadable stuff in Contents/PlugIns, Contents/PreferencePanes, and Contents/MacOS/components but it doesn't seem as likely that anything would need to be removed or replaced in there, nor does it seem like a good idea to treat that stuff as optional.

(In reply to comment #3) > Frank, David, would one of you know if it would be possible to get a > code-signing cert for the Foundation? I'll be happy to file a bug specifically > for that (and add a dependency to this bug). Yes, I think it's a doable thing to get a code signing cert for the Mozilla Foundation, one that could be used in relation to Camino, SeaMonkey, and other non-MoCo/MailCo projects. (Or we could get multiple certs, but there might be a good reason to get just one.) There are at least three things in relation to this that I can think of: 1. Paying for the cert. This is the easiest part, I can handle this, through a couple different approaches. 2. Dealing with VeriSign to prove organizational identity. I can help with this, but it would help to have someone in Mountain View to work with on this part. 3. Technical protection of the private key and maintaining secure use of the key when signing code. This is the biggest issue as far as I'm concerned. Before approving something like this I would need to have a firm plan for how you plan to do this: who are the key people responsible (for accountability I'd want one primary person plus backup), what are the technical measures, what are the administrative procedures to get something signed, and so on. This is especially important if the same cert/key is going to be used with other projects (i.e., not just Camino). So, yes, I suggest you do open a separate bug on this, and start thinking about how to address the administrative and technical issues around doing code signing.

(In reply to comment #9) > So, yes, I suggest you do open a separate bug on this, and start thinking about > how to address the administrative and technical issues around doing code > signing. Filed bug 412031 on this.

I got confused today about Camino.app/Contents/Resources, and Mark corrected me. Signing that folder will break third-party theming (I think), if we want to preserve that.

FWIW, having a valid signature and then breaking it will not lock the user out of the keychain. It will ask the user with a dialog box if they want to give the "new" (unsigned) app permission to the keychain entries. Apple sometimes inadvertently breaks codesignatures for bultt-in apps with their updates (I know, I worked on the updates until a month ago...we were getting much, much better though). This bug is just for Camino. Are there plans to do this with Firefox as well? I see the latest isn't signed: $ codesign -vvv /Applications/Firefox.app /Applications/Firefox.app: code object is not signed

(In reply to comment #12) > FWIW, having a valid signature and then breaking it will not lock the user out > of the keychain. It will ask the user with a dialog box if they want to give > the "new" (unsigned) app permission to the keychain entries. Thanks for that info. > This bug is just for Camino. Are there plans to do this with Firefox as well? I > see the latest isn't signed: Bug 400296

What happened to this bug? It looks like getting the cert bug has now stalled while Seamonkey figures out how they'll go about actually signing their binary; what's Camino's status?

No updates right now, but I bet Mark doesn't own this bug anymore...

We need to do this sooner rather than later. I'll pay for the the Apple program so we can do it. Currently, if you download Camino on OS X 10.8 with default settings, you get a notice because we're not in the Mac App Store or an "identified developer". We need to fix this ASAP and be an identified developer. Smokey, any chance you can take it?

Actually, I think it's worth than this. I think users that didn't upgrade from 10.7 to 10.8 with Camino on their computer can't install it at all without changing their security settings. For me it shows up as a warning, but a new user to 10.8 won't be able to open it at all. Can anyone confirm that that's true?

s/worth/worse

(In reply to Samuel Sidler (:ss) from comment #17) > Actually, I think it's worth than this. I think users that didn't upgrade > from 10.7 to 10.8 with Camino on their computer can't install it at all > without changing their security settings. For me it shows up as a warning, > but a new user to 10.8 won't be able to open it at all. They can right-click on the app and select 'open'. You then get the same (well similar anyway) dialog as on 10.7 and older (app downloaded from the internet, can't verify, etc). http://support.apple.com/kb/HT5290

That's fine, but I don't expect most users to know this.

(In reply to philippe (on hiatus) from comment #19) > (In reply to Samuel Sidler (:ss) from comment #17) > > Actually, I think it's worth than this. I think users that didn't upgrade > > from 10.7 to 10.8 with Camino on their computer can't install it at all > > without changing their security settings. For me it shows up as a warning, > > but a new user to 10.8 won't be able to open it at all. > > They can right-click on the app and select 'open'. You then get the same > (well similar anyway) dialog as on 10.7 and older (app downloaded from the > internet, can't verify, etc). I'm more worried about what happens when Sparkle tries to install an update (say 2.1.3) and relaunch; my guess is we hard-fail, so I think, as Sam mentions, Gatekeeper is probably a bigger issue for the majority of our users. Someone on 10.8 ought to be able to test this by using 2.1.1 to update to 2.1.2… However…I've been thinking about codesigning off and on since 10.6 was released, and much more frequently since Gatekeeper was announced. I haven't done anything because it's still very thorny, and there are lots of policy and technical issues to work out: 1) Do we sign just releases, or nightlies, too? What about milestones (see also question above about what happens to Sparkle installs, since we do nightly->milestone and milestone->milestone upgrades)? If we don't sign everything, what does that mean for people who have a release and we tell them to grab a nightly to get a bug-fix, or people who have a milestone and do the same? Will signed->unsigned just required the ctrl-click to open? Will signed->unsigned still just require re-auth of the current binary to use the Keychain the first time that binary tries (just like now)? 2) What about the ML build? How do we get it signed? If it's still possible to codesign certain files, we can probably just require Framework code + en resources, Camino code + en resources, and then the ML build would be "signed" by default. If not, then… (Note also that if we can only require en resources be signed, people who want to change icons could still do so if they made themselves an en-US, en-GB, en-CA, etc., localization and put that localization ahead of "English" in System Prefs. That mucks with the accept-language and the UI language, though, which in turn requires us to change language-detection code on cbo, but it at least gives those people an option, even if it's not a good one, rather than just leaving them to whine and whine at us.) 3) Is it possible to codesign for Gatekeeper on a 10.5 box? I've heard people claim that codesigning for Gatekeeper requires 10.8, and others claim it requires 10.6. (We know already that the designated requirement has to be generated on 10.5.8 to continue to support 10.5.8: http://fetchsoftworks.com/fetch/blog/gatekeeper-vs-leopard-an-ongoing-tale; this technically means we'd only support 10.4-10.4.11 and 10.5.8-10.8.x :P) But no-one's really addressed doing the signing on 10.5, mostly because everyone else is building on 10.7/8 these days. 4) Build system and/or madhatter support for codesigning. We'd have to codesign between the time the final binary is assembled (after lipo and regeneration of the NSS .chk files) but *before* making the .dmg, or unpack the final .dmg and sign and repack the .dmg before uploading to stage. Neither option is pleasant; in the former case, I think we'd have to rewrite parts of the Gecko build system to break apart a single step into multiple parts, while in the latter case we'd have to write everything from scratch. (It's possible we could crib some of this from current Gecko code, but there'd still be backporting and splicing required.) In either case, we'd need some way of specifying whether or not a given build should be signed. 5) Generate the designated requirement, the codesigning ruleset, and command or script to do the signing. mento's provided at least a start on the second and third item in his early attachments on this bug. And, of course, The Camino Project will have to pony up to get a Developer ID, if all of the rest of the issues can be resolved ;-) Anyway, yes, I'm the person who should own this bug now, but don't expect me to resolve it quickly.

(In reply to Smokey Ardisson (not following bugs - do not email) from comment #21) > I'm more worried about what happens when Sparkle tries to install an update > (say 2.1.3) and relaunch; my guess is we hard-fail, so I think, as Sam > mentions, Gatekeeper is probably a bigger issue for the majority of our > users. Someone on 10.8 ought to be able to test this by using 2.1.1 to > update to 2.1.2… I'll test this some other time when I don't have insomnia and can be sure I do it right. But let me take these one by one... > 1) Do we sign just releases, or nightlies, too? What about milestones (see > also question above about what happens to Sparkle installs, since we do > nightly->milestone and milestone->milestone upgrades)? If we can automate it, we do it for everything. If we can't, we focus on releases now just to get an update out. I'm not worried about nightlies because the people who are using them are few and far between and we can explain the situation to them. Milestones are... well, when's the next milestone? let's not worry about them for now. There'll be a bigger question about what Camino on WebKit supports and I imagine we'll drop some OS X versions to make this easier in the future. > If we don't sign everything, what does that mean for people who have a > release and we tell them to grab a nightly to get a bug-fix, or people who > have a milestone and do the same? Will signed->unsigned just required the > ctrl-click to open? Will signed->unsigned still just require re-auth of the > current binary to use the Keychain the first time that binary tries (just > like now)? We'll run through the scenarios as needed and document them, linking users to the page as needed. > 2) What about the ML build? How do we get it signed? If it's still > possible to codesign certain files, we can probably just require Framework > code + en resources, Camino code + en resources, and then the ML build would > be "signed" by default. If not, then… The answer I have for this is probably one you won't like. Specifically, I think we should drop release notes in other languages and ship one release for the next major version: the ML build. We might have to sign it manually, but that's fine. For the time being, we just sign the ML build manually. It'll be a pain, but we release infrequently enough that we'll be fine. > (Note also that if we can only require en resources be signed, people who > want to change icons could still do so if they made themselves an en-US, > en-GB, en-CA, etc., localization and put that localization ahead of > "English" in System Prefs. That mucks with the accept-language and the UI > language, though, which in turn requires us to change language-detection > code on cbo, but it at least gives those people an option, even if it's not > a good one, rather than just leaving them to whine and whine at us.) There aren't many of those people and I care more about the users on 10.8 we'll lose without Gatekeeper. > 3) Is it possible to codesign for Gatekeeper on a 10.5 box? I've heard > people claim that codesigning for Gatekeeper requires 10.8, and others claim > it requires 10.6. (We know already that the designated requirement has to > be generated on 10.5.8 to continue to support 10.5.8: > http://fetchsoftworks.com/fetch/blog/gatekeeper-vs-leopard-an-ongoing-tale; > this technically means we'd only support 10.4-10.4.11 and 10.5.8-10.8.x :P) > But no-one's really addressed doing the signing on 10.5, mostly because > everyone else is building on 10.7/8 these days. This I don't know. Perhaps we'll have to do the signing on a 10.7/10.8 machine which means non-automated for the time being. Sucks, but it's worth it I think. Again, we'd only do it for releases at this time, not for nightlies or milestones. When we get to the point of a milestone for Camino on WebKit, we'll probably already be building on 10.7/10.8 and it won't be an issue. > 4) Build system and/or madhatter support for codesigning. We'd have to > codesign between the time the final binary is assembled (after lipo and > regeneration of the NSS .chk files) but *before* making the .dmg, or unpack > the final .dmg and sign and repack the .dmg before uploading to stage. > > Neither option is pleasant; in the former case, I think we'd have to rewrite > parts of the Gecko build system to break apart a single step into multiple > parts, while in the latter case we'd have to write everything from scratch. > (It's possible we could crib some of this from current Gecko code, but > there'd still be backporting and splicing required.) In either case, we'd > need some way of specifying whether or not a given build should be signed. We should do the latter (for now, pre-Camino on WebKit). Writing everything from scratch might not be as hard as you think as we could build it into our tinderbox script instead of the entire build system. Or it might be way harder. I don't know. I can take a look at it possibly. > 5) Generate the designated requirement, the codesigning ruleset, and command > or script to do the signing. mento's provided at least a start on the > second and third item in his early attachments on this bug. Yeah... > And, of course, The Camino Project will have to pony up to get a Developer > ID, if all of the rest of the issues can be resolved ;-) That's a piece of cake and I'll make that purchase when we're ready using a Camino-controlled email address. I think we need to block 2.1.3 on this and I think we need to ship it... well, a couple weeks ago, but yeah. ;)

If you folks need any tips on working with codesign / designated requirements, getting the right certificate, etc. just let me know. I did some of the work on the Firefox/Thunderbird side of things. Might be best to swing by #build if you do.

(In reply to Smokey Ardisson (not following bugs - do not email) from comment #21) > I'm more worried about what happens when Sparkle tries to install an update > (say 2.1.3) and relaunch; my guess is we hard-fail, so I think, as Sam > mentions, Gatekeeper is probably a bigger issue for the majority of our > users. Someone on 10.8 ought to be able to test this by using 2.1.1 to > update to 2.1.2… I spoke briefly with a local developer and as far as she understands it (based on Apple dev docs), if the app has the permission bits set, and the user updates through the internal updater (Sparkle), then there are no problems. If the user goes to cb-o and downloads the updated version manually, then he or she has to repeat the whole song-and-dance outlined in comment 19.

(In reply to philippe (on hiatus) from comment #24) > I spoke briefly with a local developer and as far as she understands it > (based on Apple dev docs), if the app has the permission bits set, and the > user updates through the internal updater (Sparkle), then there are no > problems. That's probably the truth for most apps, which aren't part of the quarantine system, but since we're an internet app that's part of quarantine and every file we save/download/create gets quarantined, I'm not sure it will be true for us. I haven't read the Gatekeeper docs, so this is just based on other things I've read before 10.8 was released, so I'd love to be proven wrong :-)

(In reply to Smokey Ardisson (not following bugs - do not email) from comment #25) > (In reply to philippe (on hiatus) from comment #24) > > I spoke briefly with a local developer and as far as she understands it > > (based on Apple dev docs), if the app has the permission bits set, and the > > user updates through the internal updater (Sparkle), then there are no > > problems. > > That's probably the truth for most apps, which aren't part of the quarantine > system, but since we're an internet app that's part of quarantine and every > file we save/download/create gets quarantined, I'm not sure it will be true > for us. I haven't read the Gatekeeper docs, so this is just based on other > things I've read before 10.8 was released, so I'd love to be proven wrong :-) Well, so far, once the permission bits are set, you're good to go (iow: the permissions are kept when upgrading). That is: no difference from 10.7. It asks for permissions to access Keychain items; downloaded files behave the same as with Lion. Installed 10.8; installed Camino 2.1.1 (--> 'open'), accessed a couple of sites - local server, remote servers, downloaded a couple of files, logged in @ some sites (http:// and https://). Updated (manually through check for updates, Sparkle was already bitching about updating before 2.1.1. was fully launched) to 2.1.2 and continued as before (it asks for permissions to access Keychain items, and that is it). No clue what happens with plugins though - I'm sure SS will volunteer to do some extensive testing with Flash…

(In reply to philippe (on hiatus) from comment #26) > Well, so far, once the permission bits are set, you're good to go (iow: the > [...] > Updated (manually through check for > updates, Sparkle was already bitching about updating before 2.1.1. was fully > launched) to 2.1.2 and continued as before (it asks for permissions to > access Keychain items, and that is it). Awesome; thanks for checking! That makes this bug a whole lot less critical, since it's only going to affect new users on 10.8 the very first time they try Camino, and we already have info for them on the download pages.