Wiggins d Anconia
wiggins at danconia.org
Wed Feb 4 14:44:39 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
> 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.
> a lot of the communication we do is over the internet.
This is the module I referenced as using a feature of GnuPG that is
deprecated. It uses the old '--run-as-shm-coprocess' switch which was
deprecated in GnuPG 1.0.7 (I believe, but couldn't find it in the
screwed up release notes) and is removed in newer releases, maybe even
1.2.x's, and I would imagine for sure in 1.3.x's (dev branch). The
replacement is to use --command-fd with --status-fd which is what the
GnuPG::Interface module uses that I referenced below. I did actually
like the GnuPG.pm interface at the time but couldn't rely on it not
working with newer GnuPG versions. Beware it may stop working at any
time and since it doesn't seem to be maintained..... Unless of course
the reigns get picked up and the module switches to use the newer
interface, though I imagine that breaks backwards compatibility for
anyone already using it....
> -----Original Message-----
> 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
> if you
> > favored one over the other.
> > my basic use will be to automate encrypting files then ftp them to a
> > 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 ;-)...
More information about the Chicago-talk