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.
_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
