lldb ...

[René J.V. Bertin]

On Friday September 09 2016 12:10:05 Rainer Müller wrote:


> > different than your case either.  Either way, the debugger and all
> > its dependencies need to be signed by a valid certificate.
> 
> That does not seem to be the case. In my testing on OS X 10.10 Yosemite,
> it is enough to sign /opt/local/bin/ggdb with a trusted certificate to
> get it working.

And lldb requires only the debugserver executable to be signed.

> Did this change with El Capitan or Sierra?

I'm guessing that would somehow be evident from the lldb-3.9 CMake files and build instructions...

> At least on OS X 10.10 Yosemite, I can use any path to a keychain with
> `codesign --keychain`. This keychain does not have to be listed in
> `security list-keychains`.

Does `man codesign` still mention the search list  requirement in the documentation for --keychain?

On Friday September 09 2016 02:26:19 Jeremy Huddleston Sequoia wrote:

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

I do a lot of development on projects for which I also maintain ports; in fact, development that's tightly coupled to the fact the code is available via a port. Doing all that work "as myself" only to transfer it to the port afterwards is a hassle and waste of time as far as I'm concerned. It's not so much that I want to avoid having to put sudo in front of each and every port command (I'd write a `sport` wrapper/alias). I don't want to grow the habit of putting sudo in front of everything I'm doing around those ports' build directories and that I'd also be doing in development that's got nothing to do with MacPorts. I also want to be able to open a port's source tree in an IDE, run incremental builds in subdirs for ${build.dir}, etc. So I've set my macportsuser to my own username, and most of the time I run everything up to and including `port destroot` as myself (and set up symlinks to `port work` for easy access). Typically, for -devel ports that use fetch.git I also replace ${worksrcdir} with a symlink to the working copy under my own home directory (that way I also won't lose local changes if I ever forget to use -o or -k).
Many of the contributions I've made to KDE over the past few years were developed with this approach. I've used the standard approach (macportsuser = macports) on a VM Bradley gave me access to, and it's definitely a lot less productive.
Evidently this is not the kind of advanced use we need to consider for regular users, but port developers/maintainers are users too, and I think we *could* consider their needs too.

As an aside, I'd be in favour of setting up MacPorts such that ${prefix} is owned by a ${macports_operator} who's got admin rights (= myself) and reserve use of actual root privilege to those few ports that require setting up SETUID/GETUID executables or that need to create users or groups. MacPorts installs into a parallel prefix, and there are only few ports that require access to system directories. 

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

From what I can tell the Security framework (and the security and codesign execs) work from a remote (SSH) connection too. Indeed, sudo doesn't by default change HOME (there's the -H option for that) ... but that's basically what I'm arguing.

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

And the fact you're an Apple's payroll doesn't have anything to do with it either? Currently Apple doesn't have a say in the admission and upgrade of each and every port in MacPorts, do they? In a way I'd even hope they cannot force the exclusion of a port (other than ones clearly doing unlawful things); signing everything with an official key seems like a way to give them (more) leverage to control over the ports tree.

> > > So even you don't know what the ad hoc identity can and won't allow?
> > 
> > I'm not sure I understand your question.

Sorry, I understood that you hadn't realised that signing with the ad hoc identity prevents the persistent firewall popup for internet-enabled applications.

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

So a library that's signed ad-hoc won't be rejected when loaded in an application that's signed with a different identity and that requires all its dependencies to be signed with that same identity? 
What I did notice is that signing lldb with a proper lldb_codesign key didn't have any immediate effect after it had been signed with an ad-hoc key. I refused to reboot (that simply ought not be necessary, certainly not multiple times) and it was only after I stumbled upon the suggestion to restart taskgated that I got the re-signed lldb to work. Apparently that trick isn't guaranteed to work, so yeah, I'd call that an aspect of unpredictability.

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

No, I haven't. Quite frankly I'll leave that to someone who's running the latest OS X and who'd be willing to install my (or the) port:kf5-kdevelop once it should be possible to build that against Xcode's toolchain.
Of course I could file a generic request to provide the full llvm toolchain containing everything required to build 3rd party llvm utilities and extensions, but I won't be able to test anything that doesn't run on the OS version I'm using.

No specific questions about ad-hoc code-signing, not anymore at least. Thanks for providing enough answers. 

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

I'm concerned about every step that takes OS X away from a regular Unix (underneath a nice and truly integrated desktop) and towards a locked-in OS like iOS. Not that it really matters because the OS is already locked into hardware and it seems every new hardware release makes it less likely I'll be replacing my ageing MBP with a newer one...

R.