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 − 半吉
Moved from `io::Write` to `bytes::BufMut`, etc.
TODO: Move from `io::Read` to `bytes::Buf` (SerializedMessage::<impl MessageValue>::from_buffer(impl Buf))
Fortune for rsh's current commit: Future small blessing − 末小吉
Untyped serialized mmessages cannot be deserialized, they must first be given a type with `into_typed<V>()`. This operation is unsafe as it may cause a potential type confusion if the message"s original `V` is different from the newly specified `V`.
Fortune for rsh's current commit: Half curse − 半凶
When implementing tests for signing and/or encrypting messages, we can just implement the `MessageSender`/`MessageReceiver` traits when needed then call into this function.
(Those traits may need refactoring if the format of the adapter is not desireable (i.e. `&self` instead of `&mut self` or `self`; we could only blanket-impl those function to `Fn()` closures, not `FnMut()` or `FnOnce()`. (not that we should try this.)), but for now we"ll leave it as it is.)
Fortune for rsh's current commit: Small blessing − 小吉