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.
_______________________________________________
macports-dev mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-dev
