Re: [openssl-dev] [openssl.org #4702] OPENSSL: Linux SLESS11

[Matt Caswell via RT]

On 10/10/16 15:14, Jose Carlos de Oliveira via RT wrote:
> Hi,
> I have downloaded and builded last tree openssl versions for linux:
> 1)  openssl-1.0.1u.tar.gz
> 2)  openssl-1.0.2j.tar.gz
> 3)  openssl-1.1.0b.tar.gz

Any particular reason why you need all three?

> 
> I successful followed all steps found at file INSTALL
> 
> By the way, when I try to use it I have the bellow messages:
>undefined reference to ‘EVP_CIPHER_CTX_init’
>undefined reference to ‘EVP_CIPHER_CTX_cleanup’

What was the exact command you issued to see the above?

EVP_CIPHER_CTX_cleanup() no longer exists in OpenSSL 1.1.0.
EVP_CIPHER_CTX_init() is just a macro for EVP_CIPHER_CTX_reset() in 1.1.0.

Matt




> 
> The OS I´m using is a Linux SLESS11 desktop 32 bits: kernel
> 3.0.13-0.27-default
> 
> Regards,
> 
> 
> José Carlos de Oliveira (Oliveira)
> Pesquisador / Desenvolvedor - Grupo ICTS
> Brasilia - DF - Asa Norte
> SCN Q05 - Brasilia Shopping - Torre Norte Sala 917
> Fone:+5561-3246.7089
>Cel:+5561-99311.9226
>   Site:   www.grupoicts.com.br
> 
> 
> 
> 


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4702
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4636] Are the point-at-infinity checks in ecp_nistz256 correct?

[Matt Caswell via RT]

Fixed in master by e3057a57c and c74aea8d6. Still needs cherry-picking to
1.0.2.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4636
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4621] BUG: nistz256 point addition check for a = +/-b doesn't work for unreduced values

[Matt Caswell via RT]

Fixed in master by b62b2454f and dfde4219f. Still needs cherry-picking to
1.0.2.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4621
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4641] [openssl-1.1.0-pre6] make test stops with solaris64-x86_64-gcc

[Matt Caswell via RT]

On Thu Aug 11 17:12:10 2016, appro wrote:
> Hi,
>
> > I have no time to check with debugger now,
>
> Then no progress will be made. Problem needs to be identified first, and
> since similar problem was identified earlier, I'd have to insist on
> confirmation whether or not it's the same.
>
> > but I do not think it is caused by assembler,
> > because,
> > - gcc-5.4.0 with gas (GNU Binutils) 2.27
> > - cc (Solaris developerstudio12.5) with /usr/ccs/bin/as
> > have the same result (see openssl.org #4642 also).
> >
> > perl version which I use is v5.24.0.
>
> Well, (assuming for a moment it's the same problem) there is *less*
> reason to believe that x86_64cpuid.pl is broken. Because it's used with
> a *number* of other toolchains, Linux, BSD, mingw, MSVC, without any
> problem. Nor can I reproduce the problem on my Solaris VM. It's not as
> fancy as yours, apparently, but it also kind of speak in favour of
> suggestion that it's not an OpenSSL problem...
>

Believed to not be an OpenSSL problem. Closing this ticket.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4641
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4362] chacha-x86.pl has stricter aliasing requirements than other files

[Matt Caswell via RT]

Resolved by overlapping buffer checks. Closing.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4362
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4628] EVP_f_cipher regression due to overlapping regions check

[Matt Caswell via RT]

On Mon Aug 22 15:05:17 2016, david...@google.com wrote:
> 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, ctx->read_start, ENC_BLOCK_SIZE);
> }
> i = ctx->read_end - ctx->read_start;
>
> if (i <= 0) {

Fixed in 9e421962e1cd. Closing.

Matt

-- 
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

[openssl-dev] [openssl.org #4609] Configure does not honor requests for ld.gold

[Matt Caswell via RT]

On Wed Aug 17 16:18:26 2016, levitte wrote:
> On Fri Jul 08 09:36:42 2016, levitte wrote:
> > On Fri Jul 08 09:33:01 2016, noloa...@gmail.com wrote:
> > > Hmmm... If I want to use ld.gold as my linker, the easiest path is to
> > > set LD=ld.gold. It makes perfect sense to some
> >
> > Did it work for you when doing this?
> >
> > ./config -fuse-ld=gold
>
> Jeff, please respond.

Still, no response so assuming this is an acceptable work around. Closing this
ticket.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4609
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4584] Self test failures under X32

[Matt Caswell via RT]

On Tue Aug 16 08:05:06 2016, matt wrote:
> On Thu Aug 11 16:36:42 2016, matt wrote:
> > Could be this:
> >
> > https://github.com/openssl/openssl/pull/1432
>
>
> That MR has now been merged.
>
> Jeff - please can you confirm that it resolves the issue for this ticket?


No response, so assuming this is now working. Closing ticket.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4584
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4646] [1.0.2 stable branch] .\crypto\pem\pvkfmt.c(279): error C2065: 'PEM_R_HEADER_TOO_LONG': undeclared identifier

[Matt Caswell via RT]

This should be fixed now. Closing.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4646
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4644] bug: cert verification always examining entire chain

[Matt Caswell via RT]

Closing this - "working as designed".

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4644
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4584] Self test failures under X32

[Matt Caswell via RT]

On 11/08/16 13:29, Andy Polyakov via RT wrote:
>> ( cd test; \
>>   SRCTOP=../. \
>>   BLDTOP=../. \
>>   PERL="perl" \
>>   EXE_EXT= \
>>   OPENSSL_ENGINES=.././engines \
>> perl .././test/run_tests.pl test_afalg )
>> ../test/recipes/30-test_afalg.t ..
>> 1..1
>> ALG_PERR: afalg_fin_cipher_aio: io_read failed : Bad address
>> test_afalg_aes_128_cbc() failed encryption
>> ../util/shlib_wrap.sh ./afalgtest => 1
>> not ok 1 - running afalgtest
>>
>> #   Failed test 'running afalgtest'
>> #   at ../test/recipes/30-test_afalg.t line 23.
>> # Looks like you failed 1 test of 1.
>> Dubious, test returned 1 (wstat 256, 0x100)
>> Failed 1/1 subtests
> 
> For reference, problem is not specific to x32, real x86 32-bit build
> fails in same manner as well. [As well as executed under qemu-user, but
> we are probably not in position to expect *that* work.] What's common
> between x32 and x86 is that system calls pass an "emulation" layer where
> 32-bit arguments are adjusted for 64-bit kernel and return values back
> for 32-bit application...
> 
> 

Could be this:

https://github.com/openssl/openssl/pull/1432

Matt


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4584
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4584] Self test failures under X32

[Matt Caswell via RT]

On 02/08/16 01:26, noloa...@gmail.com via RT wrote:
> On Tue, Jul 19, 2016 at 10:01 AM, Matt Caswell  wrote:
>>
>>
>> On 19/07/16 14:41, Richard Levitte via RT wrote:
>>> Hi Jeff,
>>>
>>> I'm going to assume that a newer checkout of the master branch won't change
>>> much, so if you please, try this command and send mack the result:
>>
>> Who is Mack? ;-)
>>
>>>
>>> make test TESTS='test_afalg test_rehash'
>>
>> Did you mean to include "VERBOSE=1"?
>>
>> VERBOSE=1 make TESTS='test_afalg test_rehash' test
> 
> The tests run as root because its a Debian Chroot, I did not bother
> with rehash because it would fail.
> 
> Here is the result from afalg:
> 
> # VERBOSE=1 make TESTS='test_afalg' test
> make depend && make _tests
> make[1]: Entering directory '/openssl'
> make[1]: Leaving directory '/openssl'
> make[1]: Entering directory '/openssl'
> ( cd test; \
>   SRCTOP=../. \
>   BLDTOP=../. \
>   PERL="perl" \
>   EXE_EXT= \
>   OPENSSL_ENGINES=.././engines \
> perl .././test/run_tests.pl test_afalg )
> ../test/recipes/30-test_afalg.t ..
> 1..1
> ALG_PERR: afalg_fin_cipher_aio: io_read failed : Bad address
> test_afalg_aes_128_cbc() failed encryption


Hmmm. I'm thinking there is perhaps some alignment issue in the aio_read
call? In any case I think pushing this out to beyond 1.1.0 might be
appropriate.

Matt


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4584
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4572] SSL_set_bio and friends

[Matt Caswell via RT]

Closing this ticket.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4572
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4584] Self test failures under X32

[Matt Caswell via RT]

On Mon Jul 25 08:49:27 2016, matt wrote:
> Ping Jeff?

Ping again?

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4584
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4638] Fwd: Missing const EC_KEY *EC_KEY_dup(EC_KEY *src);

[Matt Caswell via RT]

Fix for this was merged as 4a9a0d9bcb. Closing.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4638
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4572] SSL_set_bio and friends

[Matt Caswell via RT]

On 30/07/16 23:45, David Benjamin via RT wrote:
>  It is a behavior change, but
> one I'm sure will break no one.

Unfortunately I don't share your optimism that it won't break any one :-(

Matt


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4572
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4618] BUG: Crash in do_ssl3_write unless OPENSSL_NO_MULTIBLOCK

[Matt Caswell via RT]

On Mon Jul 25 18:36:56 2016, d...@inky.com wrote:
> Yes, that appears to fix it. Thanks!


Fixed in 58c27c207dd. Closing ticket.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4618
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4636] Are the point-at-infinity checks in ecp_nistz256 correct?

[Matt Caswell via RT]

Ticket submitted by Brian Smith

When doing math on short Weierstrass curves like P-256, we have to special case
points at infinity. In Jacobian coordinates (X, Y, Z), points at infinity have
Z == 0. However, instead of checking for Z == 0, p256-x86-64 instead checks for
(X, Y) == (0, 0). In other words, it does, in some sense, the opposite of what
I expect it to do.

I have built a testing framework for exploring things like this in *ring*. I
will attach the input file for my tests which show that ecp_nistz256_point_add
seems to fail to recognize the point at infinity correctly. However, it is also
possible that I just don't understand how ecp_nistz256 intends to work. My
questions are:

1. With respect to additions of the form (a + infinity == a) and (infinity + b
== b), is the code in ecp_nistz256_point_add and ecp_nistz256_point_add_affine
correct?

2. if it is correct, could we add more explanation as to why it is correct?

3. Given the specifics of the implementation of the ecp_nistz256
implementation, is it even possible for us to encounter the point at infinity
as one of the parameters to ecp_nistz256_point_add, other than in the very
final addition that adds g_scalar*G + p_scalar*P? See Section 4.1 of [1].

Background: For based point (G) multiplication, the code has a large table of
multiples of G, in affine (not Jacobian) coordinates. The point at infinity
cannot be encoded in affine coordinates. The authors instead decided to encode
the point at infinity as (0, 0), since the affine point (0, 0) isn't on the
P-256 curve. It isn't clear why the authors chose to do that though, since the
point at infinity doesn't (can't, logically) appear in the table of precomputed
multiples of G anyway. Regardless, if you represent the point at infinity as
(0, 0) then it makes sense to check (x, y) == (0, 0).

But, it seems like the functions that do the computations, like
ecp_nistz256_point_add and ecp_nistz256_point_add_affine, output the point at
infinity as (_, _, 0), not necessarily (0, 0, _). Also, ecp_nistz256's
EC_METHOD uses ec_GFp_simple_is_at_infinity and
ec_GFp_simple_point_set_to_infinity, which represent the point at infinity with
z == 0, not (x, y) == 0. Further ecp_nistz256_get_affine uses
EC_POINT_is_at_infinity, which checks z == 0, not (x, y) == 0. This
inconsistency is confusing, if not wrong. Given this, it seems like the
point-at-infinity checks in the ecp_nistz256_point_add and
ecp_nistz256_point_add_affine code should also be checking that z == 0 instead
of (x, y) == (0, 0).

Note that this is confusing because `EC_POINT_new` followed by
`EC_POINT_to_infinity` initializes (X, Y, Z) = (0, 0, 0). Thus, the check of
(x, y) == (0, 0) "works" as well as the check z == 0. But, it doesn't work in
real-life cases where the point is infinity is encountered during calculations,
because we'll have (X, Y) != (0, 0) but Z == 0.

The assembly language code that does this check is hard to understand unless
one is familiar with SIMD. However, the C reference implementation that the
assembly language code used as a model is easy to understand. This code can be
found in the ecp_nistz256.c file.

Note the parameters of ecp_nistz256_point_add are P256_POINT, not
P256_POINT_AFFINE, so "representation of the point at infinity as (0, 0)"
doesn't make sense to me. But, that's exactly what it checks.

In ecp_nistz256_point_add_affine, it makes more sense to me, because parameter
|b| is in fact a |P256_POINT_AFFINE|. However, |a| is not a |P256_POINT_AFFINE|,
so the (x, y) == (0, 0) check doesn't make sense to me. The x86-64 and x86
assembly language code seems to emulate this exactly. I didn't test the ARM
code, but I'd guess it is similar.

[1] https://eprint.iacr.org/2014/130.pdf (Section 4.1)

Here's the specific logic I'm talking about (which is also present in the asm
code):


```
static void ecp_nistz256_point_add(P256_POINT *r,
   const P256_POINT *a, const P256_POINT *b) {
[...]

const BN_ULONG *in1_x = a->X;
const BN_ULONG *in1_y = a->Y;
const BN_ULONG *in1_z = a->Z;

const BN_ULONG *in2_x = b->X;
const BN_ULONG *in2_y = b->Y;
const BN_ULONG *in2_z = b->Z;

/* We encode infinity as (0,0), which is not on the curve,
 * so it is OK. */
in1infty = (in1_x[0] | in1_x[1] | in1_x[2] | in1_x[3] |
in1_y[0] | in1_y[1] | in1_y[2] | in1_y[3]);
if (P256_LIMBS == 8)
in1infty |= (in1_x[4] | in1_x[5] | in1_x[6] | in1_x[7] |
 in1_y[4] | in1_y[5] | in1_y[6] | in1_y[7]);

in2infty = (in2_x[0] | in2_x[1] | in2_x[2] | in2_x[3] |
in2_y[0] | in2_y[1] | in2_y[2] | in2_y[3]);
if (P256_LIMBS == 8)
in2infty |= (in2_x[4] | in2_x[5] | in2_x[6] | in2_x[7] |
 in2_y[4] | in2_y[5] | in2_y[6] | in2_y[7]);

[...]
}

static void ecp_nistz256_point_add_affine(P256_POINT *r,
  const P256_POINT *a,

[openssl-dev] [openssl.org #4572] SSL_set_bio and friends

[Matt Caswell via RT]

On Tue Jun 14 20:30:09 2016, david...@google.com wrote:
> I recently made some changes around BoringSSL's SSL_set_bio, etc.
> which you
> all might be interested in. The BIO management has two weird behaviors
> right now:
>
> 1. The existence of bbio is leaked in the public API when it should be
> an
> implementation detail. (Otherwise you're stuck with it for DTLS where
> it's
> really messy.) SSL_get_wbio will return it, and SSL_set_bio messes up
> when
> the bbio is active.

Fixed by 2e7dc7cd688.

> 2. SSL_set_bio's object ownership story is a mess. It also doesn't
> quite
> work. This crashes:
> SSL_set_fd(ssl, 1);
> SSL_set_rfd(ssl, 2);
> But this does not:
> SSL_set_fd(ssl, 1);
> SSL_set_wfd(ssl, 2);
> Not that anyone would do such a thing, but the asymmetry is off.

Fixed by 2e7dc7cd688 and in the docs by e040a42e44.

I also added a test, which I verified against the original 1.0.2 implementation
of SSL_set_bio(), in 7fb4c82035.

I found I needed to make some tweaks to the implementation of SSL_set_bio()
from your version in order to preserve the behaviour between 1.0.2 and master.
Possibly your version was a deliberate simplification.

Anyway, marking this as resolved.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4572
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4618] BUG: Crash in do_ssl3_write unless OPENSSL_NO_MULTIBLOCK

[Matt Caswell via RT]

On Wed Jul 20 19:46:37 2016, d...@inky.com wrote:
> OS: Mac OS X 11.11.5
> Version: OpenSSL 1.1-pre6 (head code as of yesterday)
> When the server fails under some circumstances, this line reads a bad
> address:
> /* write the header */
>
> *(outbuf[j]++) = type & 0xff;
>
> Because outbuf is 3. This is because prior to the alignment code,
> outbuf is
> NULL.
> outbuf is set to s->rlayer->wbuf[0].buf, which at that point has been
> set to
> NULL by the code guarded by
> #if !defined(OPENSSL_NO_MULTIBLOCK) && EVP_CIPH_FLAG_TLS1_1_MULTIBLOCK
>
> in ssl3_write_bytes.
> I'm sorry I can't give you a simple reproducer; I was able to
> reproduce it by
> mailing very large files with our mail app. Eventually the Exchange
> server
> fails and downstream code resets the write buffer and the multiblock
> code sets
> s->rlayer->wbuf[0].buf to NULL.
> The workaround is to compile with -DOPENSSL_NO_MULTIBLOCK -- I've
> verified
> that this eliminates the crash in practice.
> Feel free to email me if you want me to put in to some test code and
> reproduce
> it.
> Dave
> Sent with [inky](http://inky.com?kme=signature)

Hi Dave

Please could you try the attached patch and see if that resolves the issue?

Thanks

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4618
Please log in as guest with password guest if prompted

>From 32f6b811837e0279e8cbc13426ae700aff3414eb Mon Sep 17 00:00:00 2001
From: Matt Caswell 
Date: Mon, 25 Jul 2016 10:36:57 +0100
Subject: [PATCH] Fix crash as a result of MULTIBLOCK

The MULTIBLOCK code uses a "jumbo" sized write buffer which it allocates
and then frees later. Pipelining however introduced multiple pipelines. It
keeps track of how many pipelines are initialised using numwpipes.
Unfortunately the MULTIBLOCK code was not updating this when in deallocated
its buffers, leading to a buffer being marked as initialised but set to
NULL.
---
 ssl/record/rec_layer_s3.c | 26 --
 ssl/record/record_locl.h  |  2 +-
 ssl/record/ssl3_buffer.c  | 31 ---
 3 files changed, 29 insertions(+), 30 deletions(-)

diff --git a/ssl/record/rec_layer_s3.c b/ssl/record/rec_layer_s3.c
index b562913..2d0fca2 100644
--- a/ssl/record/rec_layer_s3.c
+++ b/ssl/record/rec_layer_s3.c
@@ -423,23 +423,21 @@ int ssl3_write_bytes(SSL *s, int type, const void *buf_, int len)
 else
 packlen *= 4;
 
-wb->buf = OPENSSL_malloc(packlen);
-if (wb->buf == NULL) {
+if (!ssl3_setup_write_buffer(s, 1, packlen)) {
 SSLerr(SSL_F_SSL3_WRITE_BYTES, ERR_R_MALLOC_FAILURE);
 return -1;
 }
-wb->len = packlen;
 } else if (tot == len) { /* done? */
-OPENSSL_free(wb->buf); /* free jumbo buffer */
-wb->buf = NULL;
+/* free jumbo buffer */
+ssl3_release_write_buffer(s);
 return tot;
 }
 
 n = (len - tot);
 for (;;) {
 if (n < 4 * max_send_fragment) {
-OPENSSL_free(wb->buf); /* free jumbo buffer */
-wb->buf = NULL;
+/* free jumbo buffer */
+ssl3_release_write_buffer(s);
 break;
 }
 
@@ -471,8 +469,8 @@ int ssl3_write_bytes(SSL *s, int type, const void *buf_, int len)
   sizeof(mb_param), _param);
 
 if (packlen <= 0 || packlen > (int)wb->len) { /* never happens */
-OPENSSL_free(wb->buf); /* free jumbo buffer */
-wb->buf = NULL;
+/* free jumbo buffer */
+ssl3_release_write_buffer(s);
 break;
 }
 
@@ -502,15 +500,15 @@ int ssl3_write_bytes(SSL *s, int type, const void *buf_, int len)
 i = ssl3_write_pending(s, type, [tot], nw);
 if (i <= 0) {
 if (i < 0 && (!s->wbio || !BIO_should_retry(s->wbio))) {
-OPENSSL_free(wb->buf);
-wb->buf = NULL;
+/* free jumbo buffer */
+ssl3_release_write_buffer(s);
 }
 s->rlayer.wnum = tot;
 return i;
 }
 if (i == (int)n) {
-OPENSSL_free(wb->buf); /* free jumbo buffer */
-wb->buf = NULL;
+/* free jumbo buffer */
+ssl3_release_write_buffer(s);
 return tot + i;
 }
 n -= i;
@@ -650,7 +648,7 @@ int do_ssl3_write(SSL *s, int type, const unsigned char *buf,
 }
 
 if (s->rlayer.numwpipes < numpipes)
-if (!ssl3_setup_write_buffer(s, numpipes))
+if (!ssl3_setup_write_buffer(s, numpipes, 0))
 return -1;
 
 if (totlen == 0 && !create_empty_fragment)
diff --git a/ssl/record/record_locl.h b/ssl/record/record_locl.h
index ff1eb32..435e92a 100644
--- 

[openssl-dev] [openssl.org #4584] Self test failures under X32

[Matt Caswell via RT]

Ping Jeff?

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4584
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4591] asynctest: double free or corruption on hppa

[Matt Caswell via RT]

On Tue Jul 19 16:22:22 2016, k...@roeckx.be wrote:
> On Tue, Jul 19, 2016 at 02:12:41PM +0000, Matt Caswell via RT wrote:
> >
> > Is this still an issue? And if so are you able to provide a backtrace?
>
> This might be a combination of kernel, glibc and gcc bugs, some of
> which might have been fixed. In any case, I don't think it's an
> openssl problem.

Ok - closing this ticket then.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4591
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4614] pthread_once and malloc failures

[Matt Caswell via RT]

On 19/07/16 16:23, Richard Levitte via RT wrote:
> On Mon Jul 11 16:20:29 2016, k...@roeckx.be wrote:
>> Hi,
>>
>> When trying to check what happens if we simulate malloc()
>> returning NULL I'm running into a problem that I'm not sure how to
>> deal with.
>>
>> We have CRYPTO_THREAD_run_once(), which takes an init() function
>> that returns void, so it can't return failures. At least the
>> pthread_once() function also has it as void.
>>
>> But if those functions call malloc() and that returns NULL, we now
>> don't catch that error, and later just try to use a NULL pointer.
>>
>> Anybody a good idea how to solve this?
> 
> Rethinking this...
> 
> Most of all, we use CRYPTO_THREAD_run_once() internally to initiate the first
> locks, so pretty much in an initial state of the library (not entirely true,
> since we do these inits opportunistically, but it's probable that they happen
> very early on). If they are having memory allocation, the running app is
> probably in deep shit anyway, so a hard assert in our diverse inits would
> probably be appropriate either way.

You are assuming that the application loads and inits OpenSSL early and
that it is critical to its function. It may not be.

Matt


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4614
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4591] asynctest: double free or corruption on hppa

[Matt Caswell via RT]

On Mon Jun 27 09:51:21 2016, matt wrote:
>
>
> On 26/06/16 15:44, Kurt Roeckx via RT wrote:
> > Hi,
> >
> > My last upload of openssl to experimental show this on hppa:
> > *** Error in `./asynctest': double free or corruption (out):
> > 0x007307d8 ***
> > ../util/shlib_wrap.sh ./asynctest => 134
> >
> > # Failed test 'running asynctest'
> > # at ../test/testlib/OpenSSL/Test/Simple.pm line 77.
> > # Looks like you failed 1 test of 1.
> >
> > A full log can be seen at:
> >
https://buildd.debian.org/status/fetch.php?pkg=openssl=hppa=1.1.0~pre5-
> > 4=1466951184
> >
> > This is with commit c32bdbf171ce6650ef045ec47b5abe0de7c264db
> >
> > The previous upload was succesful, the log of that is:
> >
https://buildd.debian.org/status/fetch.php?pkg=openssl=hppa=1.1.0~pre5-
> > 3=1465602753
> >
> > That was with commit 5000a6d1215ea7d6ed6179d0bcd44263f6e3c26b
>
>
> There do not appear to be any changes at all in either the asynctest
> or
> the async code between those two commits.
>
> >
> >
> > I'm not sure if this is reproducible or not, I can try a new build
> > if needed.
>
> That would be good to know, although to take this any further I think
> we're going to need more information, e.g. a backtrace.

Is this still an issue? And if so are you able to provide a backtrace?

Thanks

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4591
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4584] Self test failures under X32

[Matt Caswell via RT]

On 19/07/16 14:41, Richard Levitte via RT wrote:
> Hi Jeff,
> 
> I'm going to assume that a newer checkout of the master branch won't change
> much, so if you please, try this command and send mack the result:

Who is Mack? ;-)

> 
> make test TESTS='test_afalg test_rehash'

Did you mean to include "VERBOSE=1"?

VERBOSE=1 make TESTS='test_afalg test_rehash' test

Matt


> 
> Cheers,
> Richard
> 
> On Thu Jun 23 11:10:04 2016, noloa...@gmail.com wrote:
>> I'm working on a Debian X32 system (http://wiki.debian.org/X32Port),
>> and working from HEAD:
>>
>> # git rev-parse HEAD
>> b58614d7f5f98571b2c0bb2fb3df48f4b48a7e92
>>
>> Running 'make test' under a machine configured with './Configure
>> linux-x32 enable-ec_nistp_64_gcc_128' results in two failed self
>> tests:
>>
>> make[1]: Leaving directory '/openssl'
>> ( cd test; \
>> SRCTOP=../. \
>> BLDTOP=../. \
>> PERL="perl" \
>> EXE_EXT= \
>> OPENSSL_ENGINES=.././engines \
>> perl .././test/run_tests.pl )
>> ../test/recipes/01-test_abort.t  ok
>> ../test/recipes/01-test_ordinals.t . ok
>> ../test/recipes/01-test_symbol_presence.t .. ok
>> ../test/recipes/05-test_bf.t ... ok
>> ../test/recipes/05-test_cast.t . ok
>> ../test/recipes/05-test_des.t .. ok
>> ../test/recipes/05-test_hmac.t . ok
>> ../test/recipes/05-test_idea.t . ok
>> ../test/recipes/05-test_md2.t .. skipped: md2 is not
>> supported by this OpenSSL build
>> ../test/recipes/05-test_md4.t .. ok
>> ../test/recipes/05-test_md5.t .. ok
>> ../test/recipes/05-test_mdc2.t . ok
>> ../test/recipes/05-test_rand.t . ok
>> ../test/recipes/05-test_rc2.t .. ok
>> ../test/recipes/05-test_rc4.t .. ok
>> ../test/recipes/05-test_rc5.t .. skipped: rc5 is not
>> supported by this OpenSSL build
>> ../test/recipes/05-test_rmd.t .. ok
>> ../test/recipes/05-test_sha1.t . ok
>> ../test/recipes/05-test_sha256.t ... ok
>> ../test/recipes/05-test_sha512.t ... ok
>> ../test/recipes/05-test_wp.t ... ok
>> ../test/recipes/10-test_bn.t ... ok
>> ../test/recipes/10-test_exp.t .. ok
>> ../test/recipes/15-test_dh.t ... ok
>> ../test/recipes/15-test_dsa.t .. ok
>> ../test/recipes/15-test_ec.t ... ok
>> ../test/recipes/15-test_ecdh.t . ok
>> ../test/recipes/15-test_ecdsa.t  ok
>> ../test/recipes/15-test_rsa.t .. ok
>> ../test/recipes/20-test_enc.t .. ok
>> ../test/recipes/25-test_crl.t .. ok
>> ../test/recipes/25-test_d2i.t .. ok
>> ../test/recipes/25-test_pkcs7.t  ok
>> ../test/recipes/25-test_req.t .. ok
>> ../test/recipes/25-test_sid.t .. ok
>> ../test/recipes/25-test_verify.t ... ok
>> ../test/recipes/25-test_x509.t . ok
>> ../test/recipes/30-test_afalg.t  1/1
>> # Failed test 'running afalgtest'
>> # at ../test/recipes/30-test_afalg.t line 23.
>> # Looks like you failed 1 test of 1.
>> ../test/recipes/30-test_afalg.t  Dubious, test returned 1
>> (wstat 256, 0x100)
>> Failed 1/1 subtests
>> ../test/recipes/30-test_engine.t ... ok
>> ../test/recipes/30-test_evp.t .. ok
>> ../test/recipes/30-test_evp_extra.t  ok
>> ../test/recipes/30-test_pbelu.t  ok
>> ../test/recipes/40-test_rehash.t ... 1/5
>> # Failed test 'Testing that we aren't running as a privileged user,
>> such as root'
>> # at ../test/recipes/40-test_rehash.t line 49.
>> # Looks like you failed 1 test of 5.
>> ../test/recipes/40-test_rehash.t ... Dubious, test returned 1
>> (wstat 256, 0x100)
>> Failed 1/5 subtests
>> (less 1 skipped subtest: 3 okay)
>> ../test/recipes/70-test_asyncio.t .. ok
>> ../test/recipes/70-test_clienthello.t .. ok
>> ../test/recipes/70-test_packet.t ... ok
>> ../test/recipes/70-test_sslcertstatus.t  ok
>> ../test/recipes/70-test_sslextension.t . ok
>> ../test/recipes/70-test_sslrecords.t ... ok
>> ../test/recipes/70-test_sslsessiontick.t ... ok
>> ../test/recipes/70-test_sslskewith0p.t . ok
>> ../test/recipes/70-test_sslvertol.t  ok
>> ../test/recipes/70-test_tlsextms.t . ok
>> ../test/recipes/70-test_verify_extra.t . ok
>> ../test/recipes/80-test_ca.t ... ok
>> ../test/recipes/80-test_cipherlist.t ... ok
>> ../test/recipes/80-test_cms.t .. ok
>> ../test/recipes/80-test_ct.t ... ok
>> ../test/recipes/80-test_dane.t . ok
>> ../test/recipes/80-test_dtlsv1listen.t . ok
>> ../test/recipes/80-test_ocsp.t . ok
>> ../test/recipes/80-test_ssl_new.t .. ok
>> ../test/recipes/80-test_ssl_old.t .. ok
>> ../test/recipes/80-test_ssl_test_ctx.t . ok
>> ../test/recipes/80-test_tsa.t .. ok
>> 

[openssl-dev] [openssl.org #4606] BUG: Windows Startup Code in OpenSSL RAND_poll() Is Ineffective

[Matt Caswell via RT]

Closing this ticket - fixed in 1.1.0.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4606
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4589] Resolved: simplifying writing code that is 1.0.x and 1.1.x compatible

[Matt Caswell via RT]

On 29/06/16 08:33, Tomas Mraz via RT wrote:
> On Út, 2016-06-28 at 22:10 +, Thomas Waldmann via RT wrote:
>> On 06/28/2016 11:18 PM, Kurt Roeckx via RT wrote:
>>>
>>> On Mon, Jun 27, 2016 at 08:50:43PM +, Thomas Waldmann via RT
>>> wrote:

 I didn't ask where to get the missing code from, I asked whether
 you
 maybe want to make life simpler for people by adding this to
 1.0.x
 rather than having a thousand software developers copy and
 pasting it
 into their projects.
>>> I think this will not actually make life easier.  People using a
>>> 1.0.x version are not always using the latest 1.0.x version.
>> Aren't they?
>>
>> Don't they use 1.0.xLATEST rather soon, due to security fixes?

No, many do not. Most distros just cherry-pick the actual security fixes.


>>
>> And in case some dist maintainer chooses to rather backport, couldn't
>> they also backport the added function if it is documented as "openssl
>> 1.1.x migration support" or so?
>>
>> We aren't talking about incompatible changes, just adding 2 trivial
>> functions that were not there yet (but should have been there, when
>> looking at the rest of the API).

Well its 2 functions that you are interested in. There are actually
quite a lot of these types of things.

> You might get such kind of backport to something that still evolves
> such as (RHEL/CentOS 7) however you would not get it in older releases
> (RHEL/CentOS 5 and most probably RHEL/CentOS 6 either).
> 
> So you will still be facing the issue that there are environments where
> someone wants to build your code and these functions are not present.

Exactly!

I do think it would be a good idea to create a separate stand alone
"openssl-compat" repo on github somewhere, i.e. to just provide the
missing functions and translate them into the 1.0.2 way of doing things.
I'd create such a thing myself, but I'm fully focussed on just getting
1.1.0 out the door!

Matt


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4589
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4594] openssl s_client issue on windows platform

[Matt Caswell via RT]

On 28/06/16 16:18, Oleg Kukartsev via RT wrote:
> Guys,
> There is an issue with openssl s_client described here:
> http://stackoverflow.com/questions/25760596/how-to-terminate-openssl-s-client-after-connection
> Basically, it prevents openssl s_client automation on windows platform.
> 
> And a similar question here:
> http://stackoverflow.com/questions/19147280/how-do-you-pipe-echo-into-openssl
> 
> It works on Linux just fine, but not on windows.
> I’ve tested it on windows server 2012 R2 SP1 with following openssl
> versions:
> OpenSSL 1.0.2f  28 Jan 2016
> OpenSSL 1.0.2h  3 May 2016

It would be interesting to try this on OpenSSL 1.1.0. I have a suspicion
this issue is fixed there.

Matt


> 
> Downloaded from here:
> https://slproweb.com/products/Win32OpenSSL.html
> 
> To clarify:
> A single command like this
> openssl s_client -brief -servername some.dns.name -connect
> 192.168.68.160:443  waits for “any key” click (enter, esc, etc.)
> If I run a batch with 10 commands like above, only 1 one will wait for key
> click, all others will run right away, because a “key” is in the buffer
> still, and openssl reads from pipe in fact (i.e.  
> And after running batch, “any key” I clicked will be interpreted by shell,
> since openssl has never read it.
> 
> Here is speculation, why it might behave like this:
> http://openssl.6102.n7.nabble.com/openssl-s-client-takes-over-30-seconds-to-complete-on-Windows-td45781.html
> Dave Thompson-5
> 
> Jul
> 05, 2013; 9:19pm wrote why it might be happening:
> I'll guess this is because WaitForSingleObject doesn't treat a diskfile or
> full pipe as 'notified' (unlike a console), whereas Unix select() does
> treat them as 'ready' (like a tty).
> 
> Let me know, if I need to clarify any further.
> Thank you!
> Oleg Kukartsev
> 


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4594
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4591] asynctest: double free or corruption on hppa

[Matt Caswell via RT]

On 26/06/16 15:44, Kurt Roeckx via RT wrote:
> Hi,
> 
> My last upload of openssl to experimental show this on hppa:
> *** Error in `./asynctest': double free or corruption (out): 0x007307d8 ***
> ../util/shlib_wrap.sh ./asynctest => 134
> 
> #   Failed test 'running asynctest'
> #   at ../test/testlib/OpenSSL/Test/Simple.pm line 77.
> # Looks like you failed 1 test of 1.
> 
> A full log can be seen at:
> https://buildd.debian.org/status/fetch.php?pkg=openssl=hppa=1.1.0~pre5-4=1466951184
> 
> This is with commit c32bdbf171ce6650ef045ec47b5abe0de7c264db
> 
> The previous upload was succesful, the log of that is:
> https://buildd.debian.org/status/fetch.php?pkg=openssl=hppa=1.1.0~pre5-3=1465602753
> 
> That was with commit 5000a6d1215ea7d6ed6179d0bcd44263f6e3c26b


There do not appear to be any changes at all in either the asynctest or
the async code between those two commits.

> 
> 
> I'm not sure if this is reproducible or not, I can try a new build
> if needed.

That would be good to know, although to take this any further I think
we're going to need more information, e.g. a backtrace.

Matt


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4591
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4545] Crash in crypto/rand/md_rand.c

[Matt Caswell via RT]

On 20/06/16 10:49, Mick Saxton via RT wrote:
> I modified your patch to also catch the similar problem in ssleay_rand_bytes.
> Results from the instrumented tests attached.
> 
> These tests were run on 64-bit Windows 7.
> I have not specified a locking callback so will be using the default – could 
> this be the problem?

Ahhh!!! Yes!!!

https://www.openssl.org/docs/faq.html#PROG1

From the "threads" man page:
https://www.openssl.org/docs/man1.0.2/crypto/threads.html

"OpenSSL can safely be used in multi-threaded applications provided that
at least two callback functions are set, locking_function and threadid_func.

locking_function(int mode, int n, const char *file, int line) is needed
to perform locking on shared data structures. (Note that OpenSSL uses a
number of global data structures that will be implicitly shared whenever
multiple threads use OpenSSL.) Multi-threaded applications will crash at
random if it is not set."

In version 1.1.0 (not released yet) this requirement has gone - but this
is still needed for all released versions.

Matt




> 
> Each thread has it’s own SSL_ctx and each connection is only ever serviced by 
> the same thread.
> 
> It looks like state_index is going outside of the expected range.
> 
> This is possible if one or more threads do
>state_index += num_ceil;
> 
> and then another thread reads it before
>if ( state_index > state_num )
>   state_index %= st_num.;
> 
> Thanks for your help
> 
> 
> From: Matt Caswell via RT [mailto:r...@openssl.org]
> Sent: 18 June 2016 00:08
> To: Mick Saxton
> Cc: openssl-dev@openssl.org
> Subject: Re: [openssl-dev] [openssl.org #4545] Crash in crypto/rand/md_rand.c
> 
> 
> 
> On 17/06/16 20:56, Matt Caswell via RT wrote:
>>
>>
>> On 17/06/16 19:43, Mick Saxton via RT wrote:
>>> Perhaps we should consider if there are any negative consequences to my 
>>> solution?
>>> It does work.
>>>
>>> I am trying really hard to get contention but I am only seeing this problem 
>>> in about 1 out of 100,000 successful TLSv1.2 connections
>>> On a heavily congested network.
>>> I require three machines to just to run the test that causes the failure.
>>>
>>> All we are trying to do is get a random number – surely getting a slightly 
>>> less random number is better than crashing?
>>> It could be that the problematic instances were going to disconnect anyway 
>>> due to TCP/IP problems.
>>>
>>
>> I think we need to try instrumenting the code to see if we can get some
>> more information out. I will try and pull something together - but it
>> might be Monday before I get the opportunity.
> 
> I got to it quicker than I thought. Please see attached patch. Can you
> apply it to the latest git 1.0.2 version and re-run your test (capture
> stderr output). I'd like to see what we get.
> 
> Also is this 32-bit or 64-bit Windows? Are you able to share your
> locking callback implementation?
> 
> Thanks
> 
> Matt
> 
> 
> --
> Ticket here: 
> http://rt.openssl.org/Ticket/Display.html?id=4545<http://rt.openssl.org/Ticket/Display.html?id=4545>
> Please log in as guest with password guest if prompted
> 
> 
> 
> 
> Legal Notice: This email is intended only for the person(s) to whom it is 
> addressed. If you are not an intended recipient and have received this 
> message in error, please notify the sender immediately by replying to this 
> email or calling +44(0) 2083269015 (UK) or +1 866 592 4214 (USA). This email 
> and any attachments may be privileged and/or confidential. The unauthorized 
> use, disclosure, copying or printing of any information it contains is 
> strictly prohibited. The opinions expressed in this email are those of the 
> author and do not necessarily represent the views of 1E Ltd. Nothing in this 
> email will operate to bind 1E to any order or other contract.
> 
> 
> 


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4545
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4561] BUG: openssl-1.0.2h, evp_enc.c, non-portable bitwise operation

[Matt Caswell via RT]

On Mon Jun 13 09:37:59 2016, loic.etie...@qnective.com wrote:
> My claim about portability issues was wrong (sorry): The C-standard
> ensures that positive values are handled in the two's complement
> system, indeed.
>
> However, inl % block_size == inl & (block_size-1) is true if and only
> if block_size is a power of two, which happens to be true under the
> current implementation, but may change in the future.

I think if that assumption is probably in multiple places in the code. I don't
think this is worth fixing at this stage. Closing this ticket.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4561
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4378] Multiple warnings under OpenBSD 5.7/64-bit

[Matt Caswell via RT]

Fixed in latest master. There are a few spurious warning left that I did not
fix. They look like cases of the compiler being overly picky IMO.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4378
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4545] Crash in crypto/rand/md_rand.c

[Matt Caswell via RT]

On 17/06/16 20:56, Matt Caswell via RT wrote:
> 
> 
> On 17/06/16 19:43, Mick Saxton via RT wrote:
>> Perhaps we should consider if there are any negative consequences to my 
>> solution?
>> It does work.
>>
>> I am trying really hard to get contention but I am only seeing this problem 
>> in about 1 out of 100,000 successful TLSv1.2 connections
>> On a heavily congested network.
>> I require three machines to just to run the test that causes the failure.
>>
>> All we are trying to do is get a random number – surely getting a slightly 
>> less random number is better than crashing?
>> It could be that the problematic instances were going to disconnect anyway 
>> due to TCP/IP problems.
>>
> 
> I think we need to try instrumenting the code to see if we can get some
> more information out. I will try and pull something together - but it
> might be Monday before I get the opportunity.

I got to it quicker than I thought. Please see attached patch. Can you
apply it to the latest git 1.0.2 version and re-run your test (capture
stderr output). I'd like to see what we get.

Also is this 32-bit or 64-bit Windows? Are you able to share your
locking callback implementation?

Thanks

Matt


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4545
Please log in as guest with password guest if prompted

>From 71bec261502b5ad7ad3bb8ad39b069c49d42da5f Mon Sep 17 00:00:00 2001
From: Matt Caswell <m...@openssl.org>
Date: Fri, 17 Jun 2016 23:57:13 +0100
Subject: [PATCH] Add some instrumentation to md_rand.c

---
 crypto/rand/md_rand.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/crypto/rand/md_rand.c b/crypto/rand/md_rand.c
index bd76e23..7c2931e 100644
--- a/crypto/rand/md_rand.c
+++ b/crypto/rand/md_rand.c
@@ -270,6 +270,19 @@ static void ssleay_rand_add(const void *buf, int num, double add)
 MD_Update(, local_md, MD_DIGEST_LENGTH);
 k = (st_idx + j) - STATE_SIZE;
 if (k > 0) {
+if (j - k < 0) {
+CRYPTO_THREADID thisthreadid;
+CRYPTO_THREADID_current();
+fprintf(stderr, "MD_RAND ERROR: ssleay_rand_add: k == %d, "
+"j == %d, st_idx == %d, state_num == %ld, do_not_lock %d, "
+"crypto_lock_rand == %d, locking_threadid == %lu, "
+"thisthreadid == %lu\n",
+k, j, st_idx, state_num, do_not_lock, crypto_lock_rand,
+CRYPTO_THREADID_hash(_threadid),
+CRYPTO_THREADID_hash());
+fflush(stderr);
+abort();
+}
 MD_Update(, &(state[st_idx]), j - k);
 MD_Update(, &(state[0]), k);
 } else
@@ -492,6 +505,19 @@ int ssleay_rand_bytes(unsigned char *buf, int num, int pseudo, int lock)
 
 k = (st_idx + MD_DIGEST_LENGTH / 2) - st_num;
 if (k > 0) {
+if (MD_DIGEST_LENGTH / 2 - k < 0) {
+CRYPTO_THREADID thisthreadid;
+CRYPTO_THREADID_current();
+fprintf(stderr, "MD_RAND ERROR: ssleay_rand_bytes: k == %d, "
+"st_idx == %ld, st_num == %ld, lock %d, "
+"crypto_lock_rand == %d, locking_threadid == %lu, "
+"thisthreadid == %lu\n",
+k, st_idx, st_num, lock, crypto_lock_rand,
+CRYPTO_THREADID_hash(_threadid),
+CRYPTO_THREADID_hash());
+fflush(stderr);
+abort();
+}
 MD_Update(, &(state[st_idx]), MD_DIGEST_LENGTH / 2 - k);
 MD_Update(, &(state[0]), k);
 } else
-- 
2.7.4

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4545] Crash in crypto/rand/md_rand.c

[Matt Caswell via RT]

On 17/06/16 19:43, Mick Saxton via RT wrote:
> Perhaps we should consider if there are any negative consequences to my 
> solution?
> It does work.
> 
> I am trying really hard to get contention but I am only seeing this problem 
> in about 1 out of 100,000 successful TLSv1.2 connections
> On a heavily congested network.
> I require three machines to just to run the test that causes the failure.
> 
> All we are trying to do is get a random number – surely getting a slightly 
> less random number is better than crashing?
> It could be that the problematic instances were going to disconnect anyway 
> due to TCP/IP problems.
> 

I think we need to try instrumenting the code to see if we can get some
more information out. I will try and pull something together - but it
might be Monday before I get the opportunity.

Matt


> 
> 
> Rather than my previous suggestion – I am now suggesting:-
> 
> So in ssleay_rand_add
> 
> If ( j-k>0 ) MD_Update(, &(state[st_idx]), j – k);
> 
> And a similar fix in ssleay_rand_bytes
> 
> 
> This also avoids adding zero bytes to the hash – which it does quite often.
> 
> 
> 
> 
> From: Salz, Rich via RT [mailto:r...@openssl.org]
> Sent: 17 June 2016 18:39
> To: Mick Saxton
> Cc: openssl-dev@openssl.org
> Subject: RE: [openssl-dev] [openssl.org #4545] Crash in crypto/rand/md_rand.c
> 
> Sending mail re-opens the ticket.
> 
> Rats, wish it was fixed. Going to need something to more easily reproduce it, 
> I guess.
> 
> --
> Ticket here: 
> http://rt.openssl.org/Ticket/Display.html?id=4545
> Please log in as guest with password guest if prompted
> 
> 
> 
> 
> Legal Notice: This email is intended only for the person(s) to whom it is 
> addressed. If you are not an intended recipient and have received this 
> message in error, please notify the sender immediately by replying to this 
> email or calling +44(0) 2083269015 (UK) or +1 866 592 4214 (USA). This email 
> and any attachments may be privileged and/or confidential. The unauthorized 
> use, disclosure, copying or printing of any information it contains is 
> strictly prohibited. The opinions expressed in this email are those of the 
> author and do not necessarily represent the views of 1E Ltd. Nothing in this 
> email will operate to bind 1E to any order or other contract.
> 


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4545
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4572] SSL_set_bio and friends

[Matt Caswell via RT]

On 14/06/16 21:30, David Benjamin via RT wrote:
> For OpenSSL master, I believe it'd also work to add an s->rbio != s->wbio
> check to SSL_set_rbio, but I think those are worse semantics for
> SSL_set_{rbio,wbio}. They are new APIs, so, before it's too late, give them
> clear semantics like "SSL_set_rbio takes ownership of its argument",
> consistent with "set0" functions, rather than a mix of "set0" and "set1".

These look like good changes. I'm wondering whether we should actually
rename SSL_set_rbio() and SSL_set_wbio() to SSL_set0_rbio() and
SSL_set0_wbio() - especially since they are new to 1.1.0 so not released
yet.

*Possibly* we could also rename SSL_set_bio() to SSL_set0_bio() with a
deprecated compatibility macro.

Matt


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4572
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4456] Fedora 1, i386: error: field `next_timeout` has incomplete type

[Matt Caswell via RT]

Jeff has confirmed that this issue has been fixed in latest master. Closing
this ticket.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4456
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4565] Fatal error: Command failed for target `link_shlib.solaris'

[Matt Caswell via RT]

This is fixed in latest master. Closing.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4565
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4526] bug: use of ExitProcess on Windows platforms, 1.0.2g

[Matt Caswell via RT]

On Wed Jun 15 17:42:58 2016, rsalz wrote:
> OpenSSL_1_0_2-stable 75f9068 RT4526: Call TerminateProcess, not ExitProcess
> master 9c1a9cc RT4526: Call TerminateProcess, not ExitProcess
>
> Author: Rich Salz 
> Date: Tue Jun 14 16:19:37 2016 -0400
>
> RT4526: Call TerminateProcess, not ExitProcess
>
> Reviewed-by: Richard Levitte 

I just reverted this commit. We need to take another look at this, so reopening
this ticket.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4526
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4038] SSLv2 session reuse is broken on the 1.0.2 branch

[Matt Caswell via RT]

On Tue Jun 14 20:42:36 2016, rsalz wrote:
> SSLv2 is not supported any more.

Uyes it is on the 1.0.2 branch? It is off by default though.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4038
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #2388] out-of-date comment for renegotiation handling

[Matt Caswell via RT]

Fixed in commit e7653f3bab. Closing ticket.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2388
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #597] SSL_set_session() problem (?)

[Matt Caswell via RT]

Fixed in commit e70656cf1c.

Closing ticket.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=597
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4434] Gentoo 13, x86_64: 4 failed self tests

[Matt Caswell via RT]

On Wed Jun 01 22:20:38 2016, matt wrote:
> Hi Jeff
>
> Please could you try the attached patch?


Jeff confirmed to me that the patch solved the problem. Pushed as commit
25b9d11c0.

Closing ticket.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4434
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4329] OpenSSL 1.1.0 pre3: internal error in tls_post_process_client_key_exchange during reneg

[Matt Caswell via RT]

On Wed Jun 08 16:02:39 2016, matt wrote:
> On Tue May 24 13:53:07 2016, steve wrote:
> > On Sun Feb 21 13:55:35 2016, rainer.j...@kippdata.de wrote:
> > > Running the Apache test suite for Apache 2.4 with OpenSSL 1.1.0
> > > adjustments, I get
> > >
> >
> > Can you please check to see if this issue is still present in the latest
> > OpenSSL 1.1.0?
>
> Hi Rainer
>
> Can this ticket be closed now?


No response from OP, so assuming this is no longer an issue. Please open a new
ticket if it is.

Closing.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4329
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4558] Performance issue with DTLS packet reassembly

[Matt Caswell via RT]

On Thu Jun 02 23:24:44 2016, paul.d...@oracle.com wrote:
> The DTLS packet reassembly code has a performance problem that could
> result in a DoS attack being possible.
>
>
>
> The DTLS packet reassembly uses the data structure defined in
> ssl/pqueue.c for the purpose (it is the only user of this data
> structure that I can find). This source file implements a priority
> queue using a singly linked list. This means O(n^2) worst case
> complexity, where n is the number of fragments. A better, and in fact
> optimal, solution would be to use a heap for the purpose giving O(n
> log n) worst case complexity. Doing this would prevent a potential
> DoS attack.
>
>
>
> The attack would consist of fragmenting the DTLS stream into as many
> small packets as possible and sending them in sequential order. Each
> fragment will require a complete traversal of the list to be added.
> Continue sending these as long as the DoS is wanted. For reference,
> changing the list search method or ordering won't prevent such an
> attack, it just means a different packet ordering is required.
>
>
>
> Tim Hudson suggested I submit this even though I haven't been able to
> find time to craft a patch.


This will require some significant rework of the pqueue code. This ticket is
currently against the 1.1.0 milestone, but realistically that kind of change
isn't going to happen in that timeframe, so pushing to post 1.1.0.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4558
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4562] Possible bug in OPENSSL_config - ignore input parameter

[Matt Caswell via RT]

On Fri Jun 10 13:02:57 2016, z...@ua7.net wrote:
> Hello
>
> Looks like OPENSSL_config have a bug as result users can't set
> alternative path to openssl.cnf file.
> If you take a look on implementation of void OPENSSL_config(const char
> *config_name) it call a
> CONF_modules_load_file(NULL, config_name, CONF_MFLAGS_DEFAULT_SECTION |
> CONF_MFLAGS_IGNORE_MISSING_FILE);
> As you can see "config_name" put to "CONF_modules_load_file" as second
> argument, but if you take a look on:
> int CONF_modules_load_file(const char *filename, const char *appname,
> unsigned long flags)
>
> Looks like CONF_modules_load_file expected config file name as FIRST
> argument (instead of second).

This actually looks to me like a documentation error. The parameter to
OPENSSL_config() is not *intended* to be a filename at all - it has never
worked that way, and if you read the original commit messages you can see that
was never the intention (it is the application name within the config file).
The original documentation was a little unclear, but never actually said that
it was a filename. It then got "cleaned up" in commit 14d3b76be to what it is
now (which is wrong).

So, I think the actual fix is to correct the documentation. We should also
probably make it more obvious that it is deprecated in 1.1.0 (it does say it on
the page but you have to read half of it before you realise).

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4562
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #1051] SSL_CTX_set_default_paths

[Matt Caswell via RT]

Fixed in f5de06aae. Closing.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=1051
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #3720] Patch for "Increment SSL session miss counter appropriately"

[Matt Caswell via RT]

Patch applied - thanks. Closing.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3720
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4561] BUG: openssl-1.0.2h, evp_enc.c, non-portable bitwise operation

[Matt Caswell via RT]

On Mon Jun 06 18:26:50 2016, loic.etie...@qnective.com wrote:
> crypto/evp/evp_enc.c, EVP_EncryptUpdate
> line 337: inl & (ctx->block_mask)
> line 367: inl & (bl - 1) /* with bl = ctx->cipher->block_size */

Why do you consider this a problem?

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4561
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4456] Fedora 1, i386: error: field `next_timeout` has incomplete type

[Matt Caswell via RT]

On Tue May 31 16:49:23 2016, rsalz wrote:
> Re-Ping Jeff to take a look and see if things are fixed now.

Ping Jeff.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4456
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4479] OS X 10.8 (x86_64): Compile errors when using "no-asm -ansi"

[Matt Caswell via RT]

Status as per ticket 4480. Closing this ticket.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4479
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4480] Ubuntu 14 (x86_64): Compile errors and warnings when using "no-asm -ansi"

[Matt Caswell via RT]

I applied the original roll up patch. I wasn't keen on adding all the
__STRICT_ANSI__ ifdefs from the later patch. That seems excessive to me for
little benefit - we are generally trying to reduce the ifdef code as much as
possible. I also didn't add the __WORDSIZE bit. I believe that symbol is an
internal compiler symbol and shouldn't be used.

Closing this ticket. Thanks for the patch.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4480
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4434] Gentoo 13, x86_64: 4 failed self tests

[Matt Caswell via RT]

On Wed Jun 01 22:20:38 2016, matt wrote:
> Hi Jeff
>
> Please could you try the attached patch?


Any update on this?

Thanks

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4434
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4329] OpenSSL 1.1.0 pre3: internal error in tls_post_process_client_key_exchange during reneg

[Matt Caswell via RT]

On Tue May 24 13:53:07 2016, steve wrote:
> On Sun Feb 21 13:55:35 2016, rainer.j...@kippdata.de wrote:
> > Running the Apache test suite for Apache 2.4 with OpenSSL 1.1.0
> > adjustments, I get
> >
>
> Can you please check to see if this issue is still present in the latest
> OpenSSL 1.1.0?

Hi Rainer

Can this ticket be closed now?

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4329
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4395] OpenSSL doesn't reject out-of-context empty records

[Matt Caswell via RT]

On Mon Mar 07 22:27:23 2016, david...@google.com wrote:
> ssl3_get_record silently discards empty records without much context,
> which
> means OpenSSL will happily accept, e.g., empty app data records
> mid-handshake or empty records of bogus type. They get silently
> discarded
> and never returned to the caller, so this is harmless, just a little
> odd.

Fixed in commit 255cfeac. I also added a test for this in 4f0c475.

Thanks David. Closing.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4395
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4501] bug in BN_mod_word

[Matt Caswell via RT]

On Thu Apr 07 11:44:09 2016, peter.chernys...@gmail.com wrote:
> Hello!
> BN part program
>
> BN_ULONG BN_mod_word (const BIGNUM * a, BN_ULONG w);
>
> does not work properly on 64-bit machine with some w> 2 ^ 32, although
> declared as BN_ULONG (64 bits).


Fixed in commit e82fd1b4 (1.0.2) and 37258dad (1.1.0).

Thanks for the report.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4501
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4496] [PATCH] ssl_cert: use the recommended minimum hash from RFC 5480 for EC

[Matt Caswell via RT]

On Sat Apr 02 14:05:50 2016, sebast...@breakpoint.cc wrote:
> A TLS1.2 connetion with openssl server and gnutls-cli using a
> SECP384R1
> key ends up with SHA256 as the hash algorithm for signing the key
> exchange.
> This is because gnutls sends the hash algorithms from weak to strong
> and by default client's preference is used.
>
> gnutls complains about this situation:
> |<1>| The hash size used in signature (32) is less than the expected
> (48)

Really gnutls should not offer algorithms that it is not prepared to accept.

Also if sha256 with p256 is considered acceptable security, why wouldn't sha256
with p384 be?

OpenSSL is obeying RFC5246 7.4.1.4.1:

   Each SignatureAndHashAlgorithm value lists a single hash/signature
   pair that the client is willing to verify.  The values are indicated
   in descending order of preference.

So I don't think this is an OpenSSL bug. Closing this ticket.

Matt

>
> The complaint is based on the recommendation in RFC 5480, section 4.
> Security Considerations. There two ways to fix it:
> - Using
> -sigalgs
> "ECDSA+SHA384:ECDSA+SHA512:ECDSA+SHA256:ECDSA+SHA224:ECDSA+SHA1"
> -serverpref
> The weaker algorithms
>
> - The following patch which eliminates SHA256+SHA224 from the list of
> possible candidates. SHA1 is still available if left out in -sigalgs
> and nothing else matches.
>
> Signed-off-by: Sebastian Andrzej Siewior 
> ---
> ssl/ssl_cert.c | 19 +++
> 1 file changed, 19 insertions(+)
>
> diff --git a/ssl/ssl_cert.c b/ssl/ssl_cert.c
> index 4081ebe4ffbd..7d00ad3182f5 100644
> --- a/ssl/ssl_cert.c
> +++ b/ssl/ssl_cert.c
> @@ -1135,6 +1135,25 @@ static int ssl_security_default_callback(const
> SSL *s, const SSL_CTX *ctx, int o
> if (level >= 3)
> return 0;
> break;
> +#ifndef OPENSSL_NO_EC
> + case SSL_SECOP_SIGALG_SHARED:
> + if (s && s->cert && s->cert->key && s->cert->key->privatekey)
> {
> + EVP_PKEY *skey = s->cert->key->privatekey;
> +
> + /*
> + * RFC 5480 Section 4, Security Considerations.
> + * For a curve with keysize of 384 bits (secp384r1) we
> + * allow SHA-384 and higher
> + */
> + if (EVP_PKEY_id(skey) == EVP_PKEY_EC) {
> + if (EVP_PKEY_bits(skey) > (bits * 2))
> + return 0;
> + }
> + }
> + if (bits < minbits)
> + return 0;
> + break;
> +#endif
> default:
> if (bits < minbits)
> return 0;

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4496
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #3198] [PATCH] Fix missing NULL pointer checks and memory leaks in crypto/asn1 files

[Matt Caswell via RT]

The last patches from this have now been applied so closing this ticket.
Thanks!

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3198
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4434] Gentoo 13, x86_64: 4 failed self tests

[Matt Caswell via RT]

Hi Jeff

Please could you try the attached patch?

Thanks

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4434
Please log in as guest with password guest if prompted

>From 199bf71fb68a26a9d7ff52af7233bd0b52d0f824 Mon Sep 17 00:00:00 2001
From: Matt Caswell 
Date: Wed, 1 Jun 2016 23:15:12 +0100
Subject: [PATCH] Handle inability to create AFALG socket

Some Linux platforms have a suitably recent kernel to support AFALG, but
apparently you still can't actually create an afalg socket. This extends
the afalg_chk_platform() function to additionally check whether we can
create an AFALG socket. We also amend the afalgtest to not report a
failure to load the engine as a test failure. A failure to load is almost
certainly due to platform environmental issues, and not an OpenSSL problem.
---
 engines/afalg/e_afalg.c | 9 +
 test/afalgtest.c| 9 +++--
 2 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/engines/afalg/e_afalg.c b/engines/afalg/e_afalg.c
index ec2a57e..84f00a0 100644
--- a/engines/afalg/e_afalg.c
+++ b/engines/afalg/e_afalg.c
@@ -731,6 +731,7 @@ static int afalg_chk_platform(void)
 int ret;
 int i;
 int kver[3] = { -1, -1, -1 };
+int sock;
 char *str;
 struct utsname ut;
 
@@ -758,6 +759,14 @@ static int afalg_chk_platform(void)
 return 0;
 }
 
+/* Test if we can actually create an AF_ALG socket */
+sock = socket(AF_ALG, SOCK_SEQPACKET, 0);
+if (sock == -1) {
+AFALGerr(AFALG_F_AFALG_CHK_PLATFORM, AFALG_R_SOCKET_CREATE_FAILED);
+return 0;
+}
+close(sock);
+
 return 1;
 }
 
diff --git a/test/afalgtest.c b/test/afalgtest.c
index 3baced7..7fc03ba 100644
--- a/test/afalgtest.c
+++ b/test/afalgtest.c
@@ -102,8 +102,13 @@ int main(int argc, char **argv)
 
 e = ENGINE_by_id("afalg");
 if (e == NULL) {
-fprintf(stderr, "AFALG Test: Failed to load AFALG Engine\n");
-return 1;
+/*
+ * A failure to load is probably a platform environment problem so we
+ * don't treat this as an OpenSSL test failure, i.e. we return 0
+ */
+fprintf(stderr,
+"AFALG Test: Failed to load AFALG Engine - skipping test\n");
+return 0;
 }
 
 if (test_afalg_aes_128_cbc(e) == 0) {
-- 
2.7.4

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4244] dhparam -check should

[Matt Caswell via RT]

dhparam will never generate parameters that fail DH_check(). It would be an
internal error if it did. I added a sanity check anyway and also brought the
documentation up to date. Commit eeb21772e.

Closing this ticket.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4244
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4379] "arch/async_posix.h:67:24: error: ucontext.h: No such file or directory" under OpenBSD 5.7/64-bit

[Matt Caswell via RT]

On Wed Jun 01 09:17:18 2016, noloa...@gmail.com wrote:
> > Please could you try the attached patch?
>
> It tested OK. 'make test' executed without any problems. Ship it and
> close the ticket.

Pushed in commit e51329d38. Closing ticket.

Thanks

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4379
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4149] [PATCH] ssl_set_pkey() unnecessarily updates certificates

[Matt Caswell via RT]

Steve fixed this via commit f72f00d495.

Closing.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4149
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4189] PR #512: Clean up Windows RNG

[Matt Caswell via RT]

On Mon Dec 21 11:07:24 2015, dra...@dancingdragon.be wrote:
> https://github.com/openssl/openssl/pull/512
>
> This PR removes all of the dangerous Windows entropy gathering routines
> in favor of standard CryptGenRandom calls, as was discussed in the
> "Improving OpenSSL default RNG" thread on openssl-dev. This fixes
> common, repeatable crashes that happen when running openssl under the VS
> debugger.

For the record this became this pull request and has now been merged:

https://github.com/openssl/openssl/pull/1079

Closing this ticket.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4189
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4255] OpenSSL-1.1.0-pre2 failures using MinGW-W64

[Matt Caswell via RT]

On Tue May 10 12:36:40 2016, matt wrote:
> Re-opening. OP reports there are still issues with "make test" hanging.

The "make test" hang issue on mingw should now be resolved in the head of
master. Unfortunately there is now a completely different issue preventing
compilation for mingw :-( That is nothing to do with this ticket though so
closing.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4255
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4545] Crash in crypto/rand/md_rand.c

[Matt Caswell via RT]

On 27/05/16 11:07, Mick Saxton via RT wrote:
> Hi Matt
> 
> The test program runs against our major new development so I cannot share it 
> as is.
> 
> I will try to produce a skeleton version which I could let you have.
> 
> -  But that will be end if next week as I am away for a few days
> 
> -  That is providing that exhibits the bug.

That will be fine. Many thanks.

Matt


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4545
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4545] Crash in crypto/rand/md_rand.c

[Matt Caswell via RT]

On Fri May 20 15:49:49 2016, mi...@1e.com wrote:
> Hi
>
> Before going any further I would like to state that I have only seen
> this problem when we have 1 or more concurrent connections.
>
> Mostly we notice it on Windows but I have seen it on linux (Ubuntu).
>
> I first noticed it when using v1.0.2d but have seen it again since
> upgrading to v1.0.2h.
>
> It can happen in one of two places and results in a call to MD_Update
> with a negative value.
>
> I have come up with a temporary fix which avoids the possibility of
> crashing at the expense of some randomness.
> The system is very highly stressed at this point so debugging further
> is difficult.
>
> The fix I am using is probably not what you eventually will want to
> implement but it does improve stability.
>
> 273: MD_Update(, &(state[st_idx]), (j - k) );
> Change to
> 273: MD_Update(, &(state[st_idx]), (j - k) > 0 ? j - k :
> 1); // mi...@1e.com (j -k) must not be negative
>
> And
>
> 495: MD_Update(, &(state[st_idx]), MD_DIGEST_LENGTH / 2 -
> k )
> Change to
> 495: MD_Update(, &(state[st_idx]), MD_DIGEST_LENGTH / 2 -
> k > 0 ? MD_DIGEST_LENGTH / 2 - k : 1); // mi...@1e.com (j -k) must
> not be negative
>
>
> I do have a test program which can reproduce this behaviour.

Hi Mick

Are you able to share your test program?

Thanks

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4545
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #2270] CVS HEAD: bugfix for BIO printf() code: floating point does not print + other wrongs in that code path

[Matt Caswell via RT]

I applied this patch in part. The code has moved on since this was written and
this was from pre-reformat times so I added the changes that were still
applicable "manually". See commit 242073bdbc. Also properly implemented the %e
and %g format specifiers in commit d6056f085d. Finally I added a test for all
of this in f8f686ec1c.

Closing.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2270
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4180] Isses with respect to malloc failures handling.

[Matt Caswell via RT]

You don't say what version of OpenSSL you were testing. It seems to be either
1.0.2 or 1.0.1 (not master). Anyway, comments inserted.

On Mon Dec 14 13:45:20 2015, skoripe...@juniper.net wrote:
> Issue 1)
> We could have failed to allocate the ctx->cipher_data in
> EVP_CipherInit_ex
>
> ctx->cipher_data = OPENSSL_malloc(ctx->cipher->ctx_size);
> if (!ctx->cipher_data) {
> EVPerr(EVP_F_EVP_CIPHERINIT_EX, ERR_R_MALLOC_FAILURE);
> return 0;
> }
>
> We do subsequently return error from EVP_CipherInit_ex. However during
> shutdown because of this error we are not checking for the NULL
> cipher_data causing cores

This seems very strange to me. If we have already returned a fatal error...then
its just that - fatal. Don't try and do a graceful shutdown on an already dead
connection.

>

> Issue 2
> In file pmeth_gn.c function EVP_PKEY_keygen, openssl code tries to
> allocate EVP_PKEY using EVP_PKEY_new and immediately follows with a
> dereference of the same in the below path without checking if the
> allocation was successful or not.

Fixed in 8e0a94a58.

> Issue 3:
>
> In file s3_enc.c in function ssl3_digest_cached_records,
> EVP_DigestInit_ex is called to initialize the EVP digest. Internally
> to EVP_DigestInit_ex ctx->md_data is allocated and if it fails an
> error is returned. However in ssl3_digest_cached_records the return
> value is not checked, causing a null dereference with the below

Fixed in ada5de7c and similar commit in master (this was the only one
applicable to master BTW).


> Issue 4:
> In file ssl_lib.c, in function ssl_replace_hash, an EVP_MD_CTX is
> created using EVP_MD_CTX_create. However, the return value of this
> allocation is not checked and a dereference is made just below in
> EVP_DigestInit_ex causing a core.

This was fixed in 56d9134675 which was commited a few weeks before the date of
your report.

>
===
> Issue 5:
> In tl_enc.c, in function tls1_enc in the case of
> /\* Explicit IV length, block ciphers and TLS version 1.1 or later \*/
> openssl tries to dereference cipher after getting the value of cipher
> from s->enc_write_ctx. However cipher can be null. This can happen
> because we returned NULL in Issue 4) above and s->enc_write_ctx-
> >cipher might not have been set. Typically
> s->enc_write_ctx->cipher would have been set in the below path but
> because of Issue 4 above we did not set s->enc_write_ctx->cipher.

Issue 4 above resulted in a core if it failed...so this confuses me! Anyway I
could not see how this could occur if Issue 4 fails more gracefully. All
callers of ssl_replace_hash propagate the error. Perhaps an issue similar to
issue 1 above? Or maybe its been fixed since. I'm assuming this is no longer an
issue. Please raise a new ticket if it is.

> Issue 6:
> Similar issue as above exists in s3_pkt.c function do_ssl3_write in
> the case
> /\* Explicit IV length, block ciphers and TLS version 1.1 or later \*/
> where again s->enc_write_ctx->cipher can be NULL.

As for issue 5.

>
===
> Issue 7:
> In file t1_enc.c, in function tls1_mac, openssl after calling
> EVP_DigestSignFinal has an assert on the return value to be greater
> than 0. However, EVP_DigestSignFinal internally allocates memory and
> if this memory allocation fails, an error is returned. Hence this
> assert is overaggressive for low memory cases. So Pls see if instead
> of coring, the error can be handled gracefully.

This was fixed in the same commit mentioned above that was committed a few
weeks before your report.

>

> Issue 8:
> In file t1_enc.c, in function tls1_setup_key_block, memory is
> allocated twice for the keyblock through p1 and p2. If p1 succeeds but
> p2 fails, p1 is freed but the freed pointer p1 is left dangling inside
> s->s3->tmp.key_block which is later attempted to be freed while
> freeing s->s3 resulting in a double free.
> The fix would be to set the s->s3->tmp.key_block to NULL

This was fixed in ec8f246e6ed4 a few weeks ago.

Closing this ticket.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4180
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4501] bug in BN_mod_word

[Matt Caswell via RT]

On Thu Apr 07 11:44:09 2016, peter.chernys...@gmail.com wrote:
> Добрый день!
> программа библиотеки BN_mod_word
> BN_ULONG BN_mod_word(const BIGNUM *a, BN_ULONG w);
>
> работает неверно на 64 бит машине при некоторых w>2^32, хотя объявлена как
> BN_ULONG (64 бита).
>
> Петр
>
> Hello!
> BN part program
>
> BN_ULONG BN_mod_word (const BIGNUM * a, BN_ULONG w);
>
> does not work properly on 64-bit machine with some w> 2 ^ 32, although
> declared as BN_ULONG (64 bits).

Hello

Do you have a test case for this that demonstrates this problem?

Thanks

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4501
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4430] #1852: [BUG] Invalid Proxy Certificates Pass Validation

[Matt Caswell via RT]

This ticket was opened in error. The correct ticket that remains open is #1852.
Closing,.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4430
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4525] [PATCH] SRP client key computation (PR #1017)

[Matt Caswell via RT]

This got merged recently. Closing.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4525
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4537] [PATCH] Fix a NULL dereference in chacha20_poly1305_init_key()

[Matt Caswell via RT]

This got merged recently. Closing.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4537
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4379] "arch/async_posix.h:67:24: error: ucontext.h: No such file or directory" under OpenBSD 5.7/64-bit

[Matt Caswell via RT]

On Wed May 11 10:24:31 2016, matt wrote:
> Hi Jeff
>
> Please could you try the attached patch?

Hi Jeff

Were you able to try out the patch?

Thanks

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4379
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #2289] [PATCH 1/3] crypto/hmac: support EVP_MD_CTX_FLAG_ONESHOT and set it properly

[Matt Caswell via RT]

No movement on this in 6 years. Doesn't look like this is going to happen.
Closing.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2289
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #1878] [PATCH] Fix RSA blinding locking hole

[Matt Caswell via RT]

It is unclear whether this is still an issue. The code looks quite a bit
different in master and I suspect things have moved on. Given the age of this
ticket I think it should be closed and a new one opened if this issue
resurfaces.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=1878
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #2257] CVS HEAD: [quite probable] bug in ssl3_write: does not indirect through callback like it sibling ssl3_read

[Matt Caswell via RT]

Someone already made this change. Closing.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2257
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #1971] [PATCH 09/14] Only test speeds up to 4K packets.

[Matt Caswell via RT]

We're not going to do this. Closing.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=1971
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #2290] [PATCH 2/3] apps/speed: fix digest speed measurement and add hmac-sha1 test

[Matt Caswell via RT]

The code has moved on too much for this patch to be applicable. Closing this.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2290
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #2021] sni bug

[Matt Caswell via RT]

The code in this area has changed significantly so it is far from clear whether
this report is still relevant. Therefore closing. Please open a new ticket if
required.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2021
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #2497] [PATCH] Improve RSAOaep Error Handling

[Matt Caswell via RT]

Looks like this was independently fixed in the time since this was raised.
Closing.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2497
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #1639] BUG in BN_mod_inverse

[Matt Caswell via RT]

AFAIK it is valid to call BN_sub() in this way, and looking at the code I can't
see any problem with doing so. There is no reproducer of an actual issue in
this report, so closing.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=1639
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #2510] [PATCH] ebcdic issues: Bad time value when issuing openssl x509 -text -in

[Matt Caswell via RT]

The supplied patch is not in an acceptable form, and the diff mentioned in the
report (sourcename.txt) does not seem to be attached. Given the length of time
since this was raised this will no longer apply anyway. Please raise a new
ticket if this is still a problem.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2510
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #1747] capi engine and mingw

[Matt Caswell via RT]

CAPI can now be build under mingw in master. Closing this ticket.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=1747
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #2523] Patch to use standard RFC 5054 constants and behavior for TLS-SRP (OpenSSL 1.0.1)

[Matt Caswell via RT]

A lot of the stuff that this is removing already seems to have gone and the
patch no longer applies. I suspect that most of this is no longer necessary. If
any of it is, please open a new ticket.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2523
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #2274] SSL demo programs in openssl-1.0.0

[Matt Caswell via RT]

Most of the demos have been removed from master, and the other patches no
longer apply. Please reopen new issues if any of this is still valid.

Closing.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2274
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #2325] memory corruption after libssl is unloaded from memory

[Matt Caswell via RT]

This shouldn't be an issue any more with auto-init/auto-deinit in master.
Closing this.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2325
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #2036] bug report: TLS session resumption not checking for existence of client finished message

[Matt Caswell via RT]

I'm guessing this is no longer an issue due to the time elapsed and I think
there have been changes in this area since then (and definitely in master).

In any case there is insufficient information in this report to identify the
problem. If this is still a problem please open a new ticket.

Closing.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2036
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #2530] crypto/dsa/dsa_gen.c::dsa_builtin_paramgen has potential uninitialized seed

[Matt Caswell via RT]

Looks like the code has changed since this was raised and this issue has been
fixed.

Closing.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2530
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #1928] interface bug on Windows 64

[Matt Caswell via RT]

Will not fix for 1.1.0...Moving to a later milestone.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=1928
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4394] OpenSSL 1.1.0 state machine can't read handshake headers async

[Matt Caswell via RT]

Fixed in 1689e7e6. Also I added a test in d7295cd6d.

Thanks

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4394
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4391] [PATCH] Tighten up logic around ChangeCipherSpec.

[Matt Caswell via RT]

Patch applied in 1257adecd. Thanks!

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4391
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #1979] Add uClibc support

[Matt Caswell via RT]

Reclosing this.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=1979
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4352] Failed test 'Duplicate ClientHello extension' when testing under Clang undefined behavior sanitizer

[Matt Caswell via RT]

I can't reproduce this on latest master, so I am assuming it has been fixed.

Closing ticket.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4352
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4179] fix a bug in ssl_next_proto_validate (ssl/t1_lib.c) [GitHub PR #506]

[Matt Caswell via RT]

The associated github PR was merged so closing this ticket.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4179
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #2146] [Fwd: Re: unexpected message during renegotiate attempt]

[Matt Caswell via RT]

This issue has been discussed a number of times, but will not be fixed at this
time.

Closing

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2146
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #2037] GENERAL_NAME IPv6 parsing bug....

[Matt Caswell via RT]

I can't reproduce this, and it looks like Steve couldn't either at the time.

Closing.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2037
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #1518] [PATCH] Securing private RSA keys

[Matt Caswell via RT]

After 9 years looks like there is no support for this patch (and it will not
apply now anyway). I'd suggest if anyone does support this then a new patch be
submitted via GitHub.

Closing this ticket.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=1518
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #1919] Bug in buffer_ctrl in BIO_f_buffer?

[Matt Caswell via RT]

This seems to have been fixed at some point. Closing.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=1919
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #2363] bug: memory allocated by DH_new() may never be free()ed

[Matt Caswell via RT]

This appears to be a usage problem where the library is not being de-inited
properly. This should be resolved anyway in 1.1.0 with auto-deinit.

Closing ticket.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2363
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #2485] Heap walking in RAND_poll causes deadlock in process on Windows Server 2008 R2 (x64) that uses libCurl, OpenSSL and ADO

[Matt Caswell via RT]

Closing this ticket in favour of:
https://github.com/openssl/openssl/pull/1079

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2485
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #2459] ecdsa_method declaration prevents use in implementing a dynamic engine

[Matt Caswell via RT]

This has been fixed in 1.1.0.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2459
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev