lldb ...

Rainer Müller raimue at macports.org
Sun Sep 4 15:13:04 PDT 2016


On 2016-09-02 14:45, René J.V. Bertin wrote:
> On Friday September 02 2016 14:19:02 Rainer Müller wrote:
> 
>>> https://trac.macports.org/ticket/45251
>>
>> That would equivalent to what gdb recommends for codesigning.
> 
> Yes, minus the part related to taskgated. And plus a few extra steps that probably serve to add the certificate to the trust store.
> 
>> In my opinion, the actual implementation of codesigning should be in base:
>>
>> 1) Create a self-signed certificate/identity for code-signing
>> 2) Import certificate/identity into keychain
>> 3) Add it to trust store (`security add-trusted-cert ...`)
>> 4) In activate phase, if requested in Portfile, codesign the binary
> 
> That's what's done in my PortGroup, which could of course be a vector to test out the functionality before integrating it into "base" (and make it available before the next new base release).

For reference, this would be about #51504:
https://trac.macports.org/ticket/51504

As far as I see it, this only implements step 4), it already expects an
identity generated by the user before. Also, this is implement as a
command, I would prefer a declarative syntax (list of binaries for
codesigning).

>> Unsolved problems:
>> For step 1), how to to automate certificate creation. We cannot click
>> that in Keychain Assistent. That means finding a way to do it
>> programmatically with other tools. As far as I see, this is just a
>> standard x509 certificate which could be done with openssl, but which
>> extensions need to be enabled?
> 
> 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.

This approach cannot be used to sign kext, as that requires a
certificate signed by Apple. There is no (documented) way to trust
another certificate in the kernel.

> If the security utility doesn't already allow it, it shouldn't be particularly hard to write some code that will import a certificate into a possibly newly created keychain that is then set default. When executed as the macports user this should result in a keychain that's accessible to ... the macports user.

codesign accepts a --keychain option, so there is no need to modify the
default keychain.

> But are you sure that the activate and/or post-activate phases are executed as the macports user? I don't have the impression that's the case.

You are correct that only root would need access. That could mean that
the certificate could just be in the System.keychain. In my testing that
always seems to require a password, though...

>> For step 4), how to give user 'macports' access to the System.keychain
>> without entering a password? As an alternative, how to import the
>> identity (both private/public key) into a different keychain with
>> unlocked access?
> 
> Is there anything wrong with my approach of specifying a username (typically your own) that's used only for the signing operation?
>
> BTW, I'm pretty sure that I tried putting the certificate back into the System keychain and attempt to sign without specifying a user. That still gave the error that the certificate wasn't found, which is why I kept searching and found the solution currently implemented in the PortGroup.

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.

In your testing, did you move the private/public key ("identity") or
maybe just the public key ("certificate")?

Rainer


More information about the macports-dev mailing list