lldb ...

[René J.V. Bertin]

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.

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

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

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


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

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

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

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

>> 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?
The ad hoc key is *not* useable for signing a debugger to make it functional. 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, because everything from before that magic moment will have been signed with a different key that *might* break unpredictable things?

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

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

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

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

R