10:46 a.m.
Here is a small dynamic module that adds support for the OS X keychain
to XEmacs.
The OS X keychain is a mechanism that stores application passwords
(and other secret information) in encrypted file on the disk. This is
quite useful: For example, if the user unlocks his keychain on login,
applications may fetch passwords from the keychain to access some
server without having to ask for the server password.
I always wanted Gnus to use the keychain to store my IMAP server
passwords instead of the plain text ~/.netrc or ~/.authinfo files.
So, here is a small patch that adds a module that wraps Carbon API to
keychain into Lisp functions: KEYCHAIN-FIND, KEYCHAIN-REMOVE, and
KEYCHAIN-ADD. The functions are pretty simple to use.
The call
(keychain-add "imap:foo＠bar.org" "geheim")
adds the password "geheim" to the (user's default) keychain identified
by string "imap:foo＠bar.org". To retrieve this password, simply call:
(keychain-find "imap:foo＠bar.org")
-Eric
--
"Excuse me --- Di Du Du Duuuuh Di Dii --- Huh Weeeheeee" (Albert King)
_______________________________________________
XEmacs-Patches mailing list
XEmacs-Patches(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches
8:17 p.m.
New subject: [Q] support for the OS X keychain
QUERY
Which versions have you tested with? Since it's a module, I suppose
it can be built to be used with *any* XEmacs supporting modules,
including 21.4? (Vin alert!)
This is a good idea, but the implementation can be strengthened
without much effort.
(1) The function docstring *must* document the security implications
of passwords being left in XEmacs's memory. In particular, mention
the trivial attack via history in M-: (the obvious direct UI to the
API). Yes, I understand that these are single-user machines and that
normally the only avenue to root is sudo, in which case the single
user's system login password has to be compromised anyway. So the
risks are low. But so is the cost of documentation/education.
(2) `keychain-add' *should* be given an interactive interface that
calls `read-password' for the password. While `read-password' is only
"semi-secure" (as its documentation says), it does limit the risk
quite a bit. And if you use `read-password', then improvements to it
will automatically be used in the future.
Eric Knauel writes:
Here is a small dynamic module that adds support for the OS X
keychain
to XEmacs.
The OS X keychain is a mechanism that stores application passwords
(and other secret information) in encrypted file on the disk. This is
quite useful: For example, if the user unlocks his keychain on login,
applications may fetch passwords from the keychain to access some
server without having to ask for the server password.
I always wanted Gnus to use the keychain to store my IMAP server
passwords instead of the plain text ~/.netrc or ~/.authinfo files.
So, here is a small patch that adds a module that wraps Carbon API to
keychain into Lisp functions: KEYCHAIN-FIND, KEYCHAIN-REMOVE, and
KEYCHAIN-ADD. The functions are pretty simple to use.
_______________________________________________
XEmacs-Patches mailing list
XEmacs-Patches(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches
9:20 a.m.
New subject: [Q] support for the OS X keychain
Thank you for your suggestions, Stephen! Here's a new version of the
patch.
On Sat 22 Dec 2007 21:17, "Stephen J. Turnbull" <stephen(a)xemacs.org>
writes:
Which versions have you tested with? Since it's a module, I
suppose
it can be built to be used with *any* XEmacs supporting modules,
including 21.4? (Vin alert!)
I've tested the module with a recent 21.5 XEmacs with Mule support.
The keychain code relies on TO_EXTERNAL_FORMAT to convert a Lisp
string to malloced UTF-8 encoded C string (Apple's Carbon API wants
strings encoded as UTF-8). The lisp.h of 21.4 does not seem to have
this macro. I couldn't figure out how to convert the string with
macros of 21.4 yet --- maybe one of the 21.4 developers could give me
some advice?
(1) The function docstring *must* document the security implications
of passwords being left in XEmacs's memory. In particular, mention
the trivial attack via history in M-: (the obvious direct UI to the
API). Yes, I understand that these are single-user machines and that
normally the only avenue to root is sudo, in which case the single
user's system login password has to be compromised anyway. So the
risks are low. But so is the cost of documentation/education.
Done --- hope that the docstring is clear enough.
(2) `keychain-add' *should* be given an interactive interface
that
calls `read-password' for the password. While `read-password' is only
"semi-secure" (as its documentation says), it does limit the risk
quite a bit. And if you use `read-password', then improvements to it
will automatically be used in the future.
Good point. Seems to work with the new patch. However, one issue
remains: The `passwd' library must be loaded before calling
`keychain-add' for the first time. I'm wondering whether I have to
"autoload" or "require" the `passwd' library in some sense. I
found a
C function called `do_autoload' but I couldn't figure out what this
function does. What do the XEmacs developers suggest in this case?
-Eric
--
"Excuse me --- Di Du Du Duuuuh Di Dii --- Huh Weeeheeee" (Albert King)
_______________________________________________
XEmacs-Patches mailing list
XEmacs-Patches(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches
12:42 p.m.
New subject: [Q] support for the OS X keychain
Ar an triú lá de mí Eanair, scríobh Eric Knauel:
Thank you for your suggestions, Stephen! Here's a new version of
the
patch.
On Sat 22 Dec 2007 21:17, "Stephen J. Turnbull" <stephen(a)xemacs.org>
writes:
> Which versions have you tested with? Since it's a module, I suppose
> it can be built to be used with *any* XEmacs supporting modules,
> including 21.4? (Vin alert!)
I've tested the module with a recent 21.5 XEmacs with Mule support.
The keychain code relies on TO_EXTERNAL_FORMAT to convert a Lisp
string to malloced UTF-8 encoded C string (Apple's Carbon API wants
strings encoded as UTF-8). The lisp.h of 21.4 does not seem to have
this macro.
It’s in buffer.h.
I couldn't figure out how to convert the string with macros of
21.4 yet
--- maybe one of the 21.4 developers could give me some advice?
UTF-8 is not available as a coding system by default on 21.4. One awkward
way to work around that would be to check for non-ASCII in the strings, and
only do the translation if a) there are non-ASCII characters and b)
Ffind_coding_system (intern ("utf-8")) gives non-nil.
[...]
> (2) `keychain-add' *should* be given an interactive interface that
> calls `read-password' for the password. While `read-password' is only
> "semi-secure" (as its documentation says), it does limit the risk
> quite a bit. And if you use `read-password', then improvements to it
> will automatically be used in the future.
Good point. Seems to work with the new patch. However, one issue
remains: The `passwd' library must be loaded before calling
`keychain-add' for the first time. I'm wondering whether I have to
"autoload" or "require" the `passwd' library in some sense. I
found a
C function called `do_autoload' but I couldn't figure out what this
function does. What do the XEmacs developers suggest in this case?
Frequire (intern("passwd"));
should work.
--
¿Dónde estará ahora mi sobrino Yoghurtu Nghé, que tuvo que huir
precipitadamente de la aldea por culpa de la escasez de rinocerontes?
_______________________________________________
XEmacs-Patches mailing list
XEmacs-Patches(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches
6514
days inactive
6526
days old
3 comments
3 participants
participants (3)
-
Aidan Kehoe -
Eric Knauel -
Stephen J. Turnbull