You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It seems that only the $PASSAGE_DIR folder is checked for the .age-recipients file. That, or I am misunderstanding the documentation:
For encryption, the nearest .age-recipients file (that is, the one in the same
directory as the secret, or in the closest parent) is used with the -R age CLI
option.
For the current version (set_age_recipients()):
local current="$PREFIX/$1"
# should prevent traversal above $PREFIX
# vvvvvvvvvvvvvvvvvvvvv
while [[ $current != "$PREFIX" && ! -f $current/.age-recipients ]]; do
current="${current%/*}"
done
current="$current/.age-recipients"
Where PREFIX="${PASSAGE_DIR:-$HOME/.passage/store}", seems to prevent passage from traversing upwards. Removing the first condition leads the program to act as I would expect. There may be security implications to allowing an infinite upwards traversal in search for recipients, so the fix may be a documentation edit.
Additionally, there is no warning when the identity key fallback is used; this may lead to an unfortunate UX where additional recipients are not used to encrypt, and a "recovery" key would fail to recover the data.
Thank you for your work.
The text was updated successfully, but these errors were encountered:
It seems that only the
$PASSAGE_DIR
folder is checked for the.age-recipients
file. That, or I am misunderstanding the documentation:For the current version (
set_age_recipients()
):Where
PREFIX="${PASSAGE_DIR:-$HOME/.passage/store}"
, seems to prevent passage from traversing upwards. Removing the first condition leads the program to act as I would expect. There may be security implications to allowing an infinite upwards traversal in search for recipients, so the fix may be a documentation edit.Additionally, there is no warning when the identity key fallback is used; this may lead to an unfortunate UX where additional recipients are not used to encrypt, and a "recovery" key would fail to recover the data.
Thank you for your work.
The text was updated successfully, but these errors were encountered: