lldb ...

[Jeremy Huddleston Sequoia]

> On Sep 5, 2016, at 03:49, Rainer Müller <raimue at macports.org> wrote:
> 
> On 2016-09-05 00:57, René J.V. Bertin wrote:
>> In a first draft the command accepted a list of binaries to sign, and read the identify from a configuration file. I suppose that corresponds to what you mean with a declarative syntax?
>> I then went to a simpler, single-binary interface because I realised that it would sometimes be necessary to specify a different identity. It shouldn't be hard to change that into
>> 
>> ```
>> codesign identity binary1 [binary2 [...]]
>> ```
> 
> In a Portfile you would not be interested in the name of the identity,
> the but trust policy it grants (firewall bypass, task_for_pid, etc.).
> 
> Otherwise you would expect users to set up different identities and
> assign the correct trust policy, which is just not feasible.
> 
> I am thinking of a list of files and policies such as:
> 
> codesign.files       ${prefix}/bin/binary1 developer \
>                     ${prefix}/bin/binary2 firewall
> codesign.identifier  org.macports.${name}


I don't like this approach.

We should solve this type of problem at the base layer.  Everything should be codesigned as configured in macports.conf (using a specified identity in a specified keychain, or defaulting to adhoc).

The port itself should build() using adhoc signing, and base's post-build should resign everything (preserving all attributes) using the settings specified in macports.conf.

This approach allows us to specify an identity on the builders that is an apple developer signing identity such that all binaries coming out of MacPorts have a chain of trust back to Apple.



> Of course this identifier would usually just be the default value, so it
> does not need to be specified explicitly.
> 
>>>> Alternatively, MacPorts could create the certificate and then export it in such a way that users only have to import it. There might be other benefits to that (signing kexts provided by ports ...).
>>> 
>>> I don't think I understand your idea... Why would we need to export it
>>> for users to import it again? The generated identity is meant only to be
>>> used by MacPorts and nothing else.
>> 
>> I don't know how easy it is to automate the certificate creation, if at all possible. Creating one that users only have to import removes a step or two that could go wrong (if it cannot be automated), importing may be easier to automate, and there may be an advantage if everyone signs using the same certificate.
> 
> If users need a identity, they can generate one with Keychain Access.
> The identity generated by MacPorts is only meant to be used by MacPorts.
> 
>>> This approach cannot be used to sign kext, as that requires a
>>> certificate signed by Apple.
>> 
>> I was thinking about a hypothetical possibility to redistribute such a signed certificate. I know, probably extremely unlikely, but one can dream :)
> 
> No way to do that. As we are code-signing on the local machine, we would
> need to distribute the private key. Everyone would be allowed to sign
> their kext with this, which defeats the whole purpose of signed kexts.
> 
>>> This is not fully automatic and requires user interaction. This makes it
>>> fragile as it requires users to follow manual steps very closely to
>>> generate a certificate and set the required trust. That needs to be
>>> automated.
>> 
>> I wouldn't be completely surprised if it turns out to be impossible to automated the whole process; Apple could well have seen to that as a protection against unexpected certificates popping up, with unlimited trust etc. It's been a while since I used the API, and I only used the parts related to traditional credentials, and keychain creation/management.
> 
> My intention here is to describe a way how the code-signing can be
> automated. We do not gain much by providing a solution that still
> requires manual interaction by the user. Generating a certificate and
> signing the binary should be completely transparent to the user.

That obfuscation is very bad for security purposes.  We should not hide this detail from users.  It needs to be very explicit.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4465 bytes
Desc: not available
URL: <https://lists.macosforge.org/pipermail/macports-dev/attachments/20160908/1a63e814/attachment.p7s>