lldb ...

[René J.V. Bertin]

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).

>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 ...).

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.

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.

>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.

R.