Re: [openssl.org #3331] [PATCH] respect LDFLAGS during build
On Mon 28 Apr 2014 09:32:40 Salz, Rich wrote: While rpaths are not needed in some contexts, they are important in others, please do not remove rpath support. Yes, such as cross-compiling or embedded systems. I think it's reasonable to make it a config option tho. eh ? rpaths are not needed when cross-compiling or for embedded. they're needed only when people are installing into non-standard paths and can't be bothered to update their ld.so.conf mechanisms to include those paths. -mike signature.asc Description: This is a digitally signed message part.
Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)
On Thu 01 May 2014 13:26:48 Stephen Henson via RT wrote: On Thu May 01 12:29:58 2014, meiss...@suse.de wrote: SUSE has received a bugreport from a user, that the padding extension change breaks IronPort SMTP appliances. There might a RT on this already, not sure. https://bugzilla.novell.com/show_bug.cgi?id=875639 http://postfix.1071664.n5.nabble.com/OpenSSL-1-0-1g-and-Ironport-SMTP- appliances-interop-issue-td66873.html Quoting from our openSUSE bugreport: Last upgrade to openssl-1.0.1g-11.36.1.x86_64 broke SSL connections to some services, e.g. Cisco Ironport SMTP appliances. 1.0.1g not only fixes the Heartbleed bug but also adds another change by adding: #define TLSEXT_TYPE_padding 21 This in turn breaks SSL connections to e.g. Ironports, probably others: SSL23_GET_SERVER_HELLO:tlsv1 alert decode error Workaround: Force protocol to SSLv3 or recompile without the define above. Ironically it was added as a workaround for another bug. The padding extension was believed to have no side effects... obviously that isn't true :-( If you use a smaller cipherstring it should also work without having to force SSLv3. The padding extension is only used if the ClientHello would be between 256 and 511 bytes in length so if you reduce the number of ciphersuites it wont be used. maybe a quick system would be useful. the default behavior is to do the right thing, but through a series of env vars, quirks can be injected at the right place ? then there is no wishy/washy behavior where we try to appease every broken system out there simultaneously. -mike signature.asc Description: This is a digitally signed message part.
Re: [openssl.org #3331] [PATCH] respect LDFLAGS during build
On Mon, Jun 16, 2014 at 02:10:14AM -0400, Mike Frysinger wrote: On Mon 28 Apr 2014 09:32:40 Salz, Rich wrote: While rpaths are not needed in some contexts, they are important in others, please do not remove rpath support. Yes, such as cross-compiling or embedded systems. I think it's reasonable to make it a config option tho. eh ? rpaths are not needed when cross-compiling or for embedded. they're needed only when people are installing into non-standard paths and can't be bothered to update their ld.so.conf mechanisms to include those paths. can't be bothered is a rather loaded term. Sometimes it is a bad idea to force every application on a system to look for libraries in a location needed by just one. We should acknowledge that rpaths are sometimes useful. -- Viktor. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3331] [PATCH] respect LDFLAGS during build
On Mon 16 Jun 2014 06:39:40 Viktor Dukhovni wrote: On Mon, Jun 16, 2014 at 02:10:14AM -0400, Mike Frysinger wrote: On Mon 28 Apr 2014 09:32:40 Salz, Rich wrote: While rpaths are not needed in some contexts, they are important in others, please do not remove rpath support. Yes, such as cross-compiling or embedded systems. I think it's reasonable to make it a config option tho. eh ? rpaths are not needed when cross-compiling or for embedded. they're needed only when people are installing into non-standard paths and can't be bothered to update their ld.so.conf mechanisms to include those paths. can't be bothered is a rather loaded term. Sometimes it is a bad idea to force every application on a system to look for libraries in a location needed by just one. We should acknowledge that rpaths are sometimes useful. s/sometimes/rarely/ even then, it's trivial to keep this behavior -- set LDFLAGS yourself to your non-standard paths. i don't think using rpath is a sane default. -mike signature.asc Description: This is a digitally signed message part.
Re: Cygwin: march=i486
On Jun 5 22:09, Matt Caswell wrote: On 05/06/14 21:51, Jeremy Farrell wrote: Current OpenSSL sources only support 32-bit Cygwin. Corinna Vinschen contributed patches to support 64-bit Cygwin some time ago: http://rt.openssl.org/Ticket/Display.html?id=3110 These patches have already been applied to the 1.0.2 branch by Andy. Right. And the Cygwin distro's current openssl-1.0.1 package comes with the aforementioned patch applied as a local patch for the time being. HTH, Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat pgp8Yu8ihHOLw.pgp Description: PGP signature
Re: [openssl.org #3403] Null dereference and memory leak reports for openssl-1.0.1h from Facebook's Infer static analyzer
Hey Rich Salz, you have correctly inferred that the REPORT part is automated. The REMARKS are my human non-automated commentary resulting from looking at the code or at other INFER reports for similar issues; just a little context. regards, Peter __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3373] [BUG] [WIN] DLL copyright message not synchronize for quite a while
To be honest I'm not too sure what the policy here is, but I think we generally don't update copyright messages unless some significant change is made. There are a lot of files in the OpenSSL source code with these dates inI'd rather not go through each one individually fixing them! Matt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: [openssl.org #3373] [BUG] [WIN] DLL copyright message not synchronize for quite a while
For what it's worth, the policy at IBM (where I used to work, and where they know quite a few things about software intellectual property), is that you only update the copyright on an individual file *when you modify it.* /r$ -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rs...@jabber.me; Twitter: RichSalz
