Keychain use on Mac OS 10.5

[Claus Atzenbeck]

Hi all:

I have posted my problem some time ago. Now an update:

I use Alpine 1.0 on Mac OS 10.5.2 (Leopard) compiled with the
--with-local-password-cache-method option. On Mac OS 10.4 this option
worked perfectly and the password was stored in and retrieved from the
system's keychain.

On Mac OS 10.5, however, Alpine apparently does not get the password
from the keychain. Alpine asks my password every time it starts.

I deleted the Alpine password entries from the keychain. Now I am even
asked every time (after entering the credentials) whether I would like
to store the password in the keychain. Answering "Yes" brings up the
message

[Stop "Preserve passwords?" prompts by deleting Alpine Keychain entry]

but does not create any entry in the keychain. Interestingly, Alpine has
created password entries before (which did not work).

Could this be part of the problem?

Cheers,
Claus

[Matt Ackeret]

Post by Claus Atzenbeck
I use Alpine 1.0 on Mac OS 10.5.2 (Leopard) compiled with the
--with-local-password-cache-method option. On Mac OS 10.4 this option worked
perfectly and the password was stored in and retrieved from the system's
keychain.
On Mac OS 10.5, however, Alpine apparently does not get the password from the
keychain. Alpine asks my password every time it starts.
I deleted the Alpine password entries from the keychain. Now I am even asked
every time (after entering the credentials) whether I would like to store the
password in the keychain. Answering "Yes" brings up the message
[Stop "Preserve passwords?" prompts by deleting Alpine Keychain entry]
but does not create any entry in the keychain. Interestingly, Alpine has
created password entries before (which did not work).
Could this be part of the problem?

See if you have multiple keychains. I honestly don't remember the exact
circumstances, but I had a 'login' keychain and a keychain of my username.

I think there can be some confusion when the keys are put in the 'wrong'
keychain. I'm unsure whether this is anything alpine is doing wrong or
if it's the keychain system.

I was having a similar problem to what you were when Leopard was being
created.

Also, I use a network home directory and share it between multiple versions
of the OS, which might be part of the issue (when things change place between
different versions of the OS, it can sometimes confuse things).
Are you using a shared directory between Tiger & Leopard?

As a last ditch effort, try creating a new user on the computer and try
the steps again. See if it remembers the password there. If it does, then
it points to there being something in your original user that is provoking
the problem.

[Claus Atzenbeck]

Post by Claus Atzenbeck
I use Alpine 1.0 on Mac OS 10.5.2 (Leopard) compiled with the
--with-local-password-cache-method option. On Mac OS 10.4 this option worked
perfectly and the password was stored in and retrieved from the system's
keychain.
On Mac OS 10.5, however, Alpine apparently does not get the password from the
keychain. Alpine asks my password every time it starts.

The problem appears to be solved. The short version: Apparently there
were some problems with some Terminal configurations. (To make it even
more complicated: The problem only occurred from within screen. Alpine
behaved perfectly from within an "ordinary" terminal.)

I changed some settings in Apple's Terminal application ("Set LANG
environment variable on startup" checkbox) and Alpine were suddenly able
to retrieve the credentials from the keychain. Later, even the setting
of the preferences did not play any role.

I realized that the keychain problem also came up for command line tools
that make use of the keychain, such as hdiutil. I don't know what file
has been changed, but apparently it was somehow related to the terminal
and not Alpine.

Anyway, thanks to Matt who suggested to try out Alpine from another user login,
which pushed me into the right direction.

Cheers,
Claus

[Claus Atzenbeck]

Post by Claus Atzenbeck
I changed some settings in Apple's Terminal application ("Set LANG
environment variable on startup" checkbox) and Alpine were suddenly able to
retrieve the credentials from the keychain. Later, even the setting of the
preferences did not play any role.

Sorry, another follow-up just to correct myself (for those who are interested):

No, it was not the terminal. I used Alpine running inside screen that
comes with Mac OS (/usr/bin/screen). This caused the problem. I compiled
screen from Fink (/sw/bin/screen) and it works perfectly. This is
reproducible and independent of the Terminal settings.

Cheers,
Claus

[Matt Ackeret]

No, it was not the terminal. I used Alpine running inside screen that comes
with Mac OS (/usr/bin/screen). This caused the problem. I compiled screen from
Fink (/sw/bin/screen) and it works perfectly. This is reproducible and
independent of the Terminal settings.

I don't quite understand the underlying 'magic' that screen uses. But
this sounds like screen does something (like run under another user?)
that makes any app unable to talk to the keychain because it can't
"connect to the window server". I don't exactly know how that works too,
but it essentially requires the user to really be there live, not ssh-ed in
for example.

(Though I haven't actually used screen *routinely* in a long time. I do use
it once in a while if I start a long compile over ssh via a laptop, just so
I can reconnect if the WiFi connection cuts out for example.. I finally
just got used to using multiple literal terminal windows and using cmd keys
to switch between them. Leopard's Terminal has tabbing, but I actually
use the earlier Terminal because of the cmd-doubleclick behavior on the old
Terminal.)

[Claus Atzenbeck]

Post by Matt Ackeret
I don't quite understand the underlying 'magic' that screen uses. But
this sounds like screen does something (like run under another user?)
that makes any app unable to talk to the keychain because it can't
"connect to the window server". I don't exactly know how that works too,
but it essentially requires the user to really be there live, not ssh-ed in
for example.

As I mentioned, Fink's screen distribution works, even though it is the
exact version of screen that Apple ships with Leopard. Apple's screen on
Tiger also did not have that problem. (I don't know the difference of
Leopard's and Tiger's screen.)

It may have to do with the screenrc that comes with Fink but is not
available for Apple's screen.

I would be curious to know the reasons, but this would be off-topic
here. It's not an Alpine problem and affects other terminal tools as
well (e.g. hdiutil).

Anyway, thanks again for the initial pointer.

Cheers,
Claus

[Claus Atzenbeck]

Post by Matt Ackeret
I don't quite understand the underlying 'magic' that screen uses. But
this sounds like screen does something (like run under another user?)
that makes any app unable to talk to the keychain because it can't
"connect to the window server". I don't exactly know how that works too,
but it essentially requires the user to really be there live, not ssh-ed in
for example.

As I mentioned, Fink's screen distribution works, even though it is the exact
version of screen that Apple ships with Leopard. Apple's screen on Tiger also
did not have that problem. (I don't know the difference of Leopard's and
Tiger's screen.)

As a final close-up and reference for others who might come across this
problem later, here is the most likely reason that caused my problem.
(Sorry for being off-topic. This will be the last time.)

I found out that Matt's guess was correct:

$ ls -la /sw/bin/screen*
lrwxr-xr-x 1 root admin 12 2008-03-12 21:27 /sw/bin/screen -> screen-4.0.3*
-rwsr-xr-x 1 root admin 377952 2008-03-12 21:27 /sw/bin/screen-4.0.3*
$ ls -la /usr/bin/screen
-rwxr-xr-x 1 root wheel 601296 2007-09-24 04:11 /usr/bin/screen*

As you can see, Fink's screen has a sticky bit turned on which makes one
of the screen instances run as root, the other as user. This seems to
cause the problem of Alpine not being able to connect to the keychain
when running inside /usr/bin/screen.

Cheers,
/CA