Re: mutt and plaintext passwords : muttrc encryption ?

2008-07-31 Thread Louis-David Mitterrand
On Mon, Jul 28, 2008 at 05:12:50PM +0100, Michele Martone wrote:
 Hello.
 I was wondering about some way to protect the passwords potentially 
 stored in the mutt rc files (i have multiple acccounts, and I feel
 unconfortable remembering and typing all of them each time using
 mutt) on my Linux laptop.

Hi,

Provided you have shell access on your imap host, ssh can help you 
eleminate all passwords from you muttrc:

1) generate a ssh key with a passphrase identical to you login password,

2) when entering your gnome or kde session your key should be decrypted, 
(if using xdm then you need libpam-ssh) and ssh-agent active,

3) configure password-less ssh access to your imap and smtp host,

4) add (and adapt) these lines to your .muttrc

account-hook ^imaps?://your.imap.host/ 'set tunnel=/usr/bin/ssh 
your.imap.host /usr/bin/imapd 2/dev/null'

set sendmail=/usr/bin/ssh your.smtp.host /usr/sbin/sendmail -oem -oi

Look Ma, no passwords!

If you don't have shell access to your mail host, then I suggest you get 
a hosted account or (better) a linux virtual server, they are really 
cheap these days (starting at 6 euros at 
http://www.gandi.net/hebergement/). Then forward all other accounts to 
this central one.


Re: mutt and plaintext passwords : muttrc encryption ?

2008-07-31 Thread Derek Martin
On Wed, Jul 30, 2008 at 11:39:58PM +0100, Michele Martone wrote:
 So there I see no legitimate way of breaking mutt's environment via
 source or exec mutt keywords.

We're not talking about breaking anything.  We're talking about
someone getting your passphrases to your encryption keys by reading
them out of the environment, and in particular out of swap.  Your
comments are not relevant.

-- 
Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.



pgpJwBQKZK5ED.pgp
Description: PGP signature


[EMAIL PROTECTED]: Re: mutt and plaintext passwords : muttrc encryption ?]

2008-07-30 Thread Michele Martone
Hi,
for some reason, this message I sent to the mutt-users@mutt.org list
gets filtered out!

Maybe you could forward this message on behalf of me or just read it.
I appreciated your help, and I hope to contribute in the future.

 michele
---BeginMessage---
Unfortunately, the msmtp configuration part didn't go so well as I
wished it to go.

msmtp from version 1.4.15 has stdin password reading disabled, or at
least 'deprecated'; from the ChangeLog: 
- Do not let getpass() read from stdin, because we read the mail from
  there.
In fact, the password reading code will execute, but it will interfer
with the email message being read meanwhile, so a workaround patch 
for msmtp should be written (maybe styled in the same way vim handles
actions like date | vim -, namely file description duplication).

But this is OT here I suppose, and would not solve fully 'our' combined
problem of laziness and encryption needs.


So I followed Kyle's advice and tried mutt-1.5.18 :

./configure --enable-smtp --enable-imap --enable-pop
--with-ssl=/usr/include/gnutls/ --with-sasl=/usr/include/sasl

And then overriding the 'sendmail' command by setting :

smtp[s]://[user[:[EMAIL PROTECTED]:port]/ 

All easy, straightforward. No odds with certificates, as they are
handled by mutt directly. And all of the configuration (er.. except
fetchmail and isync AFAIK) is in plaintext muttrc and some gpg encrypted
helper muttrc chunk.


So Michael's solution :
  source gpg -d sensitivestuff.gpg |
fits perfectly with a gpg - encrypted sensitive muttrc portion.
Once decrypted, no environment variables nor exotic configuration is
required!


One last thing : since the 'gpg' command itself could be sensitive to
the shell environment, I recommend running it with X cut off (fording
the DISPLAY variable being unset):

source DISPLAY= gpg -d sensitivestuff.gpg |

This will prevent funny situations I noticed while experimenting with
mutt sessions ran under screen and multiple screen attachments (multi
display screen mode), like some Pinentry window asking me for a
passphrase on the X terminal and attached screen i was not phisically
working on :) .

I've been trying cleaning up the gpg environment completely using 

source env --ignore-environment gpg -d sensitivestuff.gpg |

but this in turn breaks gpg functionality, because unsets variables like
GNUPGHOME or HOME or other ones.

By setting selectively environment variables cited in `man 1 gpg` or 
`man gpg-agent` I wasn't able to find a working minimal gpg environment:

 source env -i HOME=/home/user COLUMNS=10 LINES=10 GPG_AGENT_INFO=
 PINENTRY_USER_DATA= GPG_TTY=`tty` gpg  --homedir /home/dez/.gnupg -d
 ~/.mutt/private.accounts.gpg|

So I guess PATH , LD_LIBRARY_PATH environment and some other are still
missing.. so my safe solution is :

source DISPLAY= gpg -d sensitivestuff.gpg |

On [EMAIL PROTECTED]:43, Michele Martone wrote:
 `figlet yes, this is THE solution, working. perfect.`
 
 thank you guys, now I'll learn to use mutt with smtp features (hope
 tls/ssl is in) and I'll drop some line if Kyle won't do this already :)
 
 On [EMAIL PROTECTED]:29, Michael Kjorling wrote:
  On 28 Jul 2008 21:53 +0100, by [EMAIL PROTECTED] (Michele Martone):
  ...
  source gpg -d sensitivestuff.gpg |
  
  and sensitivestuff being just another muttrc snippet.
---End Message---


Re: mutt and plaintext passwords : muttrc encryption ?

2008-07-30 Thread Michele Martone
As far as I know (and `man environ`, `man popen`) is that :

 - the environment can be only changed internally, via putenv(),
   setenv() POSIX calls.

 - the mutt backtick-based commands, like | terminated 'source's
   does not perform any of the 'execve,execl,...' functions nor 'fork',
   but only pipe reads (popen()'s).
   so there is no chance of a mutt-triggered environment change, unless
   you find some putenv(), setenv(), or related calls in the mutt code.

So there I see no legitimate way of breaking mutt's environment via
source or exec mutt keywords.



p.s.: I just learnt the ``list-reply'' function, feel sorry for some 
duplicate messages i've sent :P

On [EMAIL PROTECTED]:54, Kyle Wheeler wrote:
 On Monday, July 28 at 07:56 PM, quoth Derek Martin:
  ...
 ...unless bash swaps out the environment...
 ... why, in that example, would bash do that?
 Presumably, you can avoid that by removing the exec keyword in the
 script?



Re: mutt and plaintext passwords : muttrc encryption ?

2008-07-29 Thread Nicolas Rachinsky
* Kyle Wheeler [EMAIL PROTECTED] [2008-07-28 16:52 -0500]:
 On Monday, July 28 at 09:29 PM, quoth Michael Kjorling:
  Something like this:
 
  source gpg -d sensitivestuff.gpg |
 
 No. That can't work (but we can salvage this idea). First, let me 
 explain why it can't work.
 
 Think about it: what does the source command tell mutt to do? It 
 tells mutt read the file with the following name. Even in situations  
 where ending an item in a pipe means something to mutt, it means use 
 the output of this command in place of this variable whenever you need 
 it.

For source, the ending pipe means:
   If the filename ends with a vertical bar (|), then filename is
   considered to be an executable program from which to read input (eg.
   source ~/bin/myscript|).

Why do you think, mutt tries to re-read the the script's output at
some time?

Nicolas (using source script|)

-- 
http://www.rachinsky.de/nicolas


Re: mutt and plaintext passwords : muttrc encryption ?

2008-07-29 Thread Michele Martone
Unfortunately, the msmtp configuration part didn't go so well as I
wished it to go.

msmtp from version 1.4.15 has stdin password reading disabled, or at
least 'deprecated'; from the ChangeLog: 
- Do not let getpass() read from stdin, because we read the mail from
  there.
In fact, the password reading code will execute, but it will interfer
with the email message being read meanwhile, so a workaround patch 
for msmtp should be written (maybe styled in the same way vim handles
actions like date | vim -, namely file description duplication).

But this is OT here I suppose, and would not solve fully 'our' combined
problem of laziness and encryption needs.


So I followed Kyle's advice and tried mutt-1.5.18 :

./configure --enable-smtp --enable-imap --enable-pop
--with-ssl=/usr/include/gnutls/ --with-sasl=/usr/include/sasl

And then overriding the 'sendmail' command by setting :

smtp[s]://[user[:[EMAIL PROTECTED]:port]/ 

All easy, straightforward. No odds with certificates, as they are
handled by mutt directly. And all of the configuration (er.. except
fetchmail and isync AFAIK) is in plaintext muttrc and some gpg encrypted
helper muttrc chunk.


So Michael's solution :
  source gpg -d sensitivestuff.gpg |
fits perfectly with a gpg - encrypted sensitive muttrc portion.
Once decrypted, no environment variables nor exotic configuration is
required!


One last thing : since the 'gpg' command itself could be sensitive to
the shell environment, I recommend running it with X cut off (fording
the DISPLAY variable being unset):

source DISPLAY= gpg -d sensitivestuff.gpg |

This will prevent funny situations I noticed while experimenting with
mutt sessions ran under screen and multiple screen attachments (multi
display screen mode), like some Pinentry window asking me for a
passphrase on the X terminal and attached screen i was not phisically
working on :) .

I've been trying cleaning up the gpg environment completely using 

source env --ignore-environment gpg -d sensitivestuff.gpg |

but this in turn breaks gpg functionality, because unsets variables like
GNUPGHOME or HOME or other ones.

By setting selectively environment variables cited in `man 1 gpg` or 
`man gpg-agent` I wasn't able to find a working minimal gpg environment:

 source env -i HOME=/home/user COLUMNS=10 LINES=10 GPG_AGENT_INFO=
 PINENTRY_USER_DATA= GPG_TTY=`tty` gpg  --homedir /home/dez/.gnupg -d
 ~/.mutt/private.accounts.gpg|

So I guess PATH , LD_LIBRARY_PATH environment and some other are still
missing.. so my safe solution is :

source DISPLAY= gpg -d sensitivestuff.gpg |

On [EMAIL PROTECTED]:43, Michele Martone wrote:
 `figlet yes, this is THE solution, working. perfect.`
 
 thank you guys, now I'll learn to use mutt with smtp features (hope
 tls/ssl is in) and I'll drop some line if Kyle won't do this already :)
 
 On [EMAIL PROTECTED]:29, Michael Kjorling wrote:
  On 28 Jul 2008 21:53 +0100, by [EMAIL PROTECTED] (Michele Martone):
  ...
  source gpg -d sensitivestuff.gpg |
  
  and sensitivestuff being just another muttrc snippet.


Re: mutt and plaintext passwords : muttrc encryption ?

2008-07-29 Thread Kyle Wheeler
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tuesday, July 29 at 08:40 AM, quoth Nicolas Rachinsky:
For source, the ending pipe means:
   If the filename ends with a vertical bar (|), then filename is
   considered to be an executable program from which to read input (eg.
   source ~/bin/myscript|).

Why do you think, mutt tries to re-read the the script's output at
some time?

... weird. So, with my mutt (which is compiled from hg tip), when I 
run this:

 :source echo set my_var |

All I get is the error message:

 source: errors in echo set my_var |

Assuming it's something that only works in the muttrc, I tried putting 
it there:

 source echo set my_var |

But when I ran mutt, I got this:

 Error in echo set my_var |, line 1: my_var: unknown variable
 Error in /Users/kyle/.muttrc, line 3485: source: errors in echo
 set my_var |
 source: errors in /Users/kyle/.muttrc
 Press any key to continue...

unknown variable... what's this? Does it not allow for my_* variables 
anymore? What's going on?

~Kyle
- -- 
And I have other sheep, that are not of this fold.
  -- John 10:16
-BEGIN PGP SIGNATURE-
Comment: Thank you for using encryption!

iEYEARECAAYFAkiPPAUACgkQBkIOoMqOI141kQCdFEKtW1sQi6+fnyBcb96pfdjp
Yl8AnAzW4ssiBoolSBfNsNu4H/pf54zx
=eu3L
-END PGP SIGNATURE-


Re: mutt and plaintext passwords : muttrc encryption ?

2008-07-29 Thread David Champion
  :source echo set my_var |
 
 All I get is the error message:
 
  source: errors in echo set my_var |

:set my_var yields my_var: unknown variable too.  Try, for example,

:source echo set ?index_format |

I was going to suggest this approach as well, although I'd have proposed
openssl enc instead of gpg, I guess.  Not much call for an asymmetric
cipher here, especially as the point is to store secret data on a
filesystem that contains the key for decoding the secret data.  (I'm
sure your gpg key is secure and all, it's just that no stored key 
encrypted key.)

I'm kind of surprised you've missed my dozens of messages recommending
source with pipes, Kyle. :)  It's super useful.  My entire muttrc is
generated this way.

Thanks to the OP for asking the question, though.  I hadn't thought of
using programmic sources to encrypt sensitive muttrc files.  Embedding
programmatic source statements within programmatically-generated muttrc
streams... tasty.

-- 
 -D.[EMAIL PROTECTED]NSITUniversity of Chicago


Re: mutt and plaintext passwords : muttrc encryption ?

2008-07-29 Thread Michael Kjorling
On 29 Jul 2008 14:14 -0500, by [EMAIL PROTECTED] (David Champion):
 I was going to suggest this approach as well, although I'd have proposed
 openssl enc instead of gpg, I guess.  Not much call for an asymmetric
 cipher here, especially as the point is to store secret data on a

Off topic, but have a look at gpg's -c option.

-- 
Michael Kjörling .. [EMAIL PROTECTED] .. http://michael.kjorling.se
* . No bird soars too high if he soars with his own wings . *
* ENCRYPTED email preferred -- OpenPGP key ID: 0x 758F8749 BDE9ADA6 *
* ASCII Ribbon Campaign: Against HTML mail, proprietary attachments *



signature.asc
Description: Digital signature


Re: mutt and plaintext passwords : muttrc encryption ?

2008-07-29 Thread Kyle Wheeler
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tuesday, July 29 at 02:14 PM, quoth David Champion:
 :set my_var yields my_var: unknown variable too.  Try, for 
 example,

   :source echo set ?index_format |

bonk! Wow, duh, my_* variables have to be set *to* something.

 I'm kind of surprised you've missed my dozens of messages 
 recommending source with pipes, Kyle. :)  It's super useful.  My 
 entire muttrc is generated this way.

As am I... dang, that is pretty slick. Gotta love learning new tricks. 
:)

(I still think source is a bad keyword to use for this 
functionality, but I suppose that's neither here nor there.)

~Kyle
- -- 
No man has a natural right to commit aggression on the equal rights of 
another, and this is all from which the laws ought to restrain him.
  -- Thomas Jefferson, July 7, 1786
-BEGIN PGP SIGNATURE-
Comment: Thank you for using encryption!

iEYEARECAAYFAkiPlJsACgkQBkIOoMqOI15KGwCeImZ+FYOTFZw45SWSA5731/TS
6i0AoPvd0dE2HQR/YYNrhy4rB2fRJHVx
=KXd8
-END PGP SIGNATURE-


Re: mutt and plaintext passwords : muttrc encryption ?

2008-07-29 Thread Derek Martin
On Mon, Jul 28, 2008 at 10:54:40PM -0500, Kyle Wheeler wrote:
 On Monday, July 28 at 07:56 PM, quoth Derek Martin:
 On Mon, Jul 28, 2008 at 12:58:00PM -0500, Kyle Wheeler wrote:
  Nothing will be stored in plaintext on disk, your encryption is
  guaranteed to be world-class, and best of all: it will work on
  virtually any Unix machine.
 
 ...unless bash swaps out the environment...
 
 ... why, in that example, would bash do that?

Well, technically, bash wouldn't... the kernel would.  And it would do
so because it needs the physical memory where bash is holding its copy
of the environment for another process that doesn't fit in free
memory (or other reasons)...  The kernel has no way to know that the
contents of a block of memory are sensitive -- nor would it
care if it did.

 Presumably, you can avoid that by removing the exec keyword in the 
 script?

It can only be avoided by calling the mlock() system call (or
equivalent, in the case some OS has called it something else) on the
appropriate block of memory, which typically requires root privileges
on Unix systems.  However, even if you could get bash to do this, its
child processes may (and generally will) have their own copy of the
environment, which might also get swapped out...

The risk here is tiny, but non-zero.  Someone would have to be able to
gain root priviledges to read the raw swap device to get your
passphrase.  You'd ought to trust the actual root user, as root can
just snarf your passphrase out of memory... but a root exploit would
expose you to risk of having your passphrase stolen by a non-root user.

-- 
Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.



pgpqW3kg0DxQH.pgp
Description: PGP signature


Re: mutt and plaintext passwords : muttrc encryption ?

2008-07-29 Thread Michael Kjorling
On 29 Jul 2008 18:14 -0400, by [EMAIL PROTECTED] (Derek Martin):
 The risk here is tiny, but non-zero.  Someone would have to be able to
 gain root priviledges to read the raw swap device to get your

That's where (on Linux, at least) encrypted swap partitions come in
handy. You can set it up to use a random key (different on each boot),
meaning that once the system is shut down, what is left on the swap
partition is no more useful to anyone than the contents of the RAM
chips. Yes, there is still a certain risk involved, but it is much
smaller even if the system gets stolen.

The biggest problem would probably be to protect a running mutt
session on a running system from exploits that give a process
unfettered memory read access. As far as I can think of, that is
basically impossible to completely guarantee against. You can minimize
the risk, but you cannot eliminate it.

One solution that I guess would be workable would be a dm-crypt/LUKS
encrypted USB memory stick holding the sensitive part of the O.P.'s
muttrc, and source this from within ~/.muttrc. This USB memory stick
can be mounted read only under normal use and in fact should only need
to be mounted when mutt is actually being started, and can be kept in
a safe place otherwise. I do pretty much this with a KeePassX database
key file to provide a two-tier authentication mechanism.

But even that doesn't protect a running mutt from a direct attack by a
process with the ability to read mutt's memory.

-- 
Michael Kjörling .. [EMAIL PROTECTED] .. http://michael.kjorling.se
* . No bird soars too high if he soars with his own wings . *
* ENCRYPTED email preferred -- OpenPGP key ID: 0x 758F8749 BDE9ADA6 *
* ASCII Ribbon Campaign: Against HTML mail, proprietary attachments *



signature.asc
Description: Digital signature


mutt and plaintext passwords : muttrc encryption ?

2008-07-28 Thread Michele Martone
Hello.
I was wondering about some way to protect the passwords potentially 
stored in the mutt rc files (i have multiple acccounts, and I feel
unconfortable remembering and typing all of them each time using
mutt) on my Linux laptop.

My main concern is about them being stored in plaintext, which is a
little dangerous when using a laptop and traveling: there is  identity
theft potential.

A widely solution would be to encrypt the filesystem on which the
configuration files reside.
This, however is IMHO a little oversized solution in the case the main
privacy concern, like in my case, is about a bunch of text files.

So lately I'm experimenting a more gentle approach, namely using a
file (stored in my home directory) encrypted with LUKS, containing a
directory containing the important data (a passwords-only .muttrc, a
.msmtprc, a .fetchmailrc, and an .isyncrc).

Setting some sudo stuff, and configuring my bash aliases, I get this 
mini-filesystem mounted with ease - namely obtaining a 'lightweight
personal solution' for mail passwords protection.


But how about storing a whole encrypted muttrc file and letting mutt 
to decrypt it with some passphrase ?

Say, using the vim encryption algorithm (the one you trigger when 
saving a file with :X in the vim inner commandline), one would get a
quite simple and lightweight security measure, without the need of
filesystem messing and getting a 'natural' way of editing the muttrc.
I reported the Vim encryption solution because it sounds 'simple' and
'natural' to me, (and Vim encrypted files can be 'recognized' by 
having a VimCrypt signature in the first bytes)
But I know, vim is not the only text editor around here :) .

Has anybody thought or heard of a solution like this, or similar ?

--
Michele Martone
http://claudius.ce.uniroma2.it/~martone


Re: mutt and plaintext passwords : muttrc encryption ?

2008-07-28 Thread Justin Mazzola Paluska
On Mon, Jul 28, 2008 at 05:12:50PM +0100, Michele Martone wrote:
 Has anybody thought or heard of a solution like this, or similar ?

I have two solutions that I’m using (on two different machines):

1.  On my work GNOME machine, I have some python scripts that query
the GNOME Keyring for my passwords.

2.  On my home machine, I use GPG to decrypt the password part of the
muttrc.

In both cases, my .mutt/muttrc is in plaintext, which sources the
output of either the GNOME Keyring script or the GPG script.
—Justin


Re: mutt and plaintext passwords : muttrc encryption ?

2008-07-28 Thread Kyle Wheeler
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Monday, July 28 at 05:12 PM, quoth Michele Martone:
 I was wondering about some way to protect the passwords potentially 
 stored in the mutt rc files (i have multiple acccounts, and I feel 
 unconfortable remembering and typing all of them each time using 
 mutt) on my Linux laptop.

The obvious answer is: don't store them in the mutt rc files. Instead, 
store them somewhere in encrypted form and extract them when mutt is 
loaded. For example:

set imap_pass=`getpassword [EMAIL PROTECTED]

Programs that can be used to do this include pwsafe 
(http://nsd.dyndns.org/pwsafe/) and passwords 
(http://passwords.sourceforge.net/).

But you can do it even more simply than that! For example, you can use  
gpg to encrypt a file that looks like this:

 export ACCT1_PASS=thepassword
 export ACCT2_PASS=theotherpassword
 export ACCT3_PASS=yetanotherpassword

Then, once you've encrypted it, you can create a wrapper command for 
mutt that will decrypt it and use it to put those passwords into 
mutt's environment:

 #!/bin/sh
 pwds=`gpg --decrypt ~/.passwords`
 eval $pwds
 exec mutt $@

And finally, in your muttrc, you can simply have things like this:

 set imap_pass=$ACCT1_PASS

or:

 account-hook account2 'set imap_pass=$ACCT2_PASS'

Thus, you will be prompted once for a passphrase when mutt loads, and 
after that mutt will use those passwords as it needs them without 
additional overhead. Nothing will be stored in plaintext on disk, your 
encryption is guaranteed to be world-class, and best of all: it will 
work on virtually any Unix machine.

 But how about storing a whole encrypted muttrc file and letting mutt 
 to decrypt it with some passphrase ?

That seems like overkill to me.

~Kyle
- -- 
All we have to decide is what to do with the time that is given us.
-- Gandalf the Grey
-BEGIN PGP SIGNATURE-
Comment: Thank you for using encryption!

iEYEARECAAYFAkiOCKgACgkQBkIOoMqOI14JMACgvaPBdVSUqbnPjYXpz21FrlvM
K98An2uqhZ3eZ0o4FTZfwoduMLuvEZ9B
=TVF/
-END PGP SIGNATURE-


Re: mutt and plaintext passwords : muttrc encryption ?

2008-07-28 Thread Michele Martone
On [EMAIL PROTECTED]:35, Justin Mazzola Paluska wrote:
 ...
 2.  On my home machine, I use GPG to decrypt the password part of the
 muttrc.

uhm. could you give some examples for this solution ?

it seems to require no external workarounds at all, so it seems neat!

i experimented with 

`gpg -d muttrc.gpg`

inside a muttrc file, but I noticed only the first line of 
`gpg -d muttrc.gpg` gets interpreted by mutt; the other lines are
discarded.


Re: mutt and plaintext passwords : muttrc encryption ?

2008-07-28 Thread Michele Martone
this seems almost perfect to me. marvelous, elegant, general, thanks !
(so i do not dare to quote a piece of your email ..)

and is immensely less overkill than the solution I proposed.

still I can't stand the need of a wrapper.. if only one could use
multi line shell expansion, and place that `gpg --decrypt` straight into
the muttrc.

but Gandalf's advice is appropriated - this is enough for now :)

On [EMAIL PROTECTED]:58, Kyle Wheeler wrote:
 On Monday, July 28 at 05:12 PM, quoth Michele Martone:
  I was wondering about some way to protect the passwords potentially 
  stored in the mutt rc files (i have multiple acccounts, and I feel 
  unconfortable remembering and typing all of them each time using 
  mutt) on my Linux laptop.
 
 The obvious answer is: don't store them in the mutt rc files. Instead, 
 store them somewhere in encrypted form and extract them when mutt is 
 loaded. For example:
 
 set imap_pass=`getpassword [EMAIL PROTECTED]
 
 Programs that can be used to do this include pwsafe 
 (http://nsd.dyndns.org/pwsafe/) and passwords 
 (http://passwords.sourceforge.net/).
 
 But you can do it even more simply than that! For example, you can use  
 gpg to encrypt a file that looks like this:
 
  export ACCT1_PASS=thepassword
  export ACCT2_PASS=theotherpassword
  export ACCT3_PASS=yetanotherpassword
 
 Then, once you've encrypted it, you can create a wrapper command for 
 mutt that will decrypt it and use it to put those passwords into 
 mutt's environment:
 
  #!/bin/sh
  pwds=`gpg --decrypt ~/.passwords`
  eval $pwds
  exec mutt $@
 
 And finally, in your muttrc, you can simply have things like this:
 
  set imap_pass=$ACCT1_PASS
 
 or:
 
  account-hook account2 'set imap_pass=$ACCT2_PASS'
 
 Thus, you will be prompted once for a passphrase when mutt loads, and 
 after that mutt will use those passwords as it needs them without 
 additional overhead. Nothing will be stored in plaintext on disk, your 
 encryption is guaranteed to be world-class, and best of all: it will 
 work on virtually any Unix machine.
 
  But how about storing a whole encrypted muttrc file and letting mutt 
  to decrypt it with some passphrase ?
 
 That seems like overkill to me.
 
 ~Kyle
 -- 
 All we have to decide is what to do with the time that is given us.
 -- Gandalf the Grey


Re: mutt and plaintext passwords : muttrc encryption ?

2008-07-28 Thread Michele Martone
ehm. one more thing.
how would you deal with the MTA with the wrapper-based solution ?

i know only of :

using nbsmtp, in a dangerous way:
set sendmail=nbsmtp -P password ...

using ssmtp , in a dangerous way:
set sendmail=ssmtp -ap password ...

or using msmtp with 'password' fields unset in the .msmtprc file,
waiting for prompting (never worked to me though)

On [EMAIL PROTECTED]:53, Michele Martone wrote:
 this seems almost perfect to me. marvelous, elegant, general, thanks !
 ..


Re: mutt and plaintext passwords : muttrc encryption ?

2008-07-28 Thread Kyle Wheeler
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Monday, July 28 at 09:53 PM, quoth Michele Martone:
 this seems almost perfect to me. marvelous, elegant, general, thanks ! 
 (so i do not dare to quote a piece of your email ..)

Happy to help!

 still I can't stand the need of a wrapper.. if only one could use 
 multi line shell expansion, and place that `gpg --decrypt` straight 
 into the muttrc.

Well, I thought about that. We can solve it, but there are drawbacks 
(such as needing other software, or using a temporary file).

For example, if you use gpg-agent to store your passphrase, then you 
can encrypt each password as its own file:

 echo password | gpg --encrypt -o ~/.acct1_pass
 echo password2 | gpg --encrypt -o ~/.acct2_pass

Then put this into your muttrc:

 set my_acct1_pass=`gpg --decrypt ~/.acct1_pass`
 set my_acct2_pass=`gpg --decrypt ~/.acct2_pass`

 account-hook account2 'set imap_pass=$my_acct2_pass'

The key to making that convenient, though, is using gpg-agent to store 
your passphrase (so you don't have to enter it multiple times). 

If mutt could pass $my_* variables into shell escapes (or could 
directly manipulate its own variables the way that bash can (e.g. 
${my_acctpwds#*:})), then you could try using a separator character in 
your passwords (such as a colon) and then figure them out within the 
muttrc. For example, you could create the encrypted file like so:

 echo password1:password2 | gpg --encrypt -o ~/.acctpwds

Then put this in your muttrc:

 set my_acctpwds=`gpg --decrypt ~/.acctpwds`
 set my_acct1_pass=`echo $my_acctpwds | cut -d: -f1`
 set my_acct2_pass=`echo $my_acctpwds | cut -d: -f2`

But, of course, since you can't do that... c'est la vie. :)

Now, it's also possible to use a temporary file to do this:

 set my_acctpwds=`gpg --decrypt ~/.acctpwds  ~/tmp/acctpwds`
 set my_acct1_pass=`cut -d: -f1 ~/tmp/acctpwds`
 set my_acct2_pass=`cut -d: -f2 ~/tmp/acctpwds ; rm ~/tmp/acctpwds`

But that's obviously suboptimal if you're trying to avoid ever having 
that stuff on disk in plain text. It may be more acceptable if you 
have a memory-only filesystem somewhere (such as tempfs on Linux), but 
we're getting into the realm of specialized software again.

~Kyle
- -- 
I am ready to meet my Maker. Whether my Maker is ready for the great 
ordeal of meeting me is another matter.
   -- Winston Churchill
-BEGIN PGP SIGNATURE-
Comment: Thank you for using encryption!

iEYEARECAAYFAkiOOPYACgkQBkIOoMqOI17KYwCeKXdZMcTLvL/yDoLib7TrQXR9
BasAoJxchtRVq0yZfSs77uX5nUMRYk1v
=EBqZ
-END PGP SIGNATURE-


Re: mutt and plaintext passwords : muttrc encryption ?

2008-07-28 Thread Michael Kjorling
On 28 Jul 2008 21:53 +0100, by [EMAIL PROTECTED] (Michele Martone):
 still I can't stand the need of a wrapper.. if only one could use
 multi line shell expansion, and place that `gpg --decrypt` straight into
 the muttrc.

I haven't tried it, but I can't get it out of my head... wouldn't
sourcing through a pipe something that sets the sensitive stuff work?

Something like this:

source gpg -d sensitivestuff.gpg |

and sensitivestuff being just another muttrc snippet.

It would only execute the pipe once, so you avoid the problem of
needing to type your passphrase multiple times, and it *should* not
write anything to disk in plain text.

Since nobody has suggested this approach - what is wrong with it?

-- 
Michael Kjörling .. [EMAIL PROTECTED] .. http://michael.kjorling.se
* . No bird soars too high if he soars with his own wings . *
* ENCRYPTED email preferred -- OpenPGP key ID: 0x 758F8749 BDE9ADA6 *
* ASCII Ribbon Campaign: Against HTML mail, proprietary attachments *



signature.asc
Description: Digital signature


Re: mutt and plaintext passwords : muttrc encryption ?

2008-07-28 Thread Kyle Wheeler
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Monday, July 28 at 10:13 PM, quoth Michele Martone:
ehm. one more thing.
how would you deal with the MTA with the wrapper-based solution ?

Personally? I'd compile mutt with smtp support and be done with it.

i know only of :

using nbsmtp, in a dangerous way:
set sendmail=nbsmtp -P password ...

using ssmtp , in a dangerous way:
set sendmail=ssmtp -ap password ...

Well, yes, those are the most obvious.

If you're game for a temp file, you could use gpg (with gpg-agent) to 
quickly decrypt a version of their config file for use, and then 
delete it... but that'll require an MTA wrapper too (this is as 
complex and undesirable a solution as they get, eh?). For example:

 #!/bin/sh
 gpg --decrypt ~/.msmtprc.gpg -o ~/.msmtprc
 msmtp $@
 retval=$?
 rm ~/.msmtprc
 exit $retval

Nothing else leaps to mind.

~Kyle
- -- 
I know God will not give me anything I can't handle. I just wish that 
He didn't trust me so much.
  -- Mother Theresa
-BEGIN PGP SIGNATURE-
Comment: Thank you for using encryption!

iEYEARECAAYFAkiOOpoACgkQBkIOoMqOI17/ZQCeJGqFahZMeg0U1KrYHvUiZUxx
3JkAoMRLeUHAOiPoVdyMxrvDi7b7edkf
=a0aJ
-END PGP SIGNATURE-


Re: mutt and plaintext passwords : muttrc encryption ?

2008-07-28 Thread Michele Martone
`figlet yes, this is THE solution, working. perfect.`

thank you guys, now I'll learn to use mutt with smtp features (hope
tls/ssl is in) and I'll drop some line if Kyle won't do this already :)

On [EMAIL PROTECTED]:29, Michael Kjorling wrote:
 On 28 Jul 2008 21:53 +0100, by [EMAIL PROTECTED] (Michele Martone):
 ...
 source gpg -d sensitivestuff.gpg |
 
 and sensitivestuff being just another muttrc snippet.


Re: mutt and plaintext passwords : muttrc encryption ?

2008-07-28 Thread Kyle Wheeler
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Monday, July 28 at 09:29 PM, quoth Michael Kjorling:
 I haven't tried it, but I can't get it out of my head... wouldn't 
 sourcing through a pipe something that sets the sensitive stuff 
 work?

 Something like this:

 source gpg -d sensitivestuff.gpg |

No. That can't work (but we can salvage this idea). First, let me 
explain why it can't work.

Think about it: what does the source command tell mutt to do? It 
tells mutt read the file with the following name. Even in situations  
where ending an item in a pipe means something to mutt, it means use 
the output of this command in place of this variable whenever you need 
it. This is useful for doing things such as set 
signature='fortune|'. That is very similar to set 
signature=`fortune`, with the ONLY difference being that in the first 
case (with the pipe), mutt runs the command every time it needs the 
value of $signature whereas (in the case of backtics) mutt runs it 
only when reading the muttrc file.

With that in mind, re-examine the idea of using source. Does it make 
sense to say use the output of this command whenever you need the 
value of ... source?.

What you're looking for is something like the equivalent of an eval 
command, instead of source (if you've done much shell scripting, 
you'll understand the difference), because that's the usual name of a 
command meaning treat the following string as a set of commands, and 
execute/evaluate the commands. Unfortunately, mutt doesn't have an 
eval equivalent---largely because mutt's rc file is not a scripting 
language (and probably never will be), even though it sometimes seems 
like it is.

That said, there is something to be said for your idea. Check this 
out: what you CAN do is get mutt to use a named pipe. Like so (I'm 
separating the commands to keep my lines short; you can combine most 
of these):

 set my_mkfifo=`mkfifo -m 600 ~/.muttfifo`
 set my_decryptit=`gpg --decrypt ~/.mutt.gpg -o ~/.muttfifo`
 source ~/.muttfifo
 set my_cleanup=`rm ~/.muttfifo`

Eh? Eh? Nice, no? ;)

Come to think of it, we could do the same thing with all my temp-file 
ideas. And we can even handle MTAs this way:

 # this is all one line:
 set sendmail=rm -f ~/.msmtprc; mkfifo -m 600 ~/.msmtprc; gpg
 --decrypt ~/.msmtprc.gpg -o ~/.msmtprc; msmtp

~Kyle
- -- 
Genius may have its limitations but stupidity is not thus handicapped.
  -- Elbert Hubbard
-BEGIN PGP SIGNATURE-
Comment: Thank you for using encryption!

iEYEARECAAYFAkiOP5gACgkQBkIOoMqOI15G2gCfVPc/1UAVZyVrt3G826OBusVh
NV8AoPQGMirMA1YP6etWragGUXrDNryD
=MOIv
-END PGP SIGNATURE-


Re: mutt and plaintext passwords : muttrc encryption ?

2008-07-28 Thread Derek Martin
On Mon, Jul 28, 2008 at 12:58:00PM -0500, Kyle Wheeler wrote:
 Thus, you will be prompted once for a passphrase when mutt loads, and 
 after that mutt will use those passwords as it needs them without 
 additional overhead. 

...unless bash swaps its environment out... ;-)

-- 
Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.



pgprqQqxx1Mnf.pgp
Description: PGP signature


Re: mutt and plaintext passwords : muttrc encryption ?

2008-07-28 Thread Derek Martin
Man, was my last message mis-quoted!  What I meant was this:

On Mon, Jul 28, 2008 at 12:58:00PM -0500, Kyle Wheeler wrote:
 Nothing will be stored in plaintext on disk, your encryption is
 guaranteed to be world-class, and best of all: it will work on
 virtually any Unix machine.

...unless bash swaps out the environment...

Yay!

-- 
Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.



pgpMeYNdAfu3n.pgp
Description: PGP signature


Re: mutt and plaintext passwords : muttrc encryption ?

2008-07-28 Thread Kyle Wheeler
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Monday, July 28 at 07:56 PM, quoth Derek Martin:
On Mon, Jul 28, 2008 at 12:58:00PM -0500, Kyle Wheeler wrote:
 Nothing will be stored in plaintext on disk, your encryption is
 guaranteed to be world-class, and best of all: it will work on
 virtually any Unix machine.

...unless bash swaps out the environment...

... why, in that example, would bash do that?

Presumably, you can avoid that by removing the exec keyword in the 
script?

~Kyle
- -- 
Disobedience, in the eyes of any one who has read history, is man's 
original virtue. It is through disobedience that progress has been 
made, through disobedience and through rebellion.
 -- Oscar Wilde
-BEGIN PGP SIGNATURE-
Comment: Thank you for using encryption!

iEYEARECAAYFAkiOlIAACgkQBkIOoMqOI14g5wCguE3Y/FMTc2v80CRjGJiddIpA
rZMAoI9dbPP6ObtfO/ROwiTTHQk8uiKl
=MYku
-END PGP SIGNATURE-