The highest-risk open item in the project, recorded in .planning/STATE.md.
internal/attest.AppleVerifier implements real Apple App Attest verification and is at 89.8% coverage — but every one of those tests uses an injected test root CA and synthetic attestation material. No genuine attestation from a physical iPhone has ever been verified end-to-end.
The expected App Attest identity is 997DW79YCR.com.brahy.hushield.
Why this is hard to close
App Attest cannot be exercised in the iOS Simulator. DeviceAttestationProvider only activates on real hardware; SimulatorAttestationProvider is a stub. So this needs:
- A physical iPhone
- A signed build (development, TestFlight, or App Store)
- A server running
ATTEST_MODE=apple with APP_ID set to the value above
What would help
Most of this needs the maintainer's hardware and signing identity, but two things are genuinely open to contributors:
- Improve the failure diagnostics. When verification fails today, is the error specific enough to tell why — wrong
APP_ID, expired challenge, bad certificate chain, replayed counter? Better errors here save hours of on-device debugging.
- Document the verification steps in
internal/attest against Apple's published attestation format, so a reviewer can check the implementation against the spec without a device.
Labeled needs-device so nobody sinks time expecting to reproduce it in a simulator.
The highest-risk open item in the project, recorded in
.planning/STATE.md.internal/attest.AppleVerifierimplements real Apple App Attest verification and is at 89.8% coverage — but every one of those tests uses an injected test root CA and synthetic attestation material. No genuine attestation from a physical iPhone has ever been verified end-to-end.The expected App Attest identity is
997DW79YCR.com.brahy.hushield.Why this is hard to close
App Attest cannot be exercised in the iOS Simulator.
DeviceAttestationProvideronly activates on real hardware;SimulatorAttestationProvideris a stub. So this needs:ATTEST_MODE=applewithAPP_IDset to the value aboveWhat would help
Most of this needs the maintainer's hardware and signing identity, but two things are genuinely open to contributors:
APP_ID, expired challenge, bad certificate chain, replayed counter? Better errors here save hours of on-device debugging.internal/attestagainst Apple's published attestation format, so a reviewer can check the implementation against the spec without a device.Labeled
needs-deviceso nobody sinks time expecting to reproduce it in a simulator.