I may not have time to fully digest the change before the release date, but
I'm not sure this snippet quite works:
if (ctx->read_start == ctx->read_end) { /* time to read more data */
ctx->read_end = ctx->read_start = &(ctx->buf[BUF_OFFSET]);
ctx->read_end += BIO_read(next,
The krb5 PKINIT tests still pass.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4628
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
There are two commits, one that addresses bio_enc problems and one
adding test. Please double-check.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4628
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe:
Hi,
As I obviously needed to improve my test program,
I am now encrypting and decrypting files trying all ciphers in all their
available modes.
( ChaCha20, AES-128, AES-192, AES-256, Blowfish, Cast5, Camellia-128,
Camellia-192, Camellia-256, IDEA, Seed, 3 Keys Triple-DES, 2 Keys Triple-DES
)
(
Hi David,
After checking you are obviously right.
Contrary to my belief, my internal buffer was always larger than the longest
line I read.
:-(
Sorry for the noise, but thanks David for the explanations.
It helps me to fix my software (even if I will keep some spare bytes for
some time)
;-(
--
Hi David,
After checking you are obviously right.
Contrary to my belief, my internal buffer was always larger than the longest
line I read.
:-(
Sorry for the noise, but thanks David for the explanations.
It helps me to fix my software (even if I will keep some spare bytes for
some time)
;-(
--
On Sun, Jul 31, 2016 at 6:18 PM Michel via RT wrote:
> > I was able to trigger a crash simply by chaining an encrypt BIO with a
> memory BIO containing a large plaintext and then stream 100 bytes out of it
> at a time. BIO_read would consistently return 128 and, by the time the
> I was able to trigger a crash simply by chaining an encrypt BIO with a
memory BIO containing a large plaintext and then stream 100 bytes out of it
at a time. BIO_read would consistently return 128 and, by the time the
function returned, the stack was thoroughly clobbered.
I am surprised. I
> I was able to trigger a crash simply by chaining an encrypt BIO with a
memory BIO containing a large plaintext and then stream 100 bytes out of it
at a time. BIO_read would consistently return 128 and, by the time the
function returned, the stack was thoroughly clobbered.
I am surprised. I
Hey folks,
I do not believe this fix works and introduces buffer overflows.
Looking at this change:
https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=abdb460d8abe68fedcf00b52d2ba4bf4b7c1725c
It makes EVP_CipherUpdate write to out directly. While not unreasonable
(this BIO probably
Not speaking for Greg, but for me, it is now working fine again.
Thanks Andy !
-Message d'origine-
De : openssl-dev [mailto:openssl-dev-boun...@openssl.org] De la part de Rich
Salz via RT
Envoyé : dimanche 31 juillet 2016 15:58
À : ghud...@mit.edu
Cc : openssl-dev@openssl.org
Objet :
Not speaking for Greg, but for me, it is now working fine again.
Thanks Andy !
-Message d'origine-
De : openssl-dev [mailto:openssl-dev-boun...@openssl.org] De la part de Rich
Salz via RT
Envoyé : dimanche 31 juillet 2016 15:58
À : ghud...@mit.edu
Cc : openssl-dev@openssl.org
Objet :
> Does current master work? I think Andy checked in a fix.
Rich was few minutes ahead. Now it's committed. Provided test case was
verified to work. Thanks for report.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4628
Please log in as guest with password guest if prompted
--
13 matches
Mail list logo