Re: [openssl-dev] [openssl.org #3607] nistz256 is broken.

On Wed, Dec 10, 2014 at 10:05 AM, Andy Polyakov via RT wrote: > Patching went wrong for you. As you seem to operate in 1.0.2 context > attached is corresponding ecp_nistz256.pl. Thanks. So far that version is good to ~1B random tests. I'll leave it going until Monday. Cheers AGL

Re: [openssl-dev] Openssl Shared library mode compilation

On Thu, Dec 11, 2014, Kannan Narayanasamy -X (kannanar - HCL TECHNOLOGIES LIMITED at Cisco) wrote: > > Hi Team, > > For Vulnerability issue, we are indeed to upgrade the openssl version to > 0.9.8zc version. We have downloaded the source from > www.openssl.org site. Wh

[openssl-dev] [openssl.org #3497] Move dclean actions to clean

Fixed in master. commit 5ab65c50ef8287b128d6642209525283e1ea07be Author: Rich Salz Date: Thu Dec 11 17:01:16 2014 -0500 RT3497: Clean up "dclean" targets Some Makefiles had actions for "dclean" that really belonged to the "clean" target. This is wrong because clean ends up, well, not really cle

Re: [openssl-dev] [openssl.org #3629] Bug report: "run" in speed.c should be declared as volatile

Yes, global variables used in signal handlers should be volatile. Kurt ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #3630] BUG - Building OpenSSL on Windows with zlib and fips object module fails. Possible fix included.

Info: Windows 8.1 64-bit Visual Studio Premium 2012 Zlib 1.2.8 OpenSSL fips object module 2.0.8 OpenSSL 1.0.1j Note: zlib and fips object module build fine (FYI: zlib dll built from zlib distro directory contrib\vstudio\vc11 that makes zlibwapi.dll instead of making ZLIB1.DLL). The following bu

[openssl-dev] [openssl.org #3629] Bug report: "run" in speed.c should be declared as volatile

Hello. I am one of the llvm developer, I run into a situation that I think it is bug in souce code: "run" in speed.c should be declared as volatile because "run"'s value can be predicted. The problem is the following code: signal(SIGALRM,sig_done); . for (j=0; jhttps:/

Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more "Protocol" options for SSL_CONF_CTX

"Stephen Henson via RT" wrote: |On Mon Dec 08 20:20:44 2014, sdao...@yandex.com wrote: |> and finally i propose three new values for the "Protocol" slot of |> SSL_CONF_CTX_cmd(): OLDEST, NEWEST and VULNERABLE. | |Just to add my 2p to this thread which seems to have veered into rather |differ

[openssl-dev] Openssl Shared library mode compilation

Hi Team, For Vulnerability issue, we are indeed to upgrade the openssl version to 0.9.8zc version. We have downloaded the source from www.openssl.org site. While compiling we have followed the below steps including environment variables setting ready for compilation. B

Re: [openssl-dev] [openssl.org #3625] Enhancement request: user convenience for SSL_CONF_CTX with SSLv2

"Dr. Stephen Henson" wrote: |On Thu, Dec 11, 2014, Steffen Nurpmeso via RT wrote: |> are hard (not only to parse) for users but there is a lot of |> information for good in very few bytes; sad is |> |> Received SIGPIPE during IMAP operation |> IMAP write error: error::lib(0):fun

Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more "Protocol" options for SSL_CONF_CTX

"Salz, Rich via RT" wrote: |> So you want a separate "openssl-conf" package. Fine, then provide it and |> give an easy mechanism for applications to hook into it. |> And for users to be able to overwrite system defaults. |> But this has not that much to do with #3627. | |Yes it does. :) A

Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more "Protocol" options for SSL_CONF_CTX

"Stephen Henson via RT" wrote: |On Mon Dec 08 20:20:44 2014, sdao...@yandex.com wrote: |> and finally i propose three new values for the "Protocol" slot of |> SSL_CONF_CTX_cmd(): OLDEST, NEWEST and VULNERABLE. | |Just to add my 2p to this thread which seems to have veered into rather |differ

Re: [openssl-dev] [openssl.org #3625] Enhancement request: user convenience for SSL_CONF_CTX with SSLv2

"Dr. Stephen Henson" wrote: |On Thu, Dec 11, 2014, Steffen Nurpmeso via RT wrote: |> are hard (not only to parse) for users but there is a lot of |> information for good in very few bytes; sad is |> |> Received SIGPIPE during IMAP operation |> IMAP write error: error::lib(0):fun

Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more "Protocol" options for SSL_CONF_CTX

"Salz, Rich via RT" wrote: |> So you want a separate "openssl-conf" package. Fine, then provide it and |> give an easy mechanism for applications to hook into it. |> And for users to be able to overwrite system defaults. |> But this has not that much to do with #3627. | |Yes it does. :) A

[openssl-dev] [openssl.org #3627] Enhancement request: add more "Protocol" options for SSL_CONF_CTX

On Mon Dec 08 20:20:44 2014, sdao...@yandex.com wrote: > Hello, > > and finally i propose three new values for the "Protocol" slot of > SSL_CONF_CTX_cmd(): OLDEST, NEWEST and VULNERABLE. > Just to add my 2p to this thread which seems to have veered into rather different territory... I don't think

Re: [openssl-dev] [openssl.org #3625] Enhancement request: user convenience for SSL_CONF_CTX with SSLv2

On Thu, Dec 11, 2014, Steffen Nurpmeso via RT wrote: > > are hard (not only to parse) for users but there is a lot of > information for good in very few bytes; sad is > > Received SIGPIPE during IMAP operation > IMAP write error: error::lib(0):func(0):reason(0) > OpenSSL itself sho

Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more "Protocol" options for SSL_CONF_CTX

> So you want a separate "openssl-conf" package. Fine, then provide it and > give an easy mechanism for applications to hook into it. > And for users to be able to overwrite system defaults. > But this has not that much to do with #3627. Yes it does. :) A newer simpler API that does what you wa

Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more "Protocol" options for SSL_CONF_CTX

Hi. Richard Moore wrote: |> Programs which use the OpenSSL library generally just want to flip a |> switch and know that they've "turned on security", instead of trying to |My experience suggests that while that might be what some developers want, |that's not what users want. They expect tha

Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more "Protocol" options for SSL_CONF_CTX

"Salz, Rich via RT" wrote: |> I'd love to see a version of bettercrypto.org that only \ |> has to say "to configure |> OpenSSL version 1.0.3 and higher, you should use the string BEST_PRACTICE" | |That can happen but not by embedding magic strings into code. See But isn't TLSv1.2 also a mag

Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more "Protocol" options for SSL_CONF_CTX

"Salz, Rich via RT" wrote: |> Y causes a ciphersuite (or TLS version) to be dropped into VULNERABLE, |I am more concerned about the case where a common crypto type \ |is broken, and zillions (a technical term :) of websites are \ |now at-risk because there wasn't an immediate OpenSSL update

Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more "Protocol" options for SSL_CONF_CTX

Yoav Nir wrote: |> On Dec 9, 2014, at 1:24 PM, Steffen Nurpmeso via RT \ |> wrote: |> "Salz, Rich" wrote: |>|I think magic names -- shorthands -- are a very bad idea. \ |> |> I _completely_ disagree. |> |>| They are point-in-time statements whose meaning evolves, \ |>|if not erodes, o

Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more "Protocol" options for SSL_CONF_CTX

"Salz, Rich via RT" wrote: |> Personally i am willing to put enough trust in the OpenSSL team *even |> insofar* as i now do 'set ssl-protocol="ALL,-VULNERABLE"' |> and leave the task of deciding what is VULNERABLE up to you. | |That is not a responsibility we want. No how, no way. It \ |is

Re: [openssl-dev] [openssl.org #3622] bug: crypto, valgrind reports improper memory access with AES128 cbc and longer plaintext

On St, 2014-12-10 at 18:35 +0100, Andy Polyakov via RT wrote: > > Excellent. My summary is: > > - valgrind complaints about 1.0.1 OpenSLL are extremely unlikely to affect > > my program in operation (you will probably say "will not affect") > > Well, as there is suggestion of what I would say, I

Re: [openssl-dev] [openssl.org #3622] bug: crypto, valgrind reports improper memory access with AES128 cbc and longer plaintext

On St, 2014-12-10 at 18:35 +0100, Andy Polyakov via RT wrote: > > Excellent. My summary is: > > - valgrind complaints about 1.0.1 OpenSLL are extremely unlikely to affect > > my program in operation (you will probably say "will not affect") > > Well, as there is suggestion of what I would say, I

Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more "Protocol" options for SSL_CONF_CTX

Hi. Richard Moore wrote: |> Programs which use the OpenSSL library generally just want to flip a |> switch and know that they've "turned on security", instead of trying to |My experience suggests that while that might be what some developers want, |that's not what users want. They expect tha

Re: [openssl-dev] [openssl.org #3625] Enhancement request: user convenience for SSL_CONF_CTX with SSLv2

Hello, "Stephen Henson via RT" wrote: |On Mon Dec 08 19:58:31 2014, sdao...@yandex.com wrote: |> If people start using SSL_CONF_CTX as they are supposed to with |> v1.0.2, then it can be expected that users start using strings |> like, e.g. (from my thing), |> |> set ssl-protocol="ALL,-SSL

Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more "Protocol" options for SSL_CONF_CTX

"Salz, Rich via RT" wrote: |> I'd love to see a version of bettercrypto.org that only \ |> has to say "to configure |> OpenSSL version 1.0.3 and higher, you should use the string BEST_PRACTICE" | |That can happen but not by embedding magic strings into code. See But isn't TLSv1.2 also a mag

Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more "Protocol" options for SSL_CONF_CTX

"Salz, Rich via RT" wrote: |> Y causes a ciphersuite (or TLS version) to be dropped into VULNERABLE, |I am more concerned about the case where a common crypto type \ |is broken, and zillions (a technical term :) of websites are \ |now at-risk because there wasn't an immediate OpenSSL update

Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more "Protocol" options for SSL_CONF_CTX

Yoav Nir wrote: |> On Dec 9, 2014, at 1:24 PM, Steffen Nurpmeso via RT \ |> wrote: |> "Salz, Rich" wrote: |>|I think magic names -- shorthands -- are a very bad idea. \ |> |> I _completely_ disagree. |> |>| They are point-in-time statements whose meaning evolves, \ |>|if not erodes, o

Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more "Protocol" options for SSL_CONF_CTX

"Salz, Rich via RT" wrote: |> Personally i am willing to put enough trust in the OpenSSL team *even |> insofar* as i now do 'set ssl-protocol="ALL,-VULNERABLE"' |> and leave the task of deciding what is VULNERABLE up to you. | |That is not a responsibility we want. No how, no way. It \ |is

Re: [openssl-dev] [openssl.org #3625] Enhancement request: user convenience for SSL_CONF_CTX with SSLv2

Hello, "Stephen Henson via RT" wrote: |On Mon Dec 08 19:58:31 2014, sdao...@yandex.com wrote: |> If people start using SSL_CONF_CTX as they are supposed to with |> v1.0.2, then it can be expected that users start using strings |> like, e.g. (from my thing), |> |> set ssl-protocol="ALL,-SSL