> On Sep 19, 2016, at 04:18, René J.V. Bertin wrote:
>
> On Monday September 19 2016 03:46:32 Jeremy Huddleston Sequoia wrote:
>
>>> TMPDIR points into /var/folders.
>>
>> Yes, and it looks like those do get cleared out on boot.
>>
>> Note, however, that this particular case relates to the ca
On Monday September 19 2016 03:46:32 Jeremy Huddleston Sequoia wrote:
> > TMPDIR points into /var/folders.
>
> Yes, and it looks like those do get cleared out on boot.
>
> Note, however, that this particular case relates to the cache dir, not tmp
> (C, not T).
Oh, right, but there are icon cac
> On Sep 19, 2016, at 03:31, René J.V. Bertin wrote:
>
> On Monday September 19 2016 03:02:38 Jeremy Sequoia wrote:
>
>> /var/tmp definitely isn't cleared though.
>
> TMPDIR points into /var/folders.
Yes, and it looks like those do get cleared out on boot.
Note, however, that this particular
On Monday September 19 2016 03:02:38 Jeremy Sequoia wrote:
> /var/tmp definitely isn't cleared though.
TMPDIR points into /var/folders.
Here's an example entry from macports's icon cache:
%> sudo afsctool -vvv
/var/folders/11/_bf842l54ngf42g66hkzslmwgp/C/com.apple.IconServices/FFB06CC518D1
Sent from my iPhone...
> On Sep 19, 2016, at 02:52, René J.V. Bertin wrote:
>
> On Monday September 19 2016 02:08:12 Jeremy Huddleston Sequoia wrote:
>
>>> The icon cache sits in the user's $TMPDIR, and AFAIK that directory is
>>> emptied at boot.
>>
>> No. /tmp is emptied at boot, not /va
On Monday September 19 2016 02:08:12 Jeremy Huddleston Sequoia wrote:
>> The icon cache sits in the user's $TMPDIR, and AFAIK that directory is
>> emptied at boot.
>
>No. /tmp is emptied at boot, not /var/tmp and not /var/folders.
Did that change after 10.9? I keep a Finder window open on $TMPD
> On Sep 19, 2016, at 00:34, René J.V. Bertin wrote:
>
> On Sunday September 18 2016 19:23:01 Jeremy Huddleston Sequoia wrote:
>
Yes, of course it's possible. Don't. There's nothing special about the
UID in this case that has anything to do with what you're seeing.
>>>
>>> So what
On Sunday September 18 2016 19:23:01 Jeremy Huddleston Sequoia wrote:
>>> Yes, of course it's possible. Don't. There's nothing special about the
>>> UID in this case that has anything to do with what you're seeing.
>>
>> So what does make the difference?
>
>What is "the difference" that you wa
> On Sep 18, 2016, at 18:10, René J.V. Bertin wrote:
>
> On Sunday September 18 2016 17:24:55 Jeremy Huddleston Sequoia wrote:
>
>> That all looks as expected for someone on OS X 10.9. launchd2 in 10.10+ did
>> away with per-user launchd. All domains are managed by the same process.
>
> Sti
On Sunday September 18 2016 17:24:55 Jeremy Huddleston Sequoia wrote:
> That all looks as expected for someone on OS X 10.9. launchd2 in 10.10+ did
> away with per-user launchd. All domains are managed by the same process.
Still, why would a background user without even an interactive shell be
On Sun, Sep 18, 2016 at 8:41 PM, Brandon Allbery
wrote:
> Some port somewhere likely builds the icon cache while building or
> "installing" (destrooting) since it "knows" that it would only be built by
> the person intending to use it and that nobody uses packaging on OS X. :/
...or maybe some
On Sun, Sep 18, 2016 at 8:24 PM, Jeremy Huddleston Sequoia <
jerem...@apple.com> wrote:
> > Anyway, I don't see any valid reason why the macports user would have a
> fullblown icon cache. In my case each cache directory eats up about 900Mb.
> Some may find that insignificant; I still consider it a
> On Sep 18, 2016, at 04:25, René J.V. Bertin wrote:
>
> Hi,
>
> This isn't actually about codesigning but something that may have come up
> because of my testing in that domain.
>
> I got a low disk space warning (for an unrelated reason) and hunting down the
> space eater I noticed this:
>
Hi,
This isn't actually about codesigning but something that may have come up
because of my testing in that domain.
I got a low disk space warning (for an unrelated reason) and hunting down the
space eater I noticed this:
{{{
%> id macports
uid=502(macports) gid=503(macports)
groups=503(macpo
On 2016-09-16 10:18, Jeremy Huddleston Sequoia wrote:
> Yeah, this contradicts what I'm seeing as expected. Given that
> you've signed /opt/local/bin/ggdb with an entitlement, it should be
> CS_RESTRICT which should imply CS_HARD. The lack of a code signature
> would trigger !CS_VALID which would
> On Sep 10, 2016, at 17:56, Jeremy Sequoia wrote:
>
> On Sep 10, 2016, at 16:51, Rainer Müller wrote:
>
>> I got gdb to work now on Sierra now. In fact I did not even have to sign
>> any of the libraries it links to.
>>
>>
>> $ otool -L /opt/local/bin/ggdb |awk 'NR>1 {print $1}' \
>>|gr
> On Sep 13, 2016, at 2:06 AM, René J.V. Bertin wrote:
>
> On Tuesday September 13 2016 01:39:41 Jeremy Huddleston Sequoia wrote:
>
>> That's just the nature of things.
>
> Yeah, life sucks and all that ...
>
>> Do you have 3rd party menu extras? IIRC, you're on 10.9, and 3rd party menu
>>
On Tuesday September 13 2016 01:39:41 Jeremy Huddleston Sequoia wrote:
> That's just the nature of things.
Yeah, life sucks and all that ...
>Do you have 3rd party menu extras? IIRC, you're on 10.9, and 3rd party menu
>extras run in SystemUIServer. I frequently got SystemUIServer crashes than
> On Sep 13, 2016, at 00:14, René J.V. Bertin wrote:
>
> On Monday September 12 2016 21:51:55 Jeremy Sequoia wrote:
>
> I can confirm that there *is* feedback on radars, though I do have to admit
> that in my case it is usually one of 3 forms:
> - works as intended
> - please check if the issu
On Monday September 12 2016 21:51:55 Jeremy Sequoia wrote:
I can confirm that there *is* feedback on radars, though I do have to admit
that in my case it is usually one of 3 forms:
- works as intended
- please check if the issue still exists in the latest release (typically
months later)
- pleas
Sent from my iPhone...
> On Sep 12, 2016, at 21:44, Brandon Allbery wrote:
>
>
> On Tue, Sep 13, 2016 at 12:24 AM, Jeremy Sequoia wrote:
>>> I just noticed this. Received wisdom "out here" is that ``nobody is
>>> listening and nobody ever responds, so don't bother filing radars.''
>>
>> Th
On Tue, Sep 13, 2016 at 12:24 AM, Jeremy Sequoia wrote:
> I just noticed this. Received wisdom "out here" is that ``nobody is
> listening and nobody ever responds, so don't bother filing radars.''
>
>
> That is very very very false.
>
That may be, but I got paraphrases of that response from a nu
Sent from my iPhone...
> On Sep 12, 2016, at 20:57, Brandon Allbery wrote:
>
>> On Sat, Sep 10, 2016 at 12:14 PM, Jeremy Huddleston Sequoia
>> wrote:
>> Please file radars and point me to them, so I can make sure they get routed
>> to the right place (likely as dupes, but dupes are very use
On Sat, Sep 10, 2016 at 12:14 PM, Jeremy Huddleston Sequoia <
jerem...@apple.com> wrote:
> Please file radars and point me to them, so I can make sure they get
> routed to the right place (likely as dupes, but dupes are very useful
> "votes" for bugs).
I just noticed this. Received wisdom "out h
Can you please file a radar and toss me the number. This might be somehow
falling through the cracks with the new logging changes and didn't get noticed
yet. Hopefully we can get it fixed in an update soon if there isn't a
workaround.
Sent from my iPhone...
> On Sep 11, 2016, at 05:07, Raine
On 2016-09-11 02:56, Jeremy Sequoia wrote:
>> By the way, as I did lots of trial and error, is there a way to get
>> debug output (from taskgated?) to see why task_for_pid() was denied?
>
> Is it not being logged? You should see it in the system log
> (Console.app, log collect, etc).
That is whe
On Sunday September 11 2016 00:24:17 Jeremy Huddleston Sequoia wrote:
>Well, you can certainly upgrade the storage after purchase if you want (cf
>https://eshop.macsales.com/shop/ssd/owc/macbook-pro-retina-display/2013-2014-2015)
Sure ... and that's not even 10x more expensive than a 1TB HDD, an
On Sunday September 11 2016 00:24:17 Jeremy Huddleston Sequoia wrote:
>The secure thing to do is not escalate until we need to, prompt, do our thing,
>then throw away the privs when done. The problem with that is that we'd ask
>for credentials 2-3 times during the install and only when we need
> On Sep 10, 2016, at 09:44, René J.V. Bertin wrote:
>
> On Saturday September 10 2016 08:45:38 Jeremy Huddleston Sequoia wrote:
>
>> Yes, for most cases we would probably not need root access at activation
>> time, but for those cases you just listed, we would. We could do a pass
>> over th
Sent from my iPhone...
> On Sep 10, 2016, at 16:51, Rainer Müller wrote:
>
> On 2016-09-10 17:52, Jeremy Huddleston Sequoia wrote:
>>> 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 ha
On 2016-09-10 17:52, Jeremy Huddleston Sequoia wrote:
>> 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
> ve
> On Sep 10, 2016, at 09:38, Clemens Lang wrote:
>
> Hi,
>
> On Sat, Sep 10, 2016 at 09:14:16AM -0700, Jeremy Huddleston Sequoia wrote:
>> No, the DYLD_INSERT_LIBRARIES approach is the right one here.
>> Interested users would need to disable SIP.
>
> "Interested users" would be everybody who
On Saturday September 10 2016 18:38:36 Clemens Lang wrote:
> I don't see why the kernel, dyld, or whoever strips the flags could not
> just behave like running a copy of the binary at hand when it sees a
> DYLD variable, i.e. do the workaround we're doing manually at the
> moment.
Then what would
On Saturday September 10 2016 08:45:38 Jeremy Huddleston Sequoia wrote:
> Yes, for most cases we would probably not need root access at activation
> time, but for those cases you just listed, we would. We could do a pass over
> the bom to determine if root access is needed or not. The UI for h
Hi,
On Sat, Sep 10, 2016 at 09:14:16AM -0700, Jeremy Huddleston Sequoia wrote:
> No, the DYLD_INSERT_LIBRARIES approach is the right one here.
> Interested users would need to disable SIP.
"Interested users" would be everybody who uses MacPorts. I'd vote
against telling all our users to disable S
> On Sep 10, 2016, at 05:22, Clemens Lang wrote:
>
> Hi,
>
> On Fri, Sep 09, 2016 at 01:59:50PM -0700, Jeremy Huddleston Sequoia wrote:
>>> 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 r
> On Sep 10, 2016, at 05:09, Rainer Müller wrote:
>
> On 2016-09-09 22:59, Jeremy Huddleston Sequoia wrote:
>>
>>> On Sep 9, 2016, at 04:38, René J.V. Bertin wrote:
>>>
>>> On Friday September 09 2016 12:10:05 Rainer Müller wrote:
>>>
>>>
> different than your case either. Either way,
> On Sep 10, 2016, at 02:15, René J.V. Bertin wrote:
>
> On Friday September 09 2016 13:59:50 Jeremy Huddleston Sequoia wrote:
>
>>> 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
>>> reserv
On Saturday September 10 2016 15:56:54 Clemens Lang wrote:
> cat and rm deal with files, consequently trace mode needs its code to be
> injected into them (as would fakeroot). Not copying them would mean
> their unmodified copies run without the "sandbox" enabled, since
> DYLD_INSERT_LIBRARIES wou
Hi,
On Sat, Sep 10, 2016 at 03:45:25PM +0200, René J.V. Bertin wrote:
> But I see quite a few items on there that are unlikely to call other
> applications. If this is only about preserving DYLD_LIBRARY_PRELOAD,
> why do you need to treat utilities like cat or rm?
cat and rm deal with files, cons
On Saturday September 10 2016 15:15:54 Clemens Lang wrote:
Hi,
>There are no other solutions that I'm aware of on OS X. We discussed
Sorry, I meant for Apple to develop something like fakeroot from the ground up.
>FYI, I'm including a list of the files that are currently affected on my
>system
Hi,
On Sat, Sep 10, 2016 at 02:42:36PM +0200, René J.V. Bertin wrote:
> >Except that fakeroot uses library preloading, a technique that's more
> >or less dead on modern OS X thanks to Apple's changes related to SIP:
> >DYLD_INSERT_LIBRARIES is stripped for all binaries with the SIP bit
> >set.
>
On Saturday September 10 2016 14:22:16 Clemens Lang wrote:
Hi,
>Except that fakeroot uses library preloading, a technique that's more or
>less dead on modern OS X thanks to Apple's changes related to SIP:
>DYLD_INSERT_LIBRARIES is stripped for all binaries with the SIP bit set.
Fakeroot uses lib
Hi,
On Fri, Sep 09, 2016 at 01:59:50PM -0700, Jeremy Huddleston Sequoia wrote:
> > 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 t
On 2016-09-09 22:59, Jeremy Huddleston Sequoia wrote:
>
>> On Sep 9, 2016, at 04:38, René J.V. Bertin 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 v
On 2016-09-10 00:23, Jeremy Sequoia wrote:
>>> 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 dest
On Friday September 09 2016 13:59:50 Jeremy Huddleston Sequoia wrote:
>> 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 se
Sent from my iPhone...
On Sep 9, 2016, at 14:46, Lawrence Velázquez wrote:
>> On Sep 9, 2016, at 4:59 PM, Jeremy Huddleston Sequoia
>> wrote:
>>
>>> On Sep 9, 2016, at 04:38, René J.V. Bertin wrote:
>>>
>>> As an aside, I'd be in favour of setting up MacPorts such that ${prefix} is
>>> o
> On Sep 9, 2016, at 4:59 PM, Jeremy Huddleston Sequoia
> wrote:
>
>> On Sep 9, 2016, at 04:38, René J.V. Bertin wrote:
>>
>> 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
> On Sep 9, 2016, at 04:38, René J.V. Bertin 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.
On Friday September 09 2016 12:12:34 Lawrence Velázquez wrote:
> I don't know why that would happen, unless drastic changes are released
> (which does happen sometimes). It's not inherent to base; I update from trunk
> all the time with no problems.
Yeah, well. I like stability in things that f
> On Sep 9, 2016, at 10:28 AM, René J.V. Bertin wrote:
>
>> On Friday September 09 2016 09:27:31 Lawrence Velázquez wrote:
>>
>> If our release process is too cumbersome and infrequent, we should change
>> that. I don't see reason to divide base's functionality more than it already
>> is.
>
>
On Friday September 09 2016 09:27:31 Lawrence Velázquez wrote:
>> I know there's been talk about making at least parts of "base" updateable as
>> a port; this could be an easy alternative.
>
>If our release process is too cumbersome and infrequent, we should change
>that. I don't see reason to d
> On Sep 9, 2016, at 6:00 AM, Rainer Müller wrote:
>
>> On 2016-09-09 03:38, Jeremy Sequoia wrote:
>> You are describing a system to automatically create and automatically
>> trust a code signing certificate that contains a private key in a file
>> on disk that is not encrypted with a passphrase
> On Sep 9, 2016, at 7:38 AM, René J.V. Bertin wrote:
>
> 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
> after
> On Sep 9, 2016, at 4:17 AM, René J.V. Bertin wrote:
>
> 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.
As Josh has said previously, t
On Friday September 09 2016 14:25:53 Rainer Müller wrote:
>I think you misunderstand this sentence. codesign will search in this
>keychain for the certificate itself, but the keychain will not be used
>to find other certificates in the certificate chain (all intermediates
>up to a root CA). With a
On 2016-09-09 13:38, René J.V. Bertin wrote:
>> 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
> do
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
On 2016-09-09 10:17, René J.V. Bertin wrote:
> 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.
>
> The fact that codesign only accepts keychain file arguments
On 2016-09-09 11:26, Jeremy Huddleston Sequoia wrote:
> Yes. The fact that we aren't doing that for the binary packages that
> we ship is quite embarrassing. We should solve this problem more
> generally such that we can ship properly signed binaries for every
> port. Users installing the binary
On 2016-09-09 03:38, Jeremy Sequoia wrote:
> You are describing a system to automatically create and automatically
> trust a code signing certificate that contains a private key in a file
> on disk that is not encrypted with a passphrase and only depends on file
> system ACLs to protect it.
>
> Th
One more thought: if indeed we're going to try to codesign everything at some
point, in the post-destroot, we'll probably want to ignore errors during that
particular step, i.e. catch the codesign return code and simply raise a warning
instead of bailing out. Ports that *require* signing (and on
> On Sep 9, 2016, at 01:17, René J.V. Bertin wrote:
>
> 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 acce
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 to
Sent from my iPhone...
> On Sep 8, 2016, at 17:32, Rainer Müller wrote:
>
>> On 2016-09-08 22:03, Jeremy Huddleston Sequoia wrote:
>>
>>> On Sep 2, 2016, at 05:19, Rainer Müller wrote:
>>>
>>> In my opinion, the actual implementation of codesigning should be in base:
>>>
>>> 1) Create a se
Sent from my iPhone...
> On Sep 8, 2016, at 17:30, Rainer Müller wrote:
>
> On 2016-09-08 22:09, Jeremy Huddleston Sequoia wrote:
>>> On Sep 5, 2016, at 03:49, Rainer Müller wrote:
>>> My intention here is to describe a way how the code-signing can be
>>> automated. We do not gain much by pro
On 2016-09-08 22:03, Jeremy Huddleston Sequoia wrote:
>
>> On Sep 2, 2016, at 05:19, Rainer Müller wrote:
>>
>> In my opinion, the actual implementation of codesigning should be in base:
>>
>> 1) Create a self-signed certificate/identity for code-signing
>> 2) Import certificate/identity into key
On 2016-09-08 22:09, Jeremy Huddleston Sequoia wrote:
>> On Sep 5, 2016, at 03:49, Rainer Müller wrote:
>> My intention here is to describe a way how the code-signing can be
>> automated. We do not gain much by providing a solution that still
>> requires manual interaction by the user. Generating
> On Sep 8, 2016, at 15:13, René J.V. Bertin wrote:
>
> On Thursday September 08 2016 13:09:33 Jeremy Huddleston Sequoia wrote:
>>> codesign.files ${prefix}/bin/binary1 developer \
>>>${prefix}/bin/binary2 firewall
>>> codesign.identifier org.macports.${name}
>>
>>
>
On Thursday September 08 2016 13:09:33 Jeremy Huddleston Sequoia wrote:
>> codesign.files ${prefix}/bin/binary1 developer \
>> ${prefix}/bin/binary2 firewall
>> codesign.identifier org.macports.${name}
>
>
>I don't like this approach.
>
>We should solve this type of probl
> On Sep 5, 2016, at 03:49, Rainer Müller wrote:
>
> On 2016-09-05 00:57, René J.V. Bertin wrote:
>> In a first draft the command accepted a list of binaries to sign, and read
>> the identify from a configuration file. I suppose that corresponds to what
>> you mean with a declarative syntax?
>
> On Sep 2, 2016, at 05:19, Rainer Müller wrote:
>
> On 2016-08-31 23:25, Lawrence Velázquez wrote:
>>> On Aug 31, 2016, at 4:57 PM, René J.V. Bertin wrote:
>>>
>>> I noticed that Apple don't ship an lldb-mi executable (at least they don't
>>> for OS X 10.9).
>>
>> Xcode 7.3 includes it (`x
On Thu, 1 Sep 2016, [ISO-8859-1] René J.V. Bertin wrote:
> On Wednesday August 31 2016 17:29:54 Lawrence Velázquez wrote:
>
> >The gdb port instructs the user to modify a system LaunchDaemon to
> >effectively circumvent taskgated. I frankly think that's an awful idea,
> >and future ports should n
On Monday September 05 2016 16:23:23 Rainer Müller wrote:
> I see no problem in generating certificates automatically. We also add
> users to the system or create launchd configurations without forcing the
> user to do it manually.
Yeah, exactly, I'm not really comfortable with adding users to th
On 2016-09-05 12:56, René J.V. Bertin wrote:
> On Monday September 05 2016 12:21:08 Rainer Müller wrote:
>
> Do the steps in that TN include the trust setting and the magic command in
> lldb's code-signing document?
I was talking about generating self-signed identities/certificates and
that is c
On 2016-09-05 13:29, René J.V. Bertin wrote:
> Reminds me: I'm not really comfortable with the idea that PortFiles
> would be able to create and store certificates. I'd rather see a form
> where they can check for the availability of the identity, and then
> inform the user exactly what command to
On Monday September 05 2016 12:49:22 Rainer Müller wrote:
> In a Portfile you would not be interested in the name of the identity,
> the but trust policy it grants (firewall bypass, task_for_pid, etc.).
That depends, I'd say. Is it even possible to uncouple identifier and trust
policy to the ext
On Monday September 05 2016 12:21:08 Rainer Müller wrote:
Do the steps in that TN include the trust setting and the magic command in
lldb's code-signing document?
> However, another thing I did not think of before, what should be used as
> expiry date on the certificate? According to the TN, OS
On 2016-09-05 00:57, René J.V. Bertin wrote:
> In a first draft the command accepted a list of binaries to sign, and read
> the identify from a configuration file. I suppose that corresponds to what
> you mean with a declarative syntax?
> I then went to a simpler, single-binary interface because
On 2016-09-02 14:19, Rainer Müller wrote:
> For step 4), how to give user 'macports' access to the System.keychain
> without entering a password? As an alternative, how to import the
> identity (both private/public key) into a different keychain with
> unlocked access?
I found the missing informat
On Monday September 05 2016 00:13:04 Rainer Müller wrote:
> >> In my opinion, the actual implementation of codesigning should be in base:
> >>
> >> 1) Create a self-signed certificate/identity for code-signing
> >> 2) Import certificate/identity into keychain
> >> 3) Add it to trust store (`securi
On 2016-09-02 14:45, René J.V. Bertin wrote:
> On Friday September 02 2016 14:19:02 Rainer Müller wrote:
>
>>> https://trac.macports.org/ticket/45251
>>
>> That would equivalent to what gdb recommends for codesigning.
>
> Yes, minus the part related to taskgated. And plus a few extra steps that
On Friday September 02 2016 14:19:02 Rainer Müller wrote:
>> https://trac.macports.org/ticket/45251
>
>That would equivalent to what gdb recommends for codesigning.
Yes, minus the part related to taskgated. And plus a few extra steps that
probably serve to add the certificate to the trust store.
On 2016-08-31 23:25, Lawrence Velázquez wrote:
>> On Aug 31, 2016, at 4:57 PM, René J.V. Bertin wrote:
>>
>> I noticed that Apple don't ship an lldb-mi executable (at least they don't
>> for OS X 10.9).
>
> Xcode 7.3 includes it (`xcrun --run lldb-mi`) but Xcode 4.6.3 does not.
> Someone else
On Wednesday August 31 2016 23:51:46 René J.V. Bertin wrote:
> The lldb build system is apparently less well prepared to set the appropriate
> Python include path; the build just failed because pyconfig.h couldn't be
> found. Or I have something I shouldn't have: a directory
> /opt/local/includ
On Wednesday August 31 2016 17:29:54 Lawrence Velázquez wrote:
>The gdb port instructs the user to modify a system LaunchDaemon to effectively
>circumvent taskgated. I frankly think that's an awful idea, and future ports
>should not follow its example.
They certainly shouldn't if there are othe
On Wednesday August 31 2016 17:25:18 Lawrence Velázquez wrote:
> You opened a ticket about this a while ago. One of Eric's comments hints at
> what a pain it might be to get it working with code signing.
> https://trac.macports.org/ticket/45251
I remembered, and apparently it was (over) 2y ago,
> On Aug 31, 2016, at 5:06 PM, Brandon Allbery wrote:
>
>> On Wed, Aug 31, 2016 at 4:57 PM, René J.V. Bertin
>> wrote:
>>
>> The real problem is going to be with the code-signing. This is done
>> automagically by lldb's Xcode projects so it's not entirely clear which
>> files have to be sign
> On Aug 31, 2016, at 4:57 PM, René J.V. Bertin wrote:
>
> I noticed that Apple don't ship an lldb-mi executable (at least they don't
> for OS X 10.9).
Xcode 7.3 includes it (`xcrun --run lldb-mi`) but Xcode 4.6.3 does not. Someone
else is welcome to bisect on that.
> Has anyone looked at bu
On Wed, Aug 31, 2016 at 4:57 PM, René J.V. Bertin
wrote:
> The real problem is going to be with the code-signing. This is done
> automagically by lldb's Xcode projects so it's not entirely clear which
> files have to be signed ... nor if an "ad-hoc" signing identify ("-") will
> lead to a usable
91 matches
Mail list logo
