lldb ...

[Jeremy Huddleston Sequoia]

> On Sep 9, 2016, at 01:17, René J.V. Bertin <rjvbertin at gmail.com> wrote:
> 
> On Thursday September 08 2016 16:03:21 Jeremy Huddleston Sequoia wrote:
> 
>> That's not really necessary.  All that is relevant is that the macports user has read access to the file.
> 
> If memory serves me well I had to set read access on ~macports, ~macports/Library and ~macports/LibraryKeychains too in order to be able to read the test keychain in there as myself.

> The fact that codesign only accepts keychain file arguments that are also in the user's keychain search list may have something to do with that. Anyway, yes, a user specification may not be really necessary, but giving ${macports_user} read access to your own keychain directory (for instance) doesn't sound like such a good idea.

You would have needed to set executable access on those directories, not read access.  And yes, the file would need to be in the user's keychain search list.

Also, yes, giving ${macports_user} read access to your user's login keychain is not a good idea.  It should be locked down to just the users that need it and still guarded by a passphrase.

>>> 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 don't see this argument. Are you considering codesigning each and every binary automatically, without any need for requesting that from the Portfile? What's the point in that?

Yes.  The fact that we aren't doing that for the binary packages that we ship is quite embarrassing.  We should solve this problem more generally such that we can ship properly signed binaries for every port.  Users installing the binary packages that we ship right now are running unsigned code, and that is quite frightening.  There's nothing guaranteeing that the package hasn't been MITMd.  There's no way for us to revoke a certificate if it turns out that our build servers had been compromised, etc.

> OTOH, if portfile devs have to indicate which binary is to be signed they can just as well add a PortGroup to be able to access that functionality. 

Yeah, it would be much better if we just signed every Mach-O in the destroot of every port.

>> If it's in a PortGroup, it is opt-in and doesn't solve the "let's sign everything" case.
> 
> Ah, the problem with inline replying :) I don't think anyone of us has even thought of a "let's sign everything case". There's clearly never been a need for that, and even if at some point it's going to be a necessity there will 1) be enough time to have integrated the then mature feature into "base" and 2) it will become a forced necessicity. 
> 
> As a side-thought: it shouldn't be particularly difficult to implement a "base" feature which defines a set of PortGroups to be included by default by every port, if such a thing doesn't already exist. I know there's been talk about making at least parts of "base" updateable as a port; this could be an easy alternative.

Yeah, I could see this being a PortGroup that is opt-in now and then becomes always-on or opt-out in a future version of base.

>> post_destroot{} would resign it as specified in the macports.conf
> 
> I'd hate that because I've set things up with macports_user=myself and everything under workpath owned by myself, to avoid constant need for UID changing. I kind of doubt I'm the only one maintaining lots of ports who does that.

I don't understand.  Can you elaborate?  Doesn't post_destroot{} run as root in order to setup desired permissions in the destroot?  That's a good place to handle the resigning.

>>> There are 2 details to work out:
>>> - HOME is set to ${prefix}/var/macports/home (~macports)
>> 
>> HOME is irrelevant.
> 
> No, it isn't. It's what the Security framework uses to find keychains. Try it out for yourself and then correct me if I'm wrong ;)
> I was very surprised to discover that, but then I realised that this is why `sudo codesign ...` still uses the calling user's keychains.  Of course I don't know if there have been changes in this aspect in 10.10 or later, but it's true for 10.9 .

That's because you're using sudo, which doesn't change the bootstrap session.  You likely want to do something like:

sudo launchctl asuser `id -u joebob` sudo -u joebob codesign ...

which requires launchd2 (OS X 10.10+)

>> No, the user doing the signing in post_destroot{} would be root.
> 
> Codesign will still need to find the keychain, be able to read it, and the file will need to be in the searchlist of the user in who's homedir the file lives.

Oh, right... because it needs to find the user's keychain search list to validate that the given keychain is in it.  crap.  yeah.

>>> (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.
> 
> Isn't that a bit of a special case, with you certainly having Apple's benediction to work on that particular product?

XQuartz isn't any more blessed in that respect than MacPorts.


>> 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.
> 
> Are you telling us that there's work in progress that will make it near impossible to do traditional Unix development on OS X without jumping through hoops to sign everything?

Not at all.  What I'm saying is related to existing practices.  If an app contains dylibs or frameworks inside of the app bundle, they need to be @rpath or @loader_path or @executable_path-relative in order for the app bundle to be relocateable.  @rpath/@executable_path/@loader_path-relative linkage is not allowed for privileged processes for obvious security reasons.  If the app requires an entitlement to do some privileged operation, it needs to have library-validation enabled in order to utilize such libraries, and those libraries must be signed with the same certificate as the application and have valid codesignatures.

>>> 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.
>> 
>> If that's the case, then my proposal seems perfect.  It results in everything being adhoc signed by default and lets power users (and the buildbots) configure their system to resign executables with a configurable key.
> 
> So even you don't know what the ad hoc identity can and won't allow?

I'm not sure I understand your question.  I very much do understand and can answer whatever question you have.  I thought I made it quite clear in my earlier email.  What do you still not understand.

> The ad hoc key is *not* useable for signing a debugger to make it functional.

Correct.  Of course not.

> So in your approach users who want to install a debugger port will become power users, change their configuration and then what? Rebuild everything if they've been building from source,

No, they just need everything that the debugger executable links against to be signed with a trusted certificate.  That is no different than your case either.  Either way, the debugger and all its dependencies need to be signed by a valid certificate.

> because everything from before that magic moment will have been signed with a different key that *might* break unpredictable things?

Can you elaborate here?  What do you mean by "a different key"?  Adhoc signing does not use a key.  What do you expect might break or be unpredictable?

> In my book that would be a clear argument *against* signing everything, and for signing only those things that really have to be signed.

The adhoc signature contains metadata that is still used for validation/correctness but not security.  That's the value of it.  It's better to have an adhoc signature than no signature at all.  There is absolutely no benefit to being unsigned unless you expect to 

>> If the user can't be bothered to create a codesigning keychain and edit macports.conf, they probably aren't going to be trying to setup their own custom lldb installation in the first place and are probably content with the one provided by Xcode.
> 
> I think opinions differ on that. I'm inclined to think the same thing, but I'll admit that I'd really appreciate a more streamlined approach that allows me to do the whole lldb/code-signing.txt cookbook thing with one or two script calls. Esp. if that also means that we have a better guarantee that every user gets the proper signing key for a given purpose ... even those who have a much more basic grasp of English than we might expect. Have you considered how "easy" it is to follow advanced Keychain Utility instructions for someone who's using a completely different interface language and who has to figure out how the unfamiliar terms from the instructions translate into that language?
> 
> Just to be clear: I've been more or less obliged to install llvm, clang and now lldb because I use KDevelop and maintain a port for it ... and because Apple have decided NOT to ship the llvm dev stuff with Xcode (or even lldb-mi, in 10.9). What KDevelop is used for doesn't involve codesigning (or very rarely so, ATM), so I'm guessing that I'm not the only one using that IDE who isn't particularly interested in having to deal with setting up signing identities.
> Content with Xcode's lldb? Have you already tried to debug a Qt application in Xcode?

No, I don't use Qt nor do I care to touch C++ with a 10 foot poll.

Have you filed a radar at http://bugreport.apple.com requesting that we ship those other llvm utilities?  Can you point me to it, so I can followup internally?

As for Joe User who doesn't want to use Keychain Utility and wants it to "just work", they can use -k rather than -s and get binaries that are signed correctly by our buildbots once they're configured to do so.

>>> What I don't like about ad-hoc signing is that there is just about no information what that does.
>> 
>> What do you mean by that?  Can you elaborate?  I don't quite understand your question.
> 
> What I mean is that I've never found any documentation about what the ad-hoc signing identity does and doesn't allow, the trust policies it provides, etc. The codesigning manpage says that it's "documented elsewhere", suggesting the information exists somewhere, but nowhere I've been able to find.

What is your specific question?

>> If an image has no code signature, then it is treated differently on iOS compared to macOS; on iOS, such tainting causes the process to become !CS_VALID (and likely killed by CS_KILL), but on macOS, lack of code signature does not change the CS_VALID state of the process.
> 
> And here's to that never changing ...

Can you elaborate on why you are concerned about that?  I wonder if it is just confusion about what adhoc signing is about. It doesn't require a signing certificate, just a valid (possibly adhoc) signature on the binaries.


-------------- 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/20160909/24e5d97d/attachment-0001.p7s>