gpgme bug: verify + failed auto key retreival?

[Marcus Brinkmann]

On Wed, Jan 28, 2004 at 08:43:14PM +0100, Albrecht Dreß wrote:
> Maybe this is a too simplistic view, but looking at the log I see a  
> sequence of
>
> [GNUPG:] NODATA 1
> [GNUPG:] IMPORT_RES 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> [GNUPG:] ERRSIG D43F8AD8A1EE605F 17 2 00 1074795554 9
> [GNUPG:] NO_PUBKEY D43F8AD8A1EE605F
> 
> replies coming from gpg. If (and only if!) this is a safe indication for a  
> missing public key (#3 + 4) which could not be retreived from the key  
> server (#1 + 2), you could catch it (might make some "look ahead" code  
> necessary, though), skip messages #1 and #2 and continue processing the  
> signature as if no auto-retreive had been initiated/failed. In all other  
> cases, the return value would be "no data". This would resolve this very  
> specific but important case for real-life apps.

Well, that is obvious enough.  The problem is that this is not the
simplicistic view, but the complicated view (you indeed need to "look ahead"
and have a global view on what happens).  The simplicistic view is to look
at each line all by itself, and this is what happens right now.  It's not
impossible, nor particularly hard, to make the code more fancy and record
state information, but that's really ugly.  If such a work around is
necessary, I'd rather just ignore NO_DATA and thus fail silently on invalid
input or something like that.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    marcus at gnu.org
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
Marcus.Brinkmann at ruhr-uni-bochum.de
http://www.marcus-brinkmann.de/