Autofill No Longer Working Xcode Developer or TestFlight Signed Builds?

jjohnston
jjohnston
Community Member
in Mac

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

Comments

  • XIII
    XIII
    Community Member

    Could this be the reason I can no longer use Universal Autofill with my custom Fastmate builds?

  • XIII
    XIII
    Community Member

    No, does not work with the "official" Fastmate build (from their GitHub page) either 😢

  • ag_Christian
    ag_Christian

    Hey, @jjohnston, thank you for the feedback here.

    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?

    Hey there, @XIII.

    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?

  • jjohnston
    jjohnston
    Community Member
    edited June 2022

    Hi @ag_Christian,

    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:

    Executable=/Applications/<OurApp>.app/Contents/MacOS/<OurApp>
Identifier=com.<OurApp>
Format=app bundle with Mach-O universal (x86_64 arm64)
CodeDirectory v=20500 size=11703 flags=0x10000(runtime) hashes=354+7 location=embedded
Hash type=sha256 size=32
CandidateCDHash sha1=9912df38cbef2ad4d6e4aa7e99706b50d607fa5b
CandidateCDHashFull sha1=9912df38cbef2ad4d6e4aa7e99706b50d607fa5b
CandidateCDHash sha256=b39b86410dc5c791ee9434deeea8287be5fff016
CandidateCDHashFull sha256=b39b86410dc5c791ee9434deeea8287be5fff0167199d404e1f9c1e6935bade3
Hash choices=sha1,sha256
CMSDigest=d32900101ca1d9ea84247c63bc3073c3198ecf4405b1f7e1cb4fc42a4c445b81
CMSDigestType=2
CDHash=b39b86410dc5c791ee9434deeea8287be5fff016
Signature size=4745
Authority=TestFlight Beta Distribution
Authority=Apple Worldwide Developer Relations Certification Authority
Authority=Apple Root CA
Info.plist entries=42
TeamIdentifier=<OurTeam>
Runtime Version=15.4.0
Sealed Resources version=2 rules=13 files=120
Internal requirements count=1 size=124

    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.

  • ag_Christian
    ag_Christian

    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.

  • jjohnston
    jjohnston
    Community Member

    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).

  • sixbillships
    sixbillships
    Community Member

    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.

  • ag_Christian
    ag_Christian

    @jjohnston Thanks for that followup.

    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 👍

  • ag_Christian
    ag_Christian

    Hey there @sixbillships,

    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.

  • sixbillships
    sixbillships
    Community Member
    edited June 2022

    Here are those results after running "codesign -dvvv /Applications/Mosyle.app" in terminal:

    Executable=/Applications/Mosyle.app/Contents/MacOS/Mosyle
    Identifier=com.Mosyle
    Format=app bundle with Mach-O universal (x86_64 arm64)
    CodeDirectory v=20400 size=4291 flags=0x2(adhoc) hashes=128+3 location=embedded
    Hash type=sha256 size=32
    CandidateCDHash sha256=5d9357a7ea530f6f6fde745682bd6460d8a5a2bf
    CandidateCDHashFull sha256=5d9357a7ea530f6f6fde745682bd6460d8a5a2bfd5e8eb2b837fa6412c70add9
    Hash choices=sha256
    CMSDigest=5d9357a7ea530f6f6fde745682bd6460d8a5a2bfd5e8eb2b837fa6412c70add9
    CMSDigestType=2
    CDHash=5d9357a7ea530f6f6fde745682bd6460d8a5a2bf
    Signature=adhoc
    Info.plist entries=29
    TeamIdentifier=not set
    Sealed Resources version=2 rules=13 files=96
    Internal requirements count=0 size=12

  • ag_Christian
    ag_Christian

    Thanks for running that, @sixbillships.

    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.

    Thanks again

This discussion has been closed.