You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have searched existing issues and avoided creating duplicates.
I am not filing an enhancement request.
What happened?
I have first installed Zen on 1.9b
I use Little Snitch (firewall application) and had already properly configured rules for Zen, blocking 4 Mozilla telemetry domains and then a free-pass for all HTTP/S traffic from Zen, has been working fine.
1.9.1b is released and Zen silently installs it in the background
Upon closing my running 1.9b instance and shortly after that reopening Zen, up until this point still unaware of the incoming update, I am hit by a Little Snitch connection alert from Zen, which should not happen because I had already configured it with a free-pass.
Little Snitch now has a separate entry for Zen, this should not, and does not, happen with other self-updating apps.
Upon comparison of the entries, the difference is caused by the code signature which has changed.
A clean 1.9b Zen.app was signed by Daniel Garcia (H36NPCN86W):
A clean 1.9.1b Zen.app (by downloading the new .dmg directly) is now signed by Mauro Baladés (9V5K9TP787):
So far, this is actually fine, sometimes developers need to change their signature, it would still cause the Little Snitch inconvenience and it should have probably been announced as a change/included in the release notes, but it's not abnormal behavior. Were a user to manually update from 1.9b to 1.9.1b, it works fine.
The problem here is when the auto-updater comes in. When a 1.9b instance auto-updates itself to 1.9.1b, it does not fully replace every file inside the app bundle.
This leads to a mix of signatures, which now conflict and cause signature verification to fail, as you can see from the resulting app bundle of my auto-updated 1.9b -> 1.9.1b instance:
This makes macOS upset and shouldn't happen.
Solution
The problem now is, the damage is already done and will continue to be done for any current 1.9b macOS users, so for the particular case of 1.9b -> 1.9.1b+ auto-updates there is nothing that can be done to prevent this now.
I am posting this to raise awareness of the issue so others that encounter it can find the solution here, and so that this may be fixed for potential future updates with signature changes by fixing the auto-updater for account for those now.
For those affected: The fix is to delete the broken self-updated /Applications/Zen.app and manually reinstall 1.9.1b or future later version. If you installed through Homebrew you can also just re-run brew install --cask zen-browser.
Reproducible?
I have checked that this issue cannot be reproduced on Mozilla Firefox.
Version
1.9.1b
What platform are you seeing the problem on?
macOS - aarch64
Relevant log output if applicable
The text was updated successfully, but these errors were encountered:
also, security relevant things like this need to be communicated in some way. the code-signature is the only way for users to verify the release has been made by the vendor and not some attacker.
is 1.9.1 a valid release despite the non-standard signature?
Captchas
What happened?
Daniel Garcia (H36NPCN86W)
:Mauro Baladés (9V5K9TP787)
:Solution
The problem now is, the damage is already done and will continue to be done for any current 1.9b macOS users, so for the particular case of 1.9b -> 1.9.1b+ auto-updates there is nothing that can be done to prevent this now.
I am posting this to raise awareness of the issue so others that encounter it can find the solution here, and so that this may be fixed for potential future updates with signature changes by fixing the auto-updater for account for those now.
For those affected: The fix is to delete the broken self-updated
/Applications/Zen.app
and manually reinstall 1.9.1b or future later version. If you installed through Homebrew you can also just re-runbrew install --cask zen-browser
.Reproducible?
Version
1.9.1b
What platform are you seeing the problem on?
macOS - aarch64
Relevant log output if applicable
The text was updated successfully, but these errors were encountered: