Problem
Current Web import rejects a real, current Google Authenticator migration export with the secret-free error class The Google Authenticator migration metadata is unsupported.
No real QR image, migration URI, protobuf bytes, account identity, or authentication material is attached to or quoted in this Issue.
Root cause investigation
The current implementation in web/src/import/google-migration.ts accepts only top-level migration metadata version === 1.
Public current-format evidence from late 2025 documents Google Authenticator output using top-level migration version = 2 while retaining the established MigrationPayload field numbers/types. Independent importer/schema implementations continue to agree on:
otp_parameters = 1
version = 2 (int32 field number 2; the field value may be 1 or 2 depending on format generation)
batch_size = 3 (int32)
batch_index = 4 (int32)
batch_id = 5 (int32)
Recent Google exports may also include an OtpParameters field 8 (unique_id). The M5Authenticator decoder already skips unknown protobuf fields, so this additive field is not itself the metadata rejection cause.
batch_size denotes the number of QR chunks in one migration batch, not the number of accounts. The existing parser couples it directly to V1_MAX_ACCOUNTS; V1's 32-account capacity must instead remain an independent import/session constraint.
References (public format/schema evidence only; no user export data):
Required fix
- Accept only explicitly known compatible migration versions 1 and 2; do not accept arbitrary future versions.
- Preserve protobuf unknown-field skipping.
- Validate
batch_size / batch_index as QR-batch metadata independently from the 32-account V1 capacity.
- Keep malformed metadata fail-closed.
- Keep V1 maximum 32 imported accounts.
- Keep V1 account profile restricted to TOTP / SHA-1 / 6 digits / 30 seconds.
- Preserve secret zeroization and partial-batch cleanup.
- No runtime network, plaintext persistence, or firmware/protocol/Vault change.
- Unsupported metadata errors may expose only bounded non-secret numeric metadata (
version, batchSize, batchIndex); never source URI/raw payload/account fields/secrets.
Regression coverage
Use synthetic-only payloads to cover at least:
- current-compatible version 2 single QR, including an ignored synthetic unknown/additive OtpParameters field
- version 2 multi-QR and out-of-order assembly
- legacy version 1 compatibility
- unsupported version
- invalid batch index / malformed batch size
- account total greater than 32
- unsupported algorithm/digits/type
- errors do not contain the source migration URI/payload
- rejected/discarded account secrets and partial-batch secrets are cleared
Security constraints
Follow SECURITY.md. Never commit or publish real authenticator exports, screenshots, migration URIs/payloads, account identities, or real authentication material. No eFuse operation. No v0.1.0 tag or Release.
Scope
Web import implementation/tests only. If firmware, Protocol, or Vault format changes appear necessary, stop instead of expanding scope.
Problem
Current Web import rejects a real, current Google Authenticator migration export with the secret-free error class
The Google Authenticator migration metadata is unsupported.No real QR image, migration URI, protobuf bytes, account identity, or authentication material is attached to or quoted in this Issue.
Root cause investigation
The current implementation in
web/src/import/google-migration.tsaccepts only top-level migration metadataversion === 1.Public current-format evidence from late 2025 documents Google Authenticator output using top-level migration
version = 2while retaining the establishedMigrationPayloadfield numbers/types. Independent importer/schema implementations continue to agree on:otp_parameters = 1version = 2(int32field number 2; the field value may be 1 or 2 depending on format generation)batch_size = 3(int32)batch_index = 4(int32)batch_id = 5(int32)Recent Google exports may also include an
OtpParametersfield 8 (unique_id). The M5Authenticator decoder already skips unknown protobuf fields, so this additive field is not itself the metadata rejection cause.batch_sizedenotes the number of QR chunks in one migration batch, not the number of accounts. The existing parser couples it directly toV1_MAX_ACCOUNTS; V1's 32-account capacity must instead remain an independent import/session constraint.References (public format/schema evidence only; no user export data):
Required fix
batch_size/batch_indexas QR-batch metadata independently from the 32-account V1 capacity.version,batchSize,batchIndex); never source URI/raw payload/account fields/secrets.Regression coverage
Use synthetic-only payloads to cover at least:
Security constraints
Follow
SECURITY.md. Never commit or publish real authenticator exports, screenshots, migration URIs/payloads, account identities, or real authentication material. No eFuse operation. Nov0.1.0tag or Release.Scope
Web import implementation/tests only. If firmware, Protocol, or Vault format changes appear necessary, stop instead of expanding scope.