Re: more on starttls, gnutls-cli and using tls for mail

[Ted Zlatanov <tzz@lifelogs.com>]

On Sun, 25 Sep 2011 13:26:08 -0400 Karl Fogel <kfogel@red-bean.com> wrote: 

KF> Ted Zlatanov <tzz@lifelogs.com> writes:
>> `smtpmail-auth-credentials' is not a good interface for many reasons.
>> It was very, very well discussed in the past.  Everything it can do,
>> should be possible with `auth-source-search'.
>> 
>> `auth-source' supports multiple backends.  There's no reason we can't
>> provide a backend that does the dynamic fetching you want and does not
>> use a authinfo/netrc file.  The authinfo/netrc backend supports entry
>> creation and can share the file with other consumers such as libcurl;
>> this is the main reason why it's the default now.
>> 
>> You should also note that you can configure `auth-sources' to use any
>> combination of backends.  So your custom ELisp backend could be first,
>> then you'd hit the Secrets API, then the authinfo/netrc backend. [...]

KF> Thanks.  This all sounds good in principle.  As a user (even as an
KF> Elisp-literate user) I have no idea yet how to take advantage of the
KF> functionality you describe above, but I assume that's just a matter of
KF> reading the documentation.  From what I've read so far, auth-source
KF> seems to be a superset of everything anyone could ever want.

KF> It may be that after I set up something dynamic, it will be
KF> contributable back to Emacs, either as code or as examples for the
KF> auth-source Info manual.  I'll try to keep that in mind.

KF> For now, I'm dynamically constructing ~/.authinfo and then destroying it
KF> after the mail is sent, because I got that working and its undeniable
KF> awkwardness is a mere annoyance, not a showstopper.

Heheh.  OK.  You really, really want a dynamic backend then.  No
problem.

First, look at the definition of `auth-sources'.  You need to augment
the list of backends:

                 (choice
                  (string :tag "Just a file")
                  (const :tag "Default Secrets API Collection" 'default)
                  (const :tag "Login Secrets API Collection" "secrets:Login")
                  (const :tag "Temp Secrets API Collection" "secrets:session")
+                  (const :tag "Karl's Dynamic Backend" 'dynamic-data)

Then look at `auth-source-backend-parse'.  Add your new backend to the
cond statement so it's parsed properly.  Here you can parse a string
prefix like "dynamic-data:karl-dynamic-variable" (as the Sessions API does) so
your users can point to a variable easily without customizing
`auth-sources' too much.  They would just have to add a string.  The
prefix doesn't have to match the backend name.

The last step is to create your backend instance when needed and return
it:

       (auth-source-backend
        (plist-get entry :source)
        :source (plist-get entry :source)
        :type 'dynamic-data
        :search-function 'auth-source-dynamic-data-search
        :create-function 'auth-source-dynamic-data-create)))

Your create function can be a stub, that's not a problem.

Finally your search function...  Copy the `auth-source-netrc-search'
template:

(defun* auth-source-netrc-search (&rest
                                  spec
                                  &key backend require create delete
                                  type max host user port
                                  &allow-other-keys)

1) the backend is the backend you created earlier, you'll need the
"source" slot which in your case is e.g. karl-dynamic-variable.  You'd
map that to a symbol name and manipulate the value, obviously.

2) require is a list of required keys

3) max is the maximum number of results you should return

4) create can be ignored if your create-function is a stub

5) delete can be ignored if your backend doesn't delete entries,
otherwise delete everything you found up to max

6) host, user, port are the only search criteria accepted by the
netrc/authinfo backend; yours could take more

7) type is the backend type, you should return nothing if it's not
dynamic-data (the `auth-source-search' caller may ask for this).

If you want to allow creation, look at `auth-source-netrc-create'.
There's a lot of code to deal with prompting that should IMO be factored
out but I haven't had the time.  It sounds like you'd be OK with letting
the user modify the data externally though.

Daiki Ueno went through this with his plstore backend so you're the
second one to possibly write a custom backend.  If it goes well for you
I'll put these instructions in the auth-source texinfo pages.

If you think this is too complicated or you're busy, I'll do it.  Please
let me know.

Thanks
Ted