Re: Commit “emacs: Avoid double decryption in field and secret access” broke my setup

[Tino Calancha]

Hello Mekeor, thanks so much for the detailed message.

You have a great intuition for this problem. Your analysis correctly
pointed to the root cause: the previous change in the Emacs frontend
transferred clipboard ownership from the long-lived daemon to the
short-lived emacsclient, causing the content to be cleared as soon as
the process exited.

Unless this change proves to be problematic for other users, let's stick
with our solution of avoiding double encryption.

I think a workaround for your clipboard problem is a simple Emacs Lisp
function that ensures the emacs-daemon process, not the short-lived
emacsclient, handles the clipboard operation.

Please include the following function in your ~/.emacs or
~/.emacs.d/init.el file.

```
(defun mypassword-store-copy-to-clipboard-and-wait ()
  "Copies a password to the system clipboard and ensures it persists.

This function is a workaround for Wayland's clipboard management with
emacsclient.
It ensures that the `password-store-copy' command is run by the
long-lived `emacs-daemon' process, transferring clipboard ownership
to a non-expiring process."
  (interactive)
  (call-interactively #'password-store-copy))
```

After adding this code and restarting your Emacs daemon, you can
update your emacsclient command to call this new function.

```
emacsclient --create --no-wait \
  --eval "(call-interactively #'mypassword-store-copy-to-clipboard-and-wait)" \
  --eval "(delete-frame)"
```

I don't have an equivalent test environment to yours, but based on the
code and the nature of the error, I believe this workaround
should fix your problem.

Cheers,
Tino

On Mon, Aug 18, 2025 at 1:00 PM Mekeor Melire <mekeor at posteo.de> wrote:
>
> Hello. I'm reposting because my original message was badly
> formatted and got no response. If no one responds, let's please
> revert the mentioned commit.
>
>
>
> Hello. Git commit 3ca13cd8882cae4083c1c478858adbf2e82dd037 from
> 2025-06-18 broke my setup. To be precise, this part seems to break
> it:
>
>
> Now, how does it break my setup? What is my setup? I use GNU/Linux
> with Wayland and wlroots based Wayland compositor. I also run an
> Emacs daemon. To temporarily put a password in my clipboard, I run
> something along these lines:
>
>   emacsclient --create --no-wait \
>     --eval "(call-interactively #'password-store-copy)" \
>     --eval "(delete-frame)"
>
> I should also mention that I have an Elisp advice overriding
> password-store--run-1 without which my setup doesn't work. It
> makes sure that `1' is passed as SECONDS argument to
> accept-process-output.
>
> This used to work like a charm but with the mentioned commit
> active, the password doesn't end up in my clipboard.
>
> I didn't yet properly investigate the reasons. If I would wildly
> guess, I'd wonder if it's due to the removal of the invocation of
> password-store--run-show in the above mentioned commit
> snippet. Because --run-show will call password-store--run-1 which
> will call make-process. I'd guess that this means that before the
> patch, effectively my Emacs-daemon process was copying the
> password; whereas after the commit, effectively the
> emacsclient-process is copying. And since the emacsclient-process
> dies when its frame is closed, the Wayland clipboard is cleared.
>
> For now, my workaround is to call password-store-copy in an
> existing Emacs frame (i.e. one that I won't close until I at least
> have pasted the copied password).
>
> I'd be glad if my problem was solved upstream in
> password-store.el. Nevertheless, thank you for the commit and all
> the development labour.