lldb ...

[Jeremy Sequoia]

Sent from my iPhone...

> On Sep 8, 2016, at 17:32, Rainer Müller <raimue at macports.org> wrote:
> 
>> 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.

Yes, and users that build on their own can sign them however they want.

Binaries that we produce should be signed by MacPorts as a generally good security practice.

The same system should be used for both purposes.

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

Correct.  Users that want to create their own debugger will need to sign the executable with a trusted certificate.

> For what use case would ad-hoc code-signing be useful on macOS?

Consistency and correctness.

> What would be the benefit of adding an ad-hoc signature?

It's more of a correctness check at that point than a security check.

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

Automating it leads to attack vectors that are trivially exploitable.  If you go down this road, you will introduce a very juicy exploit, and this project will loose trust of many users.

Yes, users make mistakes.  Let such error-prone users just use our binaries and let experts do it themselves.  Let's make it secure by default.

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

Yes.  And also support keeping it encrypted with a passphrase that the user would be prompted for on use.

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

Yes, the certificate and public key needs to be there if self signed, but it's equally possible to use a certificate that has an existing chain of trust (e.g.: ADC-provided developer codesigning key)

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

You would just need to provide it once (at the start of running port).

I already enter my password for sudo access when upgrading.  This is just one more prompt.

> That will only annoy users as when they have to type their password more
> often.

Only the ones that opt into it, and they will understand the need and likely desire this functionality.

> 
> Rainer
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.macosforge.org/pipermail/macports-dev/attachments/20160908/22a07d0c/attachment-0001.html>