Re: lldb ...

[Jeremy Sequoia]

Sent from my iPhone...

> On Sep 8, 2016, at 17:32, Rainer Müller  wrote:
> 
>> On 2016-09-08 22:03, Jeremy Huddleston Sequoia wrote:
>> 
>>> On Sep 2, 2016, at 05:19, Rainer Müller  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@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev
___
macports-dev mailing list
macports-dev@lists.macosforge.org

Re: lldb ...

[Jeremy Sequoia]

Sent from my iPhone...

> On Sep 8, 2016, at 17:30, Rainer Müller  wrote:
> 
> On 2016-09-08 22:09, Jeremy Huddleston Sequoia wrote:
>>> On Sep 5, 2016, at 03:49, Rainer Müller  wrote:
>>> My intention here is to describe a way how the code-signing can be
>>> automated. We do not gain much by providing a solution that still
>>> requires manual interaction by the user. Generating a certificate and
>>> signing the binary should be completely transparent to the user.
>> 
>> That obfuscation is very bad for security purposes.  We should not hide this 
>> detail from users.  It needs to be very explicit.
> 
> At the moment it is very explicit. We have no automation at all and you
> need to do all of the code-signing yourself or gdb/lldb will not work as
> intended.
> 
> The alternative way, recommended in the notes of the gdb port, requires
> disabling SIP to edit /System/Library/com.apple.taskgated.plist, which I
> would consider even worse for security. See [1].
> 
> Where do you see a security risk in adding a new trusted cert?

You are describing a system to automatically create and automatically trust a 
code signing certificate that contains a private key in a file on disk that is 
not encrypted with a passphrase and only depends on file system ACLs to protect 
it.

That is trivially insecure and attack-prone.

> Consider that any software can already use your developer certificate
> from your user keychain to sign whatever it wants.

No, it cannot.  It requires my explicit authorization to do so.  I must unlock 
the keychain for it to gain access.

> You will not even be
> asked when that happens.

You should be if you set it up to do so.  If you put your private keys in your 
login keychain, then the act of logging in with your password is what unlocks 
them.  I don't consider that secure enough for my needs, so I place mine in 
another keychain which requires me to explicitly unlock it before use.

> I propose we add an additional keychain, readable by root only that is
> used to sign MacPorts binaries. As root is required to access it, your
> security would be defeated anyway if anyone gets to it.

It's great that only root can read it, but it should not be created 
automatically, added to any trusted store automatically, or stored unencrypted 
automatically.  We should instead give good instructions for setting it up with 
either a self-signed or ADC-Provided code signing certificate.

The user should just specify the path in macports.conf.  If it is locked, we 
should prompt for the passphrase to unlock it before use.


> 
> Rainer
> 
> [1] https://trac.macports.org/ticket/49815
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: lldb ...

[Rainer Müller]

On 2016-09-08 22:03, Jeremy Huddleston Sequoia wrote:
> 
>> On Sep 2, 2016, at 05:19, Rainer Müller  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
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: lldb ...

[Rainer Müller]

On 2016-09-08 22:09, Jeremy Huddleston Sequoia wrote:
>> On Sep 5, 2016, at 03:49, Rainer Müller  wrote:
>> My intention here is to describe a way how the code-signing can be
>> automated. We do not gain much by providing a solution that still
>> requires manual interaction by the user. Generating a certificate and
>> signing the binary should be completely transparent to the user.
> 
> That obfuscation is very bad for security purposes.  We should not hide this 
> detail from users.  It needs to be very explicit.

At the moment it is very explicit. We have no automation at all and you
need to do all of the code-signing yourself or gdb/lldb will not work as
intended.

The alternative way, recommended in the notes of the gdb port, requires
disabling SIP to edit /System/Library/com.apple.taskgated.plist, which I
would consider even worse for security. See [1].

Where do you see a security risk in adding a new trusted cert?

Consider that any software can already use your developer certificate
from your user keychain to sign whatever it wants. You will not even be
asked when that happens.

I propose we add an additional keychain, readable by root only that is
used to sign MacPorts binaries. As root is required to access it, your
security would be defeated anyway if anyone gets to it.

Rainer

[1] https://trac.macports.org/ticket/49815
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: lldb ...

[Jeremy Huddleston Sequoia]

> On Sep 8, 2016, at 15:13, René J.V. Bertin  wrote:
> 
> 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.

That's not really necessary.  All that is relevant is that the macports user 
has read access to the file.

> Technically it doesn't really matter if it's implemented in "base" or in a 
> PortGroup, right?

In order for *every* port to benefit, it needs to be in base.

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

If it's in a PortGroup, it is opt-in and doesn't solve the "let's sign 
everything" case.

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

Ah, right, sorry.  Mixing up build system paradigms.

build{} would sign it adhoc.
post_destroot{} would resign it as specified in the macports.conf

> There are 2 details to work out:
> - HOME is set to ${prefix}/var/macports/home (~macports)

HOME is irrelevant.

> , 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})

No, it doesn't.

> - evidently ${macports_user} will need to be able to read the required 
> keychain, possibly every directory in the path to that keychain.

No, the user doing the signing in post_destroot{} would be root.

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

If you want the macports user to do the signing, that's fine too.  It doesn't 
need to own the keychain, just have read access to it.  It could be group read 
access or other read access.

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

Yes.

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

I'd say most definitely.

> (except for things like kexts in ports like the one I once proposed for ZFS) 
> and is that something that Apple would accept

I don't see why not.  I have such a key for XQuartz.

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

That should be controlled at the base layer.  We shouldn't have a mixmatch of 
signing identities for different files as that will break library validation 
for any ports that might need LV.

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

You could certainly resign it after first validating the original signature.

Signing unsigned code without first validating it is a clear security concern.

> 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 

Re: 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 

Re: lldb ...

[Jeremy Huddleston Sequoia]

> On Sep 5, 2016, at 03:49, Rainer Müller  wrote:
> 
> On 2016-09-05 00:57, René J.V. Bertin wrote:
>> In a first draft the command accepted a list of binaries to sign, and read 
>> the identify from a configuration file. I suppose that corresponds to what 
>> you mean with a declarative syntax?
>> I then went to a simpler, single-binary interface because I realised that it 
>> would sometimes be necessary to specify a different identity. It shouldn't 
>> be hard to change that into
>> 
>> ```
>> codesign identity binary1 [binary2 [...]]
>> ```
> 
> In a Portfile you would not be interested in the name of the identity,
> the but trust policy it grants (firewall bypass, task_for_pid, etc.).
> 
> Otherwise you would expect users to set up different identities and
> assign the correct trust policy, which is just not feasible.
> 
> I am thinking of a list of files and policies such as:
> 
> 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).

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.

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.



> Of course this identifier would usually just be the default value, so it
> does not need to be specified explicitly.
> 
 Alternatively, MacPorts could create the certificate and then export it in 
 such a way that users only have to import it. There might be other 
 benefits to that (signing kexts provided by ports ...).
>>> 
>>> I don't think I understand your idea... Why would we need to export it
>>> for users to import it again? The generated identity is meant only to be
>>> used by MacPorts and nothing else.
>> 
>> I don't know how easy it is to automate the certificate creation, if at all 
>> possible. Creating one that users only have to import removes a step or two 
>> that could go wrong (if it cannot be automated), importing may be easier to 
>> automate, and there may be an advantage if everyone signs using the same 
>> certificate.
> 
> If users need a identity, they can generate one with Keychain Access.
> The identity generated by MacPorts is only meant to be used by MacPorts.
> 
>>> This approach cannot be used to sign kext, as that requires a
>>> certificate signed by Apple.
>> 
>> I was thinking about a hypothetical possibility to redistribute such a 
>> signed certificate. I know, probably extremely unlikely, but one can dream :)
> 
> No way to do that. As we are code-signing on the local machine, we would
> need to distribute the private key. Everyone would be allowed to sign
> their kext with this, which defeats the whole purpose of signed kexts.
> 
>>> This is not fully automatic and requires user interaction. This makes it
>>> fragile as it requires users to follow manual steps very closely to
>>> generate a certificate and set the required trust. That needs to be
>>> automated.
>> 
>> I wouldn't be completely surprised if it turns out to be impossible to 
>> automated the whole process; Apple could well have seen to that as a 
>> protection against unexpected certificates popping up, with unlimited trust 
>> etc. It's been a while since I used the API, and I only used the parts 
>> related to traditional credentials, and keychain creation/management.
> 
> My intention here is to describe a way how the code-signing can be
> automated. We do not gain much by providing a solution that still
> requires manual interaction by the user. Generating a certificate and
> signing the binary should be completely transparent to the user.

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

smime.p7s
Description: S/MIME cryptographic signature
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: lldb ...

[Jeremy Huddleston Sequoia]

> On Sep 2, 2016, at 05:19, Rainer Müller  wrote:
> 
> On 2016-08-31 23:25, Lawrence Velázquez wrote:
>>> On Aug 31, 2016, at 4:57 PM, René J.V. Bertin  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@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev



smime.p7s
Description: S/MIME cryptographic signature
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Do I want subports?

[Mojca Miklavec]

On 8 September 2016 at 19:33, Ken Cunningham wrote:
> Working on the optimal way to do this emulator + GUI program.
>
> The emulator itself is best built with i386, for the JIT. This requires
> libSDL to be available in i386 (so presumably +universal). You can monkey
> around with a no-JIT version, but you wouldn't want it, ultimately.
>
> The rather tiny little GUI (that just edits a simple config file with text
> lines) is compatible with gtk1 or gtk2 has no reason to be any special
> architecture (x86-64 would be just fine, if you have the gtk tree built that
> way).
>
> I don't want to make people reinstall their whole gtk tree as universal for
> no reason... on Snow Leopard (building from source) this takes half a day.
> (OK, not quite -- but a long time).
>
> Is this a role for subports, with the emulator forced to i386, but the gui
> left to be whatever?

In the case you describe I would indeed go for subports. If
architecture of the GUI is unrelated to the architecture of the
emulator, it would be an overkill to require building everything as
universal.

Mojca
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Do I want subports?

[Ryan Schmidt]

> On Sep 8, 2016, at 12:33 PM, Ken Cunningham  
> wrote:
> 
> Working on the optimal way to do this emulator + GUI program.
> 
> The emulator itself is best built with i386, for the JIT. This requires 
> libSDL to be available in i386 (so presumably +universal). You can monkey 
> around with a no-JIT version, but you wouldn't want it, ultimately.
> 
> The rather tiny little GUI (that just edits a simple config file with text 
> lines) is compatible with gtk1 or gtk2 has no reason to be any special 
> architecture (x86-64 would be just fine, if you have the gtk tree built that 
> way).
> 
> I don't want to make people reinstall their whole gtk tree as universal for 
> no reason... on Snow Leopard (building from source) this takes half a day. 
> (OK, not quite -- but a long time).
> 
> Is this a role for subports, with the emulator forced to i386, but the gui 
> left to be whatever?

Subports are helpful when several ports share common code, for example a bunch 
of plugins that are built the same way except for some configure options or 
dependencies.

Subports are also often used when several ports share the same version, 
master_sites, distfiles and checksums; that way, when you need to update the 
version, you only need to do it in one place instead of in several portfiles.

You can place any differentiating code in the subport block, or check the 
${subport} variable. If one subport requires i386 but others don't, you can put 
the "supported_archs i386" line in that subport block only.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Do I want subports?

[Ken Cunningham]

Working on the optimal way to do this emulator + GUI program.

The emulator itself is best built with i386, for the JIT. This requires
libSDL to be available in i386 (so presumably +universal). You can monkey
around with a no-JIT version, but you wouldn't want it, ultimately.

The rather tiny little GUI (that just edits a simple config file with text
lines) is compatible with gtk1 or gtk2 has no reason to be any special
architecture (x86-64 would be just fine, if you have the gtk tree built
that way).

I don't want to make people reinstall their whole gtk tree as universal for
no reason... on Snow Leopard (building from source) this takes half a day.
(OK, not quite -- but a long time).

Is this a role for subports, with the emulator forced to i386, but the gui
left to be whatever?

Ken
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: weird (buggy?) build dependency on a clang port

[Chris Jones]

Because macports-clang-3.7 occurs first in the fallback list. Print out
${compiler.fallback} if you don't believe me. :)

Installed compiler ports are not considered "more available" than
uninstalled ones.


Which of course is a good thing. A port installation should be fully 
reproducible. For a given OSX (and perhaps Xcode version), the same 
compiler should be used always, it should not depend on what the user 
happened to have installed.


Chris




- Josh
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: weird (buggy?) build dependency on a clang port

[Joshua Root]

First let me point you to this recent thread: 



On 2016-9-9 00:09 , René J.V. Bertin wrote:

I can still understand (=/= agree) that the compiler selection procedure is 
designed to take the lowest version of a compiler that is supposed to be able 
to build given code.


It isn't. It is designed to use the first compiler in the fallback list 
that is available and not blacklisted. It is implicit in this that 
compilers earlier in the list are more preferable than later ones.



But why does it not take the lowest *available* version, and why does it tell 
me to install (= activate) clang-3.7 rather than install clang-3.6 (from 
scratch)?


Because macports-clang-3.7 occurs first in the fallback list. Print out 
${compiler.fallback} if you don't believe me. :)


Installed compiler ports are not considered "more available" than 
uninstalled ones.


- Josh
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev