Gnus development mailing list
 help / color / mirror / Atom feed
From: Daiki Ueno <ueno@unixuser.org>
To: Ted Zlatanov <tzz@lifelogs.com>
Cc: ding@gnus.org
Subject: Re: auth-sources asking for password 2 or 3 times
Date: Wed, 23 Feb 2011 16:20:48 +0900	[thread overview]
Message-ID: <m3y657xlm7.fsf-ueno@unixuser.org> (raw)
In-Reply-To: <87mxln1nqc.fsf@lifelogs.com> (Ted Zlatanov's message of "Tue, 22 Feb 2011 20:36:11 -0600")

Ted Zlatanov <tzz@lifelogs.com> writes:

> DU> Why auth-source/netrc tries to visit ~/.authinfo.gpg multiple times even
> DU> for only one connection?  My guess is that, auth-source/netrc tries to
> DU> open that file for each parameter (e.g. user, host, port, password),
> DU> right?  If so, it looks to me superfluous, since user/host/port are
> DU> generally not a secret information.
>
> I don't think that's the case, at least not anymore (I changed quite a
> bit today).

Then, that's good.  I will try later.

> DU> How about splitting ~/.authinfo.gpg into 2 files, one is for non-secret
> DU> information and another is for secret information?  The non-secret file
> DU> would be a plain text compatible with netrc, while the secret file would
> DU> be encrypted and the decrypted content is a simple 1:1 mapping from ID
> DU> (auth-source token?) to password.
>
> That's exactly why `auth-sources' defaults to the list "~/.authinfo.gpg"
> "~/.authinfo" "~/.netrc".  I'm not sure why I'd make the encrypted file
> in a different format, though.  That would make it hard to move entries
> between the two formats and would confuse users.  Can you explain if I
> misunderstood?

I agree with that it might be hard for users to maintain two files.

However, you seem to be missing the point of my idea, FWIW, here is the
detail:

If auth-source.el looks for several parameters (say,
user/host/port/password) to establish a connection, it needs to decrypt
~/.authinfo.gpg (at least) 4 times if cache is disabled (right?).

However, if we store user/host/port/token in a plain text file (say,
~/.netrc), and store token/password mapping in an encrypted file (say,
~/.passwords.gpg), auth-source.el needs to decrypt the latter file only
once.

In other words, my idea is to delay decryption until password is really
necessary.  This is useful when accessing password-less news servers
(e.g. gmane).  Currently, if I start Gnus with M-x gnus-no-server and
open news.gmane.org, it asks a password for ~/.authinfo.gpg.

> Don't forget auth-source.el supports the Secrets API as well, which has
> a completely different way to search and expand results.  I'll work on
> the 'secrets backend to make it connect with Chrome password entries,
> for instance.

After brief look at the secrets API, it also seems to consider lookup
attributes as non-secret information, and only passwords have to be
encrypted on the disk.

Regards,
-- 
Daiki Ueno



  reply	other threads:[~2011-02-23  7:20 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-20 18:19 Sivaram Neelakantan
2011-02-21  1:27 ` Lars Ingebrigtsen
2011-02-21  1:35   ` Lars Ingebrigtsen
2011-02-22 22:03     ` Ted Zlatanov
2011-02-23  2:14       ` Daiki Ueno
2011-02-23  2:36         ` Ted Zlatanov
2011-02-23  7:20           ` Daiki Ueno [this message]
2011-02-23  8:40             ` Lars Ingebrigtsen
2011-02-23 12:25               ` Daiki Ueno
2011-02-23 14:58                 ` Ted Zlatanov
2011-02-25  4:35                   ` Lars Ingebrigtsen
2011-02-25  7:17                     ` Daiki Ueno
2011-02-25 14:40                       ` Michael Albinus
2011-02-26  0:49                         ` Daiki Ueno
2011-02-26  8:59                           ` Michael Albinus
2011-02-26  9:24                             ` Daiki Ueno
2011-02-25 14:43                       ` Ted Zlatanov
2011-02-23 14:54             ` Ted Zlatanov
2011-02-23  8:36       ` Lars Ingebrigtsen

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=m3y657xlm7.fsf-ueno@unixuser.org \
    --to=ueno@unixuser.org \
    --cc=ding@gnus.org \
    --cc=tzz@lifelogs.com \
    /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).