Skip Menu |

This queue is for tickets about the GnuPG CPAN distribution.

Report information
The Basics
Id: 58059
Status: open
Priority: 0/
Queue: GnuPG

People
Owner: Nobody in particular
Requestors: jjperry [...] water.com
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in: 0.17
Fixed in: (no value)



Subject: wrong response from gnupg (expected SHM_INFO)
On HP-UX 11.11 64-bit PA-RISC (HP-UX myhost B.11.11 U 9000/800) with Perl 5.8.8 from HP and on Ubuntu 10.04 with Perl 5.10.1 and found that if the file was not found threw the error: wrong response from gnupg (expected SHM_INFO): at /opt/perl_32/lib/site_perl/5.8.8/GnuPG.pm line 154 GnuPG::abort_gnupg('GnuPG=HASH(0x40017288)', 'wrong response from gnupg (expected SHM_INFO): \x{a}') called at /opt/perl_32/lib/site_perl/5.8.8/GnuPG.pm line 219 GnuPG::run_gnupg('GnuPG=HASH(0x40017288)') called at /opt/perl_32/lib/site_perl/5.8.8/GnuPG.pm line 723 GnuPG::decrypt('GnuPG=HASH(0x40017288)', 'ciphertext', '/home/test/aTESTFILE.pgp', 'output', '/home/test/TESTFILE', 'passphrase', 'test') called at ./gpgtest.pl line 6 eval {...} called at ./gpgtest.pl line 6 My script is here below. #!/usr/bin/perl use GnuPG qw( :algo ); my $gpg = new GnuPG(); print "in\n"; eval { $gpg->decrypt( ciphertext => "/home/test/aTESTFILE.pgp", output => "/home/test/TESTFILE 1546", passphrase => "mytest" ); }; print $@; print "out\n"; When printing $@ from the eval I get the output below, as I would expect from GnuPG since the file /home/test/aTESTFILE.pgp does not exist: error setting up data input: No such file or directory When I do provide the correct file name, /home/test/TESTFILE.pgp it decrypts properly to the /home/test/TESTFILE.
I believe this to be expected behavior, based on my predecessor's documentation here: The API is accessed through methods on a GnuPG object which is a wrapper around the gpg program. All methods takes their argument using named parameters, and errors are returned by throwing an exception (using croak). If you wan't to catch errors you will have to use eval. The reason two errors are being thrown is because the child and parent process are both dying, resulting in the two forks both continuing. This twin-fork behavior would not happen if an eval was not in use. I admit this is a peculiar scenario you've stumbled upon, and I spent some time looking into it, but I see no simplistic way of resolving it. Since it is a "weird error" being thrown in an error case, I think Im going to let it be.
Subject: RE: [rt.cpan.org #58059] wrong response from gnupg (expected SHM_INFO)
Date: Wed, 2 Jun 2010 14:12:55 -0400
To: <bug-GnuPG [...] rt.cpan.org>
From: "Perry, James J." <jjperry [...] water.com>
Maybe I specified it a bit wrong here but it only happens when the file to decrypt is not present. I understand the error but instead of just logging and continuing, it is killing the parent script as well so no further processing / error handling / email alerts can be generated. I tried it both with eval and without to find I get the same error, but without eval I do not have any details as to the cause of the error, i/e file not found. Thanks! -Jim Show quoted text
-----Original Message----- From: Mark Frost via RT [mailto:bug-GnuPG@rt.cpan.org] Sent: Wednesday, June 02, 2010 2:08 PM To: Perry, James J. Subject: [rt.cpan.org #58059] wrong response from gnupg (expected SHM_INFO) <URL: https://rt.cpan.org/Ticket/Display.html?id=58059 > I believe this to be expected behavior, based on my predecessor's documentation here: The API is accessed through methods on a GnuPG object which is a wrapper around the gpg program. All methods takes their argument using named parameters, and errors are returned by throwing an exception (using croak). If you wan't to catch errors you will have to use eval. The reason two errors are being thrown is because the child and parent process are both dying, resulting in the two forks both continuing. This twin-fork behavior would not happen if an eval was not in use. I admit this is a peculiar scenario you've stumbled upon, and I spent some time looking into it, but I see no simplistic way of resolving it. Since it is a "weird error" being thrown in an error case, I think Im going to let it be. Proud partner. Susan G. Komen for the Cure. Please consider our environment before printing this e-mail or attachments. ---------------------------------- CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you. ----------------------------------