Dooley.Michael at con-way.com
Wed Feb 4 13:48:36 CST 2004
Just thought I would toss out this update.
I got GnuPG 0.09 working on solaris 8 on sparc platform. there was a bug in
the module where the authur didn't quote part of his syntax. so I did that
and it is working like a charm. kinda niCe to have this avaliable now. since
a lot of the communication we do is over the internet.
From: chicago-talk-bounces at mail.pm.org
[mailto:chicago-talk-bounces at mail.pm.org] On Behalf Of Wiggins d Anconia
Sent: Tuesday, February 03, 2004 1:55 PM
To: Chicago.pm chatter
Subject: Re: [Chicago-talk] GNUPG
> anyone use any of the modules on CPAN. there are 3 or 4. was curious
> favored one over the other.
> my basic use will be to automate encrypting files then ftp them to a host.
> then retrieve files, decrypt them to a local file name and process them.
Around a year ago I took a pretty exhaustive look at the GnuPG/OpenPGP
compatible options and came up with the following summary:
"Crypt::OpenPGP - Written in Perl using numerous other Perl modules to
simulate OpenPGP (with a gnupg compatibility setting)
GnuPG::Interface - An elegant implementation of calling gnupg from the
command line, requires gnupg to be installed on the local system.
Two other modules exist, one of which uses a deprecated feature of gnupg
that we had to avoid (and should probably be avoided and is replaced by
the module mentioned above), the other failed to install because of a
dependency problem, one we specifically wanted to avoid."
My thoughts are basically still the same. If you are looking for pure
Perl (or at least no shelling out), don't have very large files (aka
that won't fit in memory all at once), and speed isn't critical then the
first is excellent. If you are looking for complete gnupg
compatibility, or speed is a bigger issue, or you don't want to keep all
of the dependencies updated, or your files don't fit in memory, then the
second may be a better option.
In the end we used neither for a number of reasons, speed being the
primary one for the first, in the second case the 'exec' used when
calling the gnupg executable caused signal handling problems with the
rest of our app, which is conveniently based on POE (tonight's
discussion which I can't make :-( ) and using Wheel::Run to handle
simultaneous subprocessing. I suspect either would be fine for your
task. I haven't done a more recent analysis, and I am not an encryption
expert, just a Perl programmer that has to process (both directions)
lots of OpenPGP files relatively quickly.
Let me know if you have any specific questions, sorry I can't provide
code, I haven't gotten that far with this employer yet ;-)...
Chicago-talk mailing list
Chicago-talk at mail.pm.org
More information about the Chicago-talk