On Sat, Feb 09, 2002 at 05:37:19AM -0500, [EMAIL PROTECTED] wrote:
> I agree that what you wish to accomplish (having mutt automatically
> encrypt a file that you attach for sending) should be possible. My
> suggestion there is to get the procedure nailed down manually and then
> try working on converting it to a batch. I can't tell from your messages
> whether or not you've done the former and where your problems are coming
> up.
Sorry, perhaps I haven't explained myself well enough.
I currently have two problems (with mutt and GPG anyway), hence two threads.
The first one (concerning this thread) is unrelated to the batching/scripting
problem. I am simply unable to send a GPG-encrypted mail. I create the
mail as usual, but just before hitting 'y' to send, I hit 'p' for the PGP
menu, and then 'e' to encrypt, and 'y' to send the mail. It appears to
encrypt the message OK - output log is as follows:
gpg: using secondary key 633D8B16 instead of primary key DC303048
gpg: No trust check due to --always-trust option
gpg: reading from `/tmp/mutt-tabby-24101-130'
gpg: writing to `-'
gpg: ELG-E/RIJNDAEL encrypted for: 633D8B16 David Smith (STMicroelectronics)
<[EMAIL PROTECTED]>
Press any key to continue...
However, when I receive the 'encrypted' mail, it comes as two parts as per
the pgp/mime standard - the first attachment is correct, but the second
(which should contain the message) is about 6 blank lines base-64 encoded
(i.e. I can push the attachment through 'mimencode -d', and I get 6 blank
lines out).
I've tried running the command specified in "pgp_encrypt_only_command" from
the command line, and it works OK. I've even tried modifying the
pgp_encrypt_only_command so that it pipes the output from GPG through tee
before giving it back to mutt - the output comes out from GPG OK, but
mutt simply isn't attaching it.
GPG signing works fine - I can sign mails (like this one), but I just can't
encrypt them.
> However, I have myself done much the same thing. I always had multiple
> files and batched them up (since this was a backup script), so I just
> collected them into a tar file, encrypted it with a special backups key,
> and then sent that file as an attachment; when I got to work (where there
> was lots of drive space :-) it was a simple matter of detaching the
> file and then extracting the tar file; that was driven by script (to
> make the proper directory and such) and all I had to do was provide the
> passphrase.
>
> I don't know what sort of work you have to do at home, but if it involves
> sending files back to work you probably aren't in read-only mode, and so
> a tar file might work well for you. Another thing I did once things got
> too large for mailing was to put the encrypted tar file into an ftp dir
> and have a script connecting every five minutes watching for it to pull
> it over; all I had to do was drop the batch into place and it would soon
> enough get copied over. You could do this in two directions :-)
There are two things I want to do. The first is to continue to work as
normal - sending mails with or without attachments from work to home and
vice-versa - but with all mail over the link GPG-encrypted. I know that
I can use hooks to specify that all mail to a particular address should
be PGP-encrypted, so I'm assuming that I can just set up mutt so that I
don't really see any difference (except that I'll have to type in the
passphrase when I want to read a mail).
The second is that I want to write a script - something like 'mail_to_home'
that can be added to any script that I'm running, to send an arbitrary file
to my home address - usually a logfile or something similar. My work
involves large CPU and memory-intensive runs (between 6 and 24 hours each),
and it's a real bummer to come in the next morning to find out that the
jobs you set running just before leaving the night before crashed after
5 minutes because you spelt a variable name wrong. Being able to send
selected files home allows me to check how things are running, so I can
decide whether I need to go and fix something.
Also, as projects reach their conclusion, managers get increasingly
interested in the results of a run - if you set the run off on a Friday
night, then they'll want to know on Saturday if it's bad - if it is, then
they'll want to use the weekend to try to fix the problem, but if it's
good, then you can have a nice quiet weekend... Of course, the contents
of the files are technically confidential, so I'd rather not mail them in
plaintext.
It's also potentially useful when not in the office - most of the people
around here are not GPG-aware, so the best way of getting them to mail a
file to you securely is to give them a script that they can just run on
the file.
I suspect that I may solve the second problem outside of mutt with a
PERL script using the relevant MIME packages.
I'm not really bothered about automated reception - the whole point is that
I will be sitting wherever the reception point is. Anyway, automated
reception and saving/executing brings in extra security risks that I'm
not really tempted to introduce...
--
David Smith Tel: +44 (0)1454 462380 (direct)
STMicroelectronics Fax: +44 (0)1454 617910
1000 Aztec West TINA (ST only): (065) 2380
Almondsbury Home: 01454 616963
BRISTOL Mobile: 07932 642724
BS32 4SQ Work Email: [EMAIL PROTECTED]
Home Email: [EMAIL PROTECTED]
