Gnus development mailing list
 help / color / mirror / Atom feed
From: Ted Zlatanov <tzz@lifelogs.com>
To: emacs-devel@gnu.org
Cc: Ding Mailing List <ding@gnus.org>
Subject: Re: authinfo gnutls netrc.el auth-sources & smtpmail-starttls-credentials
Date: Wed, 10 Jun 2009 16:18:38 -0500	[thread overview]
Message-ID: <87prdblrdd.fsf@lifelogs.com> (raw)
In-Reply-To: <d2afcfda0906092049j15164c5h4c7219dc6cb79b18@mail.gmail.com>

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





       reply	other threads:[~2009-06-10 21:18 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <d2afcfda0906092049j15164c5h4c7219dc6cb79b18@mail.gmail.com>
2009-06-10 21:18 ` Ted Zlatanov [this message]
     [not found]   ` <87zlcf2525.fsf@sandpframing.com>
2009-06-11 14:39     ` Ted Zlatanov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87prdblrdd.fsf@lifelogs.com \
    --to=tzz@lifelogs.com \
    --cc=ding@gnus.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).