Discussion:
Upgrade from GnuPG 1.4.5 to 1.4.9 breaks signature veerification
(too old to reply)
Ron Cook
2009-04-15 00:47:06 UTC
Permalink
Hi.

I've been scouring the gnupg-users mail archives but haven't yet seen
a solution to this.

One of our clients recently upgraded their production installation of
GnuPG 1.4.5 to version 1.4.9. They send encrypted / signed files to
us almost daily for real-time financial processing.

Prior to their upgrade, files received from them passed signature
verification and decrypted successfully in our production installation
of PGP 6.x, circa 1999-2000. Since the upgrade, signature
verification fails.

They've not changed their key and manual decryption / verification
works correctly through a stand-alone GnuPG 1.4.9.

It took a while for us to get them to admit to the upgrade; now they
can't recall if they had any specific command line options in place
that might not have been replicated to the new version.

Might anyone have any ideas as to anything we can suggest to them, or
any comments as to what might have changed in their process?

Feel free to request more information. If I can provide it without
violating my employer's NPI regulations, I'll be glad to do so.

Thank you.

Ron Cook
***@mac.com
Speechless
2009-04-15 14:57:38 UTC
Permalink
Hi.
I've been scouring the gnupg-users mail archives but haven't yet seen a
solution to this.
One of our clients recently upgraded their production installation of
GnuPG 1.4.5 to version 1.4.9. They send encrypted / signed files to us
almost daily for real-time financial processing.
Prior to their upgrade, files received from them passed signature
verification and decrypted successfully in our production installation
of PGP 6.x, circa 1999-2000. Since the upgrade, signature verification
fails.
See: http://www.gnupg.org/documentation/faqs.en.html#q5.1
They've not changed their key and manual decryption / verification
works correctly through a stand-alone GnuPG 1.4.9.
Encrypting manually uses the user's (most likely the system administrator's
personal) configuration file. Encrypting in batch mode via a cron job
uses the system's default global configuration file (if they set one up
after their upgrade; otherwise, they are just using GnuPG program defaults,
whatever they may be). Obviously, the two configuration files are not
identical.
It took a while for us to get them to admit to the upgrade; now they
can't recall if they had any specific command line options in place that
might not have been replicated to the new version.
Might anyone have any ideas as to anything we can suggest to them, or
any comments as to what might have changed in their process?
Feel free to request more information. If I can provide it without
violating my employer's NPI regulations, I'll be glad to do so.
Thank you.
Ron Cook
Ron Cook
2009-04-16 00:14:22 UTC
Permalink
Post by Speechless
Hi.
I've been scouring the gnupg-users mail archives but haven't yet seen a
solution to this.
One of our clients recently upgraded their production installation of
GnuPG 1.4.5 to version 1.4.9. They send encrypted / signed files to us
almost daily for real-time financial processing.
Prior to their upgrade, files received from them passed signature
verification and decrypted successfully in our production installation
of PGP 6.x, circa 1999-2000. Since the upgrade, signature verification
fails.
See: http://www.gnupg.org/documentation/faqs.en.html#q5.1
They've not changed their key and manual decryption / verification
works correctly through a stand-alone GnuPG 1.4.9.
Encrypting manually uses the user's (most likely the system administrator's
personal) configuration file. Encrypting in batch mode via a cron job
uses the system's default global configuration file (if they set one up
after their upgrade; otherwise, they are just using GnuPG program defaults,
whatever they may be). Obviously, the two configuration files are not
identical.
< snipped >

I appreciate the info.

We have a test build of our production software using a newer SDK
which will correctly verify and decrypt the files.

If it can't be put into use quickly, I can use a couple of utilities I
wrote to do the same job, but they're not coded for high volume.

I'll have our business contacts convey the options in the FAQ to our
client, as well.

Thank you.

Ron Cook
***@mac.com

Loading...