'make check' fails in latest CVS

[Brian Warner]

I updated my CVS tree yesterday and noticed that the self tests are now
failing:


PASS: sigs.test
PASS: sigs-dsa.test
(../g10/gpg --homedir . -o y --yes x) failed
gpg: NOTE: this is a development version!
gpg: NOTE: secret key 2E5FA4F4 is NOT protected.

gpg: Segmentation fault caught ... exiting
FAIL: encrypt.test
(../g10/gpg --homedir . --keyring ./pubring.pkr --secret-keyring ./secring.skr -o y --yes x) failed
gpg: NOTE: this is a development version!
gpg: NOTE: secret key 2E5FA4F4 is NOT protected.
gpg: NOTE: secret key 439F02CA is NOT protected.

gpg: Segmentation fault caught ... exiting
FAIL: encrypt-dsa.test
gpg: DBG: pop_filter called in set_block_mode - please report
gpg: DBG: pop_filter called in set_block_mode - please report
gpg: DBG: pop_filter called in set_block_mode - please report
(../g10/gpg --homedir . -o y --yes x) failed
gpg: NOTE: this is a development version!
gpg: NOTE: secret key 2E5FA4F4 is NOT protected.
gpg: Signature made Sat Jan  9 05:32:21 1999 PST using ELG-E key ID 9D266E0F
gpg: Good signature from "Test one (pp=def) <one at test.nowhere.nil>"

gpg: Segmentation fault caught ... exiting
FAIL: seat.test


The problem appeared just recently; by backing out the following files (which
appear to be an atomic set of changes that all require one another), I can get
an image that tests cleanly:

g10/armor.c                                         1.39t      Up-to-date
g10/compress.c                                      1.19t      Up-to-date
g10/encr-data.c                                     1.12t      Up-to-date
g10/filter.h                                        1.25t      Up-to-date
g10/plaintext.c                                     1.23t      Up-to-date
util/iobuf.c                                        1.33t      Up-to-date


I haven't traced it further than that.. if nobody else is seeing this problem
I'll crank up the debugger and see what the problem is.

In other news, I've been playing with a prototype of an "encryption agent", a
way to split off the secret key operations (signing and decryption) to a
separate unit (eventually to put in something portable and thus more
physically secure, a Pilot or a Java iButton or the like, but for now just as
a standalone program). I've got a simple agent protocol to send the MPIs back
and forth across some pipes, an agent program, and some hacks to GPG to use a
secret key with 0 in the secret MPIs as an indicator that it should use the
agent instead.

The basic flow:

1) create a key, a specially hacked version of keygen.c prints out the one
   secret MPI, then substitutes a zero in it before saving
2) hardcode that secret MPI along with the rest of the key into a table in
   the standalone program
3) someone encrypts a message to your public key
4) you go to decrypt it, the passphrase (if used, which is kind of pointless,
   since you're only protecting a zero) decrypts the secret MPI, elgamal.c's
   decrypt routine notices that the MPI is zero and calls the agent-calling
   function.
5) some pipes are created, a fork happens, an exec, and now the standalone
   agent is run in a separate process. A request code and the public MPIs
   (and the encrypted session key) are sent in on stdin. The agent looks up
   the public MPIs in its table to find the corresponding secret MPI. It
   decrypts the session key and writes out the resulting MPI on stdout.
6) the agent-calling code shuts down the pipes, and returns the MPI as if it
   had decrypted it all by itself.

The eventual idea is to replace the agent program with an arbitrary program,
one that might turn the request into a message sent to a Pilot or whatever.

I managed to get it to decrypt a message properly. But the key generation has
to be hacked up, and both the location of the agent program and the keys that
it knows about are all hardcoded.

Anyway, just wanted to share what I'd been working on in case it interested
anyone.

cheers,
 -Brian