This will appear with Tramp 2.7.1 on GNU ELPA, which is scheduled for
release end of June. And of course with Emacs 30, but this is months
away.
Ah, thanks! I made a note to take the workaround out when I get Tramp 2.7.1.
> I'm also surprised to see that no additional `ethan@black-diamond`
> entry was created in GNOME Secrets.
Is that so? That means, you have only the `root@black-diamond` entry in
GNOME secrets? Perhaps this is due to your auth-sources config:
--8<---------------cut here---------------start------------->8---
(setq auth-sources
'(default
"secrets:session"
"secrets:Login"
"~/.authinfo.gpg"))
--8<---------------cut here---------------end--------------->8---
"secrets:session" is a temporary collection only, which is not kept
permanently.
Ah, I just copied that from the previous post in tramp-devel and only used it in `emacs -Q` for reproduction purposes. My actual `auth-sources` is `("secrets:Login" "~/.authinfo" "~/.authinfo.gpg" "~/.netrc")`.
> Out of curiosity, how does fixing this fix the larger issue? I see
> that the successful tramp connection says `root@black-diamond`. Is
> there some kind of fallback behavior in either tramp or `auth-source`
> that tries `root@` after trying `ethan@`?
Tramp says `root@black-diamond` connection because this is what you have
told it to open for the sudo method. However, Tramp knows, that the sudo
method requires the password of the local user, and so it works with
`ethan@black-diamond`. Using `root@@black-diamond' doesn't make sense
for sudo.
Conceptually this is always right for sudo, but there was an error in
Tramp that it has asked auth-source-search for `root@black-diamond` in
the past. This was fixed in Tramp 2.6 (the version you get with Emacs
29), so an entry `root@black-diamond` was created likely using an older
Tramp version.
Ah, I see. I saw an entry in Emacs NEWS I saw when researching the issue with the title "Proper password prompts for methods "doas", "sudo" and "sudoedit". Is this the same subject? Both entries in GNOME Secrets have `root@black-diamond` as the "label" and `root` as the user.
> I forgot to mention this in my original email last
> night, but when I tried doing `(auth-source-search :user
> "any-user-name" :host "black-diamond" :require '(:secret :user) :
> create t)`, I would get a "match", always with my same password
> visible in the response. I see that `auth-source-secrets-create`
> redoes the query using `host` and `port` but without `user` or any
> other parameters.. this seems a little strange? For sudo, I think
> using the user password "as" the root password makes sense, but if I
> had multiple accounts on a single host I would be surprised for their
> passwords to get mixed up.
When Tramp creates a password entry for whatever auth-source.el backend,
it always uses the :port entry (which means the Tramp method, in
auth-source speech). So the entries are unique. When *searching*, it
tries first for an entry with all :host, :user and :port items, and if
this fails, it tries w/o :port, in case the user has created such an
entry manually.
I was referring specifically to this line in `auth-source-secrets-create`:
```
(let* (...
(current-data (car (auth-source-search :max 1
:host host
:port port)))
```
It seems like this would be liable to grab the secret for another user on the same host/port. For example, if I was using the `ssh` method, then `host` and `port` would not be unique, right? In my usage, with `sudo`, that's fine. Of course, I only skimmed the function and I may be misunderstanding.
Thanks,
Ethan