emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Moving files from lisp/gnus/ to lisp/net/?


From: Richard Stallman
Subject: Re: Moving files from lisp/gnus/ to lisp/net/?
Date: Tue, 06 Nov 2007 03:38:33 -0500

    There are solutions intended to address the real problem here: GnuPG
    uses a helper program pin-entry that asks the user for passwords.  I
    believe it can cache passwords too.  However, this is not widely used,
    and definitely not used or known except to GnuPG users.  I'm not
    convinced it is mature enough to be suggested as a solution for password
    input in emacs.  And anyway, you'd still have the gc-problem in emacs if
    the password is transfered into an emacs elisp variable.

Is pin-entry the program that is supposed to avoid the need to enter
passwords thru any other program?  I think we discussed how Emacs
could use pin-entry, right? I think we concluded that this was
possible under a window system but not on a tty; is that correct?

Maybe we should pursue this and look for a complete solution along
these lines.

Is it possible to use pin-entry for applications other than GnuPG?
Could it be the basis of a complete solution?

    The existing `read-passwd' API is not suitable for password.el, because
    each password needs to be associated with an application-dependent
    'key'.  There is no parameter for that in `read-passwd'.  Do you think
    it is worth adding one?

I see no harm in adding one.  Adding it at the end would avoid
incompatibility.

    Alternatively, and what I consider the best idea (but it was some time
    since this was discussed and I may very well have forgotten some
    important point): let's make `read-passwd' a more lower-level primitive,
    used by `password-read'.

All else being equal, I'd rather avoid adding another level of function
calling.  It increases the total complexity, and I don't see any benefit.
What is the benefit here?




reply via email to

[Prev in Thread] Current Thread [Next in Thread]