lldb ...

[René J.V. Bertin]

On Monday September 05 2016 00:13:04 Rainer Müller wrote:

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

Erm, indeed, yes.

> identity generated by the user before. Also, this is implement as a
> command, I would prefer a declarative syntax (list of binaries for
> codesigning).

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 [...]]
```

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

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

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

The macports user doesn't currently have a keychain, so what would be wrong with modifying a dedicated default keychain? (see also below).

I just checked: the Security framework indeed uses $HOME to determine which keychains are available. On OS X 10.9, that is :

```
sudo $SHELL
env HOME=~theOtherUser /Applications/Utilities/Keychain\ Access.app/Contents/MacOS/Keychain\ Access
```

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

If we manage to create a keychain for the macports user that will probably also be the case, unless that user corresponds to the actual user. Because otherwise the signing user won't be signed/logged in, and its keychain(s) will thus be locked. That's actually an argument to store the certificate in a default keychain, as that one will be open after logging in for most users.

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

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

I followed the lldb document to the letter so yes, only the certificate.

R.