bug#74105: 30.0.92; Some issues in TRAMP NEWS entries

[Sean Whitton]

Hello,

On Wed 30 Oct 2024 at 12:54pm +01, Michael Albinus wrote:

> No, the whole tramp-connection-properties machinery is not replaced,
> otherwise it would have been mentioned in NEWS. Furthermore, it is still
> explained in the Tramp info manual of Emacs 30, which could give you an
> indication that it still exists.

How about explicitly saying that it's not deprecated?

NEWS says that the connection property is deprecated, and the manual
says that the old way will eventually stop working.

In the presence of the new connection local variables, it is very
natural to mistakenly think that connection properties as a whole are
going away.

So how about just

    In previous Emacs versions this was indicated by the
    connection property "direct-async-process".  That connection
    property (though not connection properties and
    `tramp-connection-properties' in general) is now deprecated.

> I don't know whether it is common praxis. I, for example, access my NAS
> boxes (QNAP) via ssh w/o direct async processes. Simply, because they
> are special, and do not cooperate well with direct async processes.

That's fair enough, it's easy to assume one's own practices are common.

> Furthermore, there are also disadvantages using direct async processes,
> which are listed in the Tramp manual (same node as above). This prevents
> me from saying, all connections using "ssh" shall use direct async
> processes. And what's about "scp"? You can also use direct async
> processes for such connections. Would you like to recommend this as well
> in general? Where do you want to stop? Recommend "rsync"?
>
> Sorry, but the conditions are more complex than you expect. People shall
> find out what's best suited for them.

I read the list of disadvantages, and I think most of them don't apply
to the majority of users.  I didn't know about it for SCP and rsync but
now intend to enable it :)

I still think it would be a good idea to give an answer to "just turn
this on for everything, please" in the manual.

>> (3) Has there been a change to how password caching works?
>>
>>     I tried deleting the session-timeout configuration.  I made a
>>     /sudo:: connection.  After some time passed, I saw the familiar
>>     "Tramp connection timed out" message.  But it reconnected
>>     immediately when I tried to save a buffer I had open.  Does it now
>>     cache the sudo password?  In the past, you had to type it again,
>>     after the timeout.
>>
>>     If there is a change here, it's security-relevant, so it should
>>     probably be in NEWS.
>
> Likely, you're trapped by the following change, documented in NEWS.29:
>
> --8<---------------cut here---------------start------------->8---
> *** Proper password prompts for methods "doas", "sudo" and "sudoedit".
> The password prompts for these methods reflect now the credentials of
> the user requesting such a connection, and not of the user who is the
> target.  This has always been needed, just the password prompt and the
> related 'auth-sources' entry were wrong.
> --8<---------------cut here---------------end--------------->8---
>
> If it is something else, we need to debug.

Hmm, isn't this NEWS.29 change just a change in the password prompt?  I
don't see how that applies to what I described.

Unless it caches the sudo password, it shouldn't have been able to
reconnect.

-- 
Sean Whitton