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
next prev parent 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).