Re: tramp-auto-auth.el --- TRAMP automatic authentication library

[Bruno Félix Rezende Ribeiro]

Hello Michael,

Michael Albinus <address@hidden> writes:

> Thinking about this, I believe we could use such a mechanism at broader
> level. You manage just one Tramp resource (passwords). WIBNI you could
> cluster remote hosts also for other resources? For example, in order to
> say "users for a given host share the same password if they access via
> 'ssh' or 'sftp' or 'scp'". Or if you say "the connection property [1]
> \"remote-shell\" of a given list of hosts shall be \"/bin/bash\"". Or if
> you say "the connection-local variable [2] `tramp-remote-path' for a
> given list of hosts shall contain \"/appli/pub/bin\"".
>
> [1] (info "(tramp) Predefined connection information")
> [2] (info "(tramp) Remote programs")
>
> Then you could declare just clusters. I would start with a cluster name
> (a string), and a list of regular expressions which identify the remote
> hosts. Using your example, one would declare
>
> (add-to-list 'tramp-clusters '("Funny-Machines" "root@10\\.0\\." "..."))
>
> For every resource, be it a password, a connection property, or a
> connection-local variable, Tramp would always check whether there is a
> setting of that resource for the host in question, and if not, whether
> there is a setting in a cluster the host belongs to.
>
> This broader approach wouldn't be implemented by an own package via
> advising Tramp functions, but in Tramp itself. For the beginning, one
> could start with managing passwords this way.
>
>> Is this feature in this form suitable for inclusion in the TRAMP
>> standard distribution?
>
> Does this proposal makes sense to you? Would you like to work on this?

Yes, it does, and I’d like to work on it.  However, it’s not clear to me
if the code I already wrote would be used as an interim solution.  Most
of the remarks you made below seems to me to imply that’s the case,
however this conflicts with the fact that code in core Emacs should not
advice other functions.  I think it’s most likely you are just giving me
general advice as if it were to be included, but I’m not entirely sure;
because (maybe) this code could be included in GNU ELPA.  Could you
please clarify this matter?


> Just some comments on your code
>
>> ;; Copyright (C) 2019 Bruno Félix Rezende Ribeiro <address@hidden>
>
> This would be FSF copyrighted, if included in Emacs/Tramp.

All right.  I’ve already assigned my copyright to the FSF for past and
future contributions to GNU Emacs.


>> ;; Author: Bruno Félix Rezende Ribeiro <address@hidden>
>> ;; Maintainer: Bruno Félix Rezende Ribeiro <address@hidden>
>
> If there is an author, you don't need a maintainer.

Indeed.


>> ;; Package-Version: 20190827.1316
>> ;; Package-Requires: (tramp)
>
> These entries are needed only in case it would be an ELPA package.

I see.  These are there because I’ve uploaded this source file to a
local ELPA.


>> ;; After this, just put the respective sacred secret in an
>> ;; authentication source supported by auth-source library.  For
>> ;; instance:
>> ;;
>> ;; ---- ~/.authinfo.gpg ---------------------------------------------
>> ;; machine Funny-Machines login root password "$r00tP#sWD!" port ssh
>> ;; ------------------------------------------------------------------
>
> IIRC, neither "login" nor "port" keys are mandatory in auth-source. So
> you could live just with "machine" and "password".

OK.


>> ;; In case you are feeling lazy or the secret is not so secret (nor so
>> ;; sacred) -- or for any reason you need to do it all from Lisp --
>> ;; it’s enough to:
>> ;;
>> ;; (auth-source-remember '(:host "Funny-Machines" :user "root" :port "ssh")
>> ;;                    '((:secret "$r00tP#sWD!")))
>
> I wouldn't write this into a Tramp doc. Refer to the "auth" Info pages.

My intention with this was to document the way I found for another
private library to setup an auth-source entry automatically without
fiddling with user’s Netrc files.

I couldn’t find any reference to this function in auth-source’s manual.
Perhaps a section about this technique is needed there before we can
refer to it?


>> (defcustom tramp-auto-auth-alist
>
> A defcustom should have a :version key. In case it will be added to
> Tramp, :version "27.1" (the first Emacs version this user option has
> appeared) would be OK.

Noted.


>>   :require 'tramp-auto-auth)
>
> Why is this needed?

Quoting from the documentation on ‘:global’ in ‘(elisp) Defining Minor
Modes’:

  One of the effects of making a minor mode global is that the MODE
  variable becomes a customization variable.  Toggling it through the
  Customize interface turns the mode on and off, and its value can be
  saved for future Emacs sessions.  For the saved variable to work, you
  should ensure that the ‘define-minor-mode’ form is evaluated each time
  Emacs starts; for packages that are not part of Emacs, the easiest way
  to do this is to specify a ‘:require’ keyword.

Since ‘tramp-auto-auth’ is not part of Emacs, I thought that was needed.


>> ;;;###autoload
>
> Please use ";;;###tramp-autoload". The user option makes only sense
> after Tramp has been loaded.

Where is this ‘;;;###<package>-autoload’ cookie feature documented?  I
couldn’t find it.


>>      (advice-add #'tramp-action-password :around
>
> Code, which is part of core Emacs, shall not advice other
> functions. Advicing is intended for user-written Lisp.

I couldn’t find any other way to obtain the same effect.  Do you have
any suggestion?


> Please ensure also, that you do not exceed the 80 chars/line limit, for
> better readability.

Sure.


Best regards,

-- 
 88888  FFFFF Bruno Félix Rezende Ribeiro (oitofelix) [0x28D618AF]
 8   8  F     http://oitofelix.freeshell.org/
 88888  FFFF  mailto:address@hidden
 8   8  F     irc://chat.freenode.org/oitofelix
 88888  F     xmpp://address@hidden