I've written one of the many programs that want to drive pgp & gpg directly
(see http://www.bell-labs.com/nsbd). It's very difficult to do that,
because none of the implementations seem to be designed for that (perhaps
pgp5 is, I haven't tried that enough yet), and they're all different.
Everybody who writes a driving program has to deal with all these issues
over again. It would be very nice if there were a common API for these
programs.
The different command line syntax is not nearly as big a problem as trying
to parse the results of the output. The parsing algorithms are very much
of a hack and very fragile because the output changes from version to version.
These programs also produce extraneous output that are not always useful,
and it can be very tricky to distinguish an error message or warning message
that the user should see from something that can be ignored.
My particular problem right now is that pgp 2.6.2 and pgp 4.0 always precede
an error or warning with ERROR: or WARNING: but gpg does not (it's sometimes
hard to tell where the error or warning *ends* with pgp, but that's another
story). The one I just noticed was "Can't check signature: Public key not
found". I guess I will have to assume that anything that is preceded with
"gpg:" but does not start "Warning:" or "WARNING:" or "Good signature" or
"Signature made" is an error.
I don't think the shared memory interface that Werner mentioned recently
will be a very good solution. It's very hard to do that portably. I
think the best thing would be to define a simple "protocol" that a program
can use to communicate with gpg. The "messages" to gpg can be in the
form of command line options, but the results should be well-defined.
- Dave Dykstra
(see http://www.bell-labs.com/nsbd). It's very difficult to do that,
because none of the implementations seem to be designed for that (perhaps
pgp5 is, I haven't tried that enough yet), and they're all different.
Everybody who writes a driving program has to deal with all these issues
over again. It would be very nice if there were a common API for these
programs.
The different command line syntax is not nearly as big a problem as trying
to parse the results of the output. The parsing algorithms are very much
of a hack and very fragile because the output changes from version to version.
These programs also produce extraneous output that are not always useful,
and it can be very tricky to distinguish an error message or warning message
that the user should see from something that can be ignored.
My particular problem right now is that pgp 2.6.2 and pgp 4.0 always precede
an error or warning with ERROR: or WARNING: but gpg does not (it's sometimes
hard to tell where the error or warning *ends* with pgp, but that's another
story). The one I just noticed was "Can't check signature: Public key not
found". I guess I will have to assume that anything that is preceded with
"gpg:" but does not start "Warning:" or "WARNING:" or "Good signature" or
"Signature made" is an error.
I don't think the shared memory interface that Werner mentioned recently
will be a very good solution. It's very hard to do that portably. I
think the best thing would be to define a simple "protocol" that a program
can use to communicate with gpg. The "messages" to gpg can be in the
form of command line options, but the results should be well-defined.
- Dave Dykstra