lldb ...

[Rainer Müller]

On 2016-09-08 22:03, Jeremy Huddleston Sequoia wrote:
> 
>> On Sep 2, 2016, at 05:19, Rainer Müller <raimue at macports.org> 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
> 
> No, that is incredibly dangerous.  code should not be signed during activate, it should be signed at build time.  The packages that a user downloads from MacPorts should not be altered at activation time.  Ideally, the packages they download should be codesigned by a MacPorts developer codesigning certificate.

I do not want to bless binary archives produced on the buildbot or make
them special. MacPorts is not a binary-only distribution, we allow and
support local compilation of ports.

>> Unsolved problems:
>> For step 1), how to to automate certificate creation.
> 
> Don't.  This should be a manual process.  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.

Adhoc code-signing does not solve the problem at hand with gdb/lldb as
that requires a trusted certificate in keychain as far as I understand it.

For what use case would ad-hoc code-signing be useful on macOS?
What would be the benefit of adding an ad-hoc signature?

>> We cannot click
>> that in Keychain Assistent. That means finding a way to do it
>> programmatically with other tools. As far as I see, this is just a
>> standard x509 certificate which could be done with openssl, but which
>> extensions need to be enabled?
>>
>> For step 4), how to give user 'macports' access to the System.keychain
>> without entering a password?
> 
> Don't use System.keychain.  A separate keychain should be used just for the codesigning.  It should be password protected, and the user should be prompted for the password to unlock the keychain as part of 'port build'.

Users just want to get a working gdb/lldb, they don't want to learn
stuff about keychain or code-signing. They would need to create an
identity with a specific name, know where to place it, and set the
correct trust on the certificate. All these factors will lead to user
errors and that makes the manual process not feasible in my opinion.

After some testing, I would no longer want to add the identity (private
key) to System.keychain, but instead keep it in a separate keychain
accessible by root only.

However, as far as I see, for trusting the certificate (public key) it
needs to be in System.keychain or taskgated will not accept it.

>> As an alternative, how to import the
>> identity (both private/public key) into a different keychain with
>> unlocked access?
> 
> It should be unlocked by the user providing the password to unlock the keychain.

I definitely do not want my upgrades to get stalled by password dialogs.
That will only annoy users as when they have to type their password more
often.

Rainer