There's another option: Openssl code is terrible. Even interacting with it is terrible. I had to deal with x509 code lately, and it's probably the worst and least documented code I've seen in a long time.
For the "many eyes" situation to work, you have to have code which "many eyes" can understand. Asn1-related functions in openssl are not in that situation.
Edit: If you've never looked at openssl code, check this out: https://github.com/openssl/openssl/blob/063dccd027033401912d... - yup - that's part of public interface. It's got a mention on the man page, but no idea what encoding it actually outputs. Maybe ascii, maybe something else. Good luck finding out from source.
Edit2: Just a few lines above you can spot: "/* memory leak, buit should not normally matter */"
Yes, the sources are difficult to read at best. The documentation for the public APIs is not much better either.
For example, the suggestion at this page: https://www.openssl.org/docs/crypto/sha.html to use the higher-level EVP_ functions was difficult to actually adhere to, given that the EVP_ functions themselves don't actually explain how to generate a message digest given some input data. I wasted half a day once trying to understand how those functions worked once before giving up and just using the digest functions directly. It's still not clear to me why the EVP functions provide a significant advantage, or even how I would use them to accomplish the use cases outlined in the digest functions.
I suspect that not understanding the OpenSSL APIs is a common problem, and possibly an underlying cause of a lot of crypto implementation errors.
> It's still not clear to me why the EVP functions provide a significant advantage
In case of EVP_... your code is not hardcoding the hash type. You can provide the hash by its name in the config file without any code changes in the app. When using hash contexts directly, you're stuck with what you implement.
That's what I figured when I implemented it. In my application I'm fine hardcoding the hash type because if we have to change hashes away from SHA-2 we have to update all of the equipment in the field anyway, so we might as well update the software at the same time.
E: It also helps that the code with the hardcoded hash type is much easier to understand than the equivalent EVP code.
For the "many eyes" situation to work, you have to have code which "many eyes" can understand. Asn1-related functions in openssl are not in that situation.
Edit: If you've never looked at openssl code, check this out: https://github.com/openssl/openssl/blob/063dccd027033401912d... - yup - that's part of public interface. It's got a mention on the man page, but no idea what encoding it actually outputs. Maybe ascii, maybe something else. Good luck finding out from source.
Edit2: Just a few lines above you can spot: "/* memory leak, buit should not normally matter */"