> On Sep 9, 2016, at 04:38, René J.V. Bertin <rjvber...@gmail.com> wrote: > > 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.
It requires the ggdb executable and all libraries it links against to be
signed. The port is written such that it only links against Apple-provided
executables, so that solves that dependency.
> And lldb requires only the debugserver executable to be signed.
Again, because debugserver uses entitlements, all its dependencies need to be
signed as well.
$ otool -L /opt/local/libexec/llvm-devel/bin/debugserver
/opt/local/libexec/llvm-devel/bin/debugserver:
/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa
(compatibility version 1.0.0, current version 22.0.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version
307.4.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 1238.0.0)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
(compatibility version 150.0.0, current version 1348.1.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
(compatibility version 300.0.0, current version 1349.0.0)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version
228.0.0)
As you can see, all of its dependencies are system libraries, so they're all
valid.
>> 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?
Yes, that is still a requirement.
>
> 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.
YES! We should not be needing to do such things as root. That is 100% true,
and I am in full support of moving away from that and only using root for
activate. We should be able to use fakeroot (https://wiki.debian.org/FakeRoot)
for destdir.
> 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?
I've changed jobs (within Apple) twice since I worked on X11 officially. It's
not part of my job any more. I continue to do very very minimal changes to
XQuartz in my spare time, mainly to get out version bumps and security fixes.
> Currently Apple doesn't have a say in the admission and upgrade of each and
> every port in MacPorts, do they?
No, of course not.
> In a way I'd even hope they cannot force the exclusion of a port (other than
> ones clearly doing unlawful things);
No, or course not.
> signing everything with an official key seems like a way to give them (more)
> leverage to control over the ports tree.
No, it does not. We get a say in what we sign, and the certificate is signed
by Apple indicating that we have a chain of trust back to Apple. That gives us
the ability to revoke the certificate through ADC if our systems become
compromised. If you want to wear a tin foil hat, we are free to use our own
codesignigning certificate, signed by another authority (or none at all), and
establishing it as trusted will just require an extra step for our users.
Doing so will make it harder to revoke, though.
>>>> 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?
It's quite a bit more complicated than that. First off, these settings are on
by default but can be configured through SIP flags, boot args, etc. There are
also many types of restrictions that have different effects.
If a process uses entitlements, issetugid, is a system binary, has library
validation enabled, or has a __RESTRICT/__restrict section, then the process is
provleged and has more restrictions than "normal" processes. I believe (but
could be wrong) that all of those conditions force the process to be both
CS_HARD and CS_KILL. Under CS_HARD, mmap() will fail if the mapped image's
codesignature is invalid (checksum mismatch, untrusted certificate, amfi
invalidation, no codesignature, etc). Under CS_KILL, any process that is
!CS_VALID will be terminated. Such processes are also restricted from using
certain DYLD_ envvars.
Because of the CS_HARD restriction, all libraries that are linked against
require a valid code signature.
> 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.
This is because you likely already launched the executable, so the old
signature for that particular inode was already cached. If you copied
debugserver somewhere else and then copied it back, it would have addressed the
problem for you.
>>> 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.'
Well macOS is still UNIX. We continue to verify that through continual
conformance testing. I don't expect that to ever change.
> 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...
FWIW, I really love my 2015 rMBP. I was a holdout staying on the pre-retina
ones so I could continue to have a DVD drive and a 2.5" drive bay, but I
finally gave that up and am really glad that I did because the newer SSDs are
blazing fast.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
