On Thu, 11 Jun 2009 19:44:37 -0400 MON KEY <monkey@sandpframing.com> wrote: 

MK> Not everyone has an hour to point out what _you've_ missed.
MK> I made time. 

I appreciate your suggestions very much.  I am just asking you to
present them in a way that I can understand more readily.  From looking
at the stream of Emacs bug reports for a while, most people can submit
verbal explanations just fine, using code to support but not replace
them.  For reference, here's what M-x report-emacs-bug suggests:

"Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.

Your bug report will be posted to the emacs-pretest-bug@gnu.org mailing list.

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:"

The key word is "describe."  You did not describe, you posted a few
pages of code.

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

Sure, let's hope whoever does will write a patch or explain it better.

Meanwhile, assuming there's no "someone else" standing by, let's try to
figure out the problem.

MK> I did my best to couch the error in a not too obvious way so as not
MK> to needlessly over expose it.

All right.  Please use e-mail next time, so you can be clear in what
you're reporting.  It would have saved time, and is the standard way to
report security issues.

MK> I believe the `auth-sources.el' portion of the current 'auth system'
MK> should undergo a bit more public scrutiny. 

I've posted many notes to emacs-devel inviting scrutiny and
suggestions for auth-source.el.  In any case, please do review and
comment on it.  Just do it in 

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

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

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

Your cleanup sets auth-sources to nil.  That would screw up my setup, at
least.  It's definitely not OK to just evaluate it; there were many
other issues I don't have time to list and which are not really
relevant.  I would have at least wrapped everything in a let scope,
FWIW.

MK> I _am_ pointing out that the `gnus-message' logging facilty used in
MK> conjunction with `auth-source-user-or-password' gives the user the
MK> impression that by setting `gnus-verbose' to a lower threshold the
MK> logging won't occur.When use of auth-source.el is separated from Gnus
MK> that facility is irrelevant to non Gnus users; whether they set
MK> `gnus-verbose' to 1 or 10 is a moot point.

Thank you for explaining.  I've attached a patch to use only the
`message' function for logging messages, and logging is off by default.
The patch is against Emacs CVS.  Let me know what you think.

MK> Is it reasonable for an hypothetical 'average Emacs user' to expect to
MK> reliably debug/troubleshoot and configure an auth-source initiated
MK> transaction config using the current 'auth regime' and expect a safe,
MK> transparent, self cleaning, logging facility to aid in the process?

Sure.  Now, what are you suggesting should be changed or improved?

MK> While some (not all) of these expectations can be currently be met it
MK> does not come without presenting a situation whereby some users may
MK> find that they are blindly pinging a machine/host/server (which is
MK> it?) with:

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

Can you give a specific example illustrating these problems, so I can
fix their root causes?

Thanks
Ted