Fix sign-in 503 by not naming com.apple.dt.Xcode in X-Mme-Client-Info

[xiaopebaka]

Signing in has been failing since around 2026-08-31 with a 503 from
gsa.apple.com/grandslam/GsService2, on the very first request of the flow.

Cause

Apple's GrandSlam edge answers any request whose X-Mme-Client-Info names
com.apple.dt.Xcode with an HTML 503 page, before the request reaches the
backend at all.

Bisected against gsa.apple.com/grandslam/GsService2 with an init-shaped body,
three requests per row:

X-Mme-Client-Info third segment	result
<com.apple.AuthKit/1 (com.apple.dt.Xcode/25183.54.10)>	503 503 503
<com.apple.AuthKit/1 (com.apple.dt.Xcode/26.0)>	503 503 503
<com.apple.AuthKit/1 (com.apple.dt.Xcode)>	503 503 503
<com.apple.AuthKit/1 (com.apple.dt.Xcodex/26.0)>	503 503 503
<com.apple.AuthKit/1 (com.apple.foo/1.0)>	200 200 200
<com.apple.AuthKit/1 (com.apple.akd/1.0)>	200 200 200
<com.apple.AuthKit/1>	200 200 200

The match is on the com.apple.dt.Xcode prefix, not on the version and not on
the parentheses — appending a character to the identifier is still blocked,
while any other identifier is served normally.

Two things it is not:

• Not the User-Agent. All of akd/1.0 CFNetwork/808.1.4,
  akd/1.0 CFNetwork/978.0.7 Darwin/18.7.0 and
  AuthKit/1 (Macintosh; OS X 26.5.2) (com.apple.dt.Xcode/26.0) are served
  normally once the client info is clean, and all three are blocked while it is
  not. (Note the last one names com.apple.dt.Xcode too, and is still fine —
  the filter only looks at X-Mme-Client-Info.)
• Not connection reuse. Six requests over a single reused keep-alive
  connection all returned 200. The failure was on the first request of a fresh
  connection.

I mention both because the AltSign fixes for the same symptom
(#47,
#50,
#52) change exactly those two
things, and neither made a difference here.

Fix

Drop the trailing (com.apple.dt.Xcode/...) from the client info. The Xcode
flow is still identified by X-Apple-App-Info: com.apple.gs.xcode.auth and
X-Xcode-Version, neither of which is filtered.

X-Mme-Client-Info is only ever sent as a header — the copy in the anisette
client-provided data is commented out and AnisetteData::_device_description
is unused — so nothing else depends on this string.

Also: make the next one legible

plist_request checked nothing before handing the body to the plist parser, so
an HTML error page surfaced as a parse error naming neither the status code nor
the fact that the response came from the edge rather than the backend. This is
the same opaque failure AltStore saw as NSCocoaErrorDomain 3840.

It now verifies the status and Content-Type first and reports both plus a
snippet of the body, and retries 5xx responses five times with exponential
backoff. Three tests cover it against a local server: the retry path, a valid
plist over a single request, and HTML served with a 200.

Finding the cause above was only possible because of this change — the original
error said nothing useful.

Verification

init now reaches the backend and returns a real GrandSlam status. Against a
nonexistent account, 3/3:

AuthWithMessage(-20101, "Your account information was entered incorrectly.")

And a full sign-in on a real account goes through end to end with no retries:

init      -> Login step 1 completed
complete  -> Server proof verified -> Login step 2 completed
apptokens -> Successfully retrieved app token for com.apple.gs.xcode.auth

cargo test, cargo fmt --check and cargo clippy are clean on the touched
files, and the wasm feature still builds.

Note

apple-codesign-quick carries the same bug and needs the same one-line change;
I can open a second PR against that branch if you want it.

---

🤖 Generated with Claude Code

https://claude.ai/code/session_0194fngS3qeEqdSqR2JubDHE