I think this is the right change. However, I see that there is another
len-tot in the following conditional block
#if !defined(OPENSSL_NO_MULTIBLOCK) EVP_CIPH_FLAG_TLS1_1_MULTIBLOCK
This is within the same function. I wonder whether that line is also prone to
the same issue and need the same
I think this is the right change. However, I see that there is another
len-tot in the following conditional block
#if !defined(OPENSSL_NO_MULTIBLOCK) EVP_CIPH_FLAG_TLS1_1_MULTIBLOCK
This is within the same function. I wonder whether that line is also prone to
the same issue and need the same
Libressl has a patch for this at:
http://anoncvs.estpak.ee/cgi-bin/cgit/openbsd-src/commit/lib/libssl?id=cb8b51bf2f6517fe96ab0d20c4d9bba2eef1b67c
I believe that patch is not really the correct fix.
My understanding is that tot is what is already written, and
that len is until where we want to
On 26/04/2014 11:04 PM, Kurt Roeckx via RT wrote:
Libressl has a patch for this at:
http://anoncvs.estpak.ee/cgi-bin/cgit/openbsd-src/commit/lib/libssl?id=cb8b51bf2f6517fe96ab0d20c4d9bba2eef1b67c
I believe that patch is not really the correct fix.
My understanding is that tot is what is
On 26/04/2014 11:04 PM, Kurt Roeckx via RT wrote:
Libressl has a patch for this at:
http://anoncvs.estpak.ee/cgi-bin/cgit/openbsd-src/commit/lib/libssl?id=cb8b51bf2f6517fe96ab0d20c4d9bba2eef1b67c
I believe that patch is not really the correct fix.
My understanding is that tot is what is
If the API requires the same buffer and count, then perhaps the SSL structure
should hold those values, and require the user to send NULL/0 in subsequent
calls?
Or assert(). It's a programming error that requires source changes to fix.
--
Principal Security Engineer
Akamai Technologies,
If the API requires the same buffer and count, then perhaps the SSL structure
should hold those values, and require the user to send NULL/0 in subsequent
calls?
Or assert(). It's a programming error that requires source changes to fix.
--
Principal Security Engineer
Akamai Technologies,