From f8b6e3a0c6b7bd3c80b94143d1c494388e2e3da0 Mon Sep 17 00:00:00 2001 From: Avril Date: Mon, 16 Aug 2021 22:55:58 +0100 Subject: [PATCH] This bug may make ESock **unusable** in this project entirely. Individual `SerializedMessage` sending/receiving _might_ work reliably since that is based on rigid size communication, but streamed data may be untenable. Any desync in streaming buffers causes complete failure. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 − 吉 --- src/sock/enc.rs | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/sock/enc.rs b/src/sock/enc.rs index 07ccc4d..22a108f 100644 --- a/src/sock/enc.rs +++ b/src/sock/enc.rs @@ -462,7 +462,8 @@ impl ESock } //XXX: For some reason, non-exact reads + writes cause garbage to be produced on the receiving end? -// Is this fixable? Why does it disjoint? I have no idea... This is supposed to be a stream cipher, right? Why does positioning matter? Have I misunderstood how it workd? Eh... +// Is this fixable? Why does it disjoint? I have no idea... This is supposed to be a stream cipher, right? Why does positioning matter? Have I misunderstood how it workd? Eh... +// With this bug, it seems the `while read(buffer) > 0` construct is impossible. This might make this entirely useless. Hopefully with the rigid size-based format for `Message` we won't run into this problem, but subsequent data streaming will likely be affected unless we use rigid, fixed, and (inefficiently) communicated buffer sizes. impl AsyncWrite for ESock where W: AsyncWrite