We have been really busy around here with the new iPhone/iPod touch version of 1Password. Overall things have gone as smooth as one could expect for a new product on a new device. Unfortunately, we have found some serious issues that need the be addressed.
The most serious issue involves the OS X Keychain Service and how it detects if an application is allowed to access an item in a keychain.
How Keychain Permissions Work
If an application tries to access an item in the keychain that it is not explicitly allowed to access, OS X will present a dialogue to the user asking for confirmation:
Normally you will never see this confirmation dialog as we explicitly add 1Password and all the browsers to the Access Control List (ACL) of each item when we create it. If any application is updated after the ACL is created, the OS X Keychain will detect this and prompt for confirmation that the updated application is still trusted:
Clicking Allow will cause the keychain to update every item in the keychain for this "new" application. Technically, the items in the keychain are not modified directly, but rather the Code Equivalence Database will be updated to say the updated application is "equivalent" to the original application, thereby making the existing keychain item ACLs valid.
Leopard + Firewall + iPhone Sync Issues
Since the iPhone/iPod touch version of 1Password was released, there have been several reports that after upgrading 1Password users were prompted to allow access for every item in the keychain.
At first we could not figure out why this was happening as the ACL of each item should not be affected by upgrades. Clicking Allow once should have been all that was required. After some digging we found the problem was related to how Leopard handles WiFi syncing with the iPhone/iPod touch application when firewalls are enabled.
On Leopard systems that have the firewall enabled, WiFi syncing will cause Leopard to implicitly codesign the 1Password application. This happens because the 1Password application found on our site is not signed (more on this later).
Once implicitly signed, the keychain treats 1Password as a completely new application and proceeds to prompt for confirmation on every single item in the keychain. Worst of all, after any update, Leopard will re-codesign 1Password, causing the cycle to repeat itself.
Planned Solution
We have discussed solutions for this at length, and think we found the best solution given the circumstances.
One plan was to sign the 1Password application. We have been dragging our feet on this as it would require every single user to click Always Allow on every item in their keychain. We almost decided to do this anyway, but elected not to as we are concerned there could be unforeseen consequences. We could end up with a new set of problems, and still not have an acceptable work around available.
Another plan was to release two versions: one signed and one not. This would be a maintenance nightmare and is easily broken if a signed version is accidently upgraded to an unsigned one. Because of this we really do not want to go this route either.
What we decided to do was to finish the new Agile Keychain format which has been under development for the past year. The Agile Keychain will be an alternative to the OS X Keychain and will provide several new features in the long term, including better synchronization with MobileMe, the ability to add file attachments to items in 1Password, and several other amazing things we have planned.
Because of the urgency of this Permissions Issue, we decided we will release the Agile Keychain format before all these new features are completed so that those experiencing this problem can use the Agile Keychain as a workaround. This new keychain format is undergoing internal testing at the moment and should be available in a Beta release soon.
Potential Workarounds
For those awaiting this fix, you have a few options, albeit each one is far from perfect:
- Disable all automatic updates. Only upgrade when we post the "go ahead" in a post here or from the Agile Newsletter.
- Disable Betas in the automatic update. The plan is to not release another "official" version until this is resolved.
- Turn off your Firewall. We know this sucks and are not advising you do this, but wanted to list all available options.
- (Unconfirmed) Stop using the iPhone sync. AFAIK the implicit code signing only happens during the sync, so if you skip the sync you should be in the clear.
- If you must have the updates and must have the firewall, you will need to bite the bullet and click Always Allow on every item after every update.
- Downgrade to Tiger. I'M JOKING!! :)
Again, we know that none of these are acceptable long term solutions but hopefully at least one of them should be able to keep you going until we have the final work around available.
We recommend workaround #2: turn off Betas in the automatic updates until we resolve this issue.
Conclusion
The plan is to not release another "official" version until this is resolved.
We will, however, be having many Beta releases over the coming weeks as we start rolling out the new keychain format. Therefore, if you have this issue, be sure to double check your Update Preferences and disable Beta updates.
Sorry for the trouble, folks! We will get this resolved as soon as we can.
