For example: my post pointed out that Linux's naive AES has a huge timing sidechannel (e.g. the same bug JoeBob's would). This isn't news. It's also not fixed.

Many times I've been asked to review a cryptographic library and found that it had problems, had them for been for years.. Sometimes the issues had been reported and just ignored.

In some cases reporting the issue just causes the author to take it down... creating its own problems for people who were depending on it!

At the moment I have two private outstanding bug reports for total breaks in cryptosystem library code that I just stumbled into while browsing the internet where the authors/maintainers haven't replied and it's been more than a month. After a bit longer, I'll make the reports in public, but I expect the software will continue to go uncorrected (or just be taken down in response).

One piece of advice I'd give for anyone taking a dependency: go read through its bug tracker of open bugs (and recently resolved ones) -- and their public patch queue if they have one. Also do the same for all transitive dependencies. You can gain some pretty valuable knowledge and more benefit from shared bug finding.

Of course, if you're not a subject matter expert you might not be able to judge if a report is correct or if the subject is serious-- though you will probably be able to tell if the maintainers are active/responsive.

I gave a talk once on the problem of "Selection Cryptography"-- where I argue that merely _picking_ an implementation of cryptographic code (much less the primitives to use) is an act of rolling your own cryptography that triggers similar risks to writing some which also must be managed.