This really is unacceptable but I don"t even know where to start to find the issue with it. It is likely a very deep design flaw with how we interact with the cipher, making this bug impossible to fix without a complete rewrite. Just like all other software I write. Worthless.
Fortune for rsh's current commit: Blessing − 吉
For ESock to work, a `write(n)` needs to be paired with a `read(n)` for identical sizes of `n`. Not using `write_all(n)`+`read_exact(n)` causes this disjoint too? (Test with `write_all(n)`+`while read(...)` produced garbage.)
I have no idea what is going on here. I think there"s some disconnect with the cipher, but it"s a stream cipher, so positioning (i.e. where byte pattern `A` appears in slice `B` on the writing side, and slice `C` on the reading size) shouldn"t matter right? Clearly it seems to.
This is extremely disappointing.
Fortune for rsh's current commit: Future small blessing − 末小吉
TODO: Inspect contents of the duplex stream throughout transit. Make sure the encryption is happening properly.
Fortune for rsh's current commit: Half curse − 半凶
TODO: Implement AsyncWrite/Read for the write/read halves
TODO: Implement set_encrypted_write/read for the write/read halves
Fortune for rsh's current commit: Half blessing − 半吉
Avril