4 ms·

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

• skeetmtp 5y ago
  ASAN is not meant to be used in production though. Or I missed something in your comment.
  • chrsig 5y ago
    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.
    • wizzwizz4 5y ago
      > 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.
      • chrsig 5y ago
        I agree with you, but I don't understand intent of your comment.
        • wizzwizz4 5y ago
          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.
• jcalvinowens 5y ago
  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.