lldb ...

[Rainer Müller]

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}

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.

Rainer