Re: authinfo gnutls netrc.el auth-sources & smtpmail-starttls-credentials

[MON KEY]

> I appreciate your thoughts, but please realize not everyone has an hour

With all due respect Ted - WTF MAN! Emacs 23 is in pretest.

Had I not included an ample illustration your reply would most likely
have been the usual:
"Status: Close - Reason: Could not Reproduce"  (URL `http://xkcd.com/583/')

Its not a personal failing Ted ;)

The entire 'auth regime' has undergone a rather extensive and recent
remake.  The revised 'auth regime' collectively incorporates numerous
libraries spread across multipleEmacs distribution directories/apps.
These include: netrc, starttls, epa, url-auth, smtpmail, netrc,
auth-sources, etc. The issue at hand (as I understand it) is but one
of a few bug/hole related to these inter-related facilities. Others
will arise.

Not everyone has an hour to point out what _you've_ missed.
I made time. Before posting I tested the bug on two seperate machines/os':

- On w32: "GNU Emacs 23.0.92.1 (i386-mingw-nt5.1.2600) of 2009-03-31
on LENNART-69DE564 (patched)"

- On Gnu/Linux: Current pretest Emacs-23.0.94

I am sorry if the previous message was too much for you or your
schedule. Maybe someone else will catch it.

Simply put, there is currently a minor hole in the code.  This is not
a _huge_ issue. I did my best to couch the error in a not too obvious
way so as not to needlessly over expose it. I believe the
`auth-sources.el' portion of the current 'auth system' should undergo
a bit more public scrutiny. As illustrated in the previous message,
this _little_ hole is already out in the wild. I'm aware of a few
other examples. However, as the 'auth regime' has changed considerably
over the last 14 months this glitch hasn't propagated very far.

> to parse all your code. If you have specific suggestions, please make

I have made specific suggestions. Moreover, I even went so far as to
put the cleanup in there to make it easier for people to evaluate the
code and recover to a normal state.

Don't waste any valuable time trying to 'parse' that code - just evaluate it.

The code shouldn't cause any problems, it uses `auth-sources.el' so
there isn't any undo risk - even for those in "Getting Things Done"
mode.

> follow up with questions implicit in your code that I have missed.

Per the previous examples I provided; Why are the 'sleeper
gnus-messages' hanging around in *Messages*?

> auth-source.el currently is part of Gnus, so it uses Gnus logging
> facilities.  If it's moved out, we can adjust the logging. Perhaps
> you're suggesting we need an auth-source-verbose variable?

No, I was not suggesting that. You just did.

I _am_ pointing out that the `gnus-message' logging facilty used in
conjunction with `auth-source-user-or-password' gives the user the
impression that by setting `gnus-verbose' to a lower threshold the
logging won't occur.When use of auth-source.el is separated from Gnus
that facility is irrelevant to non Gnus users; whether they set
`gnus-verbose' to 1 or 10 is a moot point.
> Can you explain what the problem is, please?  Is there unwanted
> information in the *Messages* buffer?

Is there?

MK>> It is worth noting that the call out to netrc.el happens at compile time:
MK>> (eval-when-compile (require 'netrc))

> I'm not sure why that's worth noting.

Yeah. I gather. It is noteworthy because:

- auth-sources is snarfing the service ports/protocols on some
systems... except - as you acknowledge - on some its not; in which
case it fails silently, which isn't a big deal because it, "Lets
people get things done". This behaviour is compiled in. Though one
might be able to customize the ports/protocols provided - as you point
out- they don't step on imap or tramp's toes.

- `auth-source-user-or-password' employs a faulty/leaky authentication
debugging/logging interface;

- The current 'auth regime' (including auth-sources) integrates with
multiple dynamic and auth/cert/key/ interfaces which change and adapt
according to user needs, and their _multiple_ systems and networks;

- The inevitable evolutionary security fixes - the recent Gnutls 2.6.x
DSA/RSA bugs {CVE-2009-1415, CVE-2009-1416, CVE-2009-1417} being a
case in point. For example, my Gnutls installed _yesterday_ is out of
date today! See; (URL
`http://article.gmane.org/gmane.network.gnutls.general/1674');

Is it reasonable for an hypothetical 'average Emacs user' to expect to
reliably debug/troubleshoot and configure an auth-source initiated
transaction config using the current 'auth regime' and expect a safe,
transparent, self cleaning, logging facility to aid in the process?
While some (not all) of these expectations can be currently be met it
does not come without presenting a situation whereby some users may
find that they are blindly pinging a machine/host/server (which is
it?) with:

- dog knows WHO on the other end;
- receiving dog knows WHAT;
- as it gets getting routed through dog knows WHERE;
(per netrc.el snarfage)

But this is the really amazing part - a mail/newsreader is the default
facility employed with keeping the logs while such a configuration
occurs...

So yes, it is noteworthy that auth-sources has this form:
(eval-when-compile (require 'netrc));

MK>> What _are_ these?

> encrypt.el was my encryption API, which (through a discussion with many
> Emacs users and developers) was obsoleted in favor of EPG/EPA.  The
> calls you saw will be removed eventually, together with encrypt.el
> itself, but I haven't done it yet (primarily due to lack of time).

Is encrypt.el bundled with current Emacs pretest?

> Sorry, as I said above I simply could not figure out everything you're
> asking through 3-4 pages of code.
> Please rewrite as simple questions I can answer.

Take this with a grain of salt if you prefer, my intention is not to
harbor of foster FUD.

Do you think auth-sources.el is secure by passing around messages/logging
using a MUA as its default logging facility? If not, why not?

>Thanks
>Ted

s_P