Re: [openssl-dev] [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

On Tue, Nov 17, 2015 at 11:12 AM, Jeffrey Walton wrote: > > MD2 - (The argument that someone somewhere may want to keep verifying old > > MD2 signatures on self-signed certs doesn't seem like a compelling enough > > reason to me. It's been disabled by default since OpenSSL

Re: [openssl-dev] [openssl.org #4144] patch: Use '__sun' instead of 'sun' for strict ISO conforming, compiler/options

Le 17/11/15 19:09, Kurt Roeckx via RT a écrit : > On Tue, Nov 17, 2015 at 05:43:45PM +, Richard PALO via RT wrote: >> I'd like to propose the attached patch to 1.0.2d which avoids problems >> with strict ISO conforming compiler/options, which do not define 'sun' only >> '__sun' as usual...

[openssl-dev] [openssl.org #4144] patch: Use '__sun' instead of 'sun' for strict ISO conforming, compiler/options

I'd like to propose the attached patch to 1.0.2d which avoids problems with strict ISO conforming compiler/options, which do not define 'sun' only '__sun' as usual... such as gcc/clang -std=c99 This affects the build itself, but also any user of openssl/opensslconf.h -- Richard PALO >From

[openssl-dev] [openssl.org #4143] bug: fips_premain_dso.exe does not include applink.c on dll fips builds

When rebuilding with VS 2015 tools, the build fails when fips_premain_dso is executed because it does not include applink.c. The attached patch to mk1mf.pl fixes the makefile generation. Because static builds still build fips_premain_dso.exe but do not need applink.c, shared builds are

Re: [openssl-dev] [openssl.org #4124] Illegal instruction when using aes-ni-sha256 stitched implementation on AMD CPU

On Sun, Nov 08, 2015 at 11:37:55AM +, Tomas Mraz via RT wrote: > The aes-ni-sha256 stitched implementation causes SIGILL on AMD A4-6210. > It is caused by not using the AVX+SSSE3 code path for non-Intel CPUs > although the CPU seems to be fully capable of running it. The issue is now fixed in

Re: [openssl-dev] [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

On Tue, Nov 17, 2015 at 7:21 AM, Emilia Käsper wrote: > > > On Tue, Nov 17, 2015 at 11:12 AM, Jeffrey Walton wrote: >> >> > MD2 - (The argument that someone somewhere may want to keep verifying >> > old >> > MD2 signatures on self-signed certs doesn't seem

[openssl-dev] [openssl.org #4142] Fail to detect Xcode 7 for Intel AVX code

Hi, I just found the perl script for x86_64 assembly failed to detect Xcode 7 environment (Apple LLVM 7.x), and skipped generating AVX code for MAC OS ($avx variable is always false). The reason is Apple since Xcode 7.0 removed string "based on LLVM x.y.z" from version information. Now the

Re: [openssl-dev] [openssl.org #4144] patch: Use '__sun' instead of 'sun' for strict ISO conforming, compiler/options

On Tue, Nov 17, 2015 at 05:43:45PM +, Richard PALO via RT wrote: > I'd like to propose the attached patch to 1.0.2d which avoids problems > with strict ISO conforming compiler/options, which do not define 'sun' only > '__sun' as usual... such as gcc/clang -std=c99 I fail to understand how

Re: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

* Viktor Dukhovni: > If I were to guess, it would be that the base crypto implementations > of IDEA, SEED and binary elliptic curves need to stay. We could > perhaps get away with removing CAST and RIPEMD. Just one data point: CAST5 is still the default for GnuPG when using symmetric

Re: [openssl-dev] [openssl.org #4144] patch: Use '__sun' instead of 'sun' for strict ISO conforming, compiler/options

On Tue, Nov 17, 2015 at 06:33:22PM +, Richard PALO via RT wrote: > > Strict ISO conforming compilers don't define 'sun', only __sun. Ah, I clearly misunderstood your earlier message. Kurt ___ openssl-dev mailing list To unsubscribe:

Re: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

On Tue, Nov 17, 2015 at 07:10:00PM +0100, Florian Weimer wrote: > * Viktor Dukhovni: > > > If I were to guess, it would be that the base crypto implementations > > of IDEA, SEED and binary elliptic curves need to stay. We could > > perhaps get away with removing CAST and RIPEMD. > > Just one

Re: [openssl-dev] [openssl.org #4142] Fail to detect Xcode 7 for Intel AVX code

On Tue, Nov 17, 2015 at 12:43 PM, Jun Sun via RT wrote: > Hi, > > I just found the perl script for x86_64 assembly failed to detect Xcode 7 > environment (Apple LLVM 7.x), and skipped generating AVX code for MAC OS > ($avx variable is always false). The reason is Apple since

Re: [openssl-dev] [openssl.org #4142] Fail to detect Xcode 7 for Intel AVX code

On Tue, Nov 17, 2015 at 12:43 PM, Jun Sun via RT wrote: > Hi, > > I just found the perl script for x86_64 assembly failed to detect Xcode 7 > environment (Apple LLVM 7.x), and skipped generating AVX code for MAC OS > ($avx variable is always false). The reason is Apple since

[openssl-dev] [openssl.org #4145] Enhancement: patch to support s_client -starttls http

RFC 2817 defines upgrading HTTP/1.1 to TLS (or SSL). Because Apache httpd supports Connection: Upgrade and Upgrade: TLS/1.x I've gone ahead and instrumented s_client to support this behavior (and noted a small optimization in the same logic stream for starttls support). Attached is the patch to

[openssl-dev] [openssl.org #4146] Bug: expired CRL makes X509_verify_cert crash if X509_STORE_CTX is initialized without an X509_STORE

Scenario: RedHat Linux 2.6.32-131.0.15.el6.x86_64 OpenSSL 1.0.1L openssl.cnf: crlnumber = crlnumber default_crl_days = 30 generate CRL: echo 01 > crlnumber openssl ca -config openssl.cnf -batch -revoke peerRevoked.pem openssl ca -config openssl.cnf -batch -gencrl -out cacrl.crl Let 30 days

[openssl-dev] [openssl.org #4143] bug: fips_premain_dso.exe does not include applink.c on dll fips builds

On Tue Nov 17 17:43:44 2015, ge...@redhoundsoftware.com wrote: > When rebuilding with VS 2015 tools, the build fails when fips_premain_dso > is executed because it does not include applink.c. The attached patch to > mk1mf.pl fixes the makefile generation. > > Because static builds still build

Re: [openssl-dev] Fwd: Re: [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

On 17/11/15 00:01, Viktor Dukhovni wrote: > On Mon, Nov 16, 2015 at 11:23:52PM +, Matt Caswell wrote: > >> Disabling algorithms isn't the right answer IMO. I do like the idea of a >> "liblegacycrypto". That way people that only have need of current >> up-to-date crypto can stick with the

Re: [openssl-dev] [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

> MD2 - (The argument that someone somewhere may want to keep verifying old > MD2 signatures on self-signed certs doesn't seem like a compelling enough > reason to me. It's been disabled by default since OpenSSL 1.0.0.) > ... Apple still provides two Verisign certificates using

Re: [openssl-dev] Fwd: Re: [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

On Mon, Nov 16, 2015 at 9:06 PM, Peter Waltenberg wrote: > Why not offer another set of get_XYZ_byname() which resticts the caller to > socially acceptable algorithms. Or allows the opposite, it really doesn't > matter but restricted being the newer API breaks less code by

Re: [openssl-dev] [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

On 11/17/2015 12:00 PM, Jeffrey Walton wrote: > > > Also, if OpenSSL requires iOS 9 or above, then its setting policy for users. In some sense, yes. But it has always done so -- OpenSSL only supports certain platforms, and certain versions of certain platforms. There are prerequisites to being

Re: [openssl-dev] Fwd: Re: [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

> This is an interesting idea. For completeness, it has failed in other contexts Well yes but it's a different context. Policy level rather than capability, That's why I'm not in favour of removing algorithms, even changing policy higher up the stack can cause problems, but removing basic

Re: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

* Kurt Roeckx: > On Tue, Nov 17, 2015 at 07:10:00PM +0100, Florian Weimer wrote: >> * Viktor Dukhovni: >> >> > If I were to guess, it would be that the base crypto implementations >> > of IDEA, SEED and binary elliptic curves need to stay. We could >> > perhaps get away with removing CAST and