#51504: codesigning portgroup -------------------------+-------------------------------- Reporter: rjvbertin@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Keywords: | Port: -------------------------+-------------------------------- We had a very short discussion about some kind of support for code- signing, somewhere last week. I have since remembered that KDE PIM applications have a habit of causing `do you want application akonadi_foo_agent to accept incoming connections` unless they're signed even by a self-signed key. I've thus whipped up a very rudimentary PortGroup to provide a `codesign` procedure that is a priori to be called during the `post-activate`. The principle is simple: if `${prefix}/etc/macports/codesign-identify.tcl` exists, the procedure attempts to read a variable `identity` from it which must be a non-empty string . If that succeeds, all files passed in the argument(s) to `codesign` are signed, one by one. I don't really have any suggestions how to handle errors during this operation, so I'm just ignoring them. There is of course a rather evident source of error here: signing identities correspond to a certificate that must be stored in a keychain on the calling user's keychain list. It turns out that even with `macportsuser` set to myself (I know, bad) my regular signing identity isn't found, not even when I invoke the procedure from a Portfile "root" (to test with `port info foo`). I don't understand why that is (it is found when I `sudo codesign -s identity ...`) . It might thus be necessary to store the key in the/a system keychain and instruct `codesign` to use that chain? Other than that the procedure works, using `set identity "-"` to sign with an ad-hoc key. -- Ticket URL: <https://trac.macports.org/ticket/51504> MacPorts <https://www.macports.org/> Ports system for OS X