authinfo/netrc file encryption status -- GnuPG

authinfo/netrc file encryption status -- GnuPG

[Steven E.Harris]

Back in January, we had a round of discussion about adding encryption
support of authinfo files. That discussion then generalized into
adding encryption support for any type using a set of encryption tools
such as GnuPG and OpenSSL.¹

In May, Ted Zlanatov posted gnus-encrypt.el.² I just noticed that this
file is still not part of Gnus in CVS. What's the status on this
integration? Should I grab gnu-encrypt.el and start testing it, or has
it been superseded by some other effort?

My main interest is in encrypting ~/.authinfo with gpg using a
symmetric cipher. I recall that Ted had this working, but lost track
of why the code hasn't yet become a blessed part of Gnus.


Footnotes: 
¹ http://groups.google.com/groups?threadm=4n3caut1yy.fsf%40collins.bwh.harvard.edu
² http://thread.gmane.org/gmane.emacs.gnus.general/57432

-- 
Steven E. Harris

Re: authinfo/netrc file encryption status -- GnuPG

[Ted Zlatanov]

On Wed, 21 Jul 2004, seh@panix.com wrote:

> Back in January, we had a round of discussion about adding encryption
> support of authinfo files. That discussion then generalized into
> adding encryption support for any type using a set of encryption tools
> such as GnuPG and OpenSSL.¹
> 
> In May, Ted Zlanatov posted gnus-encrypt.el.² I just noticed that this
> file is still not part of Gnus in CVS. What's the status on this
> integration? Should I grab gnu-encrypt.el and start testing it, or has
> it been superseded by some other effort?
> 
> My main interest is in encrypting ~/.authinfo with gpg using a
> symmetric cipher. I recall that Ted had this working, but lost track
> of why the code hasn't yet become a blessed part of Gnus.

The current gnus-encrypt.el is attached.  I have plans to write
gencrypt.el which will do a lot more, and will involve changes to
gnus-encrypt.el, but by that time gnus-encrypt.el will be in CVS
anyhow.  So take a look and let me know if it works for you as it
is.  Just call the functions gnus-encrypt-insert-file-contents and
gnus-encrypt-write-file-contents directly after customizing
gnus-encrypt-file-alist.

As of now, netrc.el also has encryption support with OpenSSL, which
will be removed once gnus-encrypt.el is in place.  So don't use that.

The BIG delay, by the way, was because nothing in Emacs was allowed
to contain crypto code or even call crypto software.  That has been
resolved as of May 2004, so gnus-encrypt.el should be OK for
inclusion if people are happy with it.  I meant to work on
gnus-encrypt.el back then but have been too busy - so if anyone wants
to help, they're welcome to it.

Thanks
Ted

Re: authinfo/netrc file encryption status -- GnuPG

[Steven E. Harris]

"Ted Zlatanov" <tzz@lifelogs.com> writes:

> The current gnus-encrypt.el is attached.

I don't see an attachment with your post. Can you please post your
latest gnus-encrypt.el again?

-- 
Steven E. Harris

Re: authinfo/netrc file encryption status -- GnuPG

[Ted Zlatanov]

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

On Fri, 23 Jul 2004, seh@panix.com wrote:

> "Ted Zlatanov" <tzz@lifelogs.com> writes:
> 
>> The current gnus-encrypt.el is attached.
> 
> I don't see an attachment with your post. Can you please post your
> latest gnus-encrypt.el again?

Sorry.

Ted


[-- Attachment #2: gnus-encrypt.el --]
[-- Type: application/emacs-lisp, Size: 8546 bytes --]

Re: authinfo/netrc file encryption status -- GnuPG

[Steven E. Harris]

"Ted Zlatanov" <tzz@lifelogs.com> writes:

> The current gnus-encrypt.el is attached.

Thanks.

> So take a look and let me know if it works for you as it is.

So far, I noticed that `make-temp-file' (used in
gnus-encrypt-gpg-process-buffer) does not exist in XEmacs. I used
`make-temp-name' instead.

> Just call the functions gnus-encrypt-insert-file-contents and
> gnus-encrypt-write-file-contents directly after customizing
> gnus-encrypt-file-alist.

I don't understand. Is this encryption stuff not hooked into Gnus in
any way? That might explain my experience with it so far.

I encrypted my .authinfo file using gnus-encrypt-write-file-contents
(gpg, AES), but when I then fire up Gnus I don't get prompted for a
password, and Gnus can't read the file.

I used the Customize interface to add an entry to
gnus-encrypt-file-alist, which wound up looking like this:

  (("/home/sharris/.authinfo" (gpg "AES")))

Note that the gpg and cipher specification are in a nested list, which
differs from the example alist:

  '(("/home/tzz/alpha" gpg "AES") ; GPG on single file
    ;; xor encryption on all files matching "beta"
    ("beta" gnus-encrypt-xor "Semi-Secret"))

I tried redefining gnus-encrypt-file-alist like so

  (("/home/sharris/.authinfo" gpg "AES"))

but Gnus still fails to take notice of it.

[...]

> I meant to work on gnus-encrypt.el back then but have been too busy
> - so if anyone wants to help, they're welcome to it.

I can certainly help to test it.

-- 
Steven E. Harris

Re: authinfo/netrc file encryption status -- GnuPG

[Ted Zlatanov]

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

On Fri, 23 Jul 2004, seh@panix.com wrote:

> So far, I noticed that `make-temp-file' (used in
> gnus-encrypt-gpg-process-buffer) does not exist in XEmacs. I used
> `make-temp-name' instead.

I don't use XEmacs, so thanks for catching that.  Can I get your
changes as a patch?  If it's trivial don't worry about it.

>> Just call the functions gnus-encrypt-insert-file-contents and
>> gnus-encrypt-write-file-contents directly after customizing
>> gnus-encrypt-file-alist.
> 
> I don't understand. Is this encryption stuff not hooked into Gnus in
> any way? That might explain my experience with it so far.

No.  netrc.el has temporary encryption support right now, but don't
use it.  I just wanted you to test the gnus-encrypt.el functions on
their own and see if they work reliably for you.

> I encrypted my .authinfo file using gnus-encrypt-write-file-contents
> (gpg, AES), but when I then fire up Gnus I don't get prompted for a
> password, and Gnus can't read the file.
> 
> I used the Customize interface to add an entry to
> gnus-encrypt-file-alist, which wound up looking like this:
> 
>   (("/home/sharris/.authinfo" (gpg "AES")))
> 
> Note that the gpg and cipher specification are in a nested list, which
> differs from the example alist:
> 
>   '(("/home/tzz/alpha" gpg "AES") ; GPG on single file
>     ;; xor encryption on all files matching "beta"
>     ("beta" gnus-encrypt-xor "Semi-Secret"))

See attached new version, I think that's OK now.

So test the internal gnus-encrypt.el functions again, and if they work
OK for you I'll add them to netrc.el so they're used automatically
(based on the gnus-encrupt-file-alist contents).

Ted


[-- Attachment #2: gnus-encrypt.el --]
[-- Type: application/emacs-lisp, Size: 8459 bytes --]

Re: authinfo/netrc file encryption status -- GnuPG

[Steven E. Harris]

"Ted Zlatanov" <tzz@lifelogs.com> writes:

> I don't use XEmacs, so thanks for catching that.  Can I get your
> changes as a patch?  If it's trivial don't worry about it.

It's just that one function name swap: `make-temp-name' rather than
`make-temp-file'. I'm not sure how you'd prefer to make that
conditional.

> I just wanted you to test the gnus-encrypt.el functions on their own
> and see if they work reliably for you.

So far I've just tested them using gpg with AES, and the
encrypt/decrypt functions work mostly as expected. I'm not sure why
the "current buffer" can't be read-only when calling
`gnus-encrypt-write-file-contents', though:

,----[ Encrypting a read-only buffer ]
| Signaling: (buffer-read-only #<buffer "new">)
|   delete-region(1 158)
|   (progn (delete-region (point-min) (point-max)) (goto-char (point-min)) (when passphrase (insert passphrase "\n")) (insert input) (setq exit-status (apply ... ... ... program t ... nil args)) (unless (equal exit-status 0) (setq exit-status nil) (when undo-if-error ... ... ...) (with-temp-buffer ... ...)))
|   (if program (progn (delete-region ... ...) (goto-char ...) (when passphrase ...) (insert input) (setq exit-status ...) (unless ... ... ... ...)) (gnus-error 5 "GPG is not installed."))
|   (let ((program gnus-encrypt-gpg-path) (old-buffer-string ...) (input ...) (temp-file ...) (default-enable-multibyte-characters nil) (args ...) exit-status) (when encode (setq args ...)) (if program (progn ... ... ... ... ... ...) (gnus-error 5 "GPG is not installed.")) exit-status)
|   gnus-encrypt-gpg-process-buffer("xxx" "AES" t t)
|   gnus-encrypt-gpg-encode-buffer("xxx" "AES" t)
|   (setq status-ok (gnus-encrypt-gpg-encode-buffer passphrase cipher t))
|   (cond ((eq method ...) (setq status-ok ...)) ((eq method ...) (setq status-ok ...)))
|   (let* ((model ...) (method ...) (cipher ...) (contents ...) (passphrase ...) status-ok) (cond (... ...) (... ...)) (if status-ok (gnus-message 9 "%s was encrypted with %s (cipher %s)" file ... cipher) (gnus-error 5 "%s was NOT encrypted with %s (cipher %s)" file ... cipher)) (write-file file nil))
|   gnus-encrypt-write-file-contents("~/.authinfo")
|   eval((gnus-encrypt-write-file-contents "~/.authinfo"))
|   edit-and-eval-command("Redo: " (toggle-debug-on-error nil) (command-history . 1))
|   repeat-complex-command(1)
|   call-interactively(repeat-complex-command)
`----

> See attached new version, I think that's OK now.

Yes, that looks more consistent now.

> So test the internal gnus-encrypt.el functions again, and if they
> work OK for you I'll add them to netrc.el so they're used
> automatically (based on the gnus-encrupt-file-alist contents).

They do work as advertised. Please let me know when you'd like me to
try out the netrc.el integration.

-- 
Steven E. Harris

Re: authinfo/netrc file encryption status -- GnuPG

[Ted Zlatanov]

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

On Tue, 27 Jul 2004, seh@panix.com wrote:

> "Ted Zlatanov" <tzz@lifelogs.com> writes:
> 
>> I don't use XEmacs, so thanks for catching that.  Can I get your
>> changes as a patch?  If it's trivial don't worry about it.
> 
> It's just that one function name swap: `make-temp-name' rather than
> `make-temp-file'. I'm not sure how you'd prefer to make that
> conditional.

According to the Emacs docs you should use make-temp-file for safety,
but I'll go with make-temp-name for simplicity because I don't expect
the risk from it to be significant (I remove the temp file afterwards
in any case).  If anyone disagrees, let me know.

>> I just wanted you to test the gnus-encrypt.el functions on their own
>> and see if they work reliably for you.
> 
> So far I've just tested them using gpg with AES, and the
> encrypt/decrypt functions work mostly as expected. I'm not sure why
> the "current buffer" can't be read-only when calling
> `gnus-encrypt-write-file-contents', though:

I've changed the code to do the right thing, I think (at the expense
of passing around potentially large buffer substrings, but I expect
this code to be used for small files).  Can you test it again
please?  Once we're both OK with the code, I'll add the netrc.el hooks.

Thanks
Ted


[-- Attachment #2: gnus-encrypt.el --]
[-- Type: application/emacs-lisp, Size: 8379 bytes --]

Re: authinfo/netrc file encryption status -- GnuPG

[Jeremy Maitin-Shepard]

"Ted Zlatanov" <tzz@lifelogs.com> writes:

> [snip]

> According to the Emacs docs you should use make-temp-file for safety,
> but I'll go with make-temp-name for simplicity because I don't expect
> the risk from it to be significant (I remove the temp file afterwards
> in any case).  If anyone disagrees, let me know.

Since there is a security risk in using `make-temp-name', perhaps
consider using `make-temp-name' only when `make-temp-file' is
unavailable, perhaps by defining `make-temp-file' for XEmacs in
gnus-xmas.el.

> [snip]

-- 
Jeremy Maitin-Shepard

Re: authinfo/netrc file encryption status -- GnuPG

[Ted Zlatanov]

On Mon, 02 Aug 2004, jbms@attbi.com wrote:

> Since there is a security risk in using `make-temp-name', perhaps
> consider using `make-temp-name' only when `make-temp-file' is
> unavailable, perhaps by defining `make-temp-file' for XEmacs in
> gnus-xmas.el.

OK.  Done in gnus-encrypt.el without gnus-xmas.el, because the code
may move to gencrypt.el later so I don't want it to depend on other
Gnus pieces too much.

Ted

Re: authinfo/netrc file encryption status -- GnuPG

[Ted Zlatanov]

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

The specific tests you did were fine, my code wasn't.  Sorry for the
bugs.

Here's the latest gnus-encrypt.el and a working netrc.el that will do
the right thing if there's an encryption model associated with a
file.  I tested them, let me know if you get good results too.

At the end of gnus-encrypt.el is the old netrc.el code that supported
OpenSSL.  I'll enable that as well later, for now GPG is the only
choice for external encryption.

Ted


[-- Attachment #2: gnus-encrypt.el --]
[-- Type: application/emacs-lisp, Size: 11484 bytes --]

[-- Attachment #3: netrc.el --]
[-- Type: application/emacs-lisp, Size: 5770 bytes --]

Re: authinfo/netrc file encryption status -- GnuPG

[Steven E. Harris]

"Ted Zlatanov" <tzz@lifelogs.com> writes:

> I tested them, let me know if you get good results too.

It almost works as expected, but for one annoyance. I have four
servers listed in my .authinfo file. When I start Gnus, I get asked
for the decryption password six or seven times as various connections
get opened, despite having gnus-encrypt-password-cache-expiry set to
120. Shouldn't I only be asked for my decryption password once? Surely
something must be wrong, for it would be easier to type four different
passwords than to type a single on seven times.

Related questions:
o Does Gnus really reparse ~/.authinfo every time a connection gets
  opened?
o Could Gnus cache the decrypted ~/.authinfo data to avoid running gpg
  so many times?

-- 
Steven E. Harris

authinfo encryption through netrc.el works now (was: authinfo/netrc file encryption status -- GnuPG)

[Ted Zlatanov]

On Tue, 03 Aug 2004, seh@panix.com wrote:

> "Ted Zlatanov" <tzz@lifelogs.com> writes:
> 
>> I tested them, let me know if you get good results too.
> 
> It almost works as expected, but for one annoyance. I have four
> servers listed in my .authinfo file. When I start Gnus, I get asked
> for the decryption password six or seven times as various connections
> get opened, despite having gnus-encrypt-password-cache-expiry set to
> 120. Shouldn't I only be asked for my decryption password once? Surely
> something must be wrong, for it would be easier to type four different
> passwords than to type a single on seven times.

I was doing the caching wrong, it's fixed.  All the code is in CVS
now, including the netrc.el changes (they won't do anything if you
don't have gnus-encrypt-file-alist set).

I also made gnus-encrypt-password-cache-expiry be a trigger for
password-cache-expiry, meaning that setting the former automatically
sets the latter.  If this is incorrect, please let me know.

> Related questions:
> o Does Gnus really reparse ~/.authinfo every time a connection gets
>   opened?

I don't know.  Based on your experience, probably yes.

> o Could Gnus cache the decrypted ~/.authinfo data to avoid running gpg so many
> 	times?

Sure, but is that worth the trouble?  It's a small amount of data and
the file could change, so you need to not only cache but also
remember the last mtime of the file you're caching.

Thanks
Ted

Re: authinfo encryption through netrc.el works now

[Simon Josefsson]

> +(defun password-read-and-add (prompt &optional key)
> +  "Read password, for use with KEY, from user, or from cache if wanted.
> +Then store the password in the cache.  Uses `password-read' and
> +`password-cache-add'."
> +  (let ((password (password-read prompt key)))
> +    (when (and password key)
> +      (password-cache-add key password))
> +    password))

FWIW:

The point of separating reading the password and caching it, was that
code using password.el would typically look like:

1. Read password.
2. Try to authenticate against server, invoke GPG using the password, etc.
3. If authentication failed, goto 1.
4. Cache the password.

If the password is cached directly, and if the user type the wrong
password, that logic wouldn't work, and it would infloop steps 1, 2,
and 3.

I realize that perhaps a better logic would be:

1. Read and cache password.
2. Try to authenticate against server, invoke GPG using the password, etc.
3. If authentication failed, clear password, and goto 1.

And if the gnus-encrypt/netrc stuff use this logic, then fine, and
ignore this message.

Re: authinfo encryption through netrc.el works now

[Ted Zlatanov]

On Wed, 04 Aug 2004, jas@extundo.com wrote:

> The point of separating reading the password and caching it, was that
> code using password.el would typically look like:
> 
> 1. Read password.
> 2. Try to authenticate against server, invoke GPG using the password, etc.
> 3. If authentication failed, goto 1.
> 4. Cache the password.
> 
> If the password is cached directly, and if the user type the wrong
> password, that logic wouldn't work, and it would infloop steps 1, 2,
> and 3.
> 
> I realize that perhaps a better logic would be:
> 
> 1. Read and cache password.
> 2. Try to authenticate against server, invoke GPG using the password, etc.
> 3. If authentication failed, clear password, and goto 1.
> 
> And if the gnus-encrypt/netrc stuff use this logic, then fine, and
> ignore this message.

It doesn't, thanks for catching this potentially annoying bug.  I'll
work on fixing it - unfortunately there's no easy way right now in
gnus-encrypt to catch all the failure modes when decrypting so that's
where I will concentrate.

Another thing I'll do is to use the cipher + the file name as
password key.  Right now all the GPG+AES encrypted files will be
forced to use the same password.

Thanks!
Ted

Re: authinfo encryption through netrc.el works now

[Ted Zlatanov]

On 5 Aug 2004, tzz@lifelogs.com wrote:

On Wed, 04 Aug 2004, jas@extundo.com wrote:

>> If the password is cached directly, and if the user type the wrong
>> password, that logic wouldn't work, and it would infloop steps 1, 2,
>> and 3.

We're decoding a file, not connecting to the server - this is a lower
level of interaction.  I now remove failed *encryption* passwords, but
I can't (and shouldn't) care what happens with the contents of the
files once they are decoded.  So, I think, the right things will
happen now.

> Another thing I'll do is to use the cipher + the file name as
> password key.  Right now all the GPG+AES encrypted files will be
> forced to use the same password.

This is done, the file name is now a part of the key.  Should I call
expand-file-name or should I consider ~/FILE and /home/USER/FILE
fundamentally different?

Ted

Re: authinfo encryption through netrc.el works now

[Simon Josefsson]

"Ted Zlatanov" <tzz@lifelogs.com> writes:

> On 5 Aug 2004, tzz@lifelogs.com wrote:
>
> On Wed, 04 Aug 2004, jas@extundo.com wrote:
>
>>> If the password is cached directly, and if the user type the wrong
>>> password, that logic wouldn't work, and it would infloop steps 1, 2,
>>> and 3.
>
> We're decoding a file, not connecting to the server - this is a lower
> level of interaction.  I now remove failed *encryption* passwords, but
> I can't (and shouldn't) care what happens with the contents of the
> files once they are decoded.  So, I think, the right things will
> happen now.

Yup.  Handling bad passwords read from .authinfo should be taken care
of by the code using the password.

Re: authinfo encryption through netrc.el works now

[Steven E. Harris]

"Ted Zlatanov" <tzz@lifelogs.com> writes:

> I was doing the caching wrong, it's fixed.  All the code is in CVS
> now, including the netrc.el changes (they won't do anything if you
> don't have gnus-encrypt-file-alist set).

I rebuilt Gnus from CVS and can confirm that using an encrypted
.authinfo file works as promised. I only get asked for my password
once and Gnus authenticates with all servers automatically.

> I also made gnus-encrypt-password-cache-expiry be a trigger for
> password-cache-expiry, meaning that setting the former automatically
> sets the latter.  If this is incorrect, please let me know.

One observation: Exiting Gnus seems to clear the password cache. Is
that intentional? If so, could it be optional? I sometimes quit Gnus
then restart it again soon afterward. I would have expected my
encryption password to be cached even when Gnus is not running.

Thanks again for your continued effort.

-- 
Steven E. Harris

Re: authinfo encryption through netrc.el works now

[Ted Zlatanov]

On Wed, 04 Aug 2004, seh@panix.com wrote:

> I rebuilt Gnus from CVS and can confirm that using an encrypted
> .authinfo file works as promised. I only get asked for my password
> once and Gnus authenticates with all servers automatically.

I have to follow up on Simon's message about this, but I think the
situation is pretty stable as of now and you shouldn't expect the
netrc.el - gnus-encrypt.el interface to change significantly any time
soon.

> One observation: Exiting Gnus seems to clear the password cache. Is
> that intentional? 

Yes, absolutely.

> If so, could it be optional?

No.  The whole point is to hide information from people who can read
your files by using a "master" password based on the cipher used.  If
we store the password cache in a persistent file, that file can be
read.  There are ways around this but no easy ones (you can do things
like use ssh-agent or hardware encryption).  In the end, you need to
prove it's you and no one else running that second instance of Gnus.

Ted

Re: authinfo encryption through netrc.el works now

[Steven E. Harris]

"Ted Zlatanov" <tzz@lifelogs.com> writes:

> If we store the password cache in a persistent file, that file can
> be read.

I didn't mean to store the password in a persistent file. I just meant
to keep in around in memory between Gnus sessions, so long as the
password expiry timeout hasn't been reached.

When I said that I exit Gnus, I didn't mean that I exit XEmacs. I just
exit Gnus every so often (for a variety of reasons) but leave XEmacs
running. Sometimes I connect to one IMAP server, check my mail, then
exit again, and then immediately realize that I forgot to look at a
different message. So start up Gnus again -- and have to type my
password again.

> There are ways around this but no easy ones (you can do things like
> use ssh-agent or hardware encryption).

Yes, I use ssh-agent and keychain for my ssh keys. That's more the
behavior I was expecting out of the password cache.

-- 
Steven E. Harris

Re: authinfo encryption through netrc.el works now

[Ted Zlatanov]

On Thu, 05 Aug 2004, seh@panix.com wrote:

> "Ted Zlatanov" <tzz@lifelogs.com> writes:
> 
>> If we store the password cache in a persistent file, that file can
>> be read.
> 
> I didn't mean to store the password in a persistent file. I just meant
> to keep in around in memory between Gnus sessions, so long as the
> password expiry timeout hasn't been reached.

Sorry, I always use Gnus in a separate Emacs session and wasn't thinking.

> So start up Gnus again -- and have to type my password again.

I don't know why the password cache is getting cleared.  We have

(defvar password-data (make-vector 7 0))

in password.el; I thought this would not get cleared on a subsequent
load of the password.el package.  Maybe Simon will comment.

Ted

Re: authinfo encryption through netrc.el works now

[Simon Josefsson]

"Ted Zlatanov" <tzz@lifelogs.com> writes:

>> So start up Gnus again -- and have to type my password again.
>
> I don't know why the password cache is getting cleared.  We have
>
> (defvar password-data (make-vector 7 0))
>
> in password.el; I thought this would not get cleared on a subsequent
> load of the password.el package.  Maybe Simon will comment.

Perhaps the password simply expired.  IIRC, Steven said he used an
expire timer for 10 minutes, so by the time Gnus is restarted, perhaps
more than 10 minutes has expired.

The default password cache life length is 16 seconds, which IMHO
doesn't make much sense but it has been discussed before.  Try:

 (setq password-cache-expiry 47114711)
 (setq pgg-passphrase-cache-expiry 47114711)

Perhaps the password cache could include logic differentiate among
passwords, so that users may choice that IMAP/SMTP passwords are kept
around in memory forever, but OpenPGP passwords are remembered for 5
minutes, or something.  I've thought about adding a "Use cached
password? (y or n)" query as well, which is another thing that I'd
want for OpenPGP passwords but not for IMAP/SMTP passwords.

Re: authinfo encryption through netrc.el works now

[Ted Zlatanov]

On Fri, 06 Aug 2004, jas@extundo.com wrote:

> The default password cache life length is 16 seconds, which IMHO
> doesn't make much sense but it has been discussed before.  Try:
> 
>  (setq password-cache-expiry 47114711)
>  (setq pgg-passphrase-cache-expiry 47114711)

Shouldn't nil be acceptable as 'never'?

> Perhaps the password cache could include logic differentiate among
> passwords, so that users may choice that IMAP/SMTP passwords are kept
> around in memory forever, but OpenPGP passwords are remembered for 5
> minutes, or something.  I've thought about adding a "Use cached
> password? (y or n)" query as well, which is another thing that I'd
> want for OpenPGP passwords but not for IMAP/SMTP passwords.

It should be easy to base that on the key name and build a more
complex password-cache-expiry structure with customize.  I wouldn't
use it personally, I like simplicity :)

Ted

Re: authinfo/netrc file encryption status -- GnuPG

[Steven E. Harris]

"Ted Zlatanov" <tzz@lifelogs.com> writes:

> I tested them, let me know if you get good results too.

More feedback after using the updates for most of the day: I now need
to type my .authinfo decryption password more often than I used to
have to type the individual server passwords.

I have gnus-encrypt-password-cache-expiry set to 600, or ten
minutes. Now, whenever I contact a server that I haven't exchanged
data with for ten minutes, Gnus prompts me for my decryption
password. Without an encrypted .authinfo -- one missing the password
specifications to begin with -- Gnus will only prompt me for a
password if the server has disconnected, and even then Gnus still
seems to cache the passwords until I close a server manually.

The distinction here is that with an encrypted .authinfo, expiration
of the password cache seems to cause Gnus to think that it needs to
re-authenticate, even if it's not necessary with an .authinfo missing
passwords altogether.

Of course my descriptions involve a lot of hand-waving because I don't
know how Gnus actually handles server disconnects and authentication
requests. I'm just comparing against the "normal" behavior I've grown
accustomed to over the last few years.

Summarizing: With no passwords in a non-encrypted .authinfo file, I
type a password for each server each time I start Gnus, and I usually
don't have to repeat that password until I exit and restart Gnus. With
passwords in an encrypted .authinfo file, I have to type the
decryption password every gnus-encrypt-password-cache-expiry period.

Is that the expected behavior?

-- 
Steven E. Harris

Re: authinfo/netrc file encryption status -- GnuPG

[Ted Zlatanov]

On Wed, 04 Aug 2004, seh@panix.com wrote:

> Summarizing: With no passwords in a non-encrypted .authinfo file, I
> type a password for each server each time I start Gnus, and I usually
> don't have to repeat that password until I exit and restart Gnus. With
> passwords in an encrypted .authinfo file, I have to type the
> decryption password every gnus-encrypt-password-cache-expiry period.
> 
> Is that the expected behavior?

Yes, every time you run netrc-parse implicitly (by opening a nnimap or
nntp connection) you will need to give a password.  Gnus caches the
passwords in other ways, e.g. imap.el will save the variable
imap-password.  But if you use netrc.el, you don't use that caching
right now.  If you ask and someone wants to do it, fine, but I think
it's easier to just set a longer expiration time on your passwords.

Ted