GNU bug report logs - #67937
30.0.50; auth-source-pass relies on epa-file being enabled

Previous Next

Full log

Message #122 received at 67937 <at> debbugs.gnu.org (full text, mbox):

From: Arsen Arsenović <arsen <at> aarsen.me>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: damien <at> cassou.me, Eli Zaretskii <eliz <at> gnu.org>, 67937 <at> debbugs.gnu.org,
 jp <at> neverwas.me
Subject: Re: bug#67937: 30.0.50; auth-source-pass relies on epa-file being
 enabled
Date: Wed, 20 Nov 2024 18:18:43 +0100

[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)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.