lldb ...

[Jeremy Huddleston Sequoia]

> On Sep 2, 2016, at 05:19, Rainer Müller <raimue at macports.org> wrote:
> 
> On 2016-08-31 23:25, Lawrence Velázquez wrote:
>>> On Aug 31, 2016, at 4:57 PM, René J.V. Bertin <rjvbertin at gmail.com> wrote:
>>> 
>>> I noticed that Apple don't ship an lldb-mi executable (at least they don't for OS X 10.9). 
>> 
>> Xcode 7.3 includes it (`xcrun --run lldb-mi`) but Xcode 4.6.3 does not. Someone else is welcome to bisect on that.
>> 
>>> Has anyone looked at building an lldb port before?
>> 
>>> The real problem is going to be with the code-signing. This is done automagically by lldb's Xcode projects so it's not entirely clear which files have to be signed ... nor if an "ad-hoc" signing identify ("-") will lead to a usable debugger.
>> 
>> You opened a ticket about this a while ago. One of Eric's comments hints at what a pain it might be to get it working with code signing.
>> 
>> https://trac.macports.org/ticket/45251
> 
> That would equivalent to what gdb recommends for codesigning.
> 
> https://sourceware.org/gdb/wiki/BuildingOnDarwin#Giving_gdb_permission_to_control_other_processes
> 
> 
> 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.


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

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

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

> 
> Rainer
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4465 bytes
Desc: not available
URL: <https://lists.macosforge.org/pipermail/macports-dev/attachments/20160908/36c1f79f/attachment.p7s>