Transporter (docs here) invoked via xcrun iTMSTransporter, has a built-in auto-update mechanism. It will check for and cache new java libraries on first launch and once per day following, and always does this prior to actually invoking functionality. You can verify this yourself by just running xcrun iTMSTransporter and watching the log output, where you'll see the new library downloaded, i.e.: [2021-12-18 10:27:17 EST] <ForkJoinPool.commonPool-worker-23> INFO: downloading resource: org.apache.logging.log4j.api/2.16.0 It will not replace the library in-place within the .app bundle, instead it will cache them to ~/Library/Caches/com.apple.amp.itmstransporter and then only load the libs from that location. (You can also delete that cache directory to force it to re-run this process) Given all of the above, it seems like there will be no cases of someone inadvertently using the vulnerable library, even though it would remain on disk in the Xcode app bundle, for as long as Apple continues shipping it (13.2.1 still includes it). Since other platform companies and vendors have been able to quickly issue public statements on the subject of log4j2, I think the right thing for Apple's security or WWDR team to do would be to have a public KB article to just simply explain the above. Xcode is widely known and installed, log4j2 is now widely known, but these specific details are not. FB9811066 is my feedback/rdar asking for such a public KB/article on the subject.

You can find the restore ipsw images for Monterey here, on the main downloads page: https://developer.apple.com/download/

@meaton I've made a bit of progress implementing the workaround of setting --generate-entitlement-der during our archive builds on Catalina. When we perform an archive we also pass -archivePath <path to .xcarchive> and then do an -exportArchive in a subsequent step, and from there we archive the resultant enterprise-signed IPAs for use in development and QA. I set OTHER_CODE_SIGN_FLAGS=--generate-entitlement-der in both the xcodebuild archive invocation and then the subsequent -exportArchive. The resultant xcarchive produces a .app within Products that does contain 6 and 7. However, the .ipa from the -exportArchive step does not, so I can't install the exported IPA as-is. I am able to manually create an IPA wrapper for the built product originating from the .xcarchive by copying this .app into a new Payload directory and zip-ing it into a file with a .ipa extension. Installing this manually-cobbled IPA onto an iOS 15 device seems to work fine. I see from looking at IDEDistributionPipeline.log from the -exportArchive step that there is still a lot of logic to the -exportArchive step. I see when it gets to Processing step: IDEDistributionCodesignStep: it eventually gets to: 2021-07-20 16:23:18 +0000 [MT] Running /usr/bin/codesign '-vvv' '--force' '--sign' '<scrubbed>' '--entitlements' '/var/folders/6f/tcr7g_ms167blz6vbzctyrth0000gn/T/XcodeDistPipeline.~~~ubOEou/entitlements~~~QfGC1G' '--preserve-metadata=identifier,flags,runtime' '/var/folders/6f/tcr7g_ms167blz6vbzctyrth0000gn/T/XcodeDistPipeline.~~~ubOEou/Root/Payload/<scrubbed>.app' ..so I can see it has re-signed the top-level .app bundle without the additional flags we had specified from the original archive build. Is there some other way we can tell the archive export stage about the --generate-entitlement-der flag? For example, defining it in the export options? Given there is so much additional logic I see in the IDEDistributionPipeline.log steps I'm hesitant to try and do our own IPA repackaging by simply copying the .app out of the xcarchive and into an IPA zipfile, given that all of this is stopgap work for us until we upgrade to Big Sur. We're still blocked on upgrading all of our release build machines to Big Sur due to FB9363703 and FB9006786.

It would still be great if this could just be documented publicly (see FB9190730).

Also since I evidently read the article a bit too fast: it says "For any value of v less than 20400, you’ll need to re-signed [sic] your app." Signing on Big Sur (Xcode 12.1, still) seems for me to generate v20400.

We're also affected by this, but the "Using the Latest Code Signature Format" article only mentions needing to code-sign with 10.14 or later. We build and codesign on 10.15, but when I do look at the output of codesign -dv, I do indeed see the version of 20400. Is it possible this article needs to be updated? I'm confused why the version would be still 20400 on Catalina while the article suggests that signing on 10.14 or later should produce a v20500 CodeSignature format.