VaultSort 2.9.5
decryptdata-integrityyubikeycritical
Critical decrypt fix: prevents silent data loss when the encrypted temp container is too small to hold the extracted contents. Encrypted data from prior versions is safe and will now decrypt correctly.
What's New
- Decrypt now runs a preflight capacity check against the destination volume's free space (with a 64 MB safety margin) and fails fast with a clear error instead of starting an extraction it cannot finish.
- Decrypt now performs a post-extraction verification pass that confirms every file in the archive exists at its final destination at exactly the size recorded in the tar header.
Bug Fixes
- Critical: Fixed a decrypt path where a reused encrypted temp container that was too small for both the decrypted tarball and the extracted tree could silently truncate output, after which the original
.encwould be securely deleted — resulting in data loss. (Reported case: a 2-file folder decrypted to 1 file, with the surviving file truncated from 3.6 GB to 3.02 GB.) Your encrypted.vaultsortfiles from prior versions are safe; this update lets them decrypt correctly. - The temp container for directory decrypts is now sized at ~3× the ciphertext size, so a previously-reused undersized container is grown before extraction begins.
tar.xnow runs in strict mode with anonwarnhandler so write errors (ENOSPC, EIO) are thrown as real exceptions instead of being silently dropped.- A post-extract verification step blocks deletion of the original
.encif any entry is missing or truncated, preventing silent partial-decrypt "success" from causing irreversible data loss. - Backported all of the above guards (sizing hint, capacity preflight, strict extract, post-extract verify) to the YubiKey decrypt paths (WebAuthn v1 and v2), so password-decrypt and YubiKey-decrypt now have identical safety guarantees.