I suppose I'll have to write my own program. :-)
IMHO, this is a borderline bug. If it returns success when the verify
fails, when would it return failure? It feels like a waste of a useful
return code.
Most programs return non-zero for a failure. E.g., diff returns
non-zero if there's a difference. grep return non-zero if it doesn't
find anything.
Non-zero doesn't mean 'the app didn't work correctly.' It means
something useful specific to the application. In the case of 'openssl
verify', what makes sense to me would be:
0 - verified
non-zero - didn't verify
On 11/4/2012 10:51 AM, Felipe Blauth wrote:
OpenSSL app worked as expected, and that is what 0 means (EXIT_SUCCES)
in C programming. The fact that verification wasn't successful does not
mean OpenSSL app didn't work correctly. I think you either have to write
your own app (or maybe just modifiy OpenSSL verify app to return what
you want) or parse the textual return of the app (which is not very
good, IMO).
2012/11/2 Ken Goldman <kgold...@us.ibm.com
<mailto:kgold...@us.ibm.com>>
In testing my regression tests, I supply a bad CA certificate to
force the verify to fail.
I use:
> openssl verify -CAfile cacert.pem cert.pem
It printed this, which I expected.
"error 20 at 0 depth lookup: ..."
However, when my bash script checks the return code, it is still 0.
I was hoping for a non-zero error return to catch real errors later.
A bug? If not, what's the correct way to capture errors in a shell
script?
__________________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
<mailto:openssl-users@openssl.org>
Automated List Manager majord...@openssl.org
<mailto:majord...@openssl.org>
--
Felipe Menegola Blauth
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
