> On Sep 10, 2016, at 05:09, Rainer Müller <[email protected]> wrote: > > On 2016-09-09 22:59, Jeremy Huddleston Sequoia wrote: >> >>> On Sep 9, 2016, at 04:38, René J.V. Bertin <[email protected]> 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. > > No? > > $ otool -L /opt/local/bin/ggdb > /opt/local/bin/ggdb: > /opt/local/lib/libintl.8.dylib (compatibility version 10.0.0, current > version 10.5.0) > /opt/local/lib/libncurses.6.dylib (compatibility version 6.0.0, current > version 6.0.0) > /opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current > version 1.2.8) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current > version 1213.0.0) > /opt/local/lib/libiconv.2.dylib (compatibility version 8.0.0, current > version 8.1.0) > /opt/local/lib/libexpat.1.dylib (compatibility version 8.0.0, current > version 8.2.0) > > > On OS X 10.10 Yosemite, signing only the ggdb binary was certainly > enough. I cannot reproduce this on macOS 10.12 Sierra, so > the requirements might have changed.
10.10 predates SIP and related hardening around ptrace(). That version is so far in my rearview that I forget the details there, sorry. I'll have to dig into it, but it certainly seems wrong to me that a process could become privileged if it linked against unsigned libraries. > Also on Sierra it looks like I can no longer give codesign a > certificate, which is not known and trusted to the system. > > Both of these facts would destroy my idea of signing with a self-signed > certificate, but requiring the user to add trust on the certificate. > > Rainer > _______________________________________________ > macports-dev mailing list > [email protected] > https://lists.macosforge.org/mailman/listinfo/macports-dev
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
