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