On 2022-3-22 12:20 , Ryan Schmidt wrote:
It is not even our policy that contributors must read the NEWS or CHANGELOG 
files to see what changed, though I sometimes do this as it helps me discover 
things like if dependencies need to be changed.

It may not be required by policy, but I would consider reading the release notes to be basic due diligence before updating a port. There are many kinds of incompatible changes that might otherwise easily be missed.

Could MacPorts codesign everything installed by ports? If so, should we? What 
benefits would that bring? How would we do it?

We could ad-hoc codesign everything, which would not improve security at all, but would get GateKeeper to ease up a bit on restrictions on incoming network connections and the like.

Doing actual useful codesigning would require a few things:
1. A Developer ID for the project. I'm happy to sign the installers with my personal Developer ID because I build them myself and I am familiar with the code contained in them. I would not sign arbitrary third party code. 2. A Developer ID for every user who needs to install any ports that are not available as binaries. We obviously can't distribute our secret key to the public, so anything built locally needs to be signed locally, with a locally configured identity. 3. A willingness to endorse every binary we ship by putting our signature on it. 4. A plan for what to do if we inadvertently ship malware and our Developer ID certificate is revoked. AIUI, that would make it impossible to run anything signed with the existing certificate if GateKeeper is enabled. Everything would presumably have to be re-signed and reinstalled.

As you can see, the challenges are significant, and the benefits of just slapping a Developer ID signature on what we already produce are largely questionable. Assurance that binaries have not changed after being installed would be nice I suppose.

Codesigning is a in the end just a mechanism, and there are policy questions that need to be thought through before it can be useful.

- Josh

Reply via email to