On Wed, Jun 12, 2024 at 12:56 PM Michael Albinus <michael.albi...@gmx.de>
wrote:
> 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
