Re: official repository vs forks, and fixes

[Peter Mosmans]

Hi Rich,

Thanks for your explanation. Branching in git is extremely fast and
lightweight, which makes it excellent for feature developing without
disrupting anything :)
I wondered why the changes weren't applied onto the rsalz-monolith
branch in the official repository, since that branch already exists there.
A big advantage of having everything in the same official repo is that
developers who forked the repo can merge and/or cherry-pick changes onto
their own branches. Having to work with multiple upstream repositories
is, err, less-than-optimal and error-prone.

Would it be an idea to create branches in the official repo for (certain
classes of) bugfixes, which can be merged onto the respective branches
at set times ? For instance one for documentation fixes ? You could
merge these bugfix branches then also to onto your rsalz-monolith
branch, which would keep the repository nice and orderly.
Branches having lots of different commit types (features, bugfixes,
enhancements, changes) can diverge so much from the official branches
that it will get harder and harder for others to merge them onto forks
or other diverged branches without running into issues. A codebase as
large and as complex as openssl makes it already prone to versioning
errors (eg. fixes implemented in branch X but not in branch Y).

I'm eagerly awaiting the 'move' of your forked repo branch to the
official repository... I'd say the more branches in the official repo
the better!


Peter Mosmans



On 26-08-2014 23:13, Salz, Rich wrote:
>
> Think of this as pre-release software.  The changes are too large to
> disrupt the 1.0.2 release, which is already in beta.
>
>  
>
> We haven’t yet figured out how to make early-access to branches
> available, so for now I just did it via Akamai.  At some point, I’d
> expect that branch to “move” over to openssl’s repo, but we’re not
> there yet.
>
>  
>
> Make sense?
>
>  
>
> /r$
>
>  
>
> -- 
>
> Principal Security Engineer
>
> Akamai Technologies, Cambridge MA
>
> IM: rs...@jabber.me  Twitter: RichSalz
>

Re: [openssl.org #2324] convert c_rehash from perl to POSIX shell

[Mike Frysinger]

On Tue 26 Aug 2014 04:31:07 Rich Salz via RT wrote:
> The sad thing is, perl is widely available than posix shell. cool hack tho.

i don't think that's really true.  else, why is autoconf & friends relying on 
a shell and not perl ?  those see way more distribution than openssl.
-mike
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #2324] convert c_rehash from perl to POSIX shell

[Mike Frysinger via RT]

On Tue 26 Aug 2014 04:31:07 Rich Salz via RT wrote:
> The sad thing is, perl is widely available than posix shell. cool hack tho.

i don't think that's really true.  else, why is autoconf & friends relying on 
a shell and not perl ?  those see way more distribution than openssl.
-mike


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #3504] PATCH: documentation update for dgst command

[Jeffrey Walton]

Oops, thanks Rich.

On Tue, Aug 26, 2014 at 10:06 AM, Rich Salz via RT  wrote:
> The key is not optional with the -hmac option.
> This is fixed in the rsalz-monolith branch of akamai/openssl on github, to be
> rpart of release after 1.0.2
> thanks.
> --
> Rich Salz, OpenSSL dev team; rs...@openssl.org
>
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

RE: [openssl.org #3113] OpenSSL’s DH implementation uses an unnecessarily long exponent, leading to significant performance loss

[Gueron, Shay]

Hello Rich, 

I would recommend to do that. Otherwise there will be "unsuspecting users" who 
will (unintentionally) use the long exponent 
...for example, this is what happened to me in the first attempts, and I did 
not understand why it was so slow :)...

It does not really cost anything significant in complexity, and is easy to do. 

Thanks, Shay

-Original Message-
From: Rich Salz via RT [mailto:r...@openssl.org] 
Sent: Tuesday, August 26, 2014 12:00
To: Gueron, Shay
Cc: openssl-dev@openssl.org
Subject: [openssl.org #3113] OpenSSL’s DH implementation uses an unnecessarily 
long exponent, leading to significant performance loss

It would be fairly easy to address just the exponent issue. Add #define 
DH_FLG_NIST_EXP_LENGTH 0x01 int DH_generate_key_ex(DH* dh, unsigned long flags) 
{ if (flags & DH_FLG_NIST_EXP_LENGTH)
dh->length = calc_nist_length(dh);
return DH_generate_key(dh);
}
Where calc_nist_length() is like the NSS code quoted in the original post.

I can do this if you think it worthwhile.

--
Rich Salz, OpenSSL dev team; rs...@openssl.org

-
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

[openssl.org #3506] [PATCH] Fix typos in ssltest.c.

[Kurt Cancemi via RT]

Hello,

The attached patch fixes some typos in ssltest.c.

---
Kurt Cancemi
https://www.x64architecture.com

>From ea36aa8516e6e8b16896a089d58b216d38302885 Mon Sep 17 00:00:00 2001
From: Kurt Cancemi 
Date: Tue, 26 Aug 2014 17:48:43 -0400
Subject: [PATCH] Fix typos in ssltest.c.

---
 ssl/ssltest.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/ssl/ssltest.c b/ssl/ssltest.c
index f20553f..ff22374 100644
--- a/ssl/ssltest.c
+++ b/ssl/ssltest.c
@@ -379,7 +379,7 @@ static unsigned char *alpn_selected;
  * in a format suitable for passing to SSL_CTX_set_next_protos_advertised.
  *   outlen: (output) set to the length of the resulting buffer on success.
  *   err: (maybe NULL) on failure, an error message line is written to this BIO.
- *   in: a NUL termianted string like "abc,def,ghi"
+ *   in: a NUL terminated string like "abc,def,ghi"
  *
  *   returns: a malloced buffer or NULL on failure.
  */
@@ -749,7 +749,7 @@ static void sv_usage(void)
 	fprintf(stderr," -client_auth  - do client authentication\n");
 	fprintf(stderr," -proxy- allow proxy certificates\n");
 	fprintf(stderr," -proxy_auth  - set proxy policy rights\n");
-	fprintf(stderr," -proxy_cond  - experssion to test proxy policy rights\n");
+	fprintf(stderr," -proxy_cond  - expression to test proxy policy rights\n");
 	fprintf(stderr," -v- more output\n");
 	fprintf(stderr," -d- debug output\n");
 	fprintf(stderr," -reuse- use session-id reuse\n");
@@ -1025,7 +1025,7 @@ int main(int argc, char *argv[])
 #ifdef OPENSSL_FIPS
 			fips_mode=1;
 #else
-			fprintf(stderr,"not compiled with FIPS support, so exitting without running.\n");
+			fprintf(stderr,"not compiled with FIPS support, so exiting without running.\n");
 			EXIT(0);
 #endif
 			}
-- 
2.1.0

RE: [openssl.org #3113] OpenSSL’s DH implementation uses an unnecessarily long exponent, leading to significant performance loss

[Gueron, Shay via RT]

Hello Rich, 

I would recommend to do that. Otherwise there will be "unsuspecting users" who 
will (unintentionally) use the long exponent 
...for example, this is what happened to me in the first attempts, and I did 
not understand why it was so slow :)...

It does not really cost anything significant in complexity, and is easy to do. 

Thanks, Shay

-Original Message-
From: Rich Salz via RT [mailto:r...@openssl.org] 
Sent: Tuesday, August 26, 2014 12:00
To: Gueron, Shay
Cc: openssl-dev@openssl.org
Subject: [openssl.org #3113] OpenSSL’s DH implementation uses an unnecessarily 
long exponent, leading to significant performance loss

It would be fairly easy to address just the exponent issue. Add #define 
DH_FLG_NIST_EXP_LENGTH 0x01 int DH_generate_key_ex(DH* dh, unsigned long flags) 
{ if (flags & DH_FLG_NIST_EXP_LENGTH)
dh->length = calc_nist_length(dh);
return DH_generate_key(dh);
}
Where calc_nist_length() is like the NSS code quoted in the original post.

I can do this if you think it worthwhile.

--
Rich Salz, OpenSSL dev team; rs...@openssl.org

-
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: Subject: [PATCH] ssl: introduce async sign/decrypt APIs This patch is introducing `async_key_ex_cb` member of both `SSL_CTX` and `SSL`, and `SSL_supply()`. If `async_key_ex_cb` is present: * Serve

[Fedor Indutny]

Oops, just realized that I pasted whole commit message into a subject.

Anyway, CCing Rich Salz here.

Rich,

You seem to be on a wave on triaging tickets, may be you could take a look
at this one eventually?

Thank you,
Fedor.


On Sat, Aug 23, 2014 at 10:08 PM, Fedor Indutny  wrote:

> This patch is introducing `async_key_ex_cb` member of both `SSL_CTX` and
> `SSL`, and `SSL_supply()`. If `async_key_ex_cb` is present:
>
> * Server will ignore dummy RSA key, assuming that it is matching the
>   certificate.
> * Server will invoke this callback with either:
>   * `SSL_KEY_EX_RSA`
>   * `SSL_KEY_EX_RSA_SIGN`
>   as a `type` argument, and some data for signature or decryption in
>   `p`/`n` pair.
>
> At that time the sign/decryption may be performed on any thread, or even
> remotely, and the result should be supplied with `SSL_supply()`. Calling
> `SSL_supply()` will continue the handshake process without even touching
> the real private key.
>
> NOTE:
>
> The test is missing right now, I'll add it once we will figure out how the
> API should look like. Implementation appears to be working when used with
> node.js, see
> https://github.com/indutny/node/tree/feature/async-key-exchange and
> https://gist.github.com/indutny/948eaf9b5154eb395e8b for testing.
>
> ANOTHER NOTE:
>
> Pull Request on github: https://github.com/openssl/openssl/pull/162
>

[openssl.org #3499] Bug: Multiple matching certificates in CAfile

[Stephen Henson via RT]

On Fri Aug 22 21:00:55 2014, tris...@saticed.me.uk wrote:
> I have the global sign new and old CA certs in a single file.
> Successful verification seems to depend on the order of the
> certificates in the file:
>
> $ cat globalsign_new.pem globalsign_old.pem > test.pem
> $ openssl s_client -connect bbc.co.uk:443 -CAfile test.pem
> ...
> Verify return code: 0 (ok)
> $ cat globalsign_old.pem globalsign_new.pem > test.pem
> $ openssl s_client -connect bbc.co.uk:443 -CAfile test.pem
> ...
> Verify return code: 10 (certificate has expired)
> $ openssl version
> OpenSSL 1.0.1f 6 Jan 2014
>
> It seems like it should verify against both certificates, for example
> if a renewed CA cert is issued before it becomes valid.
>

This is a known issue, see PR#3359. It should be fixed in the master branch.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

RE: official repository vs forks, and fixes

[Salz, Rich]

> Would it be an idea to create branches in the official repo for (certain 
> classes of) bugfixes, which can be merged onto the respective branches at set 
> times ? For instance one for documentation fixes ? You could

Yes.  But we (the dev team) haven't figured out all of the details of our 
workflow yet.

--  
Principal Security Engineer
Akamai Technologies, Cambridge MA
IM: rs...@jabber.me Twitter: RichSalz
:��I"Ϯ��r�m
(Z+�7�zZ)���1���x��hW^��^��%����&jם.+-1�ځ��j:+v���h�

RE: [openssl.org #2324] convert c_rehash from perl to POSIX shell

[Salz, Rich]

> i don't think that's really true.  else, why is autoconf & friends relying on 
> a
> shell and not perl ?  those see way more distribution than openssl.

Last I looked, autoconf doesn't use anything that really wasn't in Version 7 
Bourne shell.  In my comment, I deliberately used the term "posix shell"

But to my mind, the question is moot, since post-1.0.2 we'll almost definitely 
have c_rehash builtin to the openssl command.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

RE: [openssl.org #2324] convert c_rehash from perl to POSIX shell

[Salz, Rich via RT]

> i don't think that's really true.  else, why is autoconf & friends relying on 
> a
> shell and not perl ?  those see way more distribution than openssl.

Last I looked, autoconf doesn't use anything that really wasn't in Version 7 
Bourne shell.  In my comment, I deliberately used the term "posix shell"

But to my mind, the question is moot, since post-1.0.2 we'll almost definitely 
have c_rehash builtin to the openssl command.


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #3478] Re: Need guidance to replace HMAC-SHA1 implementation via engine

[Rich Salz via RT]

Start here: https://www.openssl.org/news/secadv_20130205.txt
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #3439] Memory leak bug

[Florman, Bruce via RT]

Hi, and sorry about getting in on this topic so late,
Is it certain that the prior behavior of the BIO_free() function was in fact a 
bug? I ask because BIO_set() provides a mechanism for initializing a 
pre-allocated BIO structure, but now that BIO_free() unconditionally passes its 
argument to OPENSSL_free(), there is no longer a way to de-initialize a BIO 
without simultaneously de-allocating it. I had used the old conditional 
behavior of BIO_free() when implementing a private stack-allocated BIO (for 
inserting data formatted by various OpenSSL functions into a C++ iostream), and 
was dismayed to discover that our recent update to 1.0.1i caused my 8-year-old 
code to suddenly start corrupting the runtime heap.
If the new behavior of BIO_free() is now set in stone, is there any chance of 
adding a BIO_unset() function to the library, to allow the de-initialization 
and de-allocation to be decoupled when appropriate?
Bruce Florman | Senior Software Engineer
phone & fax +1.317.715.8115 | bruce.flor...@inin.com

Interactive Intelligence Inc.
Deliberately Innovative
www.inin.com


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #2210] man EVP_DigestInit(3) example little omission

[Rich Salz via RT]

OpenSSL_1_0_0-stable f2a57c1 RT2210: Add missing EVP_cleanup to example
OpenSSL_1_0_1-stable 48ecdec RT2210: Add missing EVP_cleanup to example
OpenSSL_1_0_2-stable dc5c3d7 RT2210: Add missing EVP_cleanup to example
HEAD 7b3e11c RT2210: Add missing EVP_cleanup to example

Author: Mihai Militaru 
Date: Tue Aug 26 12:35:54 2014 -0400

RT2210: Add missing EVP_cleanup to example

I also removed some trailing whitespace and cleaned
up the "see also" list.

Reviewed-by: Emilia Kasper 
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #3065] [PATCH] ec_private_key_dont_crash

[Emilia Käsper via RT]

Both suggested patches have been applied (with small modifications) to all
branches above and including 1.0.0. See commits
0388ac4c99e801462dafef3f2dab3f255ec33c96
and
f063e30fe9f316067950bdf0397b51cf87d4b6a6

Thanks!

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #3006] [PATCH] Remove duplicated code in speed.c

[Rich Salz via RT]

Fixed in rsalz-monolith branch of akamai/openssl fork on github.
To be part of post-1.0.2 release.
Thanks!
commit 15e5188312bc3bb199297be40ab58388d4141b3d
Author: Le Huang <4ta...@gmail.com>
Date: Wed Aug 27 14:53:34 2014 -0400

PR3006: Needless duplication in speed.c

Ror some reason, the "+F2:" tag handling code are copied twice.
else if (!strncmp(buf,"+F2:",4))
...
>> else if (!strncmp(buf,"+F2:",4))
>> ...

--
Rich Salz, OpenSSL dev team; rs...@openssl.org

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #3470] [BUG] DTLS abort

[Michael Tuexen]

On 18 Aug 2014, at 21:47, Michael Tuexen  
wrote:

> On 18 Aug 2014, at 16:31, Brian Hassink  wrote:
> 
>> Yes, this was observed for DTLS/SCTP.
> OK. The problem is an incorrect usage of OPENSSL_assert()... Let me see if I 
> can
> come-up with a patch...
Hi Brian,

please find attached a patch which fixes several usages of OPENSSL_assert()
and let me know if this resolves your issue.

Please note that you want also to apply the patch from
http://rt.openssl.org/Ticket/Display.html?id=3483&user=guest&pass=guest

Best regards
Michael



OPENSSL_assert.patch
Description: Binary data

> 
> Best regards
> Michael
>> 
>> -Brian
>> 
>> -Original Message-
>> From: Michael Tüxen via RT [mailto:r...@openssl.org] 
>> Sent: Thursday, August 14, 2014 6:17 PM
>> To: Brian Hassink
>> Cc: openssl-dev@openssl.org
>> Subject: Re: [openssl.org #3470] [BUG] DTLS abort
>> 
>> 
>> On 22 Jul 2014, at 23:32, Brian Hassink via RT  wrote:
>> 
>>> OpenSSL: 1.0.1e
>>> 
>>> OS: Red Hat Enterprise Linux Server release 6.5 
>>> (Santiago)
>>> 
>>> 
>>> 
>>> Hello,
>>> 
>>> 
>>> 
>>> We recently did some negative testing against OpenSSL 1.0.1e, with a focus 
>>> on DTLS, and observed that the library, running on the peer, could be made 
>>> to abort by simply disconnecting during the handshake process.
>>> 
>>> 
>>> 
>>> The abort is due to a getsockopt() or setsockopt() call failing from within 
>>> dgram_sctp_read() because the socket descriptor has been rendered invalid 
>>> by the disconnect.
>> Did you test DTLS/UDP or DTLS/SCTP? Do you really mean dgram_sctp_read()?
>> 
>> Best regards
>> Michael
>>> 
>>> 
>>> 
>>> We ran the same scenario against TLS, but it is not affected.
>>> 
>>> 
>>> 
>>> __
>>> OpenSSL Project http://www.openssl.org
>>> Development Mailing List   openssl-dev@openssl.org
>>> Automated List Manager   majord...@openssl.org
>>> 
>> 
>> __
>> OpenSSL Project http://www.openssl.org
>> Development Mailing List   openssl-dev@openssl.org
>> Automated List Manager   majord...@openssl.org
>> 
> 
> __
> OpenSSL Project http://www.openssl.org
> Development Mailing List   openssl-dev@openssl.org
> Automated List Manager   majord...@openssl.org
> 

Re: [openssl.org #3470] [BUG] DTLS abort

[Michael Tüxen via RT]

On 18 Aug 2014, at 21:47, Michael Tuexen  
wrote:

> On 18 Aug 2014, at 16:31, Brian Hassink  wrote:
> 
>> Yes, this was observed for DTLS/SCTP.
> OK. The problem is an incorrect usage of OPENSSL_assert()... Let me see if I 
> can
> come-up with a patch...
Hi Brian,

please find attached a patch which fixes several usages of OPENSSL_assert()
and let me know if this resolves your issue.

Please note that you want also to apply the patch from
http://rt.openssl.org/Ticket/Display.html?id=3483&user=guest&pass=guest

Best regards
Michael




OPENSSL_assert.patch
Description: Binary data

> 
> Best regards
> Michael
>> 
>> -Brian
>> 
>> -Original Message-
>> From: Michael Tüxen via RT [mailto:r...@openssl.org] 
>> Sent: Thursday, August 14, 2014 6:17 PM
>> To: Brian Hassink
>> Cc: openssl-dev@openssl.org
>> Subject: Re: [openssl.org #3470] [BUG] DTLS abort
>> 
>> 
>> On 22 Jul 2014, at 23:32, Brian Hassink via RT  wrote:
>> 
>>> OpenSSL: 1.0.1e
>>> 
>>> OS: Red Hat Enterprise Linux Server release 6.5 
>>> (Santiago)
>>> 
>>> 
>>> 
>>> Hello,
>>> 
>>> 
>>> 
>>> We recently did some negative testing against OpenSSL 1.0.1e, with a focus 
>>> on DTLS, and observed that the library, running on the peer, could be made 
>>> to abort by simply disconnecting during the handshake process.
>>> 
>>> 
>>> 
>>> The abort is due to a getsockopt() or setsockopt() call failing from within 
>>> dgram_sctp_read() because the socket descriptor has been rendered invalid 
>>> by the disconnect.
>> Did you test DTLS/UDP or DTLS/SCTP? Do you really mean dgram_sctp_read()?
>> 
>> Best regards
>> Michael
>>> 
>>> 
>>> 
>>> We ran the same scenario against TLS, but it is not affected.
>>> 
>>> 
>>> 
>>> __
>>> OpenSSL Project http://www.openssl.org
>>> Development Mailing List   openssl-dev@openssl.org
>>> Automated List Manager   majord...@openssl.org
>>> 
>> 
>> __
>> OpenSSL Project http://www.openssl.org
>> Development Mailing List   openssl-dev@openssl.org
>> Automated List Manager   majord...@openssl.org
>> 
> 
> __
> OpenSSL Project http://www.openssl.org
> Development Mailing List   openssl-dev@openssl.org
> Automated List Manager   majord...@openssl.org
> 

[openssl.org #1964] [PATCH 02/14] Only use gcc if CC has not been provided.

[Rich Salz via RT]

This was fixed a different way ( by adding CROSS_COMPILE variable).
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #3489] [PATCH] DTLS/sctp stored shutdown memory leak

[Michael Tuexen]

On 08 Aug 2014, at 15:54, Martin Brejcha via RT  wrote:

> Hello,
> 
> When I run our application in valgrind it shows memory leak in
> dgram_sctp_write:1262.
> Our application using openssl-1.0.1 for DTLS over sctp.
> The issue seems to be in sending of shutdown alarm. When shutdown alert
> is not sent because the socket is not dry, it is stored in bio object,
> but when the bio object is freed before this stored alarm can be sent,
> the shutdown alarm is not freed.
> 
> Possible patch is attached.
The patch looks good to me.

Best regards
Michael
> 
> Best regards,
> Martin Brejcha
> 
> 
> This e-mail and any attachment is for authorised use by the intended 
> recipient(s) only. It may contain proprietary material, confidential 
> information and/or be subject to legal privilege. It should not be copied, 
> disclosed to, retained or used by, any other party. If you are not an 
> intended recipient then please promptly delete this e-mail and any attachment 
> and all copies and inform the sender. Thank you for understanding.
> 
> diff -u -u -r openssl-1.0.1i_old/crypto/bio/bss_dgram.c 
> openssl-1.0.1i_new/crypto/bio/bss_dgram.c
> --- openssl-1.0.1i_old/crypto/bio/bss_dgram.c 2014-08-06 23:10:56.0 
> +0200
> +++ openssl-1.0.1i_new/crypto/bio/bss_dgram.c 2014-08-08 13:26:00.307001406 
> +0200
> @@ -982,7 +982,13 @@
>   return 0;
> 
>   data = (bio_dgram_sctp_data *)a->ptr;
> - if(data != NULL) OPENSSL_free(data);
> + if(data != NULL)
> + {
> + if(data->saved_message.data != NULL)
> + OPENSSL_free(data->saved_message.data);
> +
> + OPENSSL_free(data);
> + }
> 
>   return(1);
>   }

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #3489] [PATCH] DTLS/sctp stored shutdown memory leak

[Michael Tüxen via RT]

On 08 Aug 2014, at 15:54, Martin Brejcha via RT  wrote:

> Hello,
> 
> When I run our application in valgrind it shows memory leak in
> dgram_sctp_write:1262.
> Our application using openssl-1.0.1 for DTLS over sctp.
> The issue seems to be in sending of shutdown alarm. When shutdown alert
> is not sent because the socket is not dry, it is stored in bio object,
> but when the bio object is freed before this stored alarm can be sent,
> the shutdown alarm is not freed.
> 
> Possible patch is attached.
The patch looks good to me.

Best regards
Michael
> 
> Best regards,
> Martin Brejcha
> 
> 
> This e-mail and any attachment is for authorised use by the intended 
> recipient(s) only. It may contain proprietary material, confidential 
> information and/or be subject to legal privilege. It should not be copied, 
> disclosed to, retained or used by, any other party. If you are not an 
> intended recipient then please promptly delete this e-mail and any attachment 
> and all copies and inform the sender. Thank you for understanding.
> 
> diff -u -u -r openssl-1.0.1i_old/crypto/bio/bss_dgram.c 
> openssl-1.0.1i_new/crypto/bio/bss_dgram.c
> --- openssl-1.0.1i_old/crypto/bio/bss_dgram.c 2014-08-06 23:10:56.0 
> +0200
> +++ openssl-1.0.1i_new/crypto/bio/bss_dgram.c 2014-08-08 13:26:00.307001406 
> +0200
> @@ -982,7 +982,13 @@
>   return 0;
> 
>   data = (bio_dgram_sctp_data *)a->ptr;
> - if(data != NULL) OPENSSL_free(data);
> + if(data != NULL)
> + {
> + if(data->saved_message.data != NULL)
> + OPENSSL_free(data->saved_message.data);
> +
> + OPENSSL_free(data);
> + }
> 
>   return(1);
>   }


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

RE: [openssl.org #3470] [BUG] DTLS abort

[Brian Hassink via RT]

Thanks, we're rolling a new build with it now...

-Brian

-Original Message-
From: Michael Tüxen via RT [mailto:r...@openssl.org] 
Sent: Wednesday, August 27, 2014 3:33 PM
To: Brian Hassink
Cc: openssl-dev@openssl.org
Subject: Re: [openssl.org #3470] [BUG] DTLS abort

On 18 Aug 2014, at 21:47, Michael Tuexen  
wrote:

> On 18 Aug 2014, at 16:31, Brian Hassink  wrote:
> 
>> Yes, this was observed for DTLS/SCTP.
> OK. The problem is an incorrect usage of OPENSSL_assert()... Let me 
> see if I can come-up with a patch...
Hi Brian,

please find attached a patch which fixes several usages of OPENSSL_assert() and 
let me know if this resolves your issue.

Please note that you want also to apply the patch from 
http://rt.openssl.org/Ticket/Display.html?id=3483&user=guest&pass=guest

Best regards
Michael



__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #1746] bug report: minor output bug in x509 rsa public keys? (with possible patch)

[Rich Salz via RT]

The leading zero is there to avoid mistaking the first bit as a sign bit.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #2236] Snow Leopard (non macports) fails to link with default options

[Rich Salz via RT]

old release, old platform, don't believe this is still an issue.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #2283] ECDSA and checking signature validity

[Rich Salz via RT]

Oh how I have longed to be able to say this:
this isn't a bug, it's a feature.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #2305] openSSL initialization segmentation fault

[Rich Salz via RT]

Fixed in openssl, and suggested change to user's code.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #2308] safestack.h not declared extern "C"

[Rich Salz via RT]

OpenSSL_1_0_1-stable 23ea9f6 RT2308: Add extern "C" { ... } wrapper
OpenSSL_1_0_2-stable 089f10e RT2308: Add extern "C" { ... } wrapper
commit 17e80c6bd05de7406a65116f34ed59665607d8d5
Author: Rich Salz 
Date: Wed Aug 27 15:28:08 2014 -0400

RT2308: Add extern "C" { ... } wrapper

Add the wrapper to all public header files (Configure
generates one). Don't bother for those that are just
lists of #define's that do renaming.

Reviewed-by: Tim Hudson 


--
Rich Salz, OpenSSL dev team; rs...@openssl.org

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #2324] convert c_rehash from perl to POSIX shell

[Mike Frysinger]

On Wed 27 Aug 2014 15:24:45 Salz, Rich via RT wrote:
> > i don't think that's really true.  else, why is autoconf & friends relying
> > on a shell and not perl ?  those see way more distribution than openssl.
>
> Last I looked, autoconf doesn't use anything that really wasn't in Version 7
> Bourne shell.  In my comment, I deliberately used the term "posix shell"

the proposed script uses few features and doesn't really push the limits of 
POSIX:
 - variables
 - if statements
 - for/while loops
 - functions
 - `local`
 - `export`
 - `return`
 - math with $((...))
 - printf
 - $IFS
 - `[` test
 - `read`
 - $#/$*/$1 positionals

i don't have a Version 7 shell, but wikipedia indicates those are all 
available

> But to my mind, the question is moot, since post-1.0.2 we'll almost
> definitely have c_rehash builtin to the openssl command.

that would also work
-mike

signature.asc
Description: This is a digitally signed message part.

Re: [openssl.org #2324] convert c_rehash from perl to POSIX shell

[Mike Frysinger via RT]

On Wed 27 Aug 2014 15:24:45 Salz, Rich via RT wrote:
> > i don't think that's really true.  else, why is autoconf & friends relying
> > on a shell and not perl ?  those see way more distribution than openssl.
>
> Last I looked, autoconf doesn't use anything that really wasn't in Version 7
> Bourne shell.  In my comment, I deliberately used the term "posix shell"

the proposed script uses few features and doesn't really push the limits of 
POSIX:
 - variables
 - if statements
 - for/while loops
 - functions
 - `local`
 - `export`
 - `return`
 - math with $((...))
 - printf
 - $IFS
 - `[` test
 - `read`
 - $#/$*/$1 positionals

i don't have a Version 7 shell, but wikipedia indicates those are all 
available

> But to my mind, the question is moot, since post-1.0.2 we'll almost
> definitely have c_rehash builtin to the openssl command.

that would also work
-mike


signature.asc
Description: PGP signature

RE: [openssl.org #2324] convert c_rehash from perl to POSIX shell

[Salz, Rich]

These all first appeared in ksh: functions, local, return, $((math))

> > But to my mind, the question is moot, since post-1.0.2 we'll almost
> > definitely have c_rehash builtin to the openssl command.
> 
> that would also work

:)

It will also be much much much faster, since it doesn't have to call 'openssl 
x509' all the time.

/r$

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

RE: [openssl.org #2324] convert c_rehash from perl to POSIX shell

[Salz, Rich via RT]

These all first appeared in ksh: functions, local, return, $((math))

> > But to my mind, the question is moot, since post-1.0.2 we'll almost
> > definitely have c_rehash builtin to the openssl command.
> 
> that would also work

:)

It will also be much much much faster, since it doesn't have to call 'openssl 
x509' all the time.

/r$


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #2286] ElGamel over ECC

[Rich Salz via RT]

We currently have no plans to do this.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #2405] AIX 5.3 ./config hangs forever

[Rich Salz via RT]

hopefully it's not still hung, four years later.

seems some wierd system/shell/ksh interaction.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #2400] [Bug Report and Patch] Missing initialization in ASN1_STRING_to_UTF8

[Rich Salz via RT]

OpenSSL_1_0_1-stable abc2dfb RT2400: ASN1_STRING_to_UTF8 missing initializer
OpenSSL_1_0_2-stable b85d461 RT2400: ASN1_STRING_to_UTF8 missing initializer
HEAD f9fb43e RT2400: ASN1_STRING_to_UTF8 missing initializer

Author: Raphael Spreitzer 
Date: Wed Aug 27 22:53:10 2014 -0400

RT2400: ASN1_STRING_to_UTF8 missing initializer

Reviewed-by: Tim Hudson 
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #1067] OpenSSL symmetric crypto padding check incompatible with XMLENC

[Rich Salz via RT]

openssl is working as designed.
to do xmlenc-style padding, use EVP interface.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org