We need to get a developer ID from Apple; this will give us some kind of cert, and a local private key for signing.
Then we need to figure out how to get that key and cert onto the build machine, in the Keychain of the account that runs the buildbot.

Jens Alfke
added a comment - 30/Nov/12 3:21 PM We need to get a developer ID from Apple; this will give us some kind of cert, and a local private key for signing.
Then we need to figure out how to get that key and cert onto the build machine, in the Keychain of the account that runs the buildbot.

To test this go to System Preferences / Security & Privacy, and on the General tab set "Allow applications downloaded from" to "Mac App Store and Identified Developers". Set this before running Couchbase Server.app the first time. Once an app has been allowed to run this setting is no longer checked for that app, and there doesn't seem to be a way to reset that.

What is odd is that on my system, I allowed one unsigned build to run before restricting the app run setting, and then no other unsigned builds would be checked (and would all be allowed to run). Either there is a flaw in my testing methodology, or a serious weakness in this security setting: Just because one app called Couchbase Server was allowed to run should confer this privilege to other apps with the same name. A common malware tactic is to modify a trusted app and distribute it as update, and if the security setting keys off the app name it will do nothing to prevent that.

Phil Labee (Inactive)
added a comment - 31/Jan/13 9:39 AM To test this go to System Preferences / Security & Privacy, and on the General tab set "Allow applications downloaded from" to "Mac App Store and Identified Developers". Set this before running Couchbase Server.app the first time. Once an app has been allowed to run this setting is no longer checked for that app, and there doesn't seem to be a way to reset that.
What is odd is that on my system, I allowed one unsigned build to run before restricting the app run setting, and then no other unsigned builds would be checked (and would all be allowed to run). Either there is a flaw in my testing methodology, or a serious weakness in this security setting: Just because one app called Couchbase Server was allowed to run should confer this privilege to other apps with the same name. A common malware tactic is to modify a trusted app and distribute it as update, and if the security setting keys off the app name it will do nothing to prevent that.
I'm approving this change without having satisfactorily tested it.

Strictly speaking it's not the app name but its bundle ID, i.e. "com.couchbase.CouchbaseServer" or whatever we use.

> I allowed one unsigned build to run before restricting the app run setting, and then no other unsigned builds would be checked

By OK'ing an unsigned app you're basically agreeing to toss security out the window, at least for that app. This feature is really just a workaround for older apps. By OK'ing the app you're not really saying "yes, I trust this build of this app" so much as "yes, I agree to run this app even though I don't trust it".

> A common malware tactic is to modify a trusted app and distribute it as update

If it's a trusted app it's hopefully been signed, so the user wouldn't have had to waive signature checking for it.

Jens Alfke
added a comment - 31/Jan/13 11:42 AM Strictly speaking it's not the app name but its bundle ID, i.e. "com.couchbase.CouchbaseServer" or whatever we use.
> I allowed one unsigned build to run before restricting the app run setting, and then no other unsigned builds would be checked
By OK'ing an unsigned app you're basically agreeing to toss security out the window, at least for that app. This feature is really just a workaround for older apps. By OK'ing the app you're not really saying "yes, I trust this build of this app" so much as "yes, I agree to run this app even though I don't trust it".
> A common malware tactic is to modify a trusted app and distribute it as update
If it's a trusted app it's hopefully been signed, so the user wouldn't have had to waive signature checking for it.

Further thought: It might be a good idea to change the bundle ID in the new signed version of the app, because users of 2.0 with strict security settings have presumably already bypassed security on the unsigned version.

Jens Alfke
added a comment - 31/Jan/13 11:45 AM Further thought: It might be a good idea to change the bundle ID in the new signed version of the app, because users of 2.0 with strict security settings have presumably already bypassed security on the unsigned version.

Jin Lim
added a comment - 13/Feb/13 4:09 PM Please move this bug to 2.0.2 after populating the required signature manually. I am lowing the severity to critical for it isn't no longer a blocking issue.

Phil Labee (Inactive)
added a comment - 18/Feb/13 11:19 AM operator error.
I rebuilt the app, this time verifying that the codesign step occurred.
Uploaded now file to same location:
http://packages.northscale.com/latestbuilds/couchbase-server-community_x86_64_2.0.1-160-rel-signed.zip

Maria McDuff (Inactive)
added a comment - 03/Apr/13 8:22 PM works in 10.7 but not in 10.8.
if we can get the fix for 10.8 by tomorrow, end of day, QE is willing to test for release on tuesday, april 9.

Phil Labee (Inactive)
added a comment - 04/Apr/13 11:34 AM The mac builds are not being automatically signed, so build 185 is not signed. The original 172 is also not signed.
Did you try
http://packages.northscale.com/latestbuilds/couchbase-server-community_x86_64_2.0.1-172-signed.zip
to see if that was signed correctly?

Test on a machine that has never had Couchbase Server installed, and has the security setting to only allow Appstore or signed apps.

If you get the "Couchbase Server.app was downloaded from the internet" warning and you can click OK and install it, then this bug is fixed. The quarantining of files downloaded by a browser is part of the operating system and is not controlled by signing.

Phil Labee (Inactive)
added a comment - 04/Apr/13 4:09 PM I rebuilt 2.0.1-185 and uploaded a signed app to:
http://packages.northscale.com/latestbuilds/couchbase-server-community_x86_64_2.0.1-185-rel.SIGNED.zip
Test on a machine that has never had Couchbase Server installed, and has the security setting to only allow Appstore or signed apps.
If you get the "Couchbase Server.app was downloaded from the internet" warning and you can click OK and install it, then this bug is fixed. The quarantining of files downloaded by a browser is part of the operating system and is not controlled by signing.

Wayne Siu
added a comment - 29/May/13 9:04 PM Work Around:
Step One
Hold down the Control key and click the application icon. From the contextual menu choose Open.
Step Two
A popup will appear asking you to confirm this action. Click the Open button.

Phil Labee (Inactive)
added a comment - 22/Aug/13 7:02 PM Install version 2.2.0-806 on a macosx 10.8 machine that has never had Couchbase Server installed, which has the security setting to require applications to be signed with a developer ID.

verified in rc1 (build 817). still not fixed. getting same msg:
“Couchbase Server” can’t be opened because it is from an unidentified developer.
Your security preferences allow installation of only apps from the Mac App Store and identified developers.

Work Around:
Step One
Hold down the Control key and click the application icon. From the contextual menu choose Open.

Step Two
A popup will appear asking you to confirm this action. Click the Open button.

Maria McDuff (Inactive)
added a comment - 28/Aug/13 3:36 PM verified in rc1 (build 817). still not fixed. getting same msg:
“Couchbase Server” can’t be opened because it is from an unidentified developer.
Your security preferences allow installation of only apps from the Mac App Store and identified developers.
Work Around:
Step One
Hold down the Control key and click the application icon. From the contextual menu choose Open.
Step Two
A popup will appear asking you to confirm this action. Click the Open button.

Phil Labee (Inactive)
added a comment - 11/Nov/13 4:37 PM Installed certs as buildbot and signed app with "(recommended) 3rd Party Mac Developer Application", producing
http://factory.hq.couchbase.com//couchbase_server_2.5.0_MB-7250-001.zip
Signed with "(Oct 30) 3rd Party Mac Developer Application: Couchbase, Inc. (N2Q372V7W2)", producing
http://factory.hq.couchbase.com//couchbase_server_2.5.0_MB-7250-002.zip
These zip files were made on the command line, not a result of the make command. They are 2.5G in size, so they obviously include mote than the zip files produced by the make command.
Both versions of the app appear to be signed correctly!
Note: cannot run make command from ssh session. Must Remote Desktop in and use terminal shell natively.

Phil Labee (Inactive)
added a comment - 11/Nov/13 7:48 PM Finally, some progress: If the zip file is made using the --symlinks argument it appears to be un-signed. If the symlinked files are included, the app appears to be signed correctly.
The zip file with symlinks is 60M, while the zip file with copies of the files is 2.5G, more than 40X the size.

Phil Labee (Inactive)
added a comment - 13/Aug/14 6:28 PM The production macosx builder has been cloned:
10.6.2.159 macosx-x64-server-builder-01-clone
if you want to use your own host, see:
http://hub.internal.couchbase.com/confluence/display/CR/How+to+Setup+a+MacOSX+Server+Build+Node

I've got everything configured, but the build process fails at the final step, after I press the Distribute button in the Organizer window. I get a very uninformative error alert, "Code signing operation failed / Check that the identity you selected is valid."

I've asked for help on the xcode-users mailing list. Blocked until I hear something back.

Jens Alfke
added a comment - 15/Aug/14 4:03 PM Here are the Apple docs on building apps signed with a Developer ID: https://developer.apple.com/library/mac/documentation/IDEs/Conceptual/AppDistributionGuide/DistributingApplicationsOutside/DistributingApplicationsOutside.html#//apple_ref/doc/uid/TP40012582-CH12-SW2
I've got everything configured, but the build process fails at the final step, after I press the Distribute button in the Organizer window. I get a very uninformative error alert, "Code signing operation failed / Check that the identity you selected is valid."
I've asked for help on the xcode-users mailing list. Blocked until I hear something back.

With the release of OS X Mavericks 10.9.5, the way that OS X recognizes signed apps will change. Signatures created with OS X Mountain Lion 10.8.5 or earlier (v1 signatures) will be obsoleted and Gatekeeper will no longer recognize them. Users may receive a Gatekeeper warning and will need to exempt your app to continue using it. To ensure your apps will run without warning on updated versions of OS X, they must be signed on OS X Mavericks 10.9 or later (v2 signatures).

If you build code with an older version of OS X, use OS X Mavericks 10.9 or later to sign your app and create v2 signatures using the codesign tool. Structure your bundle according to the signature evaluation requirements for OS X Mavericks 10.9 or later. Considerations include:

Signed code should only be placed in directories where the system expects to find signed code.

Resources should not be located in directories where the system expects to find signed code.

The --resource-rules flag and ResourceRules.plist are not supported.

Make sure your current and upcoming releases work properly with Gatekeeper by testing on OS X Mavericks 10.9.5 and OS X Yosemite 10.10 Developer Preview 5 or later. Apps signed with v2 signatures will work on older versions of OS X.

Phil Labee (Inactive)
added a comment - 25/Aug/14 8:01 PM from Apple Developer mail list:
Dear Developer,
With the release of OS X Mavericks 10.9.5, the way that OS X recognizes signed apps will change. Signatures created with OS X Mountain Lion 10.8.5 or earlier (v1 signatures) will be obsoleted and Gatekeeper will no longer recognize them. Users may receive a Gatekeeper warning and will need to exempt your app to continue using it. To ensure your apps will run without warning on updated versions of OS X, they must be signed on OS X Mavericks 10.9 or later (v2 signatures).
If you build code with an older version of OS X, use OS X Mavericks 10.9 or later to sign your app and create v2 signatures using the codesign tool. Structure your bundle according to the signature evaluation requirements for OS X Mavericks 10.9 or later. Considerations include:
Signed code should only be placed in directories where the system expects to find signed code.
Resources should not be located in directories where the system expects to find signed code.
The --resource-rules flag and ResourceRules.plist are not supported.
Make sure your current and upcoming releases work properly with Gatekeeper by testing on OS X Mavericks 10.9.5 and OS X Yosemite 10.10 Developer Preview 5 or later. Apps signed with v2 signatures will work on older versions of OS X.
For more details, read “Code Signing changes in OS X Mavericks” and “Changes in OS X 10.9.5 and Yosemite Developer Preview 5” in OS X Code Signing In Depth":
http://c.apple.com/r?v=2&la=en&lc=us&a=EEjRsqZNfcheZauIAhlqmxVG35c6HJuf50mGu47LWEktoAjykEJp8UYqbgca3uWG&ct=AJ0T0e3y2W
Best regards,
Apple Developer Technical Support

Michael Kwok
added a comment - 16/Feb/15 8:29 PM I have a signed version that has been tested on 2 separate machines. It behaved as expected both times. Can somebody verify it's truly working? I uploaded to the link below.
http://latestbuilds.hq.couchbase.com/3.0.2/codesigned/
-Michael

Wayne Siu
added a comment - 16/Feb/15 10:26 PM Michael,
Tested on Mavericks (10.9.5) and it works. The "unidentified developer" message did not pop up. Will test on an older version next.
Can you also push this fix to sherlock if it works?

Nice, it's also backward compatible as expected. Thanks for verifying. Currently, I can only do the signing manually from command line on my MacBook. We can work on moving to the server after I get everything backup.

I just uploaded the signed version for Sherlock to the same location. Look for couchbase-server-enterprise_3.5.0-1289-macos.zip.

Michael Kwok
added a comment - 17/Feb/15 1:36 PM Nice, it's also backward compatible as expected. Thanks for verifying. Currently, I can only do the signing manually from command line on my MacBook. We can work on moving to the server after I get everything backup.
I just uploaded the signed version for Sherlock to the same location. Look for couchbase-server-enterprise_3.5.0-1289-macos.zip.

We have the ability to sign a MAC OS X application for distribution outside of MAC App Store. Keep in mind this is strictly for MAC OS X signing. Apple has a different process for signing iOS and also distributing through MAC App Store. That's something we can tackle later when we get to it. It's not significantly different and also requires a few extra steps.

Michael Kwok
added a comment - 18/Feb/15 1:07 PM We have the ability to sign a MAC OS X application for distribution outside of MAC App Store. Keep in mind this is strictly for MAC OS X signing. Apple has a different process for signing iOS and also distributing through MAC App Store. That's something we can tackle later when we get to it. It's not significantly different and also requires a few extra steps.