Hi, thanks for your fast response! Yes, the attached patch definitely fixes things for me. I've copied the definition of `auth-info-password` into my init.el for now. I'm also surprised to see that no additional `ethan@black-diamond` entry was created in GNOME Secrets.
I see that the `auth-source` docstring for `auth-source-search` says "The token's :secret key can hold a function. In that case you must call it to obtain the actual value." I guess it doesn't say you need to call it only once but that's how I interpreted it. I understand the first level of function comes from the lambda in `auth-source-secrets-search`; where does the second one come from? 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@`? I guess based on your use of the term "cascaded" that maybe `auth-source` knows it doesn't need to create a new entry because it found a different one, but I'm still surprised about it. 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. Ethan On Wed, Jun 12, 2024 at 4:22 AM Michael Albinus <michael.albi...@gmx.de> wrote: > Ethan Glasser-Camp <ethan.glasser.c...@gmail.com> writes: > > > Hi emacs/tramp developers! Thank you for your efforts on tramp! > > Hi Ethan, > > > Today I updated emacs to 29.2 and I noticed something strange when I > > tried to use tramp to access files through the sudo method. This might > > turn out to be user error but I investigated it a little bit and I > > wanted to report what I found. > > Thanks for the detailed report! > > > I also tried turning on tramp-verbose to 10, which made emacs loop. (I > > think global-flycheck-mode was running on the tramp debug buffers and > > bringing emacs to its knees somehow.) However, it also produced a > > bunch of backtraces including an error like "Wrong type argument: > > stringp, #[0 "\300\207" ["..."]", where what was inside the ... was my > > actual user account password. This was kind of alarming, both because > > of the obscurity of the error and because I didn't expect the program > > to have access to my login password. > > That error has given me a clue what happened :-) > > > - This :secret value is a byte-compiled function, but the > > byte-compiled function does not return a string when called -- > > instead, it returns a second byte-compiled function (which, when > > called, would return a string). > > And this is indeed the problem, in auth-info-password. It expects a > string or a function from the search, and if it is a function, it calls > it and expects the password string then. > > However: in the "secrets:Login" case, this could be a *cascaded* > function. So you must call it again and again, until it returns a > string. > > Tramp did know this trap, and has provided a proper compatibility > function tramp-compat-auth-info-password. But when auth-info-password > exists, as it is the case in Emacs 29, this original function is called > with this error for passwords handled by the "secrets:Login" backend. > > I have pushed the appended patch to the emacs-29[*] branch of Emacs > git. Could you pls apply it to your Emacs 29.2, and check whether it > works? > > [*]: The recent Emacs release is 29.3. Honestly, I don't expect that > there will be an Emacs 29.4; likely the next release witll be 30.1. But > anyway, the patch will be contained there, whatever release it is. > > > Thanks! > > > > Ethan > > Best regards, Michael. > >
