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