On Mar 21, 2022, at 23:02, Joshua Root wrote:

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

> Assurance that binaries have not changed after being installed would be nice 
> I suppose.

Ok, those could be useful qualities. A binary could change because of malicious 
actions or just because the disk it's stored on is failing. Preventing the 
binary from being used in either of those cases is probably good.

If we did ad-hoc codesiging in MacPorts then we would not need to use any 
Developer ID and we would have the same safeguards for Intel and PowerPC 
systems that we already have automatically on Apple Silicon systems. Would that 
be of any benefit?

"man codesign" says "Significant restrictions apply to the use of ad-hoc signed 
code; consult documentation before using this." I don't know which 
documentation it means. I found this page discussing the restrictions:

https://apple.stackexchange.com/questions/288291/what-are-the-restrictions-of-ad-hoc-code-signing

Most of the answer provided there is incomprehensible to me except for the 
conclusion that an ad-hoc signed binary is "basically [...] the same as a 
non-signed binary". Are we sure that ad-hoc codesigning is enough to pacify 
GateKeeper? Since all binaries must be codesigned on Apple Silicon, does that 
mean that GateKeeper never has anything to complain about on Apple Silicon 
systems?

The code signature appears to be stored within the file being codesigned. (I 
ad-hoc codesigned an unsigned binary produced by MacPorts and its size 
increased by 25K.) What happens if file is completely replaced? I assume the 
previous file's code signature does nothing to prevent that. We have at times 
had the situation where a user runs a third-party installer that installs older 
files on top of the files MacPorts installed, causing various problems. But I'm 
guessing codesigning wouldn't do anything to prevent that situation, in which 
case codesigning doesn't really prevent modification of the file in the way 
that one might expect.


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

Yup, and thanks for raising some of those questions in your response!

Reply via email to