pinentry

[auto15963931]

On 4/4/2012 9:50 PM, Hauke Laging wrote:
> This does not happen here (Linux, though). 

Hauke, hello. I expect when I get to the bottom of it all, I will find
the fault is caused not by Windows but by my error or need for an
adjustment of some kind. I was hoping that my description would trigger
someone's idea about a similar experience so that they could provide a
pointer to jump start my fixing the issue. Anyway, I have made some
progress.

[snip]

> However, much of the time I find that using this
> procedure does not cause the pinentry dialogue to move from one key
> to another but instead causes the dialogue window to close after
> either the first or second clicking on the cancel button instead of
> continuing on down through the complete list of keys I have
> available. It just fails to decrypt.  This failure occurs mostly
> when I first try to use the procedure, but then it starts working
> properly after a few tries even though I do exactly the same steps
> each time.  Why does it fail initially?  Is this a known issue?

This part of the problem still exists. Individually trying to decrypt a
file encrypted with throw-keyids will fail, often but not always, to try
all the keys before aborting the effort. I can prevent the problem by
using "--try-all-secrets"; but, so far as I can see, this problem arises
only during individual file decryption and not during batch decryption
procedures. At least, this has been my experience up to now.

It is a puzzling phenomenon and not apparent to me what is behind it. It
almost seems like a memory thing or caching issue, but I'm not sure, yet.

>
> I have noticed a number of instances of failures during batch
> decryption too, even though the pinentry dialogue does not arise of
> course. These failures result in the "--status-file" indicating
> that the decryption failed although in fact I can find the
> decrypted message present.

This part I have solved. My batch routine was overwriting the good
output after the routine looped through the files again.  I have changed
it now to circumvent the occurences and I get the correct results.


--