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. _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev