Re: [openssl-users] ECDSA_SIG_new and ECDSA_SIG_free details

On 12/01/2017 12:19, Salz, Rich wrote: It was a mix of what was done, and then a conscious decision to do things that way. As for the PR, well, maybe... We'd need to know details of which machine "test/sanitytest.c" fails on, and how popular it is to see if it's worthwhile. That would be

Re: [openssl-users] ECDSA_SIG_new and ECDSA_SIG_free details

> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf > Of Stephan Mühlstrasser > Sent: Thursday, January 12, 2017 07:50 > > I think IBM iSeries is affected by this, but I still have to verify this. It's been years since I worked on the iSeries (in fact, it was mostly prior

Re: [openssl-users] ECDSA_SIG_new and ECDSA_SIG_free details

Am 12.01.17 um 13:19 schrieb Salz, Rich: My question was meant to ask why the pointers are initialized with memset() instead of initializing them by an assignment with NULL or 0. Was this a deliberate decision for some reason, or did it just creep in and no one cares now to fix it? Would the

Re: [openssl-users] ECDSA_SIG_new and ECDSA_SIG_free details

> My question was meant to ask why the pointers are initialized with > memset() instead of initializing them by an assignment with NULL or 0. > Was this a deliberate decision for some reason, or did it just creep in and no > one cares now to fix it? Would the OpenSSL team accept pull requests that

Re: [openssl-users] ECDSA_SIG_new and ECDSA_SIG_free details

Am 11.01.17 um 17:09 schrieb Salz, Rich: OpenSSL does not support platforms where the memory representation of the NULL pointer contains non-zero bytes. IIRC there are even tests for this. Could someone from the OpenSSL team please explain the rationale for this decision? What is the problem

Re: [openssl-users] ECDSA_SIG_new and ECDSA_SIG_free details

ISO/C 2011, clause 6.3.2.3: An integer constant expression with the value 0, or such an expression cast to type void *, is called a null pointer constant. If a null pointer constant is converted to a pointer type, the resulting pointer, called a null pointer, is guaranteed to compare

Re: [openssl-users] ECDSA_SIG_new and ECDSA_SIG_free details

On Wed, Jan 11, 2017 at 05:27:47PM +, Michael Wojcik wrote: > Unfortunately writing proper C is a rare skill - relatively few C > programmers have ever even read the language specification - and much C > code is saddled with lots of ancient technical debt. Also, of course, it > often doesn't

Re: [openssl-users] ECDSA_SIG_new and ECDSA_SIG_free details

> The representation in memory of a null pointer need not be all-bits-zero. > (The representation in memory of an integer constant with the value zero > can either be all-bits-zero or, in the unlikely case of sign-magnitude > integers, > a sign bit of 1 followed by all-other-bits-zero.) And,

Re: [openssl-users] ECDSA_SIG_new and ECDSA_SIG_free details

> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf > Of Jeffrey Walton > Sent: Wednesday, January 11, 2017 11:19 > To: OpenSSL Users > Subject: Re: [openssl-users] ECDSA_SIG_new and ECDSA_SIG_free details > > > Could someone from the Ope

Re: [openssl-users] ECDSA_SIG_new and ECDSA_SIG_free details - NULL vs zeros

> I suspect that it was a shortcut, where they used memset() on an entire > structure, and it hopefully set pointers to NULL. > > What I pointed out is that if NULL is not all zeros, this breaks. And OpenSSL does not work on those platforms. It is part of the test suite to check for this. See

Re: [openssl-users] ECDSA_SIG_new and ECDSA_SIG_free details

On 11/01/2017 16:32, Stephan Mühlstrasser wrote: Am 03.01.17 um 21:26 schrieb Viktor Dukhovni: On Jan 3, 2017, at 2:55 PM, Ken Goldman wrote: 1 - Is this a bit of a bug? ECDSA_SIG_free() frees the r and s BIGNUMs before is frees the structure itself. However,

Re: [openssl-users] ECDSA_SIG_new and ECDSA_SIG_free details

> Could someone from the OpenSSL team please explain the rationale for this > decision? What is the problem with using assignments with 0 or NULL to > initialize pointers? I'm not from the team, so take it for what its worth... On some systems, NULL is _not_ 0. NULL can be anywhere in memory the

Re: [openssl-users] ECDSA_SIG_new and ECDSA_SIG_free details

> > OpenSSL does not support platforms where the memory representation of > > the NULL pointer contains non-zero bytes. IIRC there are even tests for > this. > > Could someone from the OpenSSL team please explain the rationale for this > decision? What is the problem with using assignments with 0

Re: [openssl-users] ECDSA_SIG_new and ECDSA_SIG_free details

Am 03.01.17 um 21:26 schrieb Viktor Dukhovni: On Jan 3, 2017, at 2:55 PM, Ken Goldman wrote: 1 - Is this a bit of a bug? ECDSA_SIG_free() frees the r and s BIGNUMs before is frees the structure itself. However, ECDSA_SIG_new() doesn't set r and s to NULL. It calls

Re: [openssl-users] ECDSA_SIG_new and ECDSA_SIG_free details

> OpenSSL does not support platforms where the memory representation of > the NULL pointer contains non-zero bytes. IIRC there are even tests for this. Yes, the basic platform sanity tests, test/sanitytest.c -- openssl-users mailing list To unsubscribe:

Re: [openssl-users] ECDSA_SIG_new and ECDSA_SIG_free details

> On Jan 3, 2017, at 2:55 PM, Ken Goldman wrote: > > 1 - Is this a bit of a bug? > > ECDSA_SIG_free() frees the r and s BIGNUMs before is frees the structure > itself. However, ECDSA_SIG_new() doesn't set r and s to > NULL. It calls zalloc, which sets them to 0x00

[openssl-users] ECDSA_SIG_new and ECDSA_SIG_free details

1 - Is this a bit of a bug? ECDSA_SIG_free() frees the r and s BIGNUMs before is frees the structure itself. However, ECDSA_SIG_new() doesn't set r and s to NULL. It calls zalloc, which sets them to 0x00 bytes. OK, in most platforms, the NULL pointer is an all 0x00 bytes value, but it's