Re: tramp (2.6.2.29.2 nil/nil); wrong-type-argument "stringp #[0 \\300\\207 [my actual password.."

[Ethan Glasser-Camp]

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.albinus@gmx.de> wrote:

Ethan Glasser-Camp <ethan.glasser.camp@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.