Cache passwords

Cache passwords

[Kai Grossjohann]

I'm thinking about augmenting Tramp with a multi-connection mode.
What does this have to do with Gnus, you ask?  Well, opening a
connection to a remote host often means that the user has to enter a
password (or five).  I would like to make it convenient for the user
to open more connections, so I'd like to cache the password that the
user typed.

Is there something in Gnus or PGG or mailcrypt that could help me with
this?  I guess I need some key (a string I guess) to store each
password under.  And I need a way of retrieving the password later.

And some security of one kind of another would be nice, too.

Kai

Re: Cache passwords

[Simon Josefsson]

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

Kai Grossjohann <kai@emptydomain.de> writes:

> I'm thinking about augmenting Tramp with a multi-connection mode.
> What does this have to do with Gnus, you ask?  Well, opening a
> connection to a remote host often means that the user has to enter a
> password (or five).  I would like to make it convenient for the user
> to open more connections, so I'd like to cache the password that the
> user typed.
>
> Is there something in Gnus or PGG or mailcrypt that could help me with
> this?  I guess I need some key (a string I guess) to store each
> password under.  And I need a way of retrieving the password later.

There is code in pgg.el for this, but perhaps depending on it in tramp
isn't the best idea.  It could be separated.  How about a password.el?

> And some security of one kind of another would be nice, too.

Left as an exercise to the reader.


[-- Attachment #2: password.el --]
[-- Type: application/emacs-lisp, Size: 6356 bytes --]

Re: Cache passwords

[Simon Josefsson]

Simon Josefsson <jas@extundo.com> writes:

> ;;; password.el --- Read passwords from user, possibly using a password cache.

I propose we install this in No Gnus and initially make PGG use it,
but later also for NNTP/IMAP/Sieve/etc password handling.

Re: Cache passwords

[Jesper Harder]

Simon Josefsson <jas@extundo.com> writes:

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

Is there a particular reason for using an obarray rather than a hash
table?

Re: Cache passwords

[Simon Josefsson]

Jesper Harder <harder@ifa.au.dk> writes:

> Simon Josefsson <jas@extundo.com> writes:
>
>> (defvar password-data (make-vector 7 0))
>
> Is there a particular reason for using an obarray rather than a hash
> table?

I dunno.  Does Emacs 20 support hash tables?  My emacs 20 doesn't have
make-hash-table.

Re: Cache passwords

[Jesper Harder]

Simon Josefsson <jas@extundo.com> writes:

> Jesper Harder <harder@ifa.au.dk> writes:
>
>> Is there a particular reason for using an obarray rather than a hash
>> table?
>
> I dunno.  Does Emacs 20 support hash tables?

Probably not.  But I thought we were dropping support for Emacs 20 in
No Gnus.

Re: Cache passwords

[Simon Josefsson]

Jesper Harder <harder@ifa.au.dk> writes:

> Simon Josefsson <jas@extundo.com> writes:
>
>> Jesper Harder <harder@ifa.au.dk> writes:
>>
>>> Is there a particular reason for using an obarray rather than a hash
>>> table?
>>
>> I dunno.  Does Emacs 20 support hash tables?
>
> Probably not.  But I thought we were dropping support for Emacs 20 in
> No Gnus.

I see (why?).  Another reason might be that it is easier to zeroize
obarray memory, the hash table interface seem rather opaque (as it
should be, of course) so I'm not sure if zeroing passwords in a hash
table wipes out all instances of the password.  (OTOH, I don't know if
this is the case for obarray's for sure either, nor do I think zeroing
is important...)

Re: Cache passwords

[Jesper Harder]

Simon Josefsson <jas@extundo.com> writes:

>> But I thought we were dropping support for Emacs 20 in No Gnus.
>
> I see 

Well, I don't really remember if any decision has been made.

> (why?).

Supporting different (broken) versions of MULE is already pretty
annoying, IMHO, and it makes the code harder to understand.

I think it will become increasingly annnoying to support 20.7 (with
lots of conditional code) when Emacs 22 finally switches to Unicode.

In general, I think it would be nice to remove some of the
compatibility cruft while we can still remember the reason why it was
there.

Re: Cache passwords

[Jeremy Maitin-Shepard]

Simon Josefsson <jas@extundo.com> writes:

> [snip]

> I see (why?).  Another reason might be that it is easier to zeroize
> obarray memory, the hash table interface seem rather opaque (as it
> should be, of course) so I'm not sure if zeroing passwords in a hash
> table wipes out all instances of the password.  (OTOH, I don't know if
> this is the case for obarray's for sure either, nor do I think zeroing
> is important...)

Given that garbage collection is used, and the high-level nature of
emacs lisp, I that there is good reason to believe that regardless of
any amount of effort, the password might remain somewhere in memory for
a while.

-- 
Jeremy Maitin-Shepard

Re: Cache passwords

[Jesper Harder]

Jeremy Maitin-Shepard <jbms@attbi.com> writes:

> Given that garbage collection is used, and the high-level nature of
> emacs lisp, I that there is good reason to believe that regardless of
> any amount of effort, the password might remain somewhere in memory for
> a while.

I do believe that explicitly overwriting a string, e.g. with
`clear-string', *will* change the bits immediately.

But it's less obvious what the effect of `clrhash' is, as Simon notes.

Re: Cache passwords

[Jeremy Maitin-Shepard]

Jesper Harder <harder@ifa.au.dk> writes:

> Jeremy Maitin-Shepard <jbms@attbi.com> writes:
>> Given that garbage collection is used, and the high-level nature of
>> emacs lisp, I that there is good reason to believe that regardless of
>> any amount of effort, the password might remain somewhere in memory for
>> a while.

> I do believe that explicitly overwriting a string, e.g. with
> `clear-string', *will* change the bits immediately.

That is true, but you don't know how many copies were made while
reading it from the minibuffer, etc.

> But it's less obvious what the effect of `clrhash' is, as Simon notes.

Indeed, this probably does not zero the individual strings.

-- 
Jeremy Maitin-Shepard

Re: Cache passwords

[Lars Magne Ingebrigtsen]

Simon Josefsson <jas@extundo.com> writes:

>> ;;; password.el --- Read passwords from user, possibly using a password cache.
>
> I propose we install this in No Gnus and initially make PGG use it,
> but later also for NNTP/IMAP/Sieve/etc password handling.

Sounds good.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Cache passwords

[Lars Magne Ingebrigtsen]

Jesper Harder <harder@ifa.au.dk> writes:

> Supporting different (broken) versions of MULE is already pretty
> annoying, IMHO, and it makes the code harder to understand.

Yup.  And slower, too.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Cache passwords

[Lars Magne Ingebrigtsen]

Jeremy Maitin-Shepard <jbms@attbi.com> writes:

> That is true, but you don't know how many copies were made while
> reading it from the minibuffer, etc.

No, you don't.  Hm.  How does one inspect the memory of a running
process under Linux?  I'd guess that there's something under
/proc/PID...  perhaps "mem"?

Anyway, it would be interesting to see how many copies of the string
`read-from-minibuffer' and friends leave of the string.  Anybody have
a method to check that?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen