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

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

[MON KEY]

use of .authinfo.gpg implies auth-sources.el (or will soon)
auth-sources wants netrc.el per `auth-source-user-or-password'
netrc.el defines a var `netrc-services' that is hard bound to "/etc/services"

How is this going to remain secure/stable/reliable across platforms -
esp. going forward in lieu of emerging and recent new functionality
with auth-sources, epa, epg?

If netrc.el wants to hardwire the `netrc-services-file' he should be
mindful that not all systems have this path available - maybe a
defcustom is in order here?

It doesn't look like this oversight can pose an immediate problem
because where the `/etc/services' is missing netrc.el just ignores the
void... and quietly proceeds - still... is that a _good_ thing?

Why not just inline the entirety of /etc/services's  '("protocol"
"port" "comment") list in netrc.el and/or include that list of triples
in `../emac/etc/services_subst' as a fallback for users/systems which
either lack the file and/or don't have read permission.

{... Backstory:  i just spent a day and a half debugging a Gnutls bug
on a Gnu/Linux system b/c of the recent 2.6.X RSA/DSA snafu before i
was able to uncover the reason i was getting funny smtp errors while
configuring Gnus.  That said, it wasn't a total loss as I was
subsequently able to get both GnuPG and Gnutls working out of the box
on a w32 system... with more or less current binaries,  having grabbed
the recent w32 2.8.x builds my second time around. Thanks Simon
Josefsson et al for the fresh binaries :) ...}

s_P

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

[MON KEY]

Ted Zlatanov <tzz@lifelogs.com> writes:
> Yes, it lets people get stuff done.  It's not a security risk and does
> not behave in an unexpected way.  It can be augmented but the
>
> Ted

Some observations:

In "../emacs/lisp/gnus/auth-source.el" `auth-source-user-or-password'
When a match is made for MODE (e.g. user's login and password) it is
cached to the hashtable
`auth-source-cache' by default - the user must override this value if
this is not what is wanted.
This cache holds: login password | host port protocol as key/vals
with login and password obfuscated to (login password) respectively.

Additionally when a match is made `auth-source-user-or-password' spits out a
'gnus-message 9' indicating the a match has been made (with password
obfuscated).

docstring for `gnus-message' provides some guidelines for message levels:
"Guideline for numbers: {...} 9 - messages inside loops."

The `gnus-message' is printed when it exceeds the `gnus-verbose'
threshold (defaults to 7)
Which is to say, assuming the user has `gnus-util' library loaded and
his `gnus-verbose' level
set at or above level 9(nine) - he may see _gnus-message_ indicating
that the password/login has been cached
along with a timestamp _if_ `gnus-add-timestamp-to-message' it t.

Great! No Wait... any code that evaluates
`auth-source-user-or-password' directly has the value returned to
*Messages*
regardless of the `gnus-verbosity' levels. He _may not_ see those but
they may well be there anywasy

`../emacs/lisp/gnus/gnus-util.el' has one of these: (require 'netrc)


`../emacs/lisp/url/url-auth.el' has one of these:
(autoload 'auth-source-user-or-password "auth-source")

---
From `../emacs/lisp/url/ChangeLog':

2008-06-07  Glenn Morris  <rgm@gnu.org>

       * url-auth.el (auth-source-user-or-password): Remove unnecessary
       eval-and-compile.
-
2008-05-12  Teodor Zlatanov  <tzz@lifelogs.com>

       * url-auth.el: Add autoload cookie for `auth-source-user-or-password'.
       (url-basic-auth, url-digest-auth): Use it with any realm,
       overriding the user name and password before the prompt.

---
Also, re: my previous post:
> auth-sources wants netrc.el per `auth-source-user-or-password'

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

Alongside these really interesting autoloads:
(autoload 'encrypt-find-model "encrypt")
(autoload 'encrypt-insert-file-contents "encrypt")

What _are_ these?
---

An experiment:

(require 'auth-source)
(require 'epa-file)
(epa-file-enable)
(setq epa-file-cache-passphrase-for-symmetric-encryption t) ;;VERY Important

(if (= gnus-verbose 7)
 "Fine fine."
 (setq gnus-verbose 7))

auth-sources
;=>((:source "~/.authinfo.gpg" :host t :protocol t))

auth-source-cache
;=>#<hash-table 'equal nil 6/65 0x2dbb600>

;;;imagine a more varied alist formated with all 6(six) of my nice key->vals mapped out e.g.:
(stan-hash-get-symbol-keys auth-source-cache)
;=>("(login password) api.del.icio.us:443:https" 
   "(login password) api.del.icio.us:443:https"
   "(login password) api.del.icio.us:443:https" 
   "(login password) api.del.icio.us:443:https"
   "(login password) api.del.icio.us:443:https" 
   "(login password) api.del.icio.us:443:https")

(auth-source-forget-all-cached)
;=>#<hash-table 'equal nil 0/65 0x2f38d00>

(stan-hash-get-symbol-keys auth-source-cache)
;=>nil

(with-temp-file (expand-file-name "~/.my-authinfo.gpg")
(insert "machine api.del.icio.us:443 port https login my-del-icio-name password my-del-icio-pass"))

(setq auth-sources '((:source "~/.my-authinfo.gpg" :host t :protocol t)))
;=>((:source "~/.my-authinfo.gpg" :host t :protocol t))

auth-sources
;=>((:source "~/.my-authinfo.gpg" :host t :protocol t))

;;; With apologies to Thierry Volipatto's `anything-delicious.el'
;;; (URL `http://www.emacswiki.org/emacs/anything-delicious.el')
(defvar *show-my-anything-delicious-user* nil
 "Your Delicious login")
(defvar *show-my-anything-delicious-password* nil
 "Your Delicious password")

(defun delicious-authentify (path)
 "Authentify user from .my-authinfo.gpg file."
 (let ((anything-delicious-auth
        (auth-source-user-or-password  
	 '("login" "password")
	 "api.del.icio.us:443"
	 "https")))
   (setq *show-my-anything-delicious-user*
	 (car anything-delicious-auth))
   (setq *show-my-anything-delicious-password*
	 (cadr anything-delicious-auth))))

(delicious-authentify "~/.my-authinfo.gpg")
;=> ;message to mini-buffer
;; Cool it got set.

;_AND_:

(= gnus-verbose 7)

(let ((this-buffer (current-buffer)))
  (with-temp-buffer
    (delicious-authentify "~/.my-authinfo.gpg"))
  (save-excursion
    (progn
      (switch-to-buffer (get-buffer "*Messages*"))
      (search-forward-regexp "*show-my-anything-delicious-password*"))
    (sit-for 3))
  (switch-to-buffer this-buffer))

;Good search-failed

(stan-hash-get-symbol-keys auth-source-cache)
;=>("(login password) api.del.icio.us:443:https")

auth-source-cache
;=>#<hash-table 'equal nil 1/65 0x2dbb600>

;; Now

(= gnus-verbose 7)
;=> t

(let ((this-buffer (current-buffer)))
  (with-temp-buffer
    (print (delicious-authentify "~/.my-authinfo.gpg")))
 (save-excursion
   (progn
     (switch-to-buffer (get-buffer "*Messages*"))
     (goto-char (point-max))
     (search-backward-regexp "*show-my-anything-delicious-password*" nil t))
   (sit-for 3))
 (switch-to-buffer this-buffer))

;GREAaaaat... I feel so dirty...
;*show-my-anything-delicious-password*
;*show-my-anything-delicious-user*
;delicious-authentify
;"my-del-icio-pass"

(defun show-gnus-sf (&optional thresh)
 "Evaluate two strings for their side-effects using `gnus-message'.
Find each string in the '*Messages*' buffer and come back to home.
When non-nil THRESH sets `gnus-verbose' to >= 9
Else sets gnus-verbose to default custom level 7 evaluates body.
Resets gnus-verbose to users default after snarfage."
 (let ((this-buffer)
       (vb))
   (setq vb gnus-verbose)
   (setq this-buffer (get-buffer (current-buffer)))
   (unwind-protect
       (let ((sf1 "my 1st sleeper Gnus-message")
             (sf2 "my 2nd sleeper Gnus-message")
             (vb  ?\t))
         (with-temp-buffer
           (cond (thresh
                  (setq gnus-verbose vb)
                  (gnus-message ?\b sf1)
                  (gnus-message ?\b sf2))
                 (t (gnus-message ?\a sf1)
                    (gnus-message ?\a sf2))))
         (pop-to-buffer (get-buffer "*Messages*") t)
         (progn
           (goto-char (point-max))
           (when (search-backward-regexp sf1 nil t)
	     (message (format "Got %s at line %s in %s with GNUS-VERBOSE level @ %s"
                         sf1 (line-number-at-pos) (get-buffer (current-buffer)) vb)))
           (goto-char (point-max))
           (if (search-backward-regexp sf2 nil t)
	       (message (format "Got %s at line %s in %s with GNUS-VERBOSE level @ %s"
                           sf2 (line-number-at-pos) (get-buffer (current-buffer)) vb))
             (format "Nothing to see here folks, move along."))
                (sit-for 1)))
     (setq gnus-verbose vb))
     (pop-to-buffer this-buffer)
     (format "Finished snarfing gnus-messages. GNUS-VERBOSE back @ level %d. Thank You." vb)))

(show-gnus-sf)
(show-gnus-sf t)
;=>Why are those sleeper gnus-messages are hanging around in *Messages*?

(= gnus-verbose 7)
;=>t 

(progn
(unintern 'delicious-authentify)
(unintern '*show-my-anything-delicious-user*)
(unintern  '*show-my-anything-delicious-password*)
(auth-source-forget-all-cached)
(setq auth-sources nil))

-
s_P

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

[Ted Zlatanov]

On Tue, 9 Jun 2009 23:49:41 -0400 MON KEY <monkey@sandpframing.com> wrote: 

MK> use of .authinfo.gpg implies auth-sources.el (or will soon)
MK> auth-sources wants netrc.el per `auth-source-user-or-password'
MK> netrc.el defines a var `netrc-services' that is hard bound to "/etc/services"

MK> How is this going to remain secure/stable/reliable across platforms -
MK> esp. going forward in lieu of emerging and recent new functionality
MK> with auth-sources, epa, epg?

MK> If netrc.el wants to hardwire the `netrc-services-file' he should be
MK> mindful that not all systems have this path available - maybe a
MK> defcustom is in order here?

It makes sense to bundle some default service definitions with Emacs,
but allow overriding and lookups in external resources (files, etc.) as
well.  There's always the option of specifying the port as a number.
Also there are packages which have their own ideas about service ports,
e.g. from imap.el:

;; Internal constants.  Change these and die.

(defconst imap-default-port 143)
(defconst imap-default-ssl-port 993)
(defconst imap-default-tls-port 993)

or tramp.el:

    ("ssh"   (tramp-login-program        "ssh")
...
	     (tramp-default-port         22))


The place to put the service port definitions and API should probably be
a new .el file in Emacs, not netrc.el or auth-sources.el.  Then Emacs
packages can migrate to using the new API.  One of the Emacs maintainers
should give an opinion here, I don't have a strong one.

MK> It doesn't look like this oversight can pose an immediate problem
MK> because where the `/etc/services' is missing netrc.el just ignores the
MK> void... and quietly proceeds - still... is that a _good_ thing?

Yes, it lets people get stuff done.  It's not a security risk and does
not behave in an unexpected way.  It can be augmented but the
fundamental principle is sound: use the host OS's idea of service ports
if it's available.

Ted

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

[Ted Zlatanov]

On Wed, 10 Jun 2009 16:43:14 -0400 MON KEY <monkey@sandpframing.com> wrote: 

MK> Some observations:

I appreciate your thoughts, but please realize not everyone has an hour
to parse all your code.  If you have specific suggestions, please make
them directly and succinctly.  I've tried to answer what I could; please
follow up with questions implicit in your code that I have missed.

MK> docstring for `gnus-message' provides some guidelines for message levels:
MK> "Guideline for numbers: {...} 9 - messages inside loops."

MK> The `gnus-message' is printed when it exceeds the `gnus-verbose'
MK> threshold (defaults to 7)
MK> Which is to say, assuming the user has `gnus-util' library loaded and
MK> his `gnus-verbose' level
MK> set at or above level 9(nine) - he may see _gnus-message_ indicating
MK> that the password/login has been cached
MK> along with a timestamp _if_ `gnus-add-timestamp-to-message' it t.

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?

MK> Great! No Wait... any code that evaluates
MK> `auth-source-user-or-password' directly has the value returned to
MK> *Messages*
MK> regardless of the `gnus-verbosity' levels. He _may not_ see those but
MK> they may well be there anywasy

MK> `../emacs/lisp/gnus/gnus-util.el' has one of these: (require 'netrc)


MK> `../emacs/lisp/url/url-auth.el' has one of these:
MK> (autoload 'auth-source-user-or-password "auth-source")

Can you explain what the problem is, please?  Is there unwanted
information in the *Messages* buffer?

MK> Also, re: my previous post:
>> auth-sources wants netrc.el per `auth-source-user-or-password'

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.

MK> Alongside these really interesting autoloads:
MK> (autoload 'encrypt-find-model "encrypt")
MK> (autoload 'encrypt-insert-file-contents "encrypt")

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).

MK> An experiment:
...
MK> ;GREAaaaat... I feel so dirty...
...
MK> ;=>Why are those sleeper gnus-messages are hanging around in *Messages*?

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.

Thanks
Ted

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

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

[MON KEY]

> 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?

I've been thinking this over a bit more.
Following 2(two) defcustoms `imap-log' and `imap-debug' are from:
`../emacs/23.0.94/lisp/net/imap.el'

These seem like sensible implimentations which auth-sources might find
useful to reflect.
;;; ==============================

(defcustom imap-log nil
  "If non-nil, an imap session trace is placed in `imap-log-buffer'.
Note that username, passwords and other privacy sensitive
information (such as e-mail) may be stored in the buffer.
It is not written to disk, however.  Do not enable this
variable unless you are comfortable with that.

See also `imap-debug'."
  :group 'imap
  :type 'boolean)

(defcustom imap-debug nil
  "If non-nil, trace imap- functions into `imap-debug-buffer'.
Uses `trace-function-background', so you can turn it off with,
say, `untrace-all'.

Note that username, passwords and other privacy sensitive
information (such as e-mail) may be stored in the buffer.
It is not written to disk, however.  Do not enable this
variable unless you are comfortable with that.

This variable only takes effect when loading the `imap' library.
See also `imap-log'."
  :group 'imap
  :type 'boolean)

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

[Ted Zlatanov]

[-- Attachment #1: Type: text/plain, Size: 3902 bytes --]

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


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: auth-source.diff --]
[-- Type: text/x-diff, Size: 2838 bytes --]

diff --git a/lisp/gnus/auth-source.el b/lisp/gnus/auth-source.el
index 1bec08f..64166aa 100644
--- a/lisp/gnus/auth-source.el
+++ b/lisp/gnus/auth-source.el
@@ -100,6 +100,12 @@
   :version "23.1" ;; No Gnus
   :type `boolean)
 
+(defcustom auth-source-debug nil
+  "Whether auth-source should log debug messages."
+  :group 'auth-source
+  :version "23.1" ;; No Gnus
+  :type `boolean)
+
 (defcustom auth-sources '((:source "~/.authinfo.gpg" :host t :protocol t))
   "List of authentication sources.
 
@@ -137,6 +143,10 @@ Each entry is the authentication type with optional properties."
 ;; (auth-source-user-or-password-imap "password" "imap.myhost.com")
 ;; (auth-source-protocol-defaults 'imap)
 
+(defun auth-source-debug (&rest msg)
+  (when auth-source-debug
+    (apply 'message msg)))
+
 (defun auth-source-pick (host protocol &optional fallback)
   "Parse `auth-sources' for HOST, and PROTOCOL matches.
 
@@ -171,21 +181,21 @@ Returns fallback choices (where PROTOCOL or HOST are nil) with FALLBACK t."
 (defun auth-source-user-or-password (mode host protocol)
   "Find MODE (string or list of strings) matching HOST and PROTOCOL.
 MODE can be \"login\" or \"password\" for example."
-  (gnus-message 9
-		"auth-source-user-or-password: get %s for %s (%s)"
-		mode host protocol)
+  (auth-source-debug
+   "auth-source-user-or-password: get %s for %s (%s)"
+   mode host protocol)
   (let* ((listy (listp mode))
 	 (mode (if listy mode (list mode)))
 	 (cname (format "%s %s:%s" mode host protocol))
 	 (found (gethash cname auth-source-cache)))
     (if found
 	(progn
-	  (gnus-message 9
-			"auth-source-user-or-password: cached %s=%s for %s (%s)"
-			mode
-			;; don't show the password
-			(if (member "password" mode) "SECRET" found)
-			host protocol)
+	  (auth-source-debug
+	   "auth-source-user-or-password: cached %s=%s for %s (%s)"
+	   mode
+	   ;; don't show the password
+	   (if (and (member "password" mode) auth-source-hide-passwords) "SECRET" found)
+	   host protocol)
 	  found)
       (dolist (choice (auth-source-pick host protocol))
 	(setq found (netrc-machine-user-or-password
@@ -195,12 +205,12 @@ MODE can be \"login\" or \"password\" for example."
 		     (list (format "%s" protocol))
 		     (auth-source-protocol-defaults protocol)))
 	(when found
-	  (gnus-message 9
-			"auth-source-user-or-password: found %s=%s for %s (%s)"
-			mode
-			;; don't show the password
-			(if (member "password" mode) "SECRET" found)
-			host protocol)
+	  (auth-source-debug
+	   "auth-source-user-or-password: found %s=%s for %s (%s)"
+	   mode
+	   ;; don't show the password
+	   (if (and (member "password" mode) auth-source-hide-passwords) "SECRET" found)
+	   host protocol)
 	  (setq found (if listy found (car-safe found)))
 	  (when auth-source-do-cache
 	    (puthash cname found auth-source-cache)))

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

[MON KEY]

Ted Zlatanov <tzz@lifelogs.com> writes:

> I appreciate your suggestions very much.  I am just asking you to

No problem. Gladly.

> present them in a way that I can understand more readily.  From looking

This might be a problem.

> 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

I find that hard to believe. Does D. Armstrong have an 800#? 
I'll consider leaving a message next time :P

> them.  For reference, here's what M-x report-emacs-bug suggests:

This is not of itself a bug.

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

Sure. why not.

> 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.

See, as you say the issue at hand isn't of itself a bug. 

Ted, this 'time thing' is an entity of your concern and one to which I
don't subscribe.

Another possible approach might be not trying to save time by assuming
you know the answer before you understand the question.

> Your cleanup sets auth-sources to nil.  That would screw up my setup, at

No. 
Your setup would've been screwed when you failed to save state or
open a second session should that have been your primary concern. 

Setting auth-sources to nil was right proper and polite thing to do
given the context.

> least.  It's definitely not OK to just evaluate it; there were many

As you say. Not OK.

> other issues I don't have time to list and which are not really

If you knew Time as well as I do you wouldn't talk about wasting IT. 
It's HIM. 

> The patch is against Emacs CVS.  Let me know what you think.

Yes.

> 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.  

There you have it.

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

Please see my post elsewhere on this thread vis a vis imap.el

> Can you give a specific example illustrating these problems, so I can

I have. 

s_P

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

[Ted Zlatanov]

On Fri, 12 Jun 2009 17:05:04 -0400 MON KEY <monkey@sandpframing.com> wrote: 

MK> Please see my post elsewhere on this thread vis a vis imap.el

I don't think it's necessary to have the debugging facilities of
imap.el, because auth-source.el does not have so much external
interaction that needs to be debugged.  There's just three places where
messages are emitted right now.  Just auth-source-debug as a boolean,
logging to *Messages*, is sufficient, which my patch proposes.  Let me
know if you see any issues with the patch.

Thanks
Ted

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

[MON KEY]

Ted Zlatanov <tzz@lifelogs.com> writes:
>
> MK> Please see my post elsewhere on this thread vis a vis imap.el
>
> I don't think it's necessary to have the debugging facilities of
> imap.el, because auth-source.el does not have so much external

The langauge of those two defcustom forms is quite communicative re:
logging/debugging and do well to extend clarity when informing the user just
how much rope he has been given. IIWM I would adopt the same or similar
tone with any such revisions/additions made to auth-sources defcustom 
related docs.

> interaction that needs to be debugged.  There's just three places where
> messages are emitted right now.  Just auth-source-debug as a boolean,

Its not the amount (or lack thereof), but rather the manner in which the logging/debugging
occurs and _how_ the user is made aware of bot the existence of such
facilities and the potential pitfalls of their use.

> logging to *Messages*, is sufficient, which my patch proposes.  Let me
> know if you see any issues with the patch.

Still looking. I will follow up accordingly.

> Ted

s_P

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

[Ted Zlatanov]

On Sun, 14 Jun 2009 20:52:11 -0400 MON KEY <monkey@sandpframing.com> wrote: 

MK> Ted Zlatanov <tzz@lifelogs.com> writes:
>> 
MK> Please see my post elsewhere on this thread vis a vis imap.el
>> 
>> I don't think it's necessary to have the debugging facilities of
>> imap.el, because auth-source.el does not have so much external

MK> The langauge of those two defcustom forms is quite communicative re:
MK> logging/debugging and do well to extend clarity when informing the user just
MK> how much rope he has been given. IIWM I would adopt the same or similar
MK> tone with any such revisions/additions made to auth-sources defcustom 
MK> related docs.

You mean something like this, perhaps:

  "If non-nil, log the authentication tokens obtained by auth-source
into `*Messages*'.

Note that username, passwords and other privacy sensitive information
may be stored in the *Messages* buffer.  It is not written to disk, but
it is visible to all Emacs code and some other attacks (depending on
your OS).  Do not enable this variable unless you are comfortable with
that.  Also see `auth-source-hide-passwords'."

(BTW, auth-source-hide-passwords defaults to t and does what you'd
expect)

I think more information should be in the documentation (auth.texi) and
not in the variable docstrings, but a more verbose explanation is
definitely a good thing.

>> interaction that needs to be debugged.  There's just three places where
>> messages are emitted right now.  Just auth-source-debug as a boolean,

MK> Its not the amount (or lack thereof), but rather the manner in which
MK> the logging/debugging occurs and _how_ the user is made aware of bot
MK> the existence of such facilities and the potential pitfalls of their
MK> use.

auth-source.el is only relevant if the user has configured
`auth-sources' explicitly or has an ~/.authinfo.gpg file (AFAIK this
file is not a convention for any other package within or outside Emacs).
I think this mitigates the security risk significantly, because the user
has to be aware of auth-source.el in order to use it.  Note also my
patch disables auth-source.el logging by default.

Ted