MacPorts Mountain Lion Futures

[James Berry]

Hi Blair,

On Jun 18, 2012, at 8:39 PM, Blair Zajac wrote:

> Backing up a bit, what do we get by signing?  My understanding is that this is required for the App Store, but MacPorts isn't distributed that way.  What issues do we run into if we don't sign?  Can MacPorts not install preconpiled software without signing?
> 

The user has choices to:

	- Accept only signed apps through the Mac App Store
	
	- Accept any signed apps

	- Allow all apps to run

http://arstechnica.com/apple/2012/02/developers-gatekeeper-a-concern-but-still-gives-power-users-control/

Without signing of our binaries, using MacPorts would require "Allow all apps to run". Implementing some or all of what I proposed wouid potentially allow "Accept any signed apps" level of permission. I'll note that I believe it's also possible to specify more granular permissions ("allow the execute at this path to run even though it's not signed"). Whether doing the work to allow us to notch back the degree of gatekeeper control is important or necessary is up for discussion…

(another potential implementation would conceivably tell Mountain Lion to "allow" our unsigned binaries by path during install).

James



> Regards,
> Blair
> 
> On Jun 18, 2012, at 8:30 PM, James Berry <jberry at macports.org> wrote:
> 
>> Here's a bit of dreaming out loud about MacPorts under Mountain Lion and future architectures in a Gatekeeper world.
>> 
>> With Gatekeeper, there are three (or four) tiers of binary deliver we can/should/might consider signing:
>> 
>> (a) The MacPorts installer should be signed.
>> 
>> (b) The MacPorts-installation should be signed.  The binaries here include daemondo, as well as the Tcl extension libraries.
>> 
>> (c) Binaries built by the MacPorts build-bots could be signed.
>> 
>> (d) Binaries built by MacPorts users could be signed.
>> 
>> I think this would call for at least three-different signing keys:
>> 
>>   (1) Official MacPorts distribution signing key for (a) and (b).
>> 
>>   (2) MacPorts build-bot signing key, for (c). This key is more vulnerable to revocation than (1), since it is used to sign a broad variety of software (the ports) that we have somewhat less control over, so it should likely be distinct.
>> 
>>   (3) The MacPorts user could have a per-user or per-machine signing key with which to sign software built by the user on their machine.
>> 
>> If it's possible and feasible to sign binaries for ports, then a per-user and/or per-machine key should be used to sign binaries for each port built. It would be very nice if this didn't require per-port changes, and could be done wholesale.
>> 
>> One approach I've pondered:
>> 
>> - Create an additional phase ("sign") to code-sign. Maybe this would run on the destroot?
>> 
>> - The sign phase would examine all files (in the destroot?), and sign each binary (executable, library or framework?) (if not already signed?).
>> 
>> - The signing key would be per-user/per-machine. So on the build-bot this would be the configured build-bot key (2), and on a user machine it would be the user's key. If no key then no signing.
>> 
>> It seems plausible that all that could be accomplished without too many huge hacks. I likely won't work on any of that any time soon, but thought I'd expose my thinking in case anybody else is so-inclined.
>> 
>> I believe Josh has put in the work already to at least accomplish (a). Do we need to create an apple-recognized official signing key for (1) before we distribute that?
>> 
>> James
>> _______________________________________________
>> macports-dev mailing list
>> macports-dev at lists.macosforge.org
>> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4820 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20120618/174826ce/attachment-0001.bin>