From: "Arsen Arsenović via Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Michael Albinus <michael.albinus@gmx.de>
Cc: damien@cassou.me, Eli Zaretskii <eliz@gnu.org>,
67937@debbugs.gnu.org, jp@neverwas.me
Subject: bug#67937: 30.0.50; auth-source-pass relies on epa-file being enabled
Date: Wed, 20 Nov 2024 18:18:43 +0100 [thread overview]
Message-ID: <86h6814ydo.fsf@aarsen.me> (raw)
In-Reply-To: <871pz69go8.fsf@gmx.de> (Michael Albinus's message of "Wed, 20 Nov 2024 14:29:59 +0100")
[-- Attachment #1: Type: text/plain, Size: 4954 bytes --]
Hi Michael,
Michael Albinus <michael.albinus@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ć
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 377 bytes --]
next prev parent reply other threads:[~2024-11-20 17:18 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-20 16:57 bug#67937: 30.0.50; auth-source-pass relies on epa-file being enabled Arsen Arsenović via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-20 18:26 ` Eli Zaretskii
2023-12-20 19:11 ` Arsen Arsenović via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-20 19:21 ` Eli Zaretskii
2023-12-20 19:58 ` Arsen Arsenović via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-21 9:45 ` Eli Zaretskii
2023-12-21 10:18 ` Arsen Arsenović via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-21 14:33 ` J.P.
2023-12-21 15:29 ` Arsen Arsenović via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-21 23:39 ` J.P.
2023-12-22 7:33 ` Arsen Arsenović via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-22 14:27 ` J.P.
2023-12-22 14:53 ` Arsen Arsenović via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-22 19:40 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-22 20:49 ` J.P.
2023-12-23 11:20 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-23 15:06 ` J.P.
2023-12-23 15:26 ` Arsen Arsenović via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-23 16:59 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-23 19:44 ` Arsen Arsenović via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-24 0:43 ` J.P.
2023-12-24 10:25 ` Arsen Arsenović via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-24 11:55 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-24 9:47 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-24 10:37 ` Arsen Arsenović via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-24 11:41 ` Eli Zaretskii
2023-12-24 12:00 ` Arsen Arsenović via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-24 15:00 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-24 16:11 ` Arsen Arsenović via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-24 17:26 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-29 8:27 ` Arsen Arsenović via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-29 9:38 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-11-19 12:33 ` Arsen Arsenović via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-11-20 13:29 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-11-20 17:18 ` Arsen Arsenović via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
[not found] ` <87msht938s.fsf@gmx.de>
2024-11-21 18:54 ` Arsen Arsenović via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-11-22 8:31 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-11-22 15:59 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-11-23 11:38 ` Arsen Arsenović via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-11-23 12:14 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-24 12:00 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-24 12:14 ` Arsen Arsenović via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-24 15:03 ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-24 16:31 ` Arsen Arsenović via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-23 15:50 ` Arsen Arsenović via Bug reports for GNU Emacs, the Swiss army knife of text editors
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86h6814ydo.fsf@aarsen.me \
--to=bug-gnu-emacs@gnu.org \
--cc=67937@debbugs.gnu.org \
--cc=arsen@aarsen.me \
--cc=damien@cassou.me \
--cc=eliz@gnu.org \
--cc=jp@neverwas.me \
--cc=michael.albinus@gmx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.