On Tue, 13 Feb 2007, Lucas Newman wrote:
> Here's a patch that addresses it.
Thanks a lot. How about this minor rewrite of it, to make the logic somewhat
easier to follow (at least in my brain):
--- src/transport.c 2 Feb 2007 23:23:37 - 1.2
+++ src/transport.c 14 Feb 2007 12:4
And I just realized that it was an earlier version of the patch which
subtracted from the write index, so ignore me :) I would like
feedback on the patch though.
-Lucas
On Feb 13, 2007, at 3:49 PM, Lucas Newman wrote:
> Here's a patch that addresses it. You may want to do it differently
>
Here's a patch that addresses it. You may want to do it differently
though, as subtracting from the write index is a little weird, but I
couldn't see how else to do it since we need to determine padding
length from the first block.
-Lucas
Index: transport.c
On Tue, 13 Feb 2007, Lucas Newman wrote:
> This loop will process 1440 bytes of data that we passed in, and then 8
> bytes are left in the buffer. However, we didn't outside of this function
> we assumed that all 1448 bytes were processed and copied into the decrypted
> packet buffer.
>
> Back
Consider the case where we ask for 4000 bytes in a read. From the
recv where data is grabbed off the network, you are given 1448 bytes
in the first chunk. This is enough data to decrypt, so in
transport.c, this call is made:
rc = decrypt(session, &p->buf[p->readidx], p->wptr, numdecrypt);
On Mon, 12 Feb 2007, Lucas Newman wrote:
> I think I understand what is happening now. If a large read blocks in the
> middle, the chunk of data obtained is processed in transport.c to determine
> if a full packet was snagged. While processing half of a packet, if the
> data is not a multiple
I think I understand what is happening now. If a large read blocks in
the middle, the chunk of data obtained is processed in transport.c to
determine if a full packet was snagged. While processing half of a
packet, if the data is not a multiple of the crypto block size, the
extra bytes ar
As a followup to the bug I reported yesterday, I have found some more
issues in the packet handling with the latest code in CVS. For one,
in the transportpacket structure, the total_num field is an integer,
so if the packet is corrupted (this is happening with large SFTP reads
– I'm still
