first, thanks for replying. and thanks for monitoring the debian list. it gives me a warm feeling to know that this critical program is being maintained.
On 5/26/05, Werner Koch <[EMAIL PROTECTED]> wrote: > GnuPG requires is home directory for internal purposes and you should > not fiddle around with it. We can't use /var/lib/gnupg because these i absolutely understand and agree. that is why i need an --export-homedir option to be certain that i do not unintentionally fiddle with the contents of that directory with my homegrown --export/--export-secret-key/... attempts. i am especially concerned that those commands are, or will be in the future, insufficient to export the homedir exactly. you see, i need the script to contain everything gpg might need on the other end. if a user of the script has a corrupted .gnupg, it will not work. but if i include it in the script, everything will be ok. > Using this data is on your own risk. There is a documented interface > on how to access it (--export/--import etc.). You are on your own if does that documented interface export the homedir without leaving anything out or changing anything? will it after 1.9? my problem is that currently i have to use 3 export commands (pub, sec, trust) to even attempt this. and i fear 1.9 now. will i have to use 4 or more commands to export it? will it be exportable? the rest of this message is a reply to your thoughtful comments. the above is my biggest issue. > BTW, never ever look at any data printed for human reading - scripts > need to parse the --status-fd and --with-colon output. For thanks for the pointer. i am not currently having the script look at human-readable output -- it just passes it to the human or log. however, it should bail at problems. i assume (and hope) that you consider the output of --armor --export, etc. to be machine-readable. > controlling gpg aside from this, the --command-fd/--status-fd > interface is the way to go. Please don't use canned commands but > parse the requests seen on --status-fd before sending commands to gpg > - if there is something you can't cope with: bail out. Note that in > most cases using the default response (which is sending an empty > string) leads to proper results. i will use those if i ever need to parse output. now all i do is verify the resulting encrypted file manually occasionally. btw, i found no gpg command that will verify that a file was properly encrypted after it has been created. that would be nice after a pipeline. i suppose the solution is to try to decrypt, then exit successfully when it wants a pass phrase. i notice that --with-key-data is documented to "print the public key data". i assume it just means the meta data -- not the key itself. is that right? for documentation i am using the gnupg package and the gnupg-doc package. if it is the key itself, there appears to be no equivalent for secret keys, trust db, etc. > Salam-Shalom, indeed.
