That holds not only for cryptography libraries, but generalizes to the entire computing stack. It's why, for example, coreboot exists, as well as various open source hardware projects. If it's fully open, you can inspect it yourself. Anywhere I see a branching statement within cryptography context, I'll know something's up.

The problems introduced in xz are still fresh, but Dual_EC_DRBG[0] also comes to mind within the cryptography context.

(Besides, getting cryptography right goes way beyond "just writing a library". As the parent commenter wrote, simple operations are the tip of the iceberg with regards to a correct implementation)

[0] https://en.wikipedia.org/wiki/Dual_EC_DRBG

If you’re not aggressively vetting the crypto libraries you’re using, you’re more or less exposing yourself to the same probability of risk as rolling your own crypto.

I'll pick my battles, it's part risk appetite and part expected attacker model. It also depends on what I'm trying to protect.

If it's in a standard library of an open source programming language, I'm less inclined to fully check the implementation.

If you're picking some random blob of code from Github, then yes. If you're picking OpenSSL or Bouncy Castle, then no. Despite Heartbleed.

When you use OpenSSL, you can trust that if you're screwed, so is the whole internet.

That actually happened once.