0.1.1: refuse to encrypt to an empty recipient list #22
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Found in the 0.1.0 pre-launch audit (security, non-blocking). Fix for 0.1.1.
read_recipients(passcore/src/lib.rs:207) returns an empty list for a.gpg-idthat's empty or holds only#comments.Keyring::encrypt(passcore/src/keyring.rs:205) loops over zero recipients and doesn't fail, so it produces a message nobody can decrypt.What happens:
.gpg-idwrites that unreadable file, commits it and pushes it..gpg-id, the re-encrypt guard (passcore/src/reencrypt.rs:106) sees each changed entry asWrong(all_presentis vacuously true). It then re-encrypts them to nobody and pushes the result.The old versions stay in git history, so the data can be recovered.
pass init ""deletes.gpg-idinstead of emptying it, so the trigger is a hand-edited file.Fix:
encrypt(andStore::init) returnInvalidInputfor an empty recipient list. Add a test against a real temp store covering both the write path and the guard path.Trunk (
keyring.rs,lib.rs,reencrypt.rs).