From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: MON KEY Newsgroups: gmane.emacs.devel Subject: Re: authinfo gnutls netrc.el auth-sources & smtpmail-starttls-credentials Date: Thu, 11 Jun 2009 19:44:37 -0400 Message-ID: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1244763892 7395 80.91.229.12 (11 Jun 2009 23:44:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 11 Jun 2009 23:44:52 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jun 12 01:44:50 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MEtwv-0001Af-FR for ged-emacs-devel@m.gmane.org; Fri, 12 Jun 2009 01:44:49 +0200 Original-Received: from localhost ([127.0.0.1]:48603 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MEtwu-0001pk-TT for ged-emacs-devel@m.gmane.org; Thu, 11 Jun 2009 19:44:48 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MEtwp-0001lb-RE for emacs-devel@gnu.org; Thu, 11 Jun 2009 19:44:43 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MEtwl-0001gj-7q for emacs-devel@gnu.org; Thu, 11 Jun 2009 19:44:43 -0400 Original-Received: from [199.232.76.173] (port=33209 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MEtwl-0001gd-1w for emacs-devel@gnu.org; Thu, 11 Jun 2009 19:44:39 -0400 Original-Received: from mail-yx0-f190.google.com ([209.85.210.190]:60288) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MEtwk-0006lw-O4 for emacs-devel@gnu.org; Thu, 11 Jun 2009 19:44:38 -0400 Original-Received: by yxe28 with SMTP id 28so8322yxe.24 for ; Thu, 11 Jun 2009 16:44:37 -0700 (PDT) Original-Received: by 10.151.125.12 with SMTP id c12mr6167029ybn.202.1244763877875; Thu, 11 Jun 2009 16:44:37 -0700 (PDT) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:111440 Archived-At: > 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