Hi Michael, this patch makes more sense to me, thanks! I guess this means
that the entries with `root@black-diamond` are sort of deprecated and I
should be trying to move to `ethan@black-diamond` entries instead.
I was able to use this patch successfully once, with a moved-aside
.emacs.d. I was asked for a password for `ethan@black-diamond` , then I was
asked for a label, and then I was asked whether I wanted to save it to my
keyring.
However, at first, with my normal .emacs.d and without the
`ethan@black-diamond` entry being present, I was asked for a password for
`ethan@black-diamond`, and then I was asked for a label, and then I was
asked again for a password. It didn't seem to create an entry in my "Login"
keyring.
I got kinda sucked in to trying to debug this (even removing the
`ethan@black-diamond` entry even though it did get created successfully
once). I deleted the `ethan@black-diamond` entry from my keyring, and then
tried again with the moved-aside .emacs.d, but.. I couldn't get it to work
properly again!
It looks like tramp is trying to get the secret from auth-source, then
hitting an error condition, and then falling back to the `password-read`
function. By adding a bunch of debugging output, and removing the
`ignore-errors` call in `tramp-read-passwd`, I was able to retrieve the
error message `Symbol’s value as variable is void: data`. As best as I can
tell, it seems to be the closure around the secret in
`auth-source-secrets-create`:
```
(when data
(setq artificial (plist-put artificial
(auth-source--symbol-keyword r)
(if (eq r 'secret)
(let ((data data))
(lambda () data))
data))))
```
I'm not really clear why this wouldn't work. Maybe it's user error? I'm not
sure if I'm supposed to byte-compile the function or something.
(My current debugging setup is to `rm -rf .emacs.d', then `emacs`, then
open up a file called `tmp.el` that starts with:
```
(require 'secrets)
(require 'tramp)
(require 'auth-source)
(setq auth-sources '("secrets:Login"))
(setq auth-source-debug t
auth-source-save-behavior 'ask
tramp-verbose 7
secrets-debug t)
```
... and then continues with versions of functions like
`auth-source-secrets-create`, `auth-source-search`,
`auth-source-secrets-search`, `auth-source-secrets-saver`,
`tramp-read-passwd`, some of which I have hacked up to add debugging
output. I M-x eval-buffer this file and then C-x C-f /sudo:: RET.)
By the way, since I started this thread, I updated NixOS and now I'm using
emacs 29.3, although I don't think that much has changed in this version.
In hindsight, maybe I should have quit while I was ahead!
Ethan
On Tue, Jun 18, 2024 at 10:57 AM Michael Albinus <michael.albi...@gmx.de>
wrote:
> Ethan Glasser-Camp <ethan.glasser.c...@gmail.com> writes:
>
> > Hi! I tried this:
>
> Hi Ethan,
>
> > Then did C-x C-f /sudo:: RET. Again, I was asked for a label but not a
> > password, and no `ethan@black-diamond` entry was created in my Login
> > keyring. The contents of the `*Messages*` buffer were the same as
> > before.
>
> Finally, I could reproduce your problem, after I had created (manually)
> the "root@gandalf" item in the "Login" collection. "gandalf2 is my local
> host.
>
> Digging further, I've found bug#49289 <https://debbugs.gnu.org/49289>.
> It isn't only for this problem, but also for the cascading secret
> function, which I have bypassed by the modified auth-info-password ...
>
> Reading the bug messages, I've seen it was fixed only for the netrc
> backend. Oh. I've applied a similar patch to the other backends, secrets
> and plstore, and voilà, problem solved :-)
>
> I've pushed the appended patch to Emacs. This includes also the revert
> of my previous auth-info-password change. If you like, you could try to
> apply it to your Emacs 29 sources. Otherwise, you'll get the fix with
> Emacs 30.
>
> Thanks for your patient testing!
>
> > Ethan
>
> Best regards, Michael.
>
>
