On Sun, 18 Feb 2007, Gerald Pfeifer wrote:
On Sun, 18 Feb 2007, Mark Crispin wrote:
If the user enters the decryption key when he runs Alpine, doesn't that
defeat the purpose of the passfile? I can see the benefit when there are
multiple passwords for multiple servers; in this case, one password unlocks
a "password vault" that Alpine can then use for the rest of the session.
But that doesn't help the typical user who just has one password that
Alpine needs to use.
Among others, it will prove helpful when (hopefully not if ;-) Alpine
is going to add support for sending PGP signed messages and reading PGP
encrypted messages using the same key unlocked by said password.
This could leverage the gpg-agent tool, for example, which is somewhat
similar to ssh-agent, in case you are familiar with the latter.
I haven't been able to find more information on this yet than the man
page, from which it looks like it will have the same defect as ssh-agent
of not tying decryption to the original application.
This defect is not necessarily as serious as it sounds in practice.
Limiting who can decrypt the passfile is certainly a good thing, but
ssh-agent is already providing the lower level of security to my entire
account. Once someone gets access to a shell with key forwarding set up,
they can generate new ssh keys for which they know the passowrd, propagate
them to all other systems, and thereby compromise my accounts. Depending
on mail server configuration, that will include some or all mail as well.
(Everything but the inbox in my case, but judicious use of procmail to
redirect inbox delivery would get that mail too.)
b
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
