setting up environmental variable?

[Tie Kan]

-----Original Message-----
 All tests are run with the following environment:

> GNUPGHOME=.
> srcdir=$(srcdir)

After I export GNUPGHOME=., all the test programs run smoothly.

There is still something I do not get:

What I am doing
--------------
I am trying to encrypt a file with a "user name" in a pubring.pgp file I
specify. As a result, I am only working intensively with the sample
program t-encrypt.c)

The basic problem I encountered is error "No recipient" when calling
function

	 Gpgme_recipients_add_name_with_validity


1. GNUPGHOME
-------------
My understanding is environmental "GNUPGHOME" specifies which
"pubring.gpg" and "secring.gpg" are used as default key-rings. For
example, command line

	GNUPGHOME=/usr/local/src/gpgme/tests/gpg gpg --list-keys

List all the keys in file /usr/local/src/gpgme/tests/gpg/pubring.gpg

In t-encrypt.c, we have

Gpgme_recipients_add_name_with_validity(rset, "Alpha",
GPGME_VALIDITY_FULL);

Here, the key used to for encryption is "Alpha". However, "Alpha" is not
listed as a user name in the pubring.gpg. It is listed as "Alpha Test"
when I run the above. There is a directory called "Alpha" and a file
Alpha/pubring.gpg inside this directory. 

My question is where exactly is this user name "Alpha" coming from? It
can not be from /usr/local/src/gpgme/tests/gpg/pubring.gpg or
/usr/local/src/gpgme/tests/Alpha/pubring.gpg because there is user name
"Alpha". If it is from the "Alpha" directory, then do we need another
environmental variable, like "srcdir" to specify where directory "Alpha"
is located (relative to $GNUPGHOME) ? 

Because neither explanation sounds reasonable to me, I am sure I am
completely messed up this subject: 

	How do I determine which "user name" to use in function
gpgme_recipients_add_name_with_validity


2. srcdir
----------
I really do not know how srcdir is used. I tried to write some C code by
using my own pubring.gpg by the following statement

Setenv("GNUPGHOME", "/home/tkan/.gnupg", 1);

And pick a user name, say "tkan_test", which is a user name in file
$GNUPGHOME/pubring.gpg, and pass it to function 

gpgme_recipients_add_name_with_validity  

This, however, occasionally give me error "No Receipient" (sometime it
works, sometime it does not work, most of time I am lost). Later in step

Gpgme_op_encrypt

I get "General Error", which I believe to be a direct consequence of the
"No Recipient" error. 

3. Choose "user name" for functions gpgme_recipients_add_name*
-------------------------------------------------------------
I think if I set "GNUPGHOME" and "srcdir" correctly and use the correct
pubring.gpg, I should able to add recipients successfully. But I really
do not know how. I have been trying this for several days and still can
not come to any conclusion. (help!)

Could you please help me to point out that if I set "GNUPGHOME" and
there is a pubring.gpg file in $GNUPGHOME directory and the command

GNUPGHOME=/my/pub/ring/directory gpg --list-keys

Gives something similar to 

Pub  1024D/75462AA6  2001-12-12  Test_key1 test at dot.com
Sub  1024g/B21E925D  2001-12-12

Which user name I need to put for 

gpgme_recipients_add_name_*

so that I will not get "No Recipient" error?

Thank you very much,

Tie 

=================================

PS. 

There is another constraint in current gpgme library:

If we do "chroot" prior to gpgme_check_engine call and the changed root
directory is not '/', gpgme_check_engine always returns error "invalid
engine". 

For example, in the following code segment (from t-encrypt.c):

...
chroot("/tmp");
gpgme_check_engine();
gpgme_new(&ctx);
...

gpgme_check_engine() always return error "invalid engine".

But this can be countered by keeping an open file descriptor which is
located outside the chroot-jail, say old_root_directory, escaping
chroot-jail with the open file descriptor, chdir(..) as many time as
necessary to the real, system root directory, then chroot("."). Call
whatever gpgme API. After all is done, chroot(old_root_directory).

It is an ugly hack, but it works so far.