GNU bug report logs -
#67937
30.0.50; auth-source-pass relies on epa-file being enabled
Previous Next
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Hi Michael,
Michael Albinus <michael.albinus <at> gmx.de> writes:
>> In the meanwhile, I'd like to understand your opinion on my conclusion
>> from the above: if epa-file-handler is the only reasonable handler for
>> the .gpg filenames in a pass store, there's no reason to rely on the
>> file-name handler system.
>
> A .gpg file could be taken from a remote location. In that case, you
> have two file name handlers, which must cooperate: epa-file-handler, and
> tramp-file-name-handler.
No, just one: tramp-file-name-handler. epa-file-handler has nothing to
do with remote file access.
> Furthermore, a .gpg file could be compressed, like file.gpg.gz.
No, it cannot, not in a pass store. Here's an example:
~/.password-store$ touch thing.gpg.gz
~/.password-store$ pass show thing
Error: thing is not in the password store.
In general, a pass file is _specifically_ a gpg-encrypted file (and it
says so in the manual), and, indeed, pass assumes so, a lot:
--8<---------------cut here---------------start------------->8---
~$ grep -F .gpg /usr/bin/pass
while [[ $current != "$PREFIX" && ! -f $current/.gpg-id ]]; do
current="$current/.gpg-id"
passfile_display="${passfile_display%.gpg}"
done < <(find "$1" -path '*/.git' -prune -o -iname '*.gpg' -print0)
local gpg_id="$PREFIX/$id_path/.gpg-id"
$GPG "${GPG_OPTS[@]}" "${signing_keys[@]}" --detach-sign "$gpg_id" || die "Could not sign .gpg_id."
[[ -n $key ]] || die "Signing of .gpg_id unsuccessful."
local passfile="$PREFIX/$path.gpg"
tree -N -C -l --noreport "$PREFIX/$path" | tail -n +2 | sed -E 's/\.gpg(\x1B\[[0-9]+m)?( ->|$)/\1\2/g' # remove .gpg at end of line, but keep colors
tree -N -C -l --noreport -P "${terms%|*}" --prune --matchdirs --ignore-case "$PREFIX" | tail -n +2 | sed -E 's/\.gpg(\x1B\[[0-9]+m)?( ->|$)/\1\2/g'
passfile="${passfile%.gpg}"
done < <(find -L "$PREFIX" -path '*/.git' -prune -o -iname '*.gpg' -print0)
local passfile="$PREFIX/$path.gpg"
local passfile="$PREFIX/$path.gpg"
local passfile="$PREFIX/$path.gpg"
local passfile="$PREFIX/$path.gpg"
if ! [[ -f $old_path.gpg && -d $old_path && $1 == */ || ! -f $old_path.gpg ]]; then
old_path="${old_path}.gpg"
[[ -d $old_path || -d $new_path || $new_path == */ ]] || new_path="${new_path}.gpg"
echo '*.gpg diff=gpg' > "$PREFIX/.gitattributes"
git -C "$INNER_GIT_DIR" config --local diff.gpg.binary true
git -C "$INNER_GIT_DIR" config --local diff.gpg.textconv "$GPG -d ${GPG_OPTS[*]}"
--8<---------------cut here---------------end--------------->8---
... as does auth-source-pass:
--8<---------------cut here---------------start------------->8---
(defun auth-source-pass--read-entry (entry)
"Return a string with the file content of ENTRY."
(with-temp-buffer
(insert-file-contents (expand-file-name
(format "%s.gpg" entry)
auth-source-pass-filename))
(buffer-substring-no-properties (point-min) (point-max))))
;; TODO: add tests for that when `assess-with-filesystem' is included
;; in Emacs
(defun auth-source-pass-entries ()
"Return a list of all password store entries."
(let ((store-dir (expand-file-name auth-source-pass-filename)))
(mapcar
(lambda (file) (file-name-sans-extension (file-relative-name file store-dir)))
(directory-files-recursively store-dir "\\.gpg\\'"))))
--8<---------------cut here---------------end--------------->8---
This is fine, of course, not making this assumption would be
unreasonable because of what the format of pass stores is.
I do understand that pass also does not cover TRAMP the same way it does
not cover compressed files, but I don't believe this is relevant here:
when we discuss a filesystem hierarchy, the TRAMP handler serves to
remap it to a remote location, while the EPA file handler serves to
_alter contents_. This is quite different.
Emacs recognizes this: '-literally' file operations support TRAMP, but
not the content-altering handlers. This is neat, I think.
> In that case, you have two file name handlers, which must cooperate:
> epa-file-handler and jka-compr-handler.
>
> Furthermore, a .gpg file could be located inside an archive, like
> archive.tar/file.gpg. In that case, you have two file name handlers,
> which must cooperate: epa-file-handler and
> tramp-archive-file-name-handler.
>
> No, it doesn't make sense to bypass the file name handler machinery.
Indeed - I have not implied otherwise. There are useful handlers.
epa-file is not one of them for this use-case.
> And all combinations of them ...
I doubt all combinations work.
But, while browsing epa-file.el just now, I've spotted:
(defvar epa-inhibit nil
"Non-nil means don't try to decrypt .gpg files when operating on them.")
This could also be a reasonable tool.
I hope this makes sense.
Have a lovely day.
--
Arsen Arsenović
[signature.asc (application/pgp-signature, inline)]
This bug report was last modified 206 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.