lldb ...

[René J.V. Bertin]

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 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 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:

{{{
%> 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.

R.

PS: the curious and observative will have noticed that signing changes the file's inode. I'm guessing that means it'll break hard links.