TheMaxMur/RS-Key v0.3.9 on GitHub

[0.3.9] - 2026-07-19

KV store no longer rolls a key back to an older value on a power-cut mid-delete.
The vendored sequential-storage's remove_item erased a key's page copies starting
from find_first_page(PartialOpen).unwrap_or_default(), which falls back to page 0
whenever there is no partial-open page (the normal steady state: a closed frontier page
plus an open buffer page). That inverted the intended oldest-first erase order, so a
power loss during a delete could erase the newest copy first and leave an older copy
live — which the next read then returned (a rollback past the committed value). The
remove path now computes the newest page the same way the read path does, so the two
agree. On RS-Key this was fail-closed (every stored value is AEAD-sealed and read past a
length/tag gate, so a resurfaced stale/short blob is rejected, not used), but it is a
real durability defect in the store that holds all sealed secrets. Found by the
kv_durability fuzz target; an upstream sequential-storage bug (fix confined to the
vendored fork, third_party/sequential-storage.patch item 3). bcdDevice → 0x082D.