-=| Kurt Roeckx, Wed, Jan 28, 2009 at 11:12:20PM +0100 |=- > On Wed, Jan 28, 2009 at 11:52:18PM +0200, Damyan Ivanov wrote: > > > However those functions can also return -1 on failure. This > > > would then mean that other applications making use of this > > > could wrongly check the return value. > > > > Since $dsa->verify(...) croaks in underlying OpenSSL call returns -1, > > it seems to me that croaking in do_verify(...) is the right thing to > > do. > > > > From what I understand, verify() and do_verify() only differ in what > > they accept as parameters, otherwise the semantic is the same -- > > verify a signature. > > > > Does in your opinion (1) patching do_verify() to croak if underlaying > > library call returns -1, (2) documenting the fact that both verify() > > and do_verify() may croak and (3) sending the patch upstream, would > > fix the bug? > > I have no idea what croak does exactly, but if it's some > mechanisme to report error conditions, like a throw in C++, > it might be a good way of doing it.
Sufficiently similar, yes.
> But then I have to wonder why croak isn't called in case
> of a 0 return value. Both 0 and -1 are error cases. And
> most applications don't care if 0 or -1 was returned.
From crypto/dsa/dsa_vrf.c (openssl source):
/* returns
* 1: correct signature
* 0: incorrect signature
* -1: error
*/
(and this is for both verify() and do_verify()
I think the intention in the perl wrappers is to mimic underlaying
functionality -- tell you if a signature is valid via the return value
-- except that it throws an exception if -1 is returned in order to
signal the error condition.
So I think my propposal above is still good for Crypt::OpenSSL::DSA.
Whether the code that uses it checks the [do_]verify() return code (or
is prepared to handle the exception) is a whole new research.
The only package declaring dependency on libcrypt-openssl-dsa-perl is
libnet-dns-sec-perl.
--
dam JabberID: d...@jabber.minus273.org
signature.asc
Description: Digital signature
