fix(storage): take V20, because 18 and 19 are burned - #505
Merged
Conversation
U5 (test_active_flash_format_is_v17) went red on this branch, and it was right to. The branch bumped the flash format to 18 -- a number that already means something else. 18 was the clear-sign identity block and 19 was the PIN-KDF migration. Both were ACTIVE, not merely drafted: git log -S"STORAGE_VERSION_LAST(19)" shows e109404 making 19 live and 6bebde7 reverting the format to V17 for 7.15. Any device that ran an alpha build in that window carries a blob stamped 18 or 19 whose layout has nothing to do with passkeys. Reusing 18 would make this firmware read those blobs as CTAP2 state. Not refuse them, not wipe them -- parse them, as something they are not. That is the failure docs/StorageVersionGate.md calls the highest-severity item in the file, and it is the reason U5 asserts a literal instead of trusting the compile-time check: STORAGE_VERSION and STORAGE_VERSION_LAST_SHIPPED are two numbers in the same header, and raising one to make a build compile is exactly the edit that must not pass silently. So: the passkey format takes 20. 18 and 19 stay in the ladder -- the enum is positional, so removing an entry renumbers everything after it -- but there is deliberately NO reader for either. A blob stamped 18 or 19 falls through to the default and the device wipes, which is the documented behaviour for an unrecognised format and is strictly better than misparsing one. The passkey format itself is unchanged: same layout, same 2525 bytes in V17's reserved plaintext area, same reader logic. Only the version number it registers under, and the V18_* -> V20_* symbol names, have moved. U5 still needs updating with the release argument for the bump (reader chain, anti-rollback story, release note) -- that is a deliberate release act and belongs to whoever cuts 7.16, not to this fix.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Unblocks #504's U5 failure without merging past the gate.
The problem
#504 bumps the flash format to 18. That number already means something else.
18 was the clear-sign identity block; 19 was the PIN-KDF migration. Both were active, not merely drafted:
Any device that ran an alpha build between those two commits carries a blob stamped 18 or 19 whose layout has nothing to do with passkeys. Dev devices in this building are in that population.
Reusing 18 makes this firmware read those blobs as CTAP2 state — not refuse them, not wipe them, parse them as something they are not. That is the failure
docs/StorageVersionGate.mdcalls the highest-severity item in the file, and it is exactly why U5 asserts a literal rather than trusting the compile-time check:STORAGE_VERSIONandSTORAGE_VERSION_LAST_SHIPPEDare two numbers in the same header, and raising one to make a build compile is the edit that must not pass silently.The fix
The passkey format takes 20.
18 and 19 stay in the ladder — the enum is positional, so removing an entry renumbers everything after it — but there is deliberately no reader for either. A blob stamped 18 or 19 falls through to the default and the device wipes: the documented behaviour for an unrecognised format, and strictly better than misparsing one.
The passkey format itself is unchanged. Same layout, same 2525 bytes in V17's reserved plaintext area, same reader logic. Only the version number it registers under and the
V18_*→V20_*symbol names moved.Still owed before U5 goes green
U5 needs updating with the release argument for the bump — reader chain, anti-rollback story, release-note wording. That is a deliberate release act per the gate doc and belongs to whoever cuts 7.16, not to this fix. I did not touch the test.