Fix a bug in X509_print_ex(3).
authorschwarze <schwarze@openbsd.org>
Tue, 6 Jul 2021 11:26:25 +0000 (11:26 +0000)
committerschwarze <schwarze@openbsd.org>
Tue, 6 Jul 2021 11:26:25 +0000 (11:26 +0000)
commit64d49c38248d035f69fcf5922002cce30427815f
treeab4dbdd337328cf0accbbb1dca62f04274b018ff
parentd73de46f4cc9b37e9f79d1ec059ab88427f1d5c4
Fix a bug in X509_print_ex(3).
If the user set nmflags == X509_FLAG_COMPAT and X509_NAME_print_ex(3)
failed, the error return value of 0 was misinterpreted as an indicator
of success, causing X509_print_ex(3) to ignore the error, continue
printing, and potentially return successfully even though not all
the content of the certificate was printed.

The X509_NAME_print_ex(3) manual page explains that this function
indicates failure by returning 0 if nmflags == X509_FLAG_COMPAT
and by returning -1 if nmflags != X509_FLAG_COMPAT.
That's definitely atrocious API design (witnessed by the
complexity of the code needed for correct error checking),
but changing the API contract and becoming incompatible
with OpenSSL would make matters even worse.

Note that just checking for <= 0 in all cases would not be correct
either because X509_NAME_print_ex(3) returns 0 to indicate that it
successfully printed zero bytes in some cases, for example when all
three of the following conditions hold:
1. nmflags != X509_FLAG_COMPAT
2. indent == 0 (which X509_print_ex(3) does use in some cases)
3. the name object is NULL or empty

I found the bug by code inspection and proposed an incomplete patch,
then jsing@ proposed this improved version of the patch.
OK jsing@.
lib/libcrypto/asn1/t_x509.c