Keychain access prompt on app upgrade

Question

Created Mar ’18

Replies 4

Boosts 0

Participants 3

I have an app that adds some items to the keychain. I've noticed recently that when upgrading the app, the system pops up the "allow access to this keychain item" dialog when it attempts to read a keychain item that was added by the previous version. This app is codesigned and passes all codesign diagnostics. Did something change recently that causes this permission request to pop up even though the both versions of the app are signed with the exact same certificate.

I will state that the app is not signed with a Developer ID Application certificate but with a valid code signing certificate from a non-Apple CA. Is there some new requirement that a Developer ID Application certificate must be used in order to not see this prompt when an app is upgraded?

I dumped the keychain using "security dump-keychain -a" before and after upgrade and the only difference between the item is that the partition_id entry contains an additional cdhash for the new app. From what I understand cdhash will change when there are major changes in the app, which is likely on upgrade.

What can I do to prevent this dialog from appearing on app upgrade?

Boost

Answer 1

KMT OP

Mar ’18

Why do you want to hide that dialog? Seems routine to allow user interaction during an event on this level.

0

Answer 2

DTS Engineer OP

Apple

Mar ’18

Last I checked the keychain access control check was based on the designated requirement (DR). When the item is created it’s tagged with the DR of the creating app and any future versions of that app must be able to satisfy that requirement. This happens automatically if you use Developer ID (or Mac App Store) signing, but I’ve no idea how well it works when you use a non-Apple CA.

I strongly recommend that you cut over to using Developer ID as soon as possible. Back when code signing was first introduced it was reasonable to use a non-Apple CA but the world, and specifically the threat model, has moved on since then. Developer ID is the only sensible approach these days (well, there’s also Mac App Store, but I presume that’s not of interest to you).

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

0

Answer 3

dustin.norman OP

Mar ’18

Thanks for the reply, Quinn. If I run codesign -dvvv -r- on my app, I can see that a designated requirement is being created for it. It looks like this:

designated => identifier "<my apps bundle id>" and certificate leaf = H"<leaf certificate hash>"

So, there is a designated requirement. I'm not sure why this wouldn't be sufficient. None of these value should change on upgrade.

0

Answer 4

DTS Engineer OP

Apple

Mar ’18

None of these value should change on upgrade.

Yeah, at this point I think we’re running into my obsolete understanding of how keychain access control works. It’s been a while since I looked into this in detail and there have been significant changes since then (like the

partition_id

stuff discussed in this thread).

If you want to dig into this deeper you should open a DTS tech support incident and discuss it with DTS’s keychain specialist. However, I stand by the recommendation from previous post: Switch to using Developer ID.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

0