lldb ...

[Rainer Müller]

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 covered in TN 2206.

>> However, another thing I did not think of before, what should be used as
>> expiry date on the certificate? According to the TN, OS X does not care
>> about the expiration date for both verification or signing for "simple
>> applications", whatever that means.
> 
> So, why would you force an expiration date on users? Say they install lldb-3.x and stay at that version for whatever reason. That port isn't going to change anymore at some point, so why force people to go through the hassle even of de/re-activating. That seems rather unheard of, and a first step on planned and forced obsolescence (where software stops working after a given date).

I am not forcing it on them. x509 certificates have an expiry date. That
is just a fact.

> I still think the easiest would be if that certificate and the corresponding keys would be stored in a keychain belonging to the MacPorts operator, not the macports. That's going to make maintenance and support so much easier. However, there's one surprising thing one should be aware of:
> 
> {{{
> %> ll /opt/local/bin/411toppm
> 288233 0 -rwxrwxr-x 1 root wheel 33904 Dec  7  2014 /opt/local/bin/411toppm*
> %> id | fgrep wheel
> Exit 1
> %> codesign -s lldb_codesign -vvv /opt/local/bin/411toppm
> /opt/local/bin/411toppm: signed Mach-O universal (i386 x86_64) [411toppm]
> %> ll /opt/local/bin/411toppm
> 57101195 52 -rwxrwxr-x 1 bertin admin 51488 Sep  5 12:41 /opt/local/bin/411toppm*
> }}}
> 
> IOW: I'm not a member of the wheel group, so I do not normally have write access to 411toppm even if I own its parent directory. Yet I could run codesign on it without having to authenticate. It's probably better that the root ownership wasn't preserved even if that shouldn't make a difference for execs that aren't SETUID or SETGUID, but still. FWIW, running `sudo codesign` doesn't alter the file's ownership:

That's expected behavior. The permissions on the file itself are not
relevant for unlinking, only permissions of the directory matter. Your
user has write access to /opt/local/bin or this would have failed with
an error message.

But yes, that means we have to take care of preserving the permissions
when codesigning.

> {{{
> %> sudo codesign -s lldb_codesign -vvv -f /opt/local/bin/asciitopgm
> /opt/local/bin/asciitopgm: replacing existing signature
> /opt/local/bin/asciitopgm: signed Mach-O universal (i386 x86_64) [asciitopgm]
> %> ll /opt/local/bin/asciitopgm
> 57101222 52 -rwxrwxr-x 1 bertin admin 51456 Sep  5 12:53 /opt/local/bin/asciitopgm*
> }}}
> 
> So the current solution in my code-signing PortGroup isn't good, probably; only the HOME directory should be set to point to where the keychain holding the signing identify is to be found.

Why set HOME when you can use --keychain?

Rainer