From mch.thu at gmail.com Thu Nov 2 13:01:18 2017 From: mch.thu at gmail.com (Ma chunhui) Date: Thu, 2 Nov 2017 21:01:18 +0800 Subject: [openssl-dev] a possible bug for certain usage of openSSL1.1.0 with TLSv1 Message-ID: Hi, Openssl team After we upgrade openSSL from 1.0.2 to 1.1.0f, we met an error which might be a bug. 1. our usage We're using java application, and using JNI call to call OpenSSL API.(In fact, we're using an opensource project named wildfly-openssl) After context and ssl is created, for one record, the decryption step is like this: call BIO_write to put encrypted data into OpenSSL call SSL_read(ssl, buf=0x0, len=0) to read 0 byte to an empty address(Note, this is a 0-length byte read) use SSL_pending to check if there is any decrypted data in the result buffer if there is data, use SSL_read to read pending data into dest buffer. 2. The usage works fine for openSSL 1.0.1 and 1.0.2 with all protocols. But not work for OpenSSL 1.1.0 with TLSv1. The reason is: TLSv1 needs two records for application data, and decrypting the first record will get a 0 length result buffer, and decrypting the second record will get the final decrypted data in the result buffer. In OpenSSL 1.0.1 & 1.0.2, the first 0 length result buffer doesn't matter but but in OpenSSL 1.1.0 the first 0 length result buffer will stop the next decryptions. The process in OpenSSL1.1.0 is like this: For the first record: after BIO_write , SSL_read(ssl, buf=0x0, length=0) is called, the first record is decrypted, tls1_enc is executed and get a 0 length result buffer, and then in ssl3_get_record, numrpipes is set to 1. Then after the execution return to ssl3_read_bytes, it found the user want to read 0 length, so it directly returns. leaving the state of the result buffer to un-read(don't have a chance to set the buffer to have been read). Then for the second record, before ssl3_get_record, it first check numrpipes, and it found the numrpipes is not 0, and last buffer is not read, so it won't process the second record. and This cause fails. and in OpenSSL 1.0.2, the condition of ssl3_get_record is if (rr->length == 0 || xxx), so ssl3_get_record can process the second record. Of course, I can change our usage to let it work for OpenSSL 1.1.0, for example, we can call SSL_read even we found SSL_pending is 0. But that means we may need another JNI call, which may affect our performance (we don't want to remove the 0 length SSL_read) A possible fix might like this: +++b/ssl/record/rec_layer_s3.c @@ -1132,6 +1132,12@@int ssl3_read_bytes(SSL *s, int type, int *recvd_type, unsigned char *buf) if (recvd_type != NULL) *recvd_type = SSL3_RECORD_get_type(rr); + if (type == SSL3_RT_APPLICATION_DATA) { + /* mark any zero length record as consumed */ + if (SSL3_RECORD_get_length(rr) == 0) SSL3_RECORD_set_read(rr); if (len <= 0) return (len); Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl at openssl.org Thu Nov 2 15:16:56 2017 From: openssl at openssl.org (OpenSSL) Date: Thu, 2 Nov 2017 15:16:56 +0000 Subject: [openssl-dev] OpenSSL version 1.0.2m published Message-ID: <20171102151656.GA14031@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 OpenSSL version 1.0.2m released =============================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.0.2m of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: https://www.openssl.org/news/openssl-1.0.2-notes.html OpenSSL 1.0.2m is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.0.2m.tar.gz Size: 5373776 SHA1 checksum: 27fb00641260f97eaa587eb2b80fab3647f6013b SHA256 checksum: 8c6ff15ec6b319b50788f42c7abc2890c08ba5a1cdcd3810eb9092deada37b0f The checksums were calculated using the following commands: openssl sha1 openssl-1.0.2m.tar.gz openssl sha256 openssl-1.0.2m.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZ+yzNAAoJENnE0m0OYESRd2UIAK0+Ht1wVP/VaL97rv7l4aBp l5JRH/0OnvIwvGh5CEGywY5MDXWZisMAzDB8AeNtDfGcN3eMDJkUITglT6EiDavF P4g3ZoK+JPJRER4i3S8z33z6x8yUBMZ26o0xVvI/JndsPGxa5oTLOGVYAi9YNwGu /IYuuYfZctzY/kVzlVn1AsoorD7trwsvAzh2bBCyWELJx3s7D40riQ8NpElmHXTg InSQRZmb83i70RYEqYTwSKKpCUjaUSZeUo3OWgzxoQfTh4IshlyB1Pdrwab7x69l gsLx914YkO+i388lqGTIMpCsdFVnu9Feap8Q2L+HsyIsnN8M8ZSvqudV6di9EO4= =al6h -----END PGP SIGNATURE----- From openssl at openssl.org Thu Nov 2 15:17:15 2017 From: openssl at openssl.org (OpenSSL) Date: Thu, 2 Nov 2017 15:17:15 +0000 Subject: [openssl-dev] OpenSSL version 1.1.0g published Message-ID: <20171102151715.GA14329@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 OpenSSL version 1.1.0g released =============================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.1.0g of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: https://www.openssl.org/news/openssl-1.1.0-notes.html OpenSSL 1.1.0g is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.1.0g.tar.gz Size: 5404748 SHA1 checksum: e8240a8be304d4317a750753321b073c664bfdd4 SHA256 checksum: de4d501267da39310905cb6dc8c6121f7a2cad45a7707f76df828fe1b85073af The checksums were calculated using the following commands: openssl sha1 openssl-1.1.0g.tar.gz openssl sha256 openssl-1.1.0g.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZ+yu1AAoJENnE0m0OYESRqkkH/3LhY0dicqyjbrE/COsUmHsi TWjd35afOl5N1LRouz7lhLE1lQsKXP67h5FCXsuCvmqwk4sJu6ItfeHOBQqkL41Q 9GS1jXasJwB4EQ0cYIPQwjC+DN1H+TWj9AYeCrvnfBTczTOujW7neEUVH2yuknk0 Gd+KOdhCIvVRxEucDQPmoza+yESpZNY01VPtGutjMAp2WDq+rYm9MUqUyAYzbRhj 5EgHx1ZRrmOU3//qsMC6sNea3uUyQL+AHdKHAsAP1QgeVEJoEgxi283FNG9cYvRh ZaaV9qZzg26dubXfOjUkIW7DxMyQ64WwIwJWDL/GtQwBLKIr5hvWqEYRnllvbZE= =I8uX -----END PGP SIGNATURE----- From openssl at openssl.org Thu Nov 2 15:20:52 2017 From: openssl at openssl.org (OpenSSL) Date: Thu, 2 Nov 2017 15:20:52 +0000 Subject: [openssl-dev] OpenSSL Security Advisory Message-ID: <20171102152052.GA17825@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 OpenSSL Security Advisory [02 Nov 2017] ======================================== bn_sqrx8x_internal carry bug on x86_64 (CVE-2017-3736) ====================================================== Severity: Moderate There is a carry propagating bug in the x86_64 Montgomery squaring procedure. No EC algorithms are affected. Analysis suggests that attacks against RSA and DSA as a result of this defect would be very difficult to perform and are not believed likely. Attacks against DH are considered just feasible (although very difficult) because most of the work necessary to deduce information about a private key may be performed offline. The amount of resources required for such an attack would be very significant and likely only accessible to a limited number of attackers. An attacker would additionally need online access to an unpatched system using the target private key in a scenario with persistent DH parameters and a private key that is shared between multiple clients. This only affects processors that support the BMI1, BMI2 and ADX extensions like Intel Broadwell (5th generation) and later or AMD Ryzen. Note: This issue is very similar to CVE-2017-3732 and CVE-2015-3193 but must be treated as a separate problem. OpenSSL 1.1.0 users should upgrade to 1.1.0g OpenSSL 1.0.2 users should upgrade to 1.0.2m This issue was reported to OpenSSL on 10th August 2017 by the OSS-Fuzz project. The fix was developed by Andy Polyakov of the OpenSSL development team. Malformed X.509 IPAddressFamily could cause OOB read (CVE-2017-3735) ==================================================================== Severity: Low This issue was previously announced in security advisory https://www.openssl.org/news/secadv/20170828.txt, but the fix has not previously been included in a release due to its low severity. OpenSSL 1.1.0 users should upgrade to 1.1.0g OpenSSL 1.0.2 users should upgrade to 1.0.2m Note ==== Support for version 1.0.1 ended on 31st December 2016. Support for versions 0.9.8 and 1.0.0 ended on 31st December 2015. Those versions are no longer receiving security updates. References ========== URL for this Security Advisory: https://www.openssl.org/news/secadv/20171102.txt Note: the online version of the advisory may be updated with additional details over time. For details of OpenSSL severity classifications please see: https://www.openssl.org/policies/secpolicy.html -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZ+y3yAAoJENnE0m0OYESRWooH/2cS+HkzBCCdnJ/CWuhKomTe hshdBbYw/eYeZgrUYZX6CYosvhLX1Hkwef3vVMxHDXsnBnnZfGfwCS2EfXJ96xXK KiXVchBwlpmovrOuAvrGtPqLkiVOZZpGMfopP30WCKc6tkdqjw/NvruMbg7Iz+Sy ki5AM7Vw7kAEa18KAGjSN4jSrCHMIKkOeGkmay5hHlYLwQRQDAAo5EmWmVOJpUXF ddvQ6h+NKqlWAMF+2/U3PhUFa4V7xqlKR3GMdRawVSaoKQUsPXvRGAhLnvqfOonx y0yl7y9a7EJrcRl8HWf7qqZf0B/m3YapCHNNcBYWry+qk7LJgGjIHDF8VFkEABg= =k+bJ -----END PGP SIGNATURE----- From kimsovan79 at gmail.com Sat Nov 4 13:30:17 2017 From: kimsovan79 at gmail.com (Kim Sovan) Date: Sat, 4 Nov 2017 20:30:17 +0700 Subject: [openssl-dev] Mailman privacy alert In-Reply-To: References: Message-ID: Sent from my iPhone > On Nov 4, 29 Heisei, at 20:20, openssl-dev-bounces at openssl.org wrote: > > An attempt was made to subscribe your address to the mailing list > openssl-dev at openssl.org. You are already subscribed to this mailing list. > > Note that the list membership is not public, so it is possible that a bad > person was trying to probe the list for its membership. This would be a > privacy violation if we let them do this, but we didn't. > > If you submitted the subscription request and forgot that you were already > subscribed to the list, then you can ignore this message. If you suspect that > an attempt is being made to covertly discover whether you are a member of this > list, and you are worried about your privacy, then feel free to send a message > to the list administrator at openssl-dev-owner at openssl.org. From matt at openssl.org Mon Nov 6 17:09:28 2017 From: matt at openssl.org (Matt Caswell) Date: Mon, 6 Nov 2017 17:09:28 +0000 Subject: [openssl-dev] a possible bug for certain usage of openSSL1.1.0 with TLSv1 In-Reply-To: References: Message-ID: <0c53fc40-39c2-1248-d615-493a84143d34@openssl.org> On 02/11/17 13:01, Ma chunhui wrote: > Hi, Openssl team > After we upgrade openSSL from 1.0.2 to 1.1.0f, we met an error which > might be a bug. Does this fix it: https://github.com/openssl/openssl/pull/4685 (master) https://github.com/openssl/openssl/pull/4686 (1.1.0) Matt From beldmit at gmail.com Fri Nov 17 08:08:34 2017 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Fri, 17 Nov 2017 11:08:34 +0300 Subject: [openssl-dev] Problems building openssl on Solaris Message-ID: Hello, We experience problems building OpenSSL on Solaris. /usr/local/src/openssl-1.1.0g>uname -a SunOS pooh.tcinet.ru 5.10 Generic_147147-26 sun4u sparc SUNW,SPARC-Enterprise /usr/local/src/openssl-1.1.0g>gcc -v Reading specs from /usr/local/lib/gcc/sparc-sun-solaris2.10/3.4.6/specs Configured with: ../configure --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --enable-shared --enable-languages=c,c++,f77 Thread model: posix gcc version 3.4.6 OpenSSL 1.1.0g is configured via ./Configure solaris64-sparcv9-gcc Here is the end of output: ... LD_LIBRARY_PATH=.:/usr/local/ssl/lib:/usr/sfw/lib/sparcv9:/usr/local/lib gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DOPENSSLDIR="/usr/local/ssl" -DENGINESDIR="/usr/local/lib/engines-1.1" -m64 -mcpu=ultrasparc -Wall -DB_ENDIAN -DBN_DIV2W -O3 -pthread -DFILIO_H -o apps/openssl apps/app_rand.o apps/apps.o apps/asn1pars.o apps/ca.o apps/ciphers.o apps/cms.o apps/crl.o apps/crl2p7.o apps/dgst.o apps/dhparam.o apps/dsa.o apps/dsaparam.o apps/ec.o apps/ecparam.o apps/enc.o apps/engine.o apps/errstr.o apps/gendsa.o apps/genpkey.o apps/genrsa.o apps/nseq.o apps/ocsp.o apps/openssl.o apps/opt.o apps/passwd.o apps/pkcs12.o apps/pkcs7.o apps/pkcs8.o apps/pkey.o apps/pkeyparam.o apps/pkeyutl.o apps/prime.o apps/rand.o apps/rehash.o apps/req.o apps/rsa.o apps/rsautl.o apps/s_cb.o apps/s_client.o apps/s_server.o apps/s_socket.o apps/s_time.o apps/sess_id.o apps/smime.o apps/speed.o apps/spkac.o apps/srp.o apps/ts.o apps/verify.o apps/version.o apps/x509.o -L. -lssl -L. -lcrypto -lsocket -lnsl -ldl gcc: unrecognized option `-pthread' ld: warning: relocation warning: R_SPARC_COPY: file ./libcrypto.so: symbol PBEPARAM_it: relocation bound to a symbol with STV_PROTECTED visibility ld: warning: relocation warning: R_SPARC_COPY: file ./libcrypto.so: symbol PBE2PARAM_it: relocation bound to a symbol with STV_PROTECTED visibility ld: warning: relocation warning: R_SPARC_COPY: file ./libcrypto.so: symbol PBKDF2PARAM_it: relocation bound to a symbol with STV_PROTECTED visibility Undefined first referenced symbol in file _sparcv9_rdtick ./libcrypto.so bn_add_words ./libcrypto.so _sparcv9_vis1_instrument ./libcrypto.so bn_sub_words ./libcrypto.so bn_sqr_words ./libcrypto.so OPENSSL_cleanse apps/apps.o _sparcv9_rdcfr ./libcrypto.so _sparcv9_vis1_instrument_bus2 ./libcrypto.so _sparcv9_vis3_probe ./libcrypto.so bn_mul_words ./libcrypto.so _sparcv9_vis2_probe ./libcrypto.so _sparcv9_vis1_probe ./libcrypto.so ChaCha20_ctr32 ./libcrypto.so _sparcv9_vis1_instrument_bus ./libcrypto.so bn_mul_comba4 ./libcrypto.so bn_mul_comba8 ./libcrypto.so bn_sqr_comba4 ./libcrypto.so bn_sqr_comba8 ./libcrypto.so _sparcv9_fmadd_probe ./libcrypto.so CRYPTO_memcmp ./libssl.so bn_mul_add_words ./libcrypto.so bn_div_words ./libcrypto.so _sparcv9_fjaesx_probe ./libcrypto.so ld: fatal: symbol referencing errors. No output written to apps/openssl collect2: ld returned 1 exit status *** Error code 1 What can we do to fix it? Thank you! -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Fri Nov 17 10:23:45 2017 From: levitte at openssl.org (Richard Levitte) Date: Fri, 17 Nov 2017 11:23:45 +0100 (CET) Subject: [openssl-dev] Problems building openssl on Solaris In-Reply-To: References: Message-ID: <20171117.112345.2018766134224925420.levitte@openssl.org> I suggest adding 'no-threads' to the OpenSSL configuration options, at least as a first step. That should at least take away gcc's complaint about '-pthread'... I cannot say if that'll fix the rest, I don't know Solaris enough. Cheers, Richard In message on Fri, 17 Nov 2017 11:08:34 +0300, Dmitry Belyavsky said: beldmit> Hello, beldmit> beldmit> We experience problems building OpenSSL on Solaris. beldmit> beldmit> /usr/local/src/openssl-1.1.0g>uname -a beldmit> beldmit> SunOS pooh.tcinet.ru 5.10 Generic_147147-26 sun4u sparc SUNW,SPARC-Enterprise beldmit> beldmit> /usr/local/src/openssl-1.1.0g>gcc -v beldmit> beldmit> Reading specs from /usr/local/lib/gcc/sparc-sun-solaris2.10/3.4.6/specs beldmit> Configured with: ../configure --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --enable-shared beldmit> --enable-languages=c,c++,f77 beldmit> Thread model: posix beldmit> gcc version 3.4.6 beldmit> beldmit> OpenSSL 1.1.0g is configured via beldmit> ./Configure solaris64-sparcv9-gcc beldmit> beldmit> Here is the end of output: beldmit> beldmit> ... beldmit> beldmit> LD_LIBRARY_PATH=.:/usr/local/ssl/lib:/usr/sfw/lib/sparcv9:/usr/local/lib gcc -DDSO_DLFCN beldmit> -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE beldmit> -DOPENSSL_PIC -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM beldmit> -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM beldmit> -DPOLY1305_ASM -DOPENSSLDIR="/usr/local/ssl" -DENGINESDIR="/usr/local/lib/engines-1.1" -m64 beldmit> -mcpu=ultrasparc -Wall -DB_ENDIAN -DBN_DIV2W -O3 -pthread -DFILIO_H -o apps/openssl beldmit> apps/app_rand.o apps/apps.o apps/asn1pars.o apps/ca.o apps/ciphers.o apps/cms.o apps/crl.o beldmit> apps/crl2p7.o apps/dgst.o apps/dhparam.o apps/dsa.o apps/dsaparam.o apps/ec.o apps/ecparam.o beldmit> apps/enc.o apps/engine.o apps/errstr.o apps/gendsa.o apps/genpkey.o apps/genrsa.o apps/nseq.o beldmit> apps/ocsp.o apps/openssl.o apps/opt.o apps/passwd.o apps/pkcs12.o apps/pkcs7.o apps/pkcs8.o beldmit> apps/pkey.o apps/pkeyparam.o apps/pkeyutl.o apps/prime.o apps/rand.o apps/rehash.o apps/req.o beldmit> apps/rsa.o apps/rsautl.o apps/s_cb.o apps/s_client.o apps/s_server.o apps/s_socket.o apps/s_time.o beldmit> apps/sess_id.o apps/smime.o apps/speed.o apps/spkac.o apps/srp.o apps/ts.o apps/verify.o beldmit> apps/version.o apps/x509.o -L. -lssl -L. -lcrypto -lsocket -lnsl -ldl beldmit> gcc: unrecognized option `-pthread' beldmit> ld: warning: relocation warning: R_SPARC_COPY: file ./libcrypto.so: symbol PBEPARAM_it: relocation beldmit> bound to a symbol with STV_PROTECTED visibility beldmit> ld: warning: relocation warning: R_SPARC_COPY: file ./libcrypto.so: symbol PBE2PARAM_it: beldmit> relocation bound to a symbol with STV_PROTECTED visibility beldmit> ld: warning: relocation warning: R_SPARC_COPY: file ./libcrypto.so: symbol PBKDF2PARAM_it: beldmit> relocation bound to a symbol with STV_PROTECTED visibility beldmit> Undefined first referenced beldmit> symbol in file beldmit> _sparcv9_rdtick ./libcrypto.so beldmit> bn_add_words ./libcrypto.so beldmit> _sparcv9_vis1_instrument ./libcrypto.so beldmit> bn_sub_words ./libcrypto.so beldmit> bn_sqr_words ./libcrypto.so beldmit> OPENSSL_cleanse apps/apps.o beldmit> _sparcv9_rdcfr ./libcrypto.so beldmit> _sparcv9_vis1_instrument_bus2 ./libcrypto.so beldmit> _sparcv9_vis3_probe ./libcrypto.so beldmit> bn_mul_words ./libcrypto.so beldmit> _sparcv9_vis2_probe ./libcrypto.so beldmit> _sparcv9_vis1_probe ./libcrypto.so beldmit> ChaCha20_ctr32 ./libcrypto.so beldmit> _sparcv9_vis1_instrument_bus ./libcrypto.so beldmit> bn_mul_comba4 ./libcrypto.so beldmit> bn_mul_comba8 ./libcrypto.so beldmit> bn_sqr_comba4 ./libcrypto.so beldmit> bn_sqr_comba8 ./libcrypto.so beldmit> _sparcv9_fmadd_probe ./libcrypto.so beldmit> CRYPTO_memcmp ./libssl.so beldmit> bn_mul_add_words ./libcrypto.so beldmit> bn_div_words ./libcrypto.so beldmit> _sparcv9_fjaesx_probe ./libcrypto.so beldmit> ld: fatal: symbol referencing errors. No output written to apps/openssl beldmit> collect2: ld returned 1 exit status beldmit> *** Error code 1 beldmit> beldmit> What can we do to fix it? beldmit> beldmit> Thank you! beldmit> beldmit> -- beldmit> SY, Dmitry Belyavsky From beldmit at gmail.com Fri Nov 17 10:46:31 2017 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Fri, 17 Nov 2017 13:46:31 +0300 Subject: [openssl-dev] Problems building openssl on Solaris In-Reply-To: <20171117.112345.2018766134224925420.levitte@openssl.org> References: <20171117.112345.2018766134224925420.levitte@openssl.org> Message-ID: Dear Richard, Adding no-threads just removes gcc complaint about -pthreads. On Fri, Nov 17, 2017 at 1:23 PM, Richard Levitte wrote: > I suggest adding 'no-threads' to the OpenSSL configuration options, at > least as a first step. That should at least take away gcc's complaint > about '-pthread'... I cannot say if that'll fix the rest, I don't > know Solaris enough. > > Cheers, > Richard > > In message gmail.com> on Fri, 17 Nov 2017 11:08:34 +0300, Dmitry Belyavsky < > beldmit at gmail.com> said: > > beldmit> Hello, > beldmit> > beldmit> We experience problems building OpenSSL on Solaris. > beldmit> > beldmit> /usr/local/src/openssl-1.1.0g>uname -a > beldmit> > beldmit> SunOS pooh.tcinet.ru 5.10 Generic_147147-26 sun4u sparc > SUNW,SPARC-Enterprise > beldmit> > beldmit> /usr/local/src/openssl-1.1.0g>gcc -v > beldmit> > beldmit> Reading specs from /usr/local/lib/gcc/sparc-sun- > solaris2.10/3.4.6/specs > beldmit> Configured with: ../configure --with-as=/usr/ccs/bin/as > --with-ld=/usr/ccs/bin/ld --enable-shared > beldmit> --enable-languages=c,c++,f77 > beldmit> Thread model: posix > beldmit> gcc version 3.4.6 > beldmit> > beldmit> OpenSSL 1.1.0g is configured via > beldmit> ./Configure solaris64-sparcv9-gcc > beldmit> > beldmit> Here is the end of output: > beldmit> > beldmit> ... > beldmit> > beldmit> LD_LIBRARY_PATH=.:/usr/local/ssl/lib:/usr/sfw/lib/sparcv9:/usr/local/lib > gcc -DDSO_DLFCN > beldmit> -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS > -DOPENSSL_NO_STATIC_ENGINE > beldmit> -DOPENSSL_PIC -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m > -DSHA1_ASM > beldmit> -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM > -DECP_NISTZ256_ASM > beldmit> -DPOLY1305_ASM -DOPENSSLDIR="/usr/local/ssl" > -DENGINESDIR="/usr/local/lib/engines-1.1" -m64 > beldmit> -mcpu=ultrasparc -Wall -DB_ENDIAN -DBN_DIV2W -O3 -pthread > -DFILIO_H -o apps/openssl > beldmit> apps/app_rand.o apps/apps.o apps/asn1pars.o apps/ca.o > apps/ciphers.o apps/cms.o apps/crl.o > beldmit> apps/crl2p7.o apps/dgst.o apps/dhparam.o apps/dsa.o > apps/dsaparam.o apps/ec.o apps/ecparam.o > beldmit> apps/enc.o apps/engine.o apps/errstr.o apps/gendsa.o > apps/genpkey.o apps/genrsa.o apps/nseq.o > beldmit> apps/ocsp.o apps/openssl.o apps/opt.o apps/passwd.o apps/pkcs12.o > apps/pkcs7.o apps/pkcs8.o > beldmit> apps/pkey.o apps/pkeyparam.o apps/pkeyutl.o apps/prime.o > apps/rand.o apps/rehash.o apps/req.o > beldmit> apps/rsa.o apps/rsautl.o apps/s_cb.o apps/s_client.o > apps/s_server.o apps/s_socket.o apps/s_time.o > beldmit> apps/sess_id.o apps/smime.o apps/speed.o apps/spkac.o apps/srp.o > apps/ts.o apps/verify.o > beldmit> apps/version.o apps/x509.o -L. -lssl -L. -lcrypto -lsocket -lnsl > -ldl > beldmit> gcc: unrecognized option `-pthread' > beldmit> ld: warning: relocation warning: R_SPARC_COPY: file > ./libcrypto.so: symbol PBEPARAM_it: relocation > beldmit> bound to a symbol with STV_PROTECTED visibility > beldmit> ld: warning: relocation warning: R_SPARC_COPY: file > ./libcrypto.so: symbol PBE2PARAM_it: > beldmit> relocation bound to a symbol with STV_PROTECTED visibility > beldmit> ld: warning: relocation warning: R_SPARC_COPY: file > ./libcrypto.so: symbol PBKDF2PARAM_it: > beldmit> relocation bound to a symbol with STV_PROTECTED visibility > beldmit> Undefined first referenced > beldmit> symbol in file > beldmit> _sparcv9_rdtick ./libcrypto.so > beldmit> bn_add_words ./libcrypto.so > beldmit> _sparcv9_vis1_instrument ./libcrypto.so > beldmit> bn_sub_words ./libcrypto.so > beldmit> bn_sqr_words ./libcrypto.so > beldmit> OPENSSL_cleanse apps/apps.o > beldmit> _sparcv9_rdcfr ./libcrypto.so > beldmit> _sparcv9_vis1_instrument_bus2 ./libcrypto.so > beldmit> _sparcv9_vis3_probe ./libcrypto.so > beldmit> bn_mul_words ./libcrypto.so > beldmit> _sparcv9_vis2_probe ./libcrypto.so > beldmit> _sparcv9_vis1_probe ./libcrypto.so > beldmit> ChaCha20_ctr32 ./libcrypto.so > beldmit> _sparcv9_vis1_instrument_bus ./libcrypto.so > beldmit> bn_mul_comba4 ./libcrypto.so > beldmit> bn_mul_comba8 ./libcrypto.so > beldmit> bn_sqr_comba4 ./libcrypto.so > beldmit> bn_sqr_comba8 ./libcrypto.so > beldmit> _sparcv9_fmadd_probe ./libcrypto.so > beldmit> CRYPTO_memcmp ./libssl.so > beldmit> bn_mul_add_words ./libcrypto.so > beldmit> bn_div_words ./libcrypto.so > beldmit> _sparcv9_fjaesx_probe ./libcrypto.so > beldmit> ld: fatal: symbol referencing errors. No output written to > apps/openssl > beldmit> collect2: ld returned 1 exit status > beldmit> *** Error code 1 > beldmit> > beldmit> What can we do to fix it? > beldmit> > beldmit> Thank you! > beldmit> > beldmit> -- > beldmit> SY, Dmitry Belyavsky > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Fri Nov 17 11:21:08 2017 From: levitte at openssl.org (Richard Levitte) Date: Fri, 17 Nov 2017 12:21:08 +0100 (CET) Subject: [openssl-dev] Problems building openssl on Solaris In-Reply-To: References: <20171117.112345.2018766134224925420.levitte@openssl.org> Message-ID: <20171117.122108.960838834807144433.levitte@openssl.org> Ah, sorry, I didn't read the output properly. Regarding the STV_PROTECTED warnings, I don't know at all... I did a bit of a search and saw that this has been discussed before, a little more than a year ago. See https://mta.openssl.org/pipermail/openssl-dev/2016-August/008192.html As for the missing symbols, that tells me something went horribly wrong when compiling assembler stuff. The quick fix is to use the 'no-asm' configuration option. However, if you want to help getting assembler to compile, I suggest doing this (no configuration change): rm crypto/sparccpuid.o make build_generated make crypto/sparccpuid.o Have a look at the output, and if you can't figure it out, please send us that output. (note: there are other assembler files that seem to fail as well, for example those for the bignum library, so this is clearly an assembler issue) Cheers, Richard In message on Fri, 17 Nov 2017 13:46:31 +0300, Dmitry Belyavsky said: beldmit> Dear Richard, beldmit> beldmit> Adding no-threads just removes gcc complaint about -pthreads. beldmit> beldmit> On Fri, Nov 17, 2017 at 1:23 PM, Richard Levitte wrote: beldmit> beldmit> I suggest adding 'no-threads' to the OpenSSL configuration options, at beldmit> least as a first step. That should at least take away gcc's complaint beldmit> about '-pthread'... I cannot say if that'll fix the rest, I don't beldmit> know Solaris enough. beldmit> beldmit> Cheers, beldmit> Richard beldmit> beldmit> In message beldmit> on Fri, 17 beldmit> Nov 2017 11:08:34 +0300, Dmitry Belyavsky said: beldmit> beldmit> beldmit> Hello, beldmit> beldmit> beldmit> beldmit> We experience problems building OpenSSL on Solaris. beldmit> beldmit> beldmit> beldmit> /usr/local/src/openssl-1.1.0g>uname -a beldmit> beldmit> beldmit> beldmit> SunOS pooh.tcinet.ru 5.10 Generic_147147-26 sun4u sparc SUNW,SPARC-Enterprise beldmit> beldmit> beldmit> beldmit> /usr/local/src/openssl-1.1.0g>gcc -v beldmit> beldmit> beldmit> beldmit> Reading specs from /usr/local/lib/gcc/sparc-sun-solaris2.10/3.4.6/specs beldmit> beldmit> Configured with: ../configure --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld beldmit> --enable-shared beldmit> beldmit> --enable-languages=c,c++,f77 beldmit> beldmit> Thread model: posix beldmit> beldmit> gcc version 3.4.6 beldmit> beldmit> beldmit> beldmit> OpenSSL 1.1.0g is configured via beldmit> beldmit> ./Configure solaris64-sparcv9-gcc beldmit> beldmit> beldmit> beldmit> Here is the end of output: beldmit> beldmit> beldmit> beldmit> ... beldmit> beldmit> beldmit> beldmit> LD_LIBRARY_PATH=.:/usr/local/ssl/lib:/usr/sfw/lib/sparcv9:/usr/local/lib gcc beldmit> -DDSO_DLFCN beldmit> beldmit> -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE beldmit> beldmit> -DOPENSSL_PIC -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m beldmit> -DSHA1_ASM beldmit> beldmit> -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM beldmit> -DECP_NISTZ256_ASM beldmit> beldmit> -DPOLY1305_ASM -DOPENSSLDIR="/usr/local/ssl" beldmit> -DENGINESDIR="/usr/local/lib/engines-1.1" -m64 beldmit> beldmit> -mcpu=ultrasparc -Wall -DB_ENDIAN -DBN_DIV2W -O3 -pthread -DFILIO_H -o beldmit> apps/openssl beldmit> beldmit> apps/app_rand.o apps/apps.o apps/asn1pars.o apps/ca.o apps/ciphers.o apps/cms.o beldmit> apps/crl.o beldmit> beldmit> apps/crl2p7.o apps/dgst.o apps/dhparam.o apps/dsa.o apps/dsaparam.o apps/ec.o beldmit> apps/ecparam.o beldmit> beldmit> apps/enc.o apps/engine.o apps/errstr.o apps/gendsa.o apps/genpkey.o apps/genrsa.o beldmit> apps/nseq.o beldmit> beldmit> apps/ocsp.o apps/openssl.o apps/opt.o apps/passwd.o apps/pkcs12.o apps/pkcs7.o beldmit> apps/pkcs8.o beldmit> beldmit> apps/pkey.o apps/pkeyparam.o apps/pkeyutl.o apps/prime.o apps/rand.o beldmit> apps/rehash.o apps/req.o beldmit> beldmit> apps/rsa.o apps/rsautl.o apps/s_cb.o apps/s_client.o apps/s_server.o apps/s_socket.o beldmit> apps/s_time.o beldmit> beldmit> apps/sess_id.o apps/smime.o apps/speed.o apps/spkac.o apps/srp.o apps/ts.o beldmit> apps/verify.o beldmit> beldmit> apps/version.o apps/x509.o -L. -lssl -L. -lcrypto -lsocket -lnsl -ldl beldmit> beldmit> gcc: unrecognized option `-pthread' beldmit> beldmit> ld: warning: relocation warning: R_SPARC_COPY: file ./libcrypto.so: symbol beldmit> PBEPARAM_it: relocation beldmit> beldmit> bound to a symbol with STV_PROTECTED visibility beldmit> beldmit> ld: warning: relocation warning: R_SPARC_COPY: file ./libcrypto.so: symbol beldmit> PBE2PARAM_it: beldmit> beldmit> relocation bound to a symbol with STV_PROTECTED visibility beldmit> beldmit> ld: warning: relocation warning: R_SPARC_COPY: file ./libcrypto.so: symbol beldmit> PBKDF2PARAM_it: beldmit> beldmit> relocation bound to a symbol with STV_PROTECTED visibility beldmit> beldmit> Undefined first referenced beldmit> beldmit> symbol in file beldmit> beldmit> _sparcv9_rdtick ./libcrypto.so beldmit> beldmit> bn_add_words ./libcrypto.so beldmit> beldmit> _sparcv9_vis1_instrument ./libcrypto.so beldmit> beldmit> bn_sub_words ./libcrypto.so beldmit> beldmit> bn_sqr_words ./libcrypto.so beldmit> beldmit> OPENSSL_cleanse apps/apps.o beldmit> beldmit> _sparcv9_rdcfr ./libcrypto.so beldmit> beldmit> _sparcv9_vis1_instrument_bus2 ./libcrypto.so beldmit> beldmit> _sparcv9_vis3_probe ./libcrypto.so beldmit> beldmit> bn_mul_words ./libcrypto.so beldmit> beldmit> _sparcv9_vis2_probe ./libcrypto.so beldmit> beldmit> _sparcv9_vis1_probe ./libcrypto.so beldmit> beldmit> ChaCha20_ctr32 ./libcrypto.so beldmit> beldmit> _sparcv9_vis1_instrument_bus ./libcrypto.so beldmit> beldmit> bn_mul_comba4 ./libcrypto.so beldmit> beldmit> bn_mul_comba8 ./libcrypto.so beldmit> beldmit> bn_sqr_comba4 ./libcrypto.so beldmit> beldmit> bn_sqr_comba8 ./libcrypto.so beldmit> beldmit> _sparcv9_fmadd_probe ./libcrypto.so beldmit> beldmit> CRYPTO_memcmp ./libssl.so beldmit> beldmit> bn_mul_add_words ./libcrypto.so beldmit> beldmit> bn_div_words ./libcrypto.so beldmit> beldmit> _sparcv9_fjaesx_probe ./libcrypto.so beldmit> beldmit> ld: fatal: symbol referencing errors. No output written to apps/openssl beldmit> beldmit> collect2: ld returned 1 exit status beldmit> beldmit> *** Error code 1 beldmit> beldmit> beldmit> beldmit> What can we do to fix it? beldmit> beldmit> beldmit> beldmit> Thank you! beldmit> beldmit> beldmit> beldmit> -- beldmit> beldmit> SY, Dmitry Belyavsky beldmit> -- beldmit> openssl-dev mailing list beldmit> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev beldmit> beldmit> -- beldmit> SY, Dmitry Belyavsky From brad at monetra.com Fri Nov 17 11:27:30 2017 From: brad at monetra.com (Brad House) Date: Fri, 17 Nov 2017 06:27:30 -0500 Subject: [openssl-dev] Problems building openssl on Solaris In-Reply-To: References: <20171117.112345.2018766134224925420.levitte@openssl.org> Message-ID: <8c9d882a-b41f-fe37-c9c4-63a826cd4517@monetra.com> I tested 1.1.0g on my solaris10 sparc machine and it worked fine, but I use opencsw packages with a more modern gcc (4.9.2). Essentially my build environment and build looks like this: # Install packages from opencsw pkgadd -d http://get.opencsw.org/now && \ /opt/csw/bin/pkgutil -U && \ /opt/csw/bin/pkgutil -y -i bash && \ /opt/csw/bin/pkgutil -y -i nano && \ /opt/csw/bin/pkgutil -y -i bzip2 && \ /opt/csw/bin/pkgutil -y -i gtar && \ /opt/csw/bin/pkgutil -y -i ggrep && \ /opt/csw/bin/pkgutil -y -i gsed && \ /opt/csw/bin/pkgutil -y -i gpatch && \ /opt/csw/bin/pkgutil -y -i wget && \ /opt/csw/bin/pkgutil -y -i perl && \ /opt/csw/bin/pkgutil -y -i top && \ /opt/csw/bin/pkgutil -y -i gmake && \ /opt/csw/bin/pkgutil -y -i gcc4g++ && \ /opt/csw/bin/pkgutil -y -i gdb && \ /opt/csw/bin/pkgutil -y -i python && \ /opt/csw/bin/pkgutil -y -i cmake && \ mkdir -p /usr/local/bin && \ ln -sf /opt/csw/bin/gtar /usr/local/bin/tar && \ ln -sf /opt/csw/bin/bash /usr/local/bin/bash && \ ln -sf /opt/csw/bin/ggrep /usr/local/bin/grep && \ ln -sf /opt/csw/bin/gsed /usr/local/bin/sed && \ ln -sf /opt/csw/bin/gmake /usr/local/bin/make && \ ln -sf /opt/csw/bin/gpatch /usr/local/bin/patch # Start a Bash shell /opt/csw/bin/bash # Set up environment export PATH=/opt/csw/bin:/usr/local/bin:/usr/sbin:/usr/bin:/usr/X/bin:/usr/ccs/bin export LD_LIBRARY_PATH=/opt/csw/lib:/opt/csw/lib/64:/usr/sfw/lib export LD_LIBRARY_PATH_64=$LD_LIBRARY_PATH # build and install openssl 1.1.0g wget https://www.openssl.org/source/openssl-1.1.0g.tar.gz && \ tar -zxvpf openssl-1.1.0g.tar.gz && \ cd openssl-1.1.0g && \ KERNEL_BITS=64 ./config --prefix=/usr/local/ssl-1.1.0g && \ make && \ make install # Verify LD_LIBRARY_PATH_64=/usr/local/ssl-1.1.0g/lib:$LD_LIBRARY_PATH_64 /usr/local/ssl-1.1.0g/bin/openssl version OpenSSL 1.1.0g 2 Nov 2017 On 11/17/17 5:46 AM, Dmitry Belyavsky wrote: > Dear Richard, > > Adding no-threads just removes gcc complaint about -pthreads. > > On Fri, Nov 17, 2017 at 1:23 PM, Richard Levitte > wrote: > > I suggest adding 'no-threads' to the OpenSSL configuration options, at > least as a first step.? That should at least take away gcc's complaint > about '-pthread'...? I cannot say if that'll fix the rest, I don't > know Solaris enough. > > Cheers, > Richard > > In message > on Fri, 17 Nov 2017 11:08:34 +0300, > Dmitry Belyavsky > said: > > beldmit> Hello, > beldmit> > beldmit> We experience problems building OpenSSL on Solaris. > beldmit> > beldmit> /usr/local/src/openssl-1.1.0g>uname -a > beldmit> > beldmit> SunOS pooh.tcinet.ru 5.10 Generic_147147-26 sun4u sparc SUNW,SPARC-Enterprise > beldmit> > beldmit> /usr/local/src/openssl-1.1.0g>gcc -v > beldmit> > beldmit> Reading specs from /usr/local/lib/gcc/sparc-sun-solaris2.10/3.4.6/specs > beldmit> Configured with: ../configure --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --enable-shared > beldmit> --enable-languages=c,c++,f77 > beldmit> Thread model: posix > beldmit> gcc version 3.4.6 > beldmit> > beldmit> OpenSSL 1.1.0g is configured via > beldmit> ./Configure solaris64-sparcv9-gcc > beldmit> > beldmit> Here is the end of output: > beldmit> > beldmit> ... > beldmit> > beldmit> LD_LIBRARY_PATH=.:/usr/local/ssl/lib:/usr/sfw/lib/sparcv9:/usr/local/lib gcc -DDSO_DLFCN > beldmit> -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE > beldmit> -DOPENSSL_PIC -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM > beldmit> -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM > beldmit> -DPOLY1305_ASM -DOPENSSLDIR="/usr/local/ssl" -DENGINESDIR="/usr/local/lib/engines-1.1" -m64 > beldmit> -mcpu=ultrasparc -Wall -DB_ENDIAN -DBN_DIV2W -O3 -pthread -DFILIO_H -o apps/openssl > beldmit> apps/app_rand.o apps/apps.o apps/asn1pars.o apps/ca.o apps/ciphers.o apps/cms.o apps/crl.o > beldmit> apps/crl2p7.o apps/dgst.o apps/dhparam.o apps/dsa.o apps/dsaparam.o apps/ec.o apps/ecparam.o > beldmit> apps/enc.o apps/engine.o apps/errstr.o apps/gendsa.o apps/genpkey.o apps/genrsa.o apps/nseq.o > beldmit> apps/ocsp.o apps/openssl.o apps/opt.o apps/passwd.o apps/pkcs12.o apps/pkcs7.o apps/pkcs8.o > beldmit> apps/pkey.o apps/pkeyparam.o apps/pkeyutl.o apps/prime.o apps/rand.o apps/rehash.o apps/req.o > beldmit> apps/rsa.o apps/rsautl.o apps/s_cb.o apps/s_client.o apps/s_server.o apps/s_socket.o apps/s_time.o > beldmit> apps/sess_id.o apps/smime.o apps/speed.o apps/spkac.o apps/srp.o apps/ts.o apps/verify.o > beldmit> apps/version.o apps/x509.o -L. -lssl -L. -lcrypto -lsocket -lnsl -ldl > beldmit> gcc: unrecognized option `-pthread' > beldmit> ld: warning: relocation warning: R_SPARC_COPY: file ./libcrypto.so: symbol PBEPARAM_it: relocation > beldmit> bound to a symbol with STV_PROTECTED visibility > beldmit> ld: warning: relocation warning: R_SPARC_COPY: file ./libcrypto.so: symbol PBE2PARAM_it: > beldmit> relocation bound to a symbol with STV_PROTECTED visibility > beldmit> ld: warning: relocation warning: R_SPARC_COPY: file ./libcrypto.so: symbol PBKDF2PARAM_it: > beldmit> relocation bound to a symbol with STV_PROTECTED visibility > beldmit> Undefined first referenced > beldmit> symbol in file > beldmit> _sparcv9_rdtick ./libcrypto.so > beldmit> bn_add_words ./libcrypto.so > beldmit> _sparcv9_vis1_instrument ./libcrypto.so > beldmit> bn_sub_words ./libcrypto.so > beldmit> bn_sqr_words ./libcrypto.so > beldmit> OPENSSL_cleanse apps/apps.o > beldmit> _sparcv9_rdcfr ./libcrypto.so > beldmit> _sparcv9_vis1_instrument_bus2 ./libcrypto.so > beldmit> _sparcv9_vis3_probe ./libcrypto.so > beldmit> bn_mul_words ./libcrypto.so > beldmit> _sparcv9_vis2_probe ./libcrypto.so > beldmit> _sparcv9_vis1_probe ./libcrypto.so > beldmit> ChaCha20_ctr32 ./libcrypto.so > beldmit> _sparcv9_vis1_instrument_bus ./libcrypto.so > beldmit> bn_mul_comba4 ./libcrypto.so > beldmit> bn_mul_comba8 ./libcrypto.so > beldmit> bn_sqr_comba4 ./libcrypto.so > beldmit> bn_sqr_comba8 ./libcrypto.so > beldmit> _sparcv9_fmadd_probe ./libcrypto.so > beldmit> CRYPTO_memcmp ./libssl.so > beldmit> bn_mul_add_words ./libcrypto.so > beldmit> bn_div_words ./libcrypto.so > beldmit> _sparcv9_fjaesx_probe ./libcrypto.so > beldmit> ld: fatal: symbol referencing errors. No output written to apps/openssl > beldmit> collect2: ld returned 1 exit status > beldmit> *** Error code 1 > beldmit> > beldmit> What can we do to fix it? > beldmit> > beldmit> Thank you! > beldmit> > beldmit> -- > beldmit> SY, Dmitry Belyavsky > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > > > > > > -- > SY, Dmitry Belyavsky > > From beldmit at gmail.com Fri Nov 17 11:40:59 2017 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Fri, 17 Nov 2017 14:40:59 +0300 Subject: [openssl-dev] Problems building openssl on Solaris In-Reply-To: <20171117.122108.960838834807144433.levitte@openssl.org> References: <20171117.112345.2018766134224925420.levitte@openssl.org> <20171117.122108.960838834807144433.levitte@openssl.org> Message-ID: Hello, On Fri, Nov 17, 2017 at 2:21 PM, Richard Levitte wrote: > Ah, sorry, I didn't read the output properly. > > Regarding the STV_PROTECTED warnings, I don't know at all... I did a > bit of a search and saw that this has been discussed before, a little > more than a year ago. See > https://mta.openssl.org/pipermail/openssl-dev/2016-August/008192.html > > As for the missing symbols, that tells me something went horribly > wrong when compiling assembler stuff. The quick fix is to use the > 'no-asm' configuration option. However, if you want to help getting > assembler to compile, I suggest doing this (no configuration change): > > rm crypto/sparccpuid.o > make build_generated > make crypto/sparccpuid.o > No errors. > (note: there are other assembler files that seem to fail as well, for > example those for the bignum library, so this is clearly an assembler > issue) > Sure... > > Cheers, > Richard > > In message gmail.com> on Fri, 17 Nov 2017 13:46:31 +0300, Dmitry Belyavsky < > beldmit at gmail.com> said: > > beldmit> Dear Richard, > beldmit> > beldmit> Adding no-threads just removes gcc complaint about -pthreads. > beldmit> > beldmit> On Fri, Nov 17, 2017 at 1:23 PM, Richard Levitte < > levitte at openssl.org> wrote: > beldmit> > beldmit> I suggest adding 'no-threads' to the OpenSSL configuration > options, at > beldmit> least as a first step. That should at least take away gcc's > complaint > beldmit> about '-pthread'... I cannot say if that'll fix the rest, I don't > beldmit> know Solaris enough. > beldmit> > beldmit> Cheers, > beldmit> Richard > beldmit> > beldmit> In message > beldmit> gmail.com> on Fri, 17 > beldmit> Nov 2017 11:08:34 +0300, Dmitry Belyavsky > said: > beldmit> > beldmit> beldmit> Hello, > beldmit> beldmit> > beldmit> beldmit> We experience problems building OpenSSL on Solaris. > beldmit> beldmit> > beldmit> beldmit> /usr/local/src/openssl-1.1.0g>uname -a > beldmit> beldmit> > beldmit> beldmit> SunOS pooh.tcinet.ru 5.10 Generic_147147-26 sun4u > sparc SUNW,SPARC-Enterprise > beldmit> beldmit> > beldmit> beldmit> /usr/local/src/openssl-1.1.0g>gcc -v > beldmit> beldmit> > beldmit> beldmit> Reading specs from /usr/local/lib/gcc/sparc-sun- > solaris2.10/3.4.6/specs > beldmit> beldmit> Configured with: ../configure --with-as=/usr/ccs/bin/as > --with-ld=/usr/ccs/bin/ld > beldmit> --enable-shared > beldmit> beldmit> --enable-languages=c,c++,f77 > beldmit> beldmit> Thread model: posix > beldmit> beldmit> gcc version 3.4.6 > beldmit> beldmit> > beldmit> beldmit> OpenSSL 1.1.0g is configured via > beldmit> beldmit> ./Configure solaris64-sparcv9-gcc > beldmit> beldmit> > beldmit> beldmit> Here is the end of output: > beldmit> beldmit> > beldmit> beldmit> ... > beldmit> beldmit> > beldmit> beldmit> LD_LIBRARY_PATH=.:/usr/local/ > ssl/lib:/usr/sfw/lib/sparcv9:/usr/local/lib gcc > beldmit> -DDSO_DLFCN > beldmit> beldmit> -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS > -DOPENSSL_NO_STATIC_ENGINE > beldmit> beldmit> -DOPENSSL_PIC -DOPENSSL_BN_ASM_MONT > -DOPENSSL_BN_ASM_GF2m > beldmit> -DSHA1_ASM > beldmit> beldmit> -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM > -DGHASH_ASM > beldmit> -DECP_NISTZ256_ASM > beldmit> beldmit> -DPOLY1305_ASM -DOPENSSLDIR="/usr/local/ssl" > beldmit> -DENGINESDIR="/usr/local/lib/engines-1.1" -m64 > beldmit> beldmit> -mcpu=ultrasparc -Wall -DB_ENDIAN -DBN_DIV2W -O3 > -pthread -DFILIO_H -o > beldmit> apps/openssl > beldmit> beldmit> apps/app_rand.o apps/apps.o apps/asn1pars.o apps/ca.o > apps/ciphers.o apps/cms.o > beldmit> apps/crl.o > beldmit> beldmit> apps/crl2p7.o apps/dgst.o apps/dhparam.o apps/dsa.o > apps/dsaparam.o apps/ec.o > beldmit> apps/ecparam.o > beldmit> beldmit> apps/enc.o apps/engine.o apps/errstr.o apps/gendsa.o > apps/genpkey.o apps/genrsa.o > beldmit> apps/nseq.o > beldmit> beldmit> apps/ocsp.o apps/openssl.o apps/opt.o apps/passwd.o > apps/pkcs12.o apps/pkcs7.o > beldmit> apps/pkcs8.o > beldmit> beldmit> apps/pkey.o apps/pkeyparam.o apps/pkeyutl.o > apps/prime.o apps/rand.o > beldmit> apps/rehash.o apps/req.o > beldmit> beldmit> apps/rsa.o apps/rsautl.o apps/s_cb.o apps/s_client.o > apps/s_server.o apps/s_socket.o > beldmit> apps/s_time.o > beldmit> beldmit> apps/sess_id.o apps/smime.o apps/speed.o apps/spkac.o > apps/srp.o apps/ts.o > beldmit> apps/verify.o > beldmit> beldmit> apps/version.o apps/x509.o -L. -lssl -L. -lcrypto > -lsocket -lnsl -ldl > beldmit> beldmit> gcc: unrecognized option `-pthread' > beldmit> beldmit> ld: warning: relocation warning: R_SPARC_COPY: file > ./libcrypto.so: symbol > beldmit> PBEPARAM_it: relocation > beldmit> beldmit> bound to a symbol with STV_PROTECTED visibility > beldmit> beldmit> ld: warning: relocation warning: R_SPARC_COPY: file > ./libcrypto.so: symbol > beldmit> PBE2PARAM_it: > beldmit> beldmit> relocation bound to a symbol with STV_PROTECTED > visibility > beldmit> beldmit> ld: warning: relocation warning: R_SPARC_COPY: file > ./libcrypto.so: symbol > beldmit> PBKDF2PARAM_it: > beldmit> beldmit> relocation bound to a symbol with STV_PROTECTED > visibility > beldmit> beldmit> Undefined first referenced > beldmit> beldmit> symbol in file > beldmit> beldmit> _sparcv9_rdtick ./libcrypto.so > beldmit> beldmit> bn_add_words ./libcrypto.so > beldmit> beldmit> _sparcv9_vis1_instrument ./libcrypto.so > beldmit> beldmit> bn_sub_words ./libcrypto.so > beldmit> beldmit> bn_sqr_words ./libcrypto.so > beldmit> beldmit> OPENSSL_cleanse apps/apps.o > beldmit> beldmit> _sparcv9_rdcfr ./libcrypto.so > beldmit> beldmit> _sparcv9_vis1_instrument_bus2 ./libcrypto.so > beldmit> beldmit> _sparcv9_vis3_probe ./libcrypto.so > beldmit> beldmit> bn_mul_words ./libcrypto.so > beldmit> beldmit> _sparcv9_vis2_probe ./libcrypto.so > beldmit> beldmit> _sparcv9_vis1_probe ./libcrypto.so > beldmit> beldmit> ChaCha20_ctr32 ./libcrypto.so > beldmit> beldmit> _sparcv9_vis1_instrument_bus ./libcrypto.so > beldmit> beldmit> bn_mul_comba4 ./libcrypto.so > beldmit> beldmit> bn_mul_comba8 ./libcrypto.so > beldmit> beldmit> bn_sqr_comba4 ./libcrypto.so > beldmit> beldmit> bn_sqr_comba8 ./libcrypto.so > beldmit> beldmit> _sparcv9_fmadd_probe ./libcrypto.so > beldmit> beldmit> CRYPTO_memcmp ./libssl.so > beldmit> beldmit> bn_mul_add_words ./libcrypto.so > beldmit> beldmit> bn_div_words ./libcrypto.so > beldmit> beldmit> _sparcv9_fjaesx_probe ./libcrypto.so > beldmit> beldmit> ld: fatal: symbol referencing errors. No output written > to apps/openssl > beldmit> beldmit> collect2: ld returned 1 exit status > beldmit> beldmit> *** Error code 1 > beldmit> beldmit> > beldmit> beldmit> What can we do to fix it? > beldmit> beldmit> > beldmit> beldmit> Thank you! > beldmit> beldmit> > beldmit> beldmit> -- > beldmit> beldmit> SY, Dmitry Belyavsky > beldmit> -- > beldmit> openssl-dev mailing list > beldmit> To unsubscribe: https://mta.openssl.org/ > mailman/listinfo/openssl-dev > beldmit> > beldmit> -- > beldmit> SY, Dmitry Belyavsky > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From khalprin at autosoln.com Fri Nov 17 16:40:06 2017 From: khalprin at autosoln.com (kenh) Date: Fri, 17 Nov 2017 09:40:06 -0700 (MST) Subject: [openssl-dev] Initialization and cleanup in 1.1.0f Message-ID: <1510936806832-0.post@n7.nabble.com> I'm using OpenSSL 1.1.0f in a client application. My implementation is using up memory like crazy, so I must not be doing something right. I read that 1.1.0 no longer needs explicit library initialization, so I've take out the one-time calls (like SSL_library_init() and SSL_load_error_strings()). I create an SSL_CTX object and an SSL object for each communication I have to do. The connections may use different certificate/key files so I create and destroy these objects for each connection (I'm using non-blocking sockets on a Windows platform). Having tried numerous variations, I'm currently using this code to create the objects: const SSL_METHOD* meth = SSLv23_method(); ssl_ctx = SSL_CTX_new(meth); SSL_CTX_set_verify(ssl_ctx, SSL_VERIFY_NONE, nullptr); SSL_CTX_set_quiet_shutdown(ssl_ctx, 1); // non-standard. SSL_CTX_sess_set_cache_size(ssl_ctx, 1); // no longer needed after adding next line (?) SSL_CTX_set_session_cache_mode(ssl_ctx, SSL_SESS_CACHE_OFF); // setup certificate file, private key file, password, etc. SetupContext(info); ssl = SSL_new(ssl_ctx); bio[BIO_SEND] = BIO_new(BIO_s_mem()); bio[BIO_RECV] = BIO_new(BIO_s_mem()); SSL_set_bio(ssl, bio[BIO_RECV], bio[BIO_SEND]); and the clean up at the end of the communication is done this way: if ( nullptr != ssl ) { SSL_shutdown(ssl); SSL_CTX_free(ssl_ctx); SSL_free(ssl); // free's the two bio buffers associated with it. ssl = nullptr; } What am I missing? Thanks. -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-Dev-f29372.html From paul.dale at oracle.com Tue Nov 21 01:31:05 2017 From: paul.dale at oracle.com (Paul Dale) Date: Mon, 20 Nov 2017 17:31:05 -0800 (PST) Subject: [openssl-dev] FIPS module for 1.1.x ? Message-ID: With the recent changes in OMC, how has the OpenSSL 1.1.x FIPS plan changed? Can the OMC provide some insight? It was suggested that I wait for things to settle before asking and it has been a few weeks since the last of the announcements. Previously, there was a plan to expand the engine interface so it could provide FIPS capability but I understand that other possibilities are again under consideration. Pauli -- Oracle Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Tue Nov 21 22:50:31 2017 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 21 Nov 2017 22:50:31 +0000 Subject: [openssl-dev] FIPS module for 1.1.x ? In-Reply-To: References: Message-ID: <3AB5BCA2-12CE-45E6-AB33-9765C2C9A5B6@akamai.com> FIPS remains a very important goal. Hopefully we?ll have more details to share in early December. -------------- next part -------------- An HTML attachment was scrubbed... URL: From beldmit at gmail.com Mon Nov 27 16:56:00 2017 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Mon, 27 Nov 2017 19:56:00 +0300 Subject: [openssl-dev] Certificate Limitation Profile Message-ID: Hello, I'm working on an internet draft describing application-level analog of CRLs. I named the proposed file format Certificate Limitation Profile. I think that current model of trust when only CAs can revoke the certificates issued by them does not fit current situation, and we also need app-level limitations, as browser vendors (Google, Mozilla) already do. Currently such limitations are hard coded into the particular software. Being standardized, it will be possible to reuse such limitations across various applications and avoid hard-coding. Here is the link to the draft: https://datatracker.ietf.org/doc/draft-belyavskiy-certificate-limitation-policy/ The current version of the draft (hopefully) describes necessary ASN.1 structures that are enough for the most practical cases. I have middle-term plans to provide a support of the draft in OpenSSL, if the idea seems interesting enough. Any feedback is welcome. Thank you! -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From kurt at roeckx.be Tue Nov 28 12:25:04 2017 From: kurt at roeckx.be (Kurt Roeckx) Date: Tue, 28 Nov 2017 13:25:04 +0100 Subject: [openssl-dev] Certificate Limitation Profile In-Reply-To: References: Message-ID: <20171128122503.4oy2jmkzyq3thwa7@roeckx.be> On Mon, Nov 27, 2017 at 07:56:00PM +0300, Dmitry Belyavsky wrote: > Here is the link to the draft: > https://datatracker.ietf.org/doc/draft-belyavskiy-certificate-limitation-policy/ I'm wondering how you think that policy will be distributed and why it needs signed. I expect that there will always be some way of authenticating the document if you download it without requiring that the document is signed itself. For instance it might come as part of some software distribution (like a browser), and either you trust all the files in that distribution or you don't. If it's signed, who will be signing it, and how does the application know which key to use to verify the signature? I can also imagine that users might wish to modify that file, for instance add an internal CA or certificate, not trust some CA, ... They could of course generate their own key, and tell the software to use that key. Kurt From angus at magsys.co.uk Tue Nov 28 14:46:00 2017 From: angus at magsys.co.uk (Angus Robertson - Magenta Systems Ltd) Date: Tue, 28 Nov 2017 14:46 +0000 (GMT Standard Time) Subject: [openssl-dev] [openssl-users] DTLS in multi-thread and concurrent connection acceptance environment In-Reply-To: <50aaef27-25b8-d442-26ae-cd2f9ca2c23c@openssl.org> Message-ID: > I don't know if anyone has ever created any metrics on how far it > can be scaled. I've certainly not seen it if they have. But there > are no knownlimitations on this approach (this is the intended > way to do things). Our Delphi OpenSSL implementation on Windows mostly uses a single thread and event driven code, although Windows itself uses a thread per connection. But we don't support DTLS. I did some testing last year with simple SSL TCP/IP client and server on Windows 10, and had 2,000 simultaneous SSL sessions running on the same PC, always thought client versions of Windows supported far fewer sessions. The main limitation during testing with a single thread was the set-up time for SSL, there is a limit of how many new sessions can be started per second. My test was starting 100 sessions per second, and about 20% failed initially, but succeeded later on retries. I used my own applications for testing, ComCap5 and ComGen5 from https://www.magsys.co.uk/comcap/ ComGen is a TCP/UDP session data generator, configurable for multiple IPs and ports, and volume of sessions. Angus From beldmit at gmail.com Tue Nov 28 19:11:43 2017 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Tue, 28 Nov 2017 22:11:43 +0300 Subject: [openssl-dev] Certificate Limitation Profile In-Reply-To: <20171128122503.4oy2jmkzyq3thwa7@roeckx.be> References: <20171128122503.4oy2jmkzyq3thwa7@roeckx.be> Message-ID: Dear Kurt, On Tue, Nov 28, 2017 at 3:25 PM, Kurt Roeckx wrote: > On Mon, Nov 27, 2017 at 07:56:00PM +0300, Dmitry Belyavsky wrote: > > Here is the link to the draft: > > https://datatracker.ietf.org/doc/draft-belyavskiy- > certificate-limitation-policy/ > > I'm wondering how you think that policy will be distributed and > why it needs signed. I expect that there will always be some way > of authenticating the document if you download it without requiring > that the document is signed itself. For instance it might come > as part of some software distribution (like a browser), and either > you trust all the files in that distribution or you don't. > I agree that an unsigned variant of CLP makes sense. But it seems to me that if CLP is signed by the certificate that can be verified using standard chain of trust, it has some advantages. > If it's signed, who will be signing it, and how does the > application know which key to use to verify the signature? > I think that if the CLP is native for the application, the key/cert should be hard coded in the app itself. If we use an external one (e.g. issued by Mozilla or Chrome), we can specify the certificate in app's config and verify the certificate after constructing the chain of trust from the roots. > > I can also imagine that users might wish to modify that file, > for instance add an internal CA or certificate, not trust some > CA, ... They could of course generate their own key, and tell the > software to use that key. > Yes, it's a possible mode of operation. But if we allow unsigned CLPs, the own key can become unnecessary. -------------- next part -------------- An HTML attachment was scrubbed... URL: From uri at ll.mit.edu Tue Nov 28 19:18:48 2017 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Tue, 28 Nov 2017 19:18:48 +0000 Subject: [openssl-dev] Certificate Limitation Profile In-Reply-To: References: <20171128122503.4oy2jmkzyq3thwa7@roeckx.be> Message-ID: <88A965C3-58AE-4921-81BD-BCFDD8E30FA3@ll.mit.edu> I'm wondering how you think that policy will be distributed and why it needs signed. ? For instance it might come as part of some software distribution (like a browser), and either you trust all the files in that distribution or you don't. I agree that an unsigned variant of CLP makes sense. But it seems to me that if CLP is signed by the certificate that can be verified using standard chain of trust, it has some advantages. I think it makes perfect sense to sign CLP, because it allows you to separate trust in the server you?re downloading the content from and the content itself. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5211 bytes Desc: not available URL: From openssl-users at dukhovni.org Tue Nov 28 20:14:06 2017 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 28 Nov 2017 20:14:06 +0000 Subject: [openssl-dev] Certificate Limitation Profile In-Reply-To: <88A965C3-58AE-4921-81BD-BCFDD8E30FA3@ll.mit.edu> References: <20171128122503.4oy2jmkzyq3thwa7@roeckx.be> <88A965C3-58AE-4921-81BD-BCFDD8E30FA3@ll.mit.edu> Message-ID: <20171128201406.GX3322@mournblade.imrryr.org> On Tue, Nov 28, 2017 at 07:18:48PM +0000, Blumenthal, Uri - 0553 - MITLL wrote: > I think it makes perfect sense to sign CLP, because it allows you to > separate trust in the server you?re downloading the content from and the > content itself. The problem with "data at rest" signatures is that it then becomes difficult to ascertain freshness. How do you know that you're not usign a much too stale version of the CLP, that fails to include a recently deprecated trust anchor. Therefore, one needs to be careful to not rely *solely* on the signature of the CLP payload. It is still important to get a fresh copy from a trusted source sufficiently often. -- Viktor. From beldmit at gmail.com Tue Nov 28 20:37:35 2017 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Tue, 28 Nov 2017 23:37:35 +0300 Subject: [openssl-dev] Certificate Limitation Profile In-Reply-To: <20171128201406.GX3322@mournblade.imrryr.org> References: <20171128122503.4oy2jmkzyq3thwa7@roeckx.be> <88A965C3-58AE-4921-81BD-BCFDD8E30FA3@ll.mit.edu> <20171128201406.GX3322@mournblade.imrryr.org> Message-ID: Dear Victor, On Tue, Nov 28, 2017 at 11:14 PM, Viktor Dukhovni < openssl-users at dukhovni.org> wrote: > On Tue, Nov 28, 2017 at 07:18:48PM +0000, Blumenthal, Uri - 0553 - MITLL > wrote: > > > I think it makes perfect sense to sign CLP, because it allows you to > > separate trust in the server you?re downloading the content from and the > > content itself. > > The problem with "data at rest" signatures is that it then becomes > difficult to ascertain freshness. How do you know that you're not > usign a much too stale version of the CLP, that fails to include a > recently deprecated trust anchor. > > Therefore, one needs to be careful to not rely *solely* on the > signature of the CLP payload. It is still important to get a fresh > copy from a trusted source sufficiently often. > Thank you. It seems reasonable to add nextUpdate field to the header of CLP to avoid problems related to using stale CLP. I expect that fresh CLPs in most cases are delivered via update procedures of applications, and update mechanism allows fresh enough CLP. On the other hand enforcing freshness can cause difficulties in situation when an application becomes unsupported on a specific version of platform (e.g. stale version of Android/iOS). -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Tue Nov 28 21:03:13 2017 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 28 Nov 2017 21:03:13 +0000 Subject: [openssl-dev] Certificate Limitation Profile In-Reply-To: References: <20171128122503.4oy2jmkzyq3thwa7@roeckx.be> <88A965C3-58AE-4921-81BD-BCFDD8E30FA3@ll.mit.edu> <20171128201406.GX3322@mournblade.imrryr.org> Message-ID: <20171128210312.GZ3322@mournblade.imrryr.org> On Tue, Nov 28, 2017 at 11:37:35PM +0300, Dmitry Belyavsky wrote: > Thank you. It seems reasonable to add nextUpdate field to > the header of CLP to avoid problems related to using stale CLP. > > I expect that fresh CLPs in most cases are delivered via update procedures > of applications, and update mechanism allows fresh enough CLP. > > On the other hand enforcing freshness can cause difficulties in situation > when an application becomes unsupported on a specific version of platform > (e.g. stale version of Android/iOS). Perhaps a sensible way to handle nextUpdate is to refuse to import a purportedly fresh CLP whose nextUpdate has expired or is older than what you have. If an application is failing to get updates, then it can continue to run with what it has. The idea is to prevent "rollback" attacks, more than fail closed on expired CLPs when nothing fresh is available. -- Viktor.