Getting started with 1Password for your growing team, or refining your setup? Our Secured Success quickstart guide is for you.
Forum Discussion
Former Member
4 years agoAutofill No Longer Working Xcode Developer or TestFlight Signed Builds?
I upgraded to 8.7.1 this morning and noticed that Autofill no longer works on builds I am testing via Xcode or build released in Test Flight. Builds that are released using DeveloperID signing or rel...
ag_Christian
1Password Team
4 years agoThanks for that info, @jjohnston. That helped me have more context looking around this area of the code.
For a bit of background context, this is the codesigning requirement that 1Password for Mac is trying to enforce on your app:
anchor apple generic and (
certificate leaf[field.1.2.840.113635.100.6.1.9] or (
certificate 1[field.1.2.840.113635.100.6.2.6] and certificate leaf[field.1.2.840.113635.100.6.1.13]
)
) and (certificate leaf[subject.OU] = "<YourTeamIDHere>" or certificate leaf[field.1.2.840.113635.100.6.1.9] exists)
Note that codesign
supports evaluating arbitrary requirements on binaries, so you can confirm the problem locally if desired:
codesign -vvv -R /path/to/file.requirements <path to binary>
There's a lot of IDs in the requirement string, but the important ones for your use case is this subset:
certificate 1[field.1.2.840.113635.100.6.2.6] and certificate leaf[field.1.2.840.113635.100.6.1.13]
These enforce that the intermediate certificate is the currently valid Developer ID Certification Authority
. The second one enforces that it is a "developer non-MAS distribution certificate, which looks like this:
Based off the output from codesign
, neither of these match since Apple has a dedicated PKI subset for TestFlight. The team identifier matches fine, but the rest causes the evaluation to fail, and therefore Universal Autofill to bail out when trying to fill into your application.
I will reach out internally and see what others think about this issue, and if there would be any problems to the obvious answer of allowing the TestFlight CA chain as well. Thank you again for the information here.
Regarding the XCode issues, the reason seems to be the same as above for the most part. XCode-signed applications also come from the Apple Worldwide Developer Relations Certification Authority
CA and then a personal certificate issued to your Apple ID. These ones may be tricky to support, if at all, as it would allow anyone with an Apple developer account to sign an app pretending to be another in a way that Universal Autofill would accept.