lldb ...

[René J.V. Bertin]

On Monday September 05 2016 12:49:22 Rainer Müller wrote:

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

That depends, I'd say. Is it even possible to uncouple identifier and trust policy to the extent that a single identifier can sign for either of the set of trust policies available for that identity, instead of all of them? 

Because if it can't, you'll still be looking at a certificate per policy, each with an identity (presumably based on the policy name) ... and someone will have to create them.

> Otherwise you would expect users to set up different identities and
> assign the correct trust policy, which is just not feasible.

That problem (if it is one) goes away when certificates (identities) can be created automatically, no?
Either way, it really seems that signing is a requirement that's rarely necessary. And for "basic" things like preventing recurrent requests to allow an app to accept internet connections can be done with the ad-hoc identity, at least on 10.9 . Not that we shouldn't strive to make this all as streamlined as possible, but are the steps to get lldb (or gdb) to work really too complicated to follow for the intended audience of those ports?

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

That looks like just a small variation, icing on the cake that can be formalised once the basic functionality is there (and we know what's feasible in practice, etc).

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

I wasn't hinting at it being used for other purposes.

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

Ideally, yes. But having a formal framework to codesign binaries is a gain even if the process cannot be completely automated, and whether the functionality is implemented in a PortGroup (my preference at least until everything is mature) or in "base".

Reminds me: I'm not really comfortable with the idea that PortFiles would be able to create and store certificates. I'd rather see a form where they can check for the availability of the identity, and then inform the user exactly what command to run. More tedious, but at least it forces you to see what's being done.

R