Hacker News Reader

Be careful with ASAN on cryptographic code, though. It can introduce side channels.

ASAN is not meant to be used in production though. Or I missed something in your comment.

I've seen it advised to periodically release to production with ASAN/UBSAN/TSAN enabled, with the intention that it's only 1/nth of a deployment, and even then, only deployed for enough time to collect instrumentation. I don't have a citation to share, so take with as many grains of salt as you feel appropriate.

If nothing else, I appreciate the advisement that it can have security implications.

> with the intention that it's only 1/nth of a deployment, and even then, only deployed for enough time to collect instrumentation

You can't unleak secrets.

I agree with you, but I don't understand intent of your comment.

If you leak all the secrets 1% of the time, that's not leaking 1% of the secrets. All of the secrets have been leaked, albeit over a short stretch of time.

That's definitely a good point, and worth thinking about. But most people don't go to the trouble to rebuild dependencies like openssl. Unless you're actually implementing crypto, it seems unlikely you'd expose anything, although you do have to consider the possibility that a crypto library could call an instrumented function which could leak state.

Reply on news.ycombinator.com