The devil is in the details on this. The core concern was that libolm (the obsolete C impl of e2ee in Matrix) used crypto primitives which don’t protect from timing attacks.
However, in practice, this was not exploitable: the only way to exercise these primitives was over the network, where network latency and request rate limiting mitigates such attacks.
Meanwhile, we had already rewritten and replaced libolm with vodozemac, a pure rust implementation using robust primitives, shipped in the major Matrix SDKs and implementations like Element and Element X.
I’m not sure this counts as alarmingly cavalier. I do regret libolm ever going into production with substandard primitives from a hygiene perspective, but we fixed it as soon as we could via vodozemac, and meanwhile included the safety warning.
The part that was "alarmingly cavalier" was when you admitted to knowing about these problems for years and not fixing them or telling the ecosystem of competing clients about them so they could mitigate their risk. https://news.ycombinator.com/item?id=41249371
You visibly deprecated Olm after my disclosures went public. When I last checked, only Element and its forks actually use vodozemac, so the rest of the ecosystem which still binds libolm was still vulnerable, and probably still is today.
However, in practice, this was not exploitable: the only way to exercise these primitives was over the network, where network latency and request rate limiting mitigates such attacks.
Meanwhile, we had already rewritten and replaced libolm with vodozemac, a pure rust implementation using robust primitives, shipped in the major Matrix SDKs and implementations like Element and Element X.
I’m not sure this counts as alarmingly cavalier. I do regret libolm ever going into production with substandard primitives from a hygiene perspective, but we fixed it as soon as we could via vodozemac, and meanwhile included the safety warning.