lldb ...

[René J.V. Bertin]

On Thursday September 08 2016 13:09:33 Jeremy Huddleston Sequoia wrote:
>> codesign.files       ${prefix}/bin/binary1 developer \
>>                     ${prefix}/bin/binary2 firewall
>> codesign.identifier  org.macports.${name}
>
>
>I don't like this approach.
>
>We should solve this type of problem at the base layer.  Everything should be codesigned as configured in macports.conf (using a specified identity in a specified keychain, or defaulting to adhoc).

I think you'll also need to specify the user who owns the keychain, let's call him/her the macports_operator.

Technically it doesn't really matter if it's implemented in "base" or in a PortGroup, right? I like the idea of a PortGroup because it allows to deploy the new feature without waiting for a new base release, and also makes pushing updates so much easier.
Similarly, it shouldn't really make a difference whether the information is read from macports.conf or somewhere else - but I suppose a PortGroup can read from that file too.

>The port itself should build() using adhoc signing, and base's post-build should resign everything (preserving all attributes) using the settings specified in macports.conf.

build{} and post-build{} are executed as ${macports_user}, right? That should be compatible with my observation that codesign will change ownership of the target file (unless it's executed as root). There are 2 details to work out:
- HOME is set to ${prefix}/var/macports/home (~macports), not to ~${macports_user} i.e. not the home directory of the user specified via the macports_user variable. It will need to point to the home directory of the user who owns the keychain (${macports_operator})
- evidently ${macports_user} will need to be able to read the required keychain, possibly every directory in the path to that keychain.

The first detail is trivial, the 2nd a bit less. I get around it because the post-activate{} step executes as root, so read access is automatic. The only easy way to solve it for the macports_user is to let the keychain be owned by that user. I've tried to set things up that way by preparing a keychain with a signing certificate and its 2 keys. Once that's done you can automate the process of installing that keychain in ~macports/Library/Keychains and adding it to the search list via the security command. However, codesign refused to find that identity, when called by macports user. There's a transcript of my attempts in an earlier of my messages in this thread.
The base layer could of course do a dedicated post-build that is executed as root. I presume...

>This approach allows us to specify an identity on the builders that is an apple developer signing identity such that all binaries coming out of MacPorts have a chain of trust back to Apple.

Is that something we want (except for things like kexts in ports like the one I once proposed for ZFS) and is that something that Apple would accept ... without requiring a vote in when updates can be published, what can be accepted etc?
I also don't really see why it would be bad to allow ports to let users sign or resign binaries with an identity of their own. If you allow that for building from source, why not allow it for prebuilt packages too? Can you give an example what's so incredibly dangerous about resigning code that was signed on the buildbots? I can see that for things like kexts (which will be rejected anyway if you resign them with an inappropriate key), but for most other stuff in MacPorts? I know of only 1 port that actually requires signing the binary after installing - gdb. All the others I can think of are apps like kmail and family (port:kdepim) which *benefit* from signing to stop the nagging about "do you want this application to accept internet connections". And that can be handled just fine with the ad-hoc identify.

>That obfuscation is very bad for security purposes.  We should not hide this detail from users.  It needs to be very explicit.

A middle ground can probably be found, one that makes it easier for users (and/= increases the likelihood that every user gets it right the 1st time) but that still requires some form of explicit action from the user.

If you look at lldb's instructions for setting up a signing key it isn't very explicit at all what's going on for someone who (honestly?) doesn't really care. It's just tedious. I think that a good compromise would be if an implementation of a codesigning procedure prints the command to execute (a script provided by macports) as a function of the signing requirements, a command that the user can then paste in a CLI . Probably a set of commands; one to create and populate a keychain in the own keychain directory, and a sudo'ed one to install that keychain where it should go, if needed.

> The user should create a keychain and specify the path to the keychain in
> macports.conf.  If that's not set, we should just adhoc sign.

What I don't like about ad-hoc signing is that there is just about no information what that does.

> It should be unlocked by the user providing the password to unlock the
> keychain.

Is that going to work if codesign is executed as macports, or a UID that's not root and doesn't belong to the user currently logged in?

R.