Autofill 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 released through the App Store (non TestFlight) seem to be OK.
I noted the following release note in 8.7.1 and suspect it to be the culprit: "We now verify the code signature of apps before we allow filling using Universal Autofill."
This is a bit frustrating as a developer that wants to use 1Password during testing (and, furthermore, ensure 1Password works with our app). It seems like, in particular, TestFlight builds should at least be allowed.
1Password Version: 8.7.1 Extension Version: N/A OS Version: macOS 12.4
It looks like the problem here is that its just an "adhoc" code signature with no trust chained back to Apple. Ad-hoc signatures have no cryptographic proof to back up their validity and generally don't support as much as normal signatures.
I'm not sure there's anything else to do right now about this, so you have my apologies for the inconvenience this is causing. We will consider this use case and see if there's a good way to support it without compromising on the security of Universal Autofill in other cases, but I can't make any promises.
Would you mind running the following command and sharing the output on the app bundle you created with "Unite":
codesign -dvvv /path/to/bundle.app
Universal Autofill currently requires a valid code signature on all apps that it fills into. If codesign tells you that the application bundle is not signed at all, that is most likely the reason why it stopped working.
That said, I'm not sure who you're really protecting by blocking credential fills on Xcode builds... Likewise, other developers are NOT allowed to build code using my App ID. This makes such users already on the more tech-savvy side, and unlikely to trust arbitrary codebases with their credentials, and the AutoFill wouldn't automatically pop-up for them anyway (as their compiled app would have a different App ID).
I agree with what you're saying here. I apologize for speaking incorrectly yesterday, I ended up twisting around the threads in my head and came to the wrong conclusion. We're looking into both cases internally 👍
I'm not a developer, but I use many web apps (created with the app "Unite"), and the universal autofill within these web apps has also stopped working since the 8.7.1 update. Universal autofill was working prior to this update.
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.
Yeah, I went through a similar thought process about this issue. If it helps, External TestFlight builds DO have to go through an App Store review process by Apple (it's not as intense of a review as the final App Store approval, but they don't really disclose what is and is NOT covered in such a review).
Xcode builds, obviously, do not go through any sort of review process. That said, I'm not sure who you're really protecting by blocking credential fills on Xcode builds. I'm pretty sure Apple already blocks me from just handing those builds over to run on someone else's machine. Thus, for someone to actually be harmed by a malicious password-harvesting build they'd have to first download Xcode, compile the code, and run that code on their system. Likewise, other developers are NOT allowed to build code using my App ID. This makes such users already on the more tech-savvy side, and unlikely to trust arbitrary codebases with their credentials, and the AutoFill wouldn't automatically pop-up for them anyway (as their compiled app would have a different App ID).
All-in-all, though, I'd be much happier if it at least worked on TestFlight. I can handle the Xcode builds the hard way (with old school copy-and-paste).
Thanks 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.
TestFlight Apps on macOS are signed by Apple in a process very similar to how released App Store apps are signed.
For that matter, Apps out of Xcode are signed too, but with a developer certificate. Thus, I'm not quite sure what rules are being applied when 1Password checks for "signed apps" (or perhaps it's all a red herring and none of this is the issue why Autofill is no longer working in these apps).
I assume you're looking for particular certificate authorities or intermediate certificates - something more than just the mere presence of a signature?
Here are the results from running codesign -d -vvv <OurApp>.app on one of our TestFlight apps on macOS:
Note the Authority=TestFlight Beta Distribution certificate in the chain. A released App Store app signed by Apple would have Authority=Apple Mac OS Application Signing in its place. Likewise, a development app from Xcode would have something like Authority=Apple Development: <Developer Name> (<Developer Team ID>).
However, all signatures are still derived from Apple Worldwide Developer Relations Certification Authority and the Apple Root CA in turn.
This is a bit frustrating as a developer that wants to use 1Password during testing (and, furthermore, ensure 1Password works with our app). It seems like, in particular, TestFlight builds should at least be allowed.
We're sorry that we broke your flow here, for what it's worth. While evaluating this change, we tried to consider how many people would be using unsigned or dev-only applications. I'm unfamiliar with how TestFlight apps work on macOS, but doesn't XCode sign applications automatically when it builds them?
Would you be able to confirm that your download is coming from this releases page page? I downloaded a build earlier and it looks like it's codesigned correctly:
I installed the app into /Applications, and then created this test item in 1Passowrd 8 for Mac and then tried to fill it:
After finding the item in quick access and manually selecting autofill, I got this prompt:
Both of these options ended up filling the credentials into FastMate. If I select the Fill & Update Login, Quick Access is able to fill it with Command+Shift+\. Do you know where the flow breaks for you? If its still not working, do you mind checking your logs for any autofill failures to look into this further?
