IJHack / QtPass / 41221506800

93%

Build Type

push

github

Committed by web-flow

Commit Message

RealPass::Init: take --path from the pair the store check judged (#2097)

* RealPass::Init: take --path from the pair the store check judged

PathValidator::isPathInStore() compares canonical paths; the --path for
pass came from a lexical relativeFilePath(). With the store setting
reached through a link (~/.password-store -> /data/pass) and a folder
spelled through its target (/data/pass/team), the check passed and
--path became ../../data/pass/team, which pass refuses as a sneaky path.

PathValidator::storeRelativePath() returns the place in the store from
the same canonical pair (isPathInStore() is now its has_value()), and
refuseFolderOutsideStore() hands it to the caller, so the check and the
--path cannot disagree.

Failed safe before (pass refused); no caller spells a folder that way.
Raised by CodeRabbit and Henk on #2096, tracked in #2094.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VJygpMUf461yZgfAqwMJ6d
Signed-off-by: Anne Jan Brouwer <brouwer@annejan.com>

* Init: work in the store's own spelling once the folder is placed

A folder spelled through the target of a linked store root passed the
store check (canonical) but was then used as given, and the recipient
list lookups compare against the store as named:

- RealPass walked the tree for its signed-list check in that spelling,
  so each entry's nearest list was not found and deeper rolled-back
  lists went unchecked while pass init (now given a valid --path)
  re-encrypted under them.
- ImitatePass re-encrypted in that spelling, so each entry's nearest
  list fell back to the store root's and entries were encrypted to the
  root's recipients instead of the folder's new list.

Both now continue from the store's spelling of the same folder
(store + its store-relative place). The link checks stay on the given
spelling: a canonical path has no links left to find, and .gpg-id and
.gpg-id.sig are the same files either way.

Found by ... (continued)

Coverage Stats

24 of 26 new or added lines in 4 files covered. (92.31%)

2 existing lines in 2 files now uncovered.

9952 of 10747 relevant lines covered (92.6%)

400.36 hits per line