Igor Artamonov
ccb349f3d2
Read called XORKeyStream(b, b) — XOR-ing the entire caller buffer even when the underlying transport returned fewer bytes. AES-CTR's keystream position is then advanced by len(b), but the peer only consumed n bytes' worth of keystream. After a single short read the two keystreams diverge for the lifetime of the connection, every subsequent MTProto message decrypts to garbage, and the engine fails with "consume message: decrypt: msg_key is invalid". The faketls layer makes short reads routine: each Read returns at most one TLS Application record's payload, regardless of how big the caller buffer is. So in practice the stream desynced almost immediately on high-traffic clients (active supergroups, post-relogin catch-up) and intermittently on quiet ones. Match the upstream gotd/td fix and only XOR the n bytes that came out of the transport. Add a regression test (chunkConn delivers ciphertext in 7-byte chunks; client reads through Obfuscated2.Read with a 128-byte buffer; plaintext must round-trip). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
mautrix-telegram
A Matrix-Telegram puppeting/relaybot bridge.
Sponsors
Documentation
All setup and usage instructions are located on docs.mau.fi. Some quick links:
- Bridge setup (or with Docker)
- Basic usage: Authentication
Features & Roadmap
ROADMAP.md contains a general overview of what is supported by the bridge.
Discussion
Matrix room: #telegram:maunium.net
Telegram chat: mautrix_telegram (bridged to Matrix room)