I’m in touch with AgileBits on this. They’re validating Chrome’s signature by calling into Security.framework. We’re discussing ways to do this validation that don’t assume invalidity because the running Chrome and on-disk Chrome no longer match. My thinking is that the dynamic and static checks can both be done, but rather than checking strict equivalence of their signatures, requirements (such as their designated requirements) can be cross-checked.

Any update here? I keep getting bitten by this. 

Greg, are you free enough to help me out with this?

My main priority right now is deploying component updates for Chrome OS, but I am happy to help out when I have free cycles. What do we need to do, send AgileBits some sample code showing them how to cross check the requirements? Can we see a sample of the code they're using to check Chrome's signature? 

The source of the problem is this check in SecCode::checkValidity in the open source Security.framework:

	// check that static and dynamic views are consistent
	if (this->cdHash() && !CFEqual(this->cdHash(), myDisk->cdHash()))
		MacOSError::throwMe(errSecCSStaticCodeChanged);

Once Chrome is updated, the CD Hash of the code in memory won't match the CD hash of the binary located at the same path on disk. This is because rather than checking the vnode that actually backs the in memory image, the Security.framework uses the path.

Unfortunately, there is no easy flag to avoid to static check and fix this. One possibility is to explicitly check for the errSecCSStaticCodeChanged return value from SecCodeCheckValidity and then fall back to doing the static check yourself but this is risky for two reasons:

1) It relies on internal knowledge of how the code works today
2) This error (errSecCSStaticCodeChanged) already causes the ::checkValidity function to skip the requirements checks, since it fails as soon as something goes wrong.

I also considered if we could solve this problem uses the csops() syscall and a mix of checking CS_OPS_STATUS for CS_VALID, plus CS_OPS_CDHASH and CS_OPS_IDENTITY, but that is also dicey because the kernel decides validity on a page-in basis, and it doesn't understand requirements at all.

Has anyone filed a Radar about this bug in SecCode::checkValidity? We would love to file a duplicate if possible as this is one of the most significant stumbling blocks to users of 1Password and Chrome.

I suspect Apple's response would be that we should change what we're doing rather than believing it's a bug in macOS?

Right because of how code signing on macOS is implemented, I don't think Apple can fix this in any reasonable window.

We have a versioned directory for the framework. Could this be solved with a versioned executable in the MacOS directory (and changing the Info.plist to point at the current one)?

I'm also wondering if this could help with  issue 777863 . Some very quick tests suggest yes.

Update: slightly longer tests suggest no. Haven't tested this w/ 1Password.

I have had a very hard time proving this to myself, but I strongly suspect that when Chrome is in this state, it's 1password that complains loudly, but other things break as well:

- desktop notifications
- copy and paste
- AppleEvents...?  (The actual symptom is that ScriptingBridge events seem to silently fail)

In general I frequently encounter users who have Chrome on macOS running in a noticeably degraded state where some inter-process communication feature is broken; a standard diagnostic tip is to see if an update is pending.  No other app seems to self-update this way.  Would it be possible to just postpone the on-disk update until process restart?

FYI: This should be resolved by the work on issue 496298.