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 <[email protected]> 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
>> [email protected]
>> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
