Re: [openssl-dev] MacOS defaults?

On 7 March 2016 at 09:59, Andy Polyakov wrote: > Hmm. So why do I see this on my macbook? > > $ arch > i386 Try "uname -m" >>> >>> This is not reliable. Because it must have changed recently, it used to >>> be i386 even on 64-bit systems. sysctl -n

Re: [openssl-dev] MacOS defaults?

Hmm. So why do I see this on my macbook? $ arch i386 >>> >>> Try "uname -m" >> >> This is not reliable. Because it must have changed recently, it used to >> be i386 even on 64-bit systems. sysctl -n hw.optional.x86_64 is the way >> to go, it's right there in ./config... > >

[openssl-dev] 答复: 答复: 答复: [openssl.org #4360] [BUG] OpenSSL-1.0.1 crash on sha1_block_data_order_ssse3 asm

Hi Jeff, I'm not sure this information is enough, if you want more information about this problem, please tell me ASAP. Thank you. B/R -邮件原件- 发件人: Hejian (E) 发送时间: 2016年3月7日 11:24 收件人: 'noloa...@gmail.com' 抄送: openssl-dev@openssl.org; Liubo (Liubo, OSS); 'r...@openssl.org' 主题: 答复:

[openssl-dev] [openssl.org #4397] BUG: 1.0.2g fails to build on Mac OS X 10.6.8 due to 0b assembly literals

Some older versions of OS X (10.6.8 "Snow Leopard" and possibly below) ship with a toolchain that is based on an old version of the GNU assembler, which does not support binary literals. Assembling an expression that contains a 0b00011011 literal will cause a warning and treat the immediate as 0.

Re: [openssl-dev] Errors when loading an OpenSSL RSA Engine

If I remember correctly, the RSAX engine was dropped from OpenSSL in 1.0.2 because equivalent code had been added to the core OpenSSL library. It built correctly in 1.0.1. Regards, jjf On 07/03/2016 22:47, Blumenthal, Uri - 0553 - MITLL wrote: A naïve question.

Re: [openssl-dev] MacOS defaults?

Try  $ machine Apparently "arch" is not only old (the latest release was in July 2010), but it does not differentiate between Intel-32 and Intel-64.  On my own Mac (proven to be 64-bit :) arch returns "i386", machine returns "x86_64h". Oh, and do hook up BB-10 to LTE - an absolute must for

Re: [openssl-dev] MacOS defaults?

> On Mar 7, 2016, at 5:01 AM, Ben Laurie wrote: > > On 7 March 2016 at 09:59, Andy Polyakov wrote: >> Hmm. So why do I see this on my macbook? >> >> $ arch >> i386 > > Try "uname -m" This is not reliable. Because it must

[openssl-dev] Errors when loading an OpenSSL RSA Engine

I want to build an OpenSSL RSA engine, starting from this existing source code file which is a faster method implemented by Intel. First of all I want to build this code so I'm using these commands: gcc -fPIC -m64 -o eng_rsax.o

[openssl-dev] [openssl.org #4381] [PATCH] Missing Sanity Check for OBJ_nid2obj() in OpenSSL-1.0.2g

In reviewing code in directory 'crypto/asn1', file 'asn_moid.c', in function 'do_create()', there is a call to 'OBJ_nid2obj()' which is not checked for a return value of NULL. The patch file below adds the check and returns 0 if NULL is returned: --- asn_moid.c.orig 2016-03-06

[openssl-dev] [openssl.org #4384] [PATCH] Missing Sanity Check plus potential NULL pointer deref (CWE-476)

Hello All, In reviewing code in directory 'engines', file 'e_aep.c', there is a call to function 'bn_expand()', but it is not checked for a return value of NULL. However, a member of the variable 'bn' (bn->d) are used in memset()/memcpy() calls, but if 'bn' is NULL, a segmentation

Re: [openssl-dev] Errors when loading an OpenSSL RSA Engine

In message <1457369381041-64385.p...@n7.nabble.com> on Mon, 7 Mar 2016 09:49:41 -0700 (MST), danigrosu said: dni.grosu> I want to build an OpenSSL RSA engine, starting from this existing dni.grosu> source code file dni.grosu> which is a faster method implemented by Intel.

Re: [openssl-dev] [openssl.org #4373] OS X 10.5, 32-bit PPC, and missing symbols (_ASYNC_get_current_job, _EVP_MD_meth_set_init, _RSA_PKCS1_OpenSSL, _EVP_MD_meth_new...)

> Working from master: > > $ git reset --hard HEAD && git pull > HEAD is now at e9b1c42 make errors > > Then: > > $ KERNEL_BITS=32 ./config > ... > > $ make depend && make clean && make > ... > > > $ make > ... > > LD_LIBRARY_PATH=..: cc -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_THREADS >

Re: [openssl-dev] MacOS defaults?

> Try > $ machine > > Apparently "arch" is not only old (the latest release was in July 2010), but > it does not differentiate between Intel-32 and Intel-64. > > On my own Mac (proven to be 64-bit :) arch returns "i386", machine returns > "x86_64h". And I get i486 (sic!) on proven to be

Re: [openssl-dev] [openssl.org #4367] FEATURE: Please add -headerpad_max_install_names to LDFLAGS for dynamic libraries on OS X builds

> OS X side steps the problems with selecting the wrong runtime library > and RPATHs by using something called an install name. Effectively, the > install name should be placed in libcrypto.dylib and libssl.dylib, and > it calls out the fully qualified path name. Programs linked to a > library

Re: [openssl-dev] [openssl.org #4378] Multiple warnings under OpenBSD 5.7/64-bit

On 03/04/2016 08:21 PM, noloa...@gmail.com via RT wrote: > OpenBSD uses GCC 4.2.1 > This report would be more useful if it gave some indication of what version of the openssl source it corresponded to. -Ben -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4378 Please log in as

Re: [openssl-dev] 1.0.2g MacOSX x86_64 build failure (1.0.2f and 1.0.1s are fine)

> The only plausible change from 1.0.2f to 1.0.2g that I see that might > be related to this is below. Does it work if you revert this change > (patch -R): commit 10c639a8a56c90bec9e332c7ca76ef552b3952ac [snip] Confirmed. Reverting that commit fixes the build. >>> >>> Does

[openssl-dev] [openssl.org #4382] [PATCH] Missing Sanity Check(s) for BUF_strdup() in OpenSSL-1.0.2g

Hello All, In reviewing source code in directory 'crypto/conf', file 'conf_mod.c', there is a call to BUF_strdup() in function 'module_add()' which is not checked for a return value of NULL, indicating failure. The patch file below adds the check and calls OPENSSL_free(tmod) to release the

[openssl-dev] [openssl.org #4385] [PATCH] Missing Sanity Checks for RSA_new_method() in OpenSSL-1.0.2g

Hello All, In reviewing source code in directory 'engines', file 'e_4758cca.c', there are two calls to function 'RSA_new_method()' which are not checked for a return value of NULL, indicating failure. The patch file below should address/correct this issue: --- e_4758cca.c.orig2016-03-06

[openssl-dev] [openssl.org #4386] [PATCH] Add sanity checks for BN_new() in OpenSSL-1.0.2g

Hello All, In reviewing code in directory 'engines/ccgost', file 'gost2001.c', there are two calls to BN_new() which are not checked for a return value of NULL, indicating failure. The patch file below should address/correct this issue: --- gost2001.c.orig 2016-03-06 11:32:49.676178425

Re: [openssl-dev] Errors when loading an OpenSSL RSA Engine

On 07/03/2016 17:56, Richard Levitte wrote: In message <1457369381041-64385.p...@n7.nabble.com> on Mon, 7 Mar 2016 09:49:41 -0700 (MST), danigrosu said: dni.grosu> I want to build an OpenSSL RSA engine, starting from this existing dni.grosu> source code file dni.grosu>

[openssl-dev] [openssl.org #4383] [PATCH] Add error checking for bn2_expand()/BN_new()/RSA_new_method() in file 'e_chil.c' for OpenSSL-1.0.2g

Hello All, In reviewing source code in directory 'crypto/engines', file 'e_chil.c' there are some comments warning to check for error when bn_expand2() or BN_new() or RSA_new_method() is called. The patch file below adds the requested checks to the code: --- e_chil.c.orig 2016-03-06

Re: [openssl-dev] [openssl.org #4378] Multiple warnings under OpenBSD 5.7/64-bit

On Mon, Mar 7, 2016 at 12:11 PM, Kaduk, Ben via RT wrote: > On 03/04/2016 08:21 PM, noloa...@gmail.com via RT wrote: >> OpenBSD uses GCC 4.2.1 >> > > This report would be more useful if it gave some indication of what > version of the openssl source it corresponded to. Oh,

Re: [openssl-dev] MacOS defaults?

On 3/7/16, 11:05 , "openssl-dev on behalf of Andy Polyakov" wrote: >> Try >> $ machine >> >> Apparently "arch" is not only old (the latest release was in July >>2010), but it does not differentiate between Intel-32 and Intel-64.

Re: [openssl-dev] [openssl.org #4378] Multiple warnings under OpenBSD 5.7/64-bit

On Mon, Mar 7, 2016 at 12:11 PM, Kaduk, Ben via RT wrote: > On 03/04/2016 08:21 PM, noloa...@gmail.com via RT wrote: >> OpenBSD uses GCC 4.2.1 >> > > This report would be more useful if it gave some indication of what > version of the openssl source it corresponded to. Oh,

[openssl-dev] [openssl.org #4265] [BUG/PATCH] OpenSSL does not compile when SRTP is disabled

This fix is in master in commit d631602. -- Rich Salz, OpenSSL dev team; rs...@openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4265 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe:

Re: [openssl-dev] MacOS defaults?

>>> Try >>> $ machine >>> >>> Apparently "arch" is not only old (the latest release was in July >>> 2010), but it does not differentiate between Intel-32 and Intel-64. >>> >>> On my own Mac (proven to be 64-bit :) arch returns "i386", machine >>> returns "x86_64h". >> >> And I get i486 (sic!) on

Re: [openssl-dev] MacOS defaults?

On Sun, Mar 6, 2016 at 6:05 PM, Andy Polyakov wrote: >>> Hmm. So why do I see this on my macbook? >>> >>> $ arch >>> i386 >> >> Try "uname -m" > > This is not reliable. Because it must have changed recently, it used to > be i386 even on 64-bit systems. sysctl -n

Re: [openssl-dev] MacOS defaults?

>>>And I get i486 (sic!) on proven to be 64-bit Mac. >> >> Yes another proof that we cannot rely on “arch” on the newer Mac OS X >> boxes. > >I meant that I get i486 from 'machine’! I.e. what I tried to say all >along is that one can't trust 'arch' *nor* 'machine' or 'uname -m' to >identify

[openssl-dev] [openssl.org #4388] [PATCH] Don't be sensitive to the order of ALPN and NPN.

If the server consumer configures NPN and not ALPN, OpenSSL should still resolve NPN against clients which advertises it. (NB: Chrome will be removing NPN soon, so hopefully there won't be any such consumers.) Losing the alpn_select_cb check makes OpenSSL depend on whether ALPN or NPN comes first

[openssl-dev] [openssl.org #4392] [PATCH] Resolve DTLS cookie and version before session resumption.

Session resumption involves a version check, so version negotiation must happen first. Currently, the DTLS implementation cannot do session resumption in DTLS 1.0 because the ssl_version check always checks against 1.2. Switching the order also removes the need to fixup ssl_version in DTLS

[openssl-dev] [openssl.org #4394] OpenSSL 1.1.0 state machine can't read handshake headers async

No patch for this one since I'm not that familiar with your state machine. If the peer sends handshake messages fragmented across records such that the handshake message header is split over two records AND the two records are received in different steps asynchronously, OpenSSL fails to reassemble

[openssl-dev] [openssl.org #4391] [PATCH] Tighten up logic around ChangeCipherSpec.

ChangeCipherSpec messages have a defined value. They also may not occur in the middle of a handshake message. The current logic will accept a ChangeCipherSpec with value 2. It also would accept up to three bytes of handshake data before the ChangeCipherSpec which it would discard (because

[openssl-dev] [openssl.org #4393] [PATCH] Call EC_GROUP_order_bits in priv2opt.

The private key is a scalar and should be sized by the order, not the degree. (Unlike my other recent emails, this has nothing to do with BoringSSL tests. :-) ) David -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4393 Please log in as guest with password guest if prompted

Re: [openssl-dev] [openssl.org #4386] [PATCH] Add sanity checks for BN_new() in OpenSSL-1.0.2g

If one of the allocation calls succeeds and the other fails, the patched code will leak memory. It needs something along the lines of: if (order != NULL) BN_clear_free(order); if (d != NULL) BN_clear_free(d); in the failure case code. Pauli -- Oracle Dr Paul Dale | Cryptographer | Network

Re: [openssl-dev] [openssl.org #4386] [PATCH] Add sanity checks for BN_new() in OpenSSL-1.0.2g

If one of the allocation calls succeeds and the other fails, the patched code will leak memory. It needs something along the lines of: if (order != NULL) BN_clear_free(order); if (d != NULL) BN_clear_free(d); in the failure case code. Pauli -- Oracle Dr Paul Dale | Cryptographer | Network

[openssl-dev] [openssl.org #4387] [PATCH] Fix V2ClientHello handling

The V2ClientHello code creates an empty compression list, but the compression list must explicitly contain the null compression (and later code enforces this). As a result, all V2ClientHellos currently get rejected on master. The SendV2ClientHello-Sync test in BoringSSL's test suite can be used

[openssl-dev] [openssl.org #4390] [PATCH] Don't send signature algorithms when client_version is below TLS 1.2.

Per RFC 5246, Note: this extension is not meaningful for TLS versions prior to 1.2. Clients MUST NOT offer it if they are offering prior versions. However, even if clients do offer it, the rules specified in [TLSEXT] require servers to ignore extensions they do not understand.

[openssl-dev] [openssl.org #4395] OpenSSL doesn't reject out-of-context empty records

ssl3_get_record silently discards empty records without much context, which means OpenSSL will happily accept, e.g., empty app data records mid-handshake or empty records of bogus type. They get silently discarded and never returned to the caller, so this is harmless, just a little odd. This is

Re: [openssl-dev] Errors when loading an OpenSSL RSA Engine

A naïve question. OpenSSL RSA engine (RSAX) by Intel wants to call function mod_exp_512() that is defined somewhere else. I checked, and that function is not defined anywhere in the sources of either OpenSSL-1.0.2h-dev, or OpenSSL-1.1.0-pre. $ clang -shared -o eng_rsax.so eng_rsax.o

Re: [openssl-dev] [openssl.org #4386] [PATCH] Add sanity checks for BN_new() in OpenSSL-1.0.2g

Dr. Dale, I actually saw that, but forgot to correct it before sending (my bad)...:( Bill On Mon, Mar 7, 2016 at 1:44 PM, paul.d...@oracle.com via RT wrote: > If one of the allocation calls succeeds and the other fails, the patched > code will leak memory. > It needs

Re: [openssl-dev] MacOS defaults?

On Mon, Mar 7, 2016 at 3:57 PM, Jeffrey Walton wrote: > On Sun, Mar 6, 2016 at 6:05 PM, Andy Polyakov wrote: Hmm. So why do I see this on my macbook? $ arch i386 >>> >>> Try "uname -m" >> >> This is not reliable. Because it must have

[openssl-dev] [openssl.org #4389] [PATCH] The NewSessionTicket message is not optional.

Per RFC 4507, section 3.3: This message [NewSessionTicket] MUST be sent if the server included a SessionTicket extension in the ServerHello. This message MUST NOT be sent if the server did not include a SessionTicket extension in the ServerHello. The presence of the NewSessionTicket

Re: [openssl-dev] [openssl.org #4366] OS X 10.5, 64-bit PPC, no-asm, and "Failed test 'running asynctest'"

On 03/02/16 03:54, noloa...@gmail.com via RT wrote: > $ make depend && make clean && make > ... > > $ make test > ... > > ../test/recipes/80-test_tsa.t . ok > ../test/recipes/90-test_async.t ... 1/1 > # Failed test 'running asynctest' > # at

Re: [openssl-dev] MacOS defaults?

On 6 March 2016 at 23:05, Andy Polyakov wrote: >>> Hmm. So why do I see this on my macbook? >>> >>> $ arch >>> i386 >> >> Try "uname -m" > > This is not reliable. Because it must have changed recently, it used to > be i386 even on 64-bit systems. sysctl -n hw.optional.x86_64 is

Re: [openssl-dev] MacOS defaults?

On 6 March 2016 at 22:40, Viktor Dukhovni wrote: > >> On Mar 6, 2016, at 12:00 PM, Ben Laurie wrote: >> >> Hmm. So why do I see this on my macbook? >> >> $ arch >> i386 > > Try "uname -m" x86_64 But AIUI, uname -m tells me what hardware I've got,

Re: [openssl-dev] [openssl.org #4377] Prevent potential NULL pointer dereference in OpenSSL-1.0.2g (CWE-476)

On 04.03.2016 20:33, Bill Parker via RT wrote: > In reviewing code in directory 'crypto/evp', in file 'openbsd_hw.c', > there is a call to OPENSSL_realloc() which is NOT checked for a return > value of NULL, indicating failure. However, the statement after this > is memcpy(), which if the

[openssl-dev] [openssl.org #4396] OS X 10-5, 64-bit PowerPC, error: 'split_send_fragment' undeclared (first use in this function)

This just showed up on OS X 10-5, 64-bit PowerPC. Its not present under Linux. $ git reset --hard HEAD HEAD is now at e1d9f1a Remove kinv/r fields from DSA structure. $ git pull Already up-to-date. $ ./config && make depend && make clean && make ... c -I.. -I../include -DDSO_DLFCN

Re: [openssl-dev] [openssl.org #4396]: OS X 10-5, 64-bit PowerPC, error: 'split_send_fragment' undeclared (first use in this function)

On 07/03/16 23:43, noloa...@gmail.com via RT wrote: > On Mon, Mar 7, 2016 at 6:29 PM, Matt Caswell via RT wrote: >> Fix already on the way. >> > > Thanks. I'm not sure what's triggering it on OS X because those > defines don't seem to show up in the configuration gear:

Re: [openssl-dev] [openssl.org #4396]: OS X 10-5, 64-bit PowerPC, error: 'split_send_fragment' undeclared (first use in this function)

On 07/03/16 23:43, noloa...@gmail.com via RT wrote: > On Mon, Mar 7, 2016 at 6:29 PM, Matt Caswell via RT wrote: >> Fix already on the way. >> > > Thanks. I'm not sure what's triggering it on OS X because those > defines don't seem to show up in the configuration gear:

[openssl-dev] [openssl.org #4396]: OS X 10-5, 64-bit PowerPC, error: 'split_send_fragment' undeclared (first use in this function)

On Mon, Mar 7, 2016 at 6:02 PM, Jeffrey Walton wrote: > This just showed up on OS X 10-5, 64-bit PowerPC. Its not present under Linux. > > $ git reset --hard HEAD > HEAD is now at e1d9f1a Remove kinv/r fields from DSA structure. > $ git pull > Already up-to-date. This can be

Re: [openssl-dev] [openssl.org #4396]: OS X 10-5, 64-bit PowerPC, error: 'split_send_fragment' undeclared (first use in this function)

Fix already on the way. Matt On 07/03/16 23:28, noloa...@gmail.com via RT wrote: > On Mon, Mar 7, 2016 at 6:02 PM, Jeffrey Walton wrote: >> This just showed up on OS X 10-5, 64-bit PowerPC. Its not present under >> Linux. >> >> $ git reset --hard HEAD >> HEAD is now at

Re: [openssl-dev] [openssl.org #4396]: OS X 10-5, 64-bit PowerPC, error: 'split_send_fragment' undeclared (first use in this function)

Fix already on the way. Matt On 07/03/16 23:28, noloa...@gmail.com via RT wrote: > On Mon, Mar 7, 2016 at 6:02 PM, Jeffrey Walton wrote: >> This just showed up on OS X 10-5, 64-bit PowerPC. Its not present under >> Linux. >> >> $ git reset --hard HEAD >> HEAD is now at

Re: [openssl-dev] [openssl.org #4396]: OS X 10-5, 64-bit PowerPC, error: 'split_send_fragment' undeclared (first use in this function)

On Mon, Mar 7, 2016 at 6:29 PM, Matt Caswell via RT wrote: > Fix already on the way. > Thanks. I'm not sure what's triggering it on OS X because those defines don't seem to show up in the configuration gear: $ egrep -R 'EVP_CIPH_FLAG_TLS1_1_MULTIBLOCK|OPENSSL_NO_MULTIBLOCK' *

Re: [openssl-dev] [openssl.org #4396]: OS X 10-5, 64-bit PowerPC, error: 'split_send_fragment' undeclared (first use in this function)

On Mon, Mar 7, 2016 at 6:29 PM, Matt Caswell via RT wrote: > Fix already on the way. > Thanks. I'm not sure what's triggering it on OS X because those defines don't seem to show up in the configuration gear: $ egrep -R 'EVP_CIPH_FLAG_TLS1_1_MULTIBLOCK|OPENSSL_NO_MULTIBLOCK' *