[inputmice]

> Also relevant https://soatok.blog/2024/08/04/against-xmppomemo/ recently.

Signal, Matrix, Telegram, XMPP; Use whatever you want. But there is a lot of FUD if not outright lies in that blog post. The author looked at Conversations for all but five minutes, desperately trying to dig up some dirt.

[Kye]

>> "But there is a lot of FUD if not outright lies in that blog post. "

For example...

[inputmice]

* Conversations uses two different OpenPGP implementations. (It doesn’t)

* The auth tag truncation was 'silently' introduced in the spec. It wasn’t. The author retracted that but only barely

* ominously pointing out that Conversations has a SASL implementation (In fact Conversations can use that to detect some MITM attacks; which is pretty cool)

* ominously pointing out that Conversations has a certificate parser (yes and so does almost everything that uses TLS)

[some_furry]

> * ominously pointing out that Conversations has a certificate parser (yes and so does almost everything that uses TLS)

It's trivial to use TLS without writing your own certificate parser. Doing this means taking on a lot of unnecessary risk, such as CVE-2023-33202.

Your encrypted messaging application shouldn't need to have a separate X.509 or ASN.1 parser built into it. If you're going to use them from TLS, you should rely on the library your OS vendor maintains for you, since they have an incentive to keep theirs secure anyway.

"Ominously pointing out" that the Conversations project has taken on an unhealthy amount of complexity and risk isn't FUD, it's a criticism of how the project is managed. Confuse the two at your own peril.

[inputmice]

There are certificates that are valid for the XMPP domain example.com but not for the regular (HTTP) server on example.com. Off-the-shelf verifier don’t have support for that.