From rt at openssl.org Mon Feb 1 01:35:41 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 01:35:41 +0000 Subject: [openssl-dev] [openssl.org #1755] config silently ignores standard compiler search path on AIX and reverts from gcc to cc In-Reply-To: <6CBB3FF28784714BB8826060E713397103C7AA6E@exchange.ud.com> References: <6CBB3FF28784714BB8826060E713397103C7AA6E@exchange.ud.com> Message-ID: 0.9.8 is gone, and this seems fixed in current versions.-- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 01:37:38 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 01:37:38 +0000 Subject: [openssl-dev] [openssl.org #1825] Segmentation Fault In-Reply-To: <49809DD8.9070308@nkiconsulting.com> References: <49809DD8.9070308@nkiconsulting.com> Message-ID: please open a new ticket if this happens with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 13:42:03 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 13:42:03 +0000 Subject: [openssl-dev] [openssl.org #4129] [PATCH] Can BIO_new_mem_buf take a const void* instead of a void* ? In-Reply-To: <1446841060-15685-1-git-send-email-dkg@fifthhorseman.net> References: <1446841060-15685-1-git-send-email-dkg@fifthhorseman.net> Message-ID: Why yes, yes it can, Dan. :) Fixed in master and 1.0.2; thanks for the comprehensive patch. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From hkario at redhat.com Mon Feb 1 14:23:30 2016 From: hkario at redhat.com (Hubert Kario) Date: Mon, 01 Feb 2016 15:23:30 +0100 Subject: [openssl-dev] [openssl-users] pkeyutl does not invoke hash? In-Reply-To: References: <20160118192227.17788998.21663.45907@ll.mit.edu> <20160120163743.GA18335@openssl.org> Message-ID: <1618304.aEJkvr3W8x@pintsize.usersys.redhat.com> On Wednesday 20 January 2016 17:17:47 Blumenthal, Uri - 0553 - MITLL wrote: > I see. Steve, what would you suggest to add to the man page, in view > of what we?ve been discussing for the last few days here? I've updated the pull request to state explicitly that no hashing will be done for RSA, ECDSA and DSA signature inputs. old proposed patch: https://github.com/tomato42/openssl/commit/f37b5e639e57c2d4c3b404c24ecb11b8ec627e9b new proposed patch: https://github.com/openssl/openssl/commit/02c0d466664126cf277a8d51b09863fad55daf74 -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From rsalz at akamai.com Mon Feb 1 16:17:24 2016 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 1 Feb 2016 16:17:24 +0000 Subject: [openssl-dev] [openssl-users] pkeyutl does not invoke hash? In-Reply-To: <1618304.aEJkvr3W8x@pintsize.usersys.redhat.com> References: <20160118192227.17788998.21663.45907@ll.mit.edu> <20160120163743.GA18335@openssl.org> <1618304.aEJkvr3W8x@pintsize.usersys.redhat.com> Message-ID: > new proposed patch: > https://github.com/openssl/openssl/commit/02c0d466664126cf277a8d51b09863fad55daf74 Checked into master; thanks for your help to improve things! From uri at ll.mit.edu Mon Feb 1 16:28:13 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Mon, 1 Feb 2016 16:28:13 +0000 Subject: [openssl-dev] [openssl-users] pkeyutl does not invoke hash? In-Reply-To: <1618304.aEJkvr3W8x@pintsize.usersys.redhat.com> References: <20160118192227.17788998.21663.45907@ll.mit.edu> <20160120163743.GA18335@openssl.org> <1618304.aEJkvr3W8x@pintsize.usersys.redhat.com> Message-ID: On 2/1/16, 9:23 , "Hubert Kario" wrote: >On Wednesday 20 January 2016 17:17:47 Blumenthal, Uri - 0553 - MITLL >wrote: >> I see. Steve, what would you suggest to add to the man page, in view >> of what we?ve been discussing for the last few days here? > >I've updated the pull request to state explicitly that no hashing will >be done for RSA, ECDSA and DSA signature inputs. Perfect! Thanks!! >old proposed patch: >https://github.com/tomato42/openssl/commit/f37b5e639e57c2d4c3b404c24ecb11b >8ec627e9b >new proposed patch: >https://github.com/openssl/openssl/commit/02c0d466664126cf277a8d51b09863fa >d55daf74 Rich, let?s percolate this to the OpenSSL_1_0_2-stable? When EdDSA support is included in pkeyutl (and tested) - more text can be added, describing what parameters *exactly* EdDSA takes, what they mean, and how EdDSA processing differs from other signatures. This EdDSA change would only go to the master. Again, thank you! >-- >Regards, >Hubert Kario >Senior Quality Engineer, QE BaseOS Security team >Web: www.cz.redhat.com >Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4308 bytes Desc: not available URL: From rsalz at akamai.com Mon Feb 1 16:45:31 2016 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 1 Feb 2016 16:45:31 +0000 Subject: [openssl-dev] [openssl-users] pkeyutl does not invoke hash? In-Reply-To: References: <20160118192227.17788998.21663.45907@ll.mit.edu> <20160120163743.GA18335@openssl.org> <1618304.aEJkvr3W8x@pintsize.usersys.redhat.com> Message-ID: <8965e429d86b400e9ee649cb5bd29ae2@usma1ex-dag1mb1.msg.corp.akamai.com> > Rich, let?s percolate this to the OpenSSL_1_0_2-stable? Done. From mohan at computer.org Mon Feb 1 18:34:57 2016 From: mohan at computer.org (J Mohan Rao Arisankala) Date: Tue, 2 Feb 2016 00:04:57 +0530 Subject: [openssl-dev] openssl-1.1.0-pre2 make failure with perl-5.8.8 on Linux Message-ID: Hi, I have a development environment, which uses a very old perl version (5.8.8). The compilation of openssl-1.1.0-pre2 fails with the following error, I have attached a patch below that worked for me: make[5]: Entering directory `/mail/src/mohan/v6.0/buildinstructions/openssl1.1/build64/openssl' Bareword found where operator expected at util/mkdef.pl line 1573, near "s/\./_/gr" Unquoted string "r" may clash with future reserved word at util/mkdef.pl line 1573. syntax error at util/mkdef.pl line 1573, near "s/\./_/gr" Execution of util/mkdef.pl aborted due to compilation errors. /opt/gcc-4.7.2/lib/gcc/x86_64-unknown-linux-gnu/4.7.2/../../../../x86_64-unknown-linux-gnu/bin/ld:crypto.map:1: syntax error in VERSION script collect2: error: ld returned 1 exit status make[5]: *** [link_a.linux-shared] Error 1 $ perl -v This is perl, v5.8.8 built for i686-linux-thread-multi Copyright 1987-2006, Larry Wall ... +++++++++++++++++++++++ +++++++++++++++++++++++++++++++++ diff -Nur ../openssl-1.1.0-pre2/util/mkdef.pl ./util/mkdef.pl --- ../openssl-1.1.0-pre2/util/mkdef.pl 2016-01-14 01:51:33.000000000 -0800 +++ ./util/mkdef.pl 2016-02-01 09:08:00.000000000 -0800 @@ -1569,8 +1569,10 @@ while() { if (/OPENSSL_VERSION_TEXT\s+"OpenSSL (\d\.\d\.)(\d[a-z]*)(-| )/) { + my $basev = $1; my $suffix = $2; - my $baseversion = $1 =~ s/\./_/gr; + $basev =~ s/\./_/g; + my $baseversion = $basev; close IN; return ($baseversion."0", $baseversion.$suffix); } +++++++++++++++++++++++ +++++++++++++++++++++++++++++++++ After applying the patch, the compilation is successful and here is the openssl version. $ openssl version -a OpenSSL 1.1.0-pre2 (alpha) 14 Jan 2016 built on: reproducible build, date unspecified platform: linux-x86_64 compiler: gcc -I. -I.. -I../include -Iinclude -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -pthread -DDSO_DLFCN -DHAVE_DLFCN_H -I/usr/local/include -DPURIFY -m64 -DL_ENDIAN -Wall -O3 -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM OPENSSLDIR: "/usr/local/etc/ssl" Please let me know if you need any additional info. Thanks, Mohan -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Mon Feb 1 18:41:06 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 18:41:06 +0000 Subject: [openssl-dev] [openssl.org #92] Prototypes SSL_write() & SSL_read() problem in openssl/ssl.h for 64-bit applications In-Reply-To: <200206102000.QAA14204@interlock2.lexmark.com> References: <200206102000.QAA14204@interlock2.lexmark.com> Message-ID: please open a new ticket if still a problem. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 18:42:17 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 18:42:17 +0000 Subject: [openssl-dev] [openssl.org #465] [patch] X509_LOOKUP_hash_dir with multiple directories problem In-Reply-To: <3E2BFE50.3000704@systinet.com> References: <3E2BFE50.3000704@systinet.com> Message-ID: This is reported against 0.9.8; please open a new ticket if still a problem with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 18:43:11 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 18:43:11 +0000 Subject: [openssl-dev] [openssl.org #590] BUG REPORT: X509_get_signature_type() returning NID_undef In-Reply-To: <003801c30803$4d5b0280$6701a8c0@austin> References: <003801c30803$4d5b0280$6701a8c0@austin> Message-ID: This is reported against 0.9.8; please open a new ticket if still a problem with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 18:43:55 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 18:43:55 +0000 Subject: [openssl-dev] [openssl.org #598] OpenSSL: error:1409F07F:SSL routines:SSL3_WRITE_PENDING:bad write retry In-Reply-To: <033b01c30d8f$790e2380$c4e857c3@kocnet.koc> References: <033b01c30d8f$790e2380$c4e857c3@kocnet.koc> Message-ID: This is reported against 0.9.8; please open a new ticket if still a problem with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 18:44:41 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 18:44:41 +0000 Subject: [openssl-dev] [openssl.org #773] No OAEP support for S/MIME In-Reply-To: <200311191758.28386.thorsten.mueller@aachen.utimaco.de> References: <200311191758.28386.thorsten.mueller@aachen.utimaco.de> Message-ID: it's been 13 years, unlikely to happen. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 18:45:33 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 18:45:33 +0000 Subject: [openssl-dev] [openssl.org #791] CBC padding patch for FIPS-81 In-Reply-To: References: Message-ID: This is reported against 0.9.8; please open a new ticket if still a problem with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 18:46:16 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 18:46:16 +0000 Subject: [openssl-dev] [openssl.org #828] [PATCH] "openssl smime -verify" on binary files In-Reply-To: <16971.1076938143@www4.gmx.net> References: <16971.1076938143@www4.gmx.net> Message-ID: Over 10 years old, not going to happen. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 18:47:39 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 18:47:39 +0000 Subject: [openssl-dev] [openssl.org #1068] X509_NAME_add_entry: inserting with loc == 0 and set == 0 creates wrong set References: Message-ID: This is reported against 0.9.8; please open a new ticket if still a problem with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 18:48:00 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 18:48:00 +0000 Subject: [openssl-dev] [openssl.org #1189] Bug Report and Patch : -subj option of the req command does not refer openssl.cnf to check the minimum and maximum limits of each field In-Reply-To: <20050818040823.82541.qmail@web51310.mail.yahoo.com> References: <20050818040823.82541.qmail@web51310.mail.yahoo.com> Message-ID: This is reported against 0.9.8; please open a new ticket if still a problem with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 18:49:07 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 18:49:07 +0000 Subject: [openssl-dev] [openssl.org #1234] Failing to load zlib.so results in other errors later. In-Reply-To: <20051101001333.GA22742@roeckx.be> References: <20051101001333.GA22742@roeckx.be> Message-ID: This is reported against 0.9.8; please open a new ticket if still a problem with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 18:49:41 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 18:49:41 +0000 Subject: [openssl-dev] [openssl.org #1244] changing TMP_D causes build to fail In-Reply-To: <11CFA5F21C19884E882246F39DBE4B1A0C149F38@SDCEXMB01.corp.siebel.com> References: <11CFA5F21C19884E882246F39DBE4B1A0C149F38@SDCEXMB01.corp.siebel.com> Message-ID: changing the directory is not supported. this is an old version. we are fixing things in the next release -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 18:50:27 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 18:50:27 +0000 Subject: [openssl-dev] [openssl.org #1292] SSL_add_dir_cert_subjects_to_stack does not check for read access of file, breaking TLS enabled LDAP clients In-Reply-To: <20060314153826.8D64CBBE2@smtp4.aerasec.de> References: <20060314153826.8D64CBBE2@smtp4.aerasec.de> Message-ID: This is reported against 0.9.8; please open a new ticket if still a problem with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 18:51:43 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 18:51:43 +0000 Subject: [openssl-dev] [openssl.org #1327] Bug in openssl/util/mkdef.pl (HEAD) In-Reply-To: <1904A73111EDD047A666323D5D3D7DE615D0BD@sdmail-01.divxnetworks.com> References: <1904A73111EDD047A666323D5D3D7DE615D0BD@sdmail-01.divxnetworks.com> Message-ID: This is reported against 0.9.8; please open a new ticket if still a problem with current releases. Also we're changing the build process for the next release as well. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 18:53:02 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 18:53:02 +0000 Subject: [openssl-dev] [openssl.org #1328] FW: (Repost) SSL_shutdown and SSL_free issues In-Reply-To: <4A6B67609D48464B88EDB4D2C81D2D7B444003@crunchymail.cfrog.local> References: <4A6B67609D48464B88EDB4D2C81D2D7B444003@crunchymail.cfrog.local> Message-ID: This is reported against 0.9.8; please open a new ticket if still a problem with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 18:53:25 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 18:53:25 +0000 Subject: [openssl-dev] [openssl.org #1365] PATCH: Adding IPv6 support to s_client and s_server In-Reply-To: <20060713085427.GC24844@relay.adelton.com> References: <20060713085427.GC24844@relay.adelton.com> Message-ID: This is reported against 0.9.8; please open a new ticket if still a problem with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 18:54:45 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 18:54:45 +0000 Subject: [openssl-dev] [openssl.org #1378] Contribution: twopipe patch for speed test In-Reply-To: <44EDAA5D.2060705@jan-o-sch.net> References: <44EDAA5D.2060705@jan-o-sch.net> Message-ID: This is reported against 0.9.8; please open a new ticket if still a problem with current releases. Also, spawning way more procseses than your system can handle isn't really openssl's fault :) -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 18:55:37 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 18:55:37 +0000 Subject: [openssl-dev] [openssl.org #1400] spurious CRs in S/MIME clearsigned mails In-Reply-To: <20061001082637.GA13194@nordnet.fr> References: <20061001082637.GA13194@nordnet.fr> Message-ID: This is reported against 0.9.8; please open a new ticket if still a problem with current releases. also not clear it was really an interop problem at all. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 18:56:19 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 18:56:19 +0000 Subject: [openssl-dev] [openssl.org #1424] Re: CRL update revision for X509_add_crl In-Reply-To: References: <8F5C067D-72CC-4F82-A029-C33B2DDA7EC0@u.washington.edu> Message-ID: It's been nearly 10 years, this isn't going to happen. If still desired please open a new ticket. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 18:57:21 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 18:57:21 +0000 Subject: [openssl-dev] [openssl.org #1444] Insufficient error reporting in openssl ca In-Reply-To: <20061225094034.GA1769@cryptocom.ru> References: <20061225094034.GA1769@cryptocom.ru> Message-ID: This is reported against 0.9.8; please open a new ticket if still a problem with current releases. also not enough information to reproduce the condition. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 18:58:10 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 18:58:10 +0000 Subject: [openssl-dev] [openssl.org #1449] [PATCH] Suspend and reinstate certificates in CA application In-Reply-To: References: Message-ID: It's been almost ten years, this is unlikely to happen. Please open a new ticket if still desired. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 18:59:27 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 18:59:27 +0000 Subject: [openssl-dev] [openssl.org #1470] [PATCH] fix some memory leaks in asn1 crypto In-Reply-To: <46690B497E6EBB478E2B8401DCBFFE7911D098@sjcexch01.corp.2wire.com> References: <46690B497E6EBB478E2B8401DCBFFE7911D098@sjcexch01.corp.2wire.com> Message-ID: This is reported against 0.9.8; please open a new ticket if still a problem with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 19:00:14 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 19:00:14 +0000 Subject: [openssl-dev] [openssl.org #1482] [PATCH] add "ciphertext stealing" support to the EVP library In-Reply-To: <8552a3bc0702072342v5d364daby44bde5d25111bd38@mail.gmail.com> References: <8552a3bc0702072342v5d364daby44bde5d25111bd38@mail.gmail.com> Message-ID: This is reported against 0.9.8; please open a new ticket if still a problem with current releases. It's been eight years, unlikely to happen with a new patch. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 19:00:53 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 19:00:53 +0000 Subject: [openssl-dev] [openssl.org #1491] [BUG][PATCH] malloc and friends returns not checked In-Reply-To: <20070221215751.GQ14234@shell> References: <20070221215751.GQ14234@shell> Message-ID: This is reported against 0.9.8; please open a new ticket if still a problem with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 19:01:20 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 19:01:20 +0000 Subject: [openssl-dev] [openssl.org #1497] Issue: PKCS#12 export with empty password produces incorrect encoding of MacData in PFX object In-Reply-To: <45E796FE.2070104@brainhub.org> References: <45E796FE.2070104@brainhub.org> Message-ID: This is reported against 0.9.8; please open a new ticket if still a problem with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 19:02:21 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 19:02:21 +0000 Subject: [openssl-dev] [openssl.org #1534] [Bug report] Verification fails caused by too many CA certs In-Reply-To: References: Message-ID: This is reported against 0.9.8; please open a new ticket if still a problem with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From kongd56 at gmail.com Mon Feb 1 19:03:12 2016 From: kongd56 at gmail.com (kong don) Date: Mon, 1 Feb 2016 11:03:12 -0800 Subject: [openssl-dev] (no subject) Message-ID: -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Mon Feb 1 19:05:46 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 19:05:46 +0000 Subject: [openssl-dev] [openssl.org #1584] INSTALL.W32 Configure prefix must be unix format directory delimeters In-Reply-To: <46F78E39.1060702@addis.org.uk> References: <46F78E39.1060702@addis.org.uk> Message-ID: This is reported against 0.9.8; please open a new ticket if still a problem with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 19:06:38 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 19:06:38 +0000 Subject: [openssl-dev] [openssl.org #1608] [BUG] SSL_get_error returns SSL_ERROR_SSL if read() returns -1 / EINTR In-Reply-To: <20071120163751.b2hkgv3ngooaezds@m.safari.iki.fi> References: <20071120163751.b2hkgv3ngooaezds@m.safari.iki.fi> Message-ID: This is reported against 0.9.8; please open a new ticket if still a problem with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 19:07:24 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 19:07:24 +0000 Subject: [openssl-dev] [openssl.org #1617] Bug report: RAND_poll problem on Solaris - select call failing In-Reply-To: <1E87A4B6BF42AF4EB428D5F69F29487B0137A025@esealmw105.eemea.ericsson.se> References: <1E87A4B6BF42AF4EB428D5F69F29487B0137A025@esealmw105.eemea.ericsson.se> Message-ID: This is reported against 0.9.8; please open a new ticket if still a problem with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 19:08:31 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 19:08:31 +0000 Subject: [openssl-dev] [openssl.org #1642] patch purify errors In-Reply-To: <47B37D90.9050306@cryptsoft.com> References: <47B37D90.9050306@cryptsoft.com> Message-ID: Dear Mr Hudson, This is reported against 0.9.8; please open a new ticket if still a problem with current releases. On the other hand, since you're a member of the dev team... fix it yourself :) -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 19:09:10 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 19:09:10 +0000 Subject: [openssl-dev] [openssl.org #1656] Clients compiled with tls extention can't talk to some servers. In-Reply-To: <20080323171226.GA22111@roeckx.be> References: <20080323171226.GA22111@roeckx.be> Message-ID: Kurt, I assume this isn't an issue or you would have fixed it :) This is reported against 0.9.8; please open a new ticket if still a problem with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 19:09:33 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 19:09:33 +0000 Subject: [openssl-dev] [openssl.org #1670] SSL_CTX_load_verify_locations() fails without error with invalid files In-Reply-To: <1210190049.9518.363.camel@hurina> References: <1210190049.9518.363.camel@hurina> Message-ID: This is reported against 0.9.8; please open a new ticket if still a problem with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From kongd56 at gmail.com Mon Feb 1 19:09:45 2016 From: kongd56 at gmail.com (kong don) Date: Mon, 1 Feb 2016 11:09:45 -0800 Subject: [openssl-dev] (no subject) Message-ID: -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Mon Feb 1 19:10:31 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 19:10:31 +0000 Subject: [openssl-dev] [openssl.org #1682] BIO_snprintf can NOT work properly on HPUX 11.23 IA for 32bits mode In-Reply-To: References: Message-ID: Andy, I assume you're not going to fix this or it's no longer a problem. This is reported against 0.9.8; please open a new ticket if still a problem with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 19:10:49 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 19:10:49 +0000 Subject: [openssl-dev] [openssl.org #1729] Bug in add_cert_dir - crypto/x905/by_dir.c In-Reply-To: References: Message-ID: This is reported against 0.9.8; please open a new ticket if still a problem with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 19:12:46 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 19:12:46 +0000 Subject: [openssl-dev] [openssl.org #1802] Bug report: Persistent memory leak that cannot be freed In-Reply-To: <31f8ea450812221332k448aa521pca4b889d96b6826d@mail.gmail.com> References: <31f8ea450812221332k448aa521pca4b889d96b6826d@mail.gmail.com> Message-ID: This is reported against 0.9.8; please open a new ticket if still a problem with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From onicrypt at gmail.com Mon Feb 1 19:12:48 2016 From: onicrypt at gmail.com (Nich Ramsey) Date: Mon, 1 Feb 2016 11:12:48 -0800 Subject: [openssl-dev] [openssl.org #1682] BIO_snprintf can NOT work properly on HPUX 11.23 IA for 32bits mode In-Reply-To: References: Message-ID: I'm continually getting repeat messages and messages with no text body. So annoying, please make it stop!! On Feb 1, 2016 11:10 AM, "Rich Salz via RT" wrote: > Andy, I assume you're not going to fix this or it's no longer a problem. > > This is reported against 0.9.8; please open a new ticket if still a problem > with current releases. > -- > Rich Salz, OpenSSL dev team; rsalz at openssl.org > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Mon Feb 1 19:12:52 2016 From: rt at openssl.org (Nich Ramsey via RT) Date: Mon, 01 Feb 2016 19:12:52 +0000 Subject: [openssl-dev] [openssl.org #1682] BIO_snprintf can NOT work properly on HPUX 11.23 IA for 32bits mode In-Reply-To: References: Message-ID: I'm continually getting repeat messages and messages with no text body. So annoying, please make it stop!! On Feb 1, 2016 11:10 AM, "Rich Salz via RT" wrote: > Andy, I assume you're not going to fix this or it's no longer a problem. > > This is reported against 0.9.8; please open a new ticket if still a problem > with current releases. > -- > Rich Salz, OpenSSL dev team; rsalz at openssl.org > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > From rt at openssl.org Mon Feb 1 19:13:17 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 19:13:17 +0000 Subject: [openssl-dev] [openssl.org #1808] enc(1) Salt option: -S In-Reply-To: <20090106173925.2r6ccqyds88wkc44@webmail.versatel.nl> References: <20090106173925.2r6ccqyds88wkc44@webmail.versatel.nl> Message-ID: -- Rich Salz, OpenSSL dev team; rsalz at openssl.org This is reported against 0.9.8; please open a new ticket if still a problem with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rsalz at akamai.com Mon Feb 1 19:14:56 2016 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 1 Feb 2016 19:14:56 +0000 Subject: [openssl-dev] [openssl.org #1682] BIO_snprintf can NOT work properly on HPUX 11.23 IA for 32bits mode In-Reply-To: References: Message-ID: <771c166256b14b789991b53780291c69@usma1ex-dag1mb1.msg.corp.akamai.com> But you ARE getting messages. You quoted it below. ? Sorry for the flurry of bug activity. We?re cleaning up ticket list. -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz From: Nich Ramsey [mailto:onicrypt at gmail.com] Sent: Monday, February 01, 2016 2:13 PM To: rt at openssl.org; openssl-dev at openssl.org Subject: Re: [openssl-dev] [openssl.org #1682] BIO_snprintf can NOT work properly on HPUX 11.23 IA for 32bits mode I'm continually getting repeat messages and messages with no text body. So annoying, please make it stop!! On Feb 1, 2016 11:10 AM, "Rich Salz via RT" > wrote: Andy, I assume you're not going to fix this or it's no longer a problem. This is reported against 0.9.8; please open a new ticket if still a problem with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From kongd56 at gmail.com Mon Feb 1 19:15:41 2016 From: kongd56 at gmail.com (kong don) Date: Mon, 1 Feb 2016 11:15:41 -0800 Subject: [openssl-dev] (no subject) Message-ID: -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Mon Feb 1 19:16:07 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 19:16:07 +0000 Subject: [openssl-dev] [openssl.org #1816] bug in DES_xcbc_encrypt() for decrypting 8 bytes of input (?) In-Reply-To: <561cc61d0901111935k29ee85c6wf0aaadc967fa83a8@mail.gmail.com> References: <561cc61d0901111935k29ee85c6wf0aaadc967fa83a8@mail.gmail.com> Message-ID: This is reported against 0.9.x; please open a new ticket if still a problem with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 19:16:52 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 19:16:52 +0000 Subject: [openssl-dev] [openssl.org #1832] PATCH: force IPv4/IPv6 for s_client In-Reply-To: References: Message-ID: openssl 1.1 will have full ipv6 support. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 19:17:42 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 19:17:42 +0000 Subject: [openssl-dev] [openssl.org #1848] Bug found in BN_is_prime_fasttest_ex( ) In-Reply-To: <2925D8E6BC464F5D99A3A51D43B2254E@D76MK421> References: <2925D8E6BC464F5D99A3A51D43B2254E@D76MK421> Message-ID: This is reported against 0.9.x; please open a new ticket if still a problem with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 19:18:04 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 19:18:04 +0000 Subject: [openssl-dev] [openssl.org #1852] [BUG] Invalid Proxy Certificates Pass Validation In-Reply-To: <49A81357.30509@switch.ch> References: <49A81357.30509@switch.ch> Message-ID: This is reported against 0.9.x; please open a new ticket if still a problem with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From onicrypt at gmail.com Mon Feb 1 19:19:44 2016 From: onicrypt at gmail.com (Nich Ramsey) Date: Mon, 1 Feb 2016 11:19:44 -0800 Subject: [openssl-dev] [openssl.org #1682] BIO_snprintf can NOT work properly on HPUX 11.23 IA for 32bits mode In-Reply-To: <771c166256b14b789991b53780291c69@usma1ex-dag1mb1.msg.corp.akamai.com> References: <771c166256b14b789991b53780291c69@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: Haha yeah I AM getting messages, a whole fuckton of them. I'll try to ignore the flurry, I know you guys just had a new release. Outside of this small annoyance, keep up the awesome work, I love what you soon are doing!! On Feb 1, 2016 11:15 AM, "Salz, Rich" wrote: > But you ARE getting messages. You quoted it below. J > > > > Sorry for the flurry of bug activity. We?re cleaning up ticket list. > > > > -- > > Senior Architect, Akamai Technologies > > IM: richsalz at jabber.at Twitter: RichSalz > > > > *From:* Nich Ramsey [mailto:onicrypt at gmail.com] > *Sent:* Monday, February 01, 2016 2:13 PM > *To:* rt at openssl.org; openssl-dev at openssl.org > *Subject:* Re: [openssl-dev] [openssl.org #1682] BIO_snprintf can NOT > work properly on HPUX 11.23 IA for 32bits mode > > > > I'm continually getting repeat messages and messages with no text body. So > annoying, please make it stop!! > > On Feb 1, 2016 11:10 AM, "Rich Salz via RT" wrote: > > Andy, I assume you're not going to fix this or it's no longer a problem. > > This is reported against 0.9.8; please open a new ticket if still a problem > with current releases. > -- > Rich Salz, OpenSSL dev team; rsalz at openssl.org > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Mon Feb 1 19:21:03 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 19:21:03 +0000 Subject: [openssl-dev] [openssl.org #2018] BUG: rsautl reports "RSA operation error" when decryption output is empty In-Reply-To: <592936F6-B1F8-4B11-A6F6-8945B9354879@trusteer.com> References: <592936F6-B1F8-4B11-A6F6-8945B9354879@trusteer.com> Message-ID: This is reported against 0.9.x; please open a new ticket if still a problem with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 19:22:06 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 19:22:06 +0000 Subject: [openssl-dev] [openssl.org #2185] security vulnerability fixed In-Reply-To: <6E9EAF9B-CEA8-4EA5-B7B7-3530BF8864BF@steinmetz.org> References: <6E9EAF9B-CEA8-4EA5-B7B7-3530BF8864BF@steinmetz.org> Message-ID: This is reported against 0.9.x; please open a new ticket if still a problem with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 19:22:24 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 19:22:24 +0000 Subject: [openssl-dev] [openssl.org #2201] 1.0 beta5, Solaris cc compile options In-Reply-To: References: Message-ID: This is reported against 0.9.x; please open a new ticket if still a problem with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 19:23:36 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 19:23:36 +0000 Subject: [openssl-dev] [openssl.org #2298] Build failure on WinCE platform openssl-1.0.0 & 1.0.0a In-Reply-To: <4926CAF6.8090109@nokia.com> References: <4926CAF6.8090109@nokia.com> Message-ID: This is reported against 0.9.x; please open a new ticket if still a problem with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 19:24:14 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 19:24:14 +0000 Subject: [openssl-dev] [openssl.org #2303] BUG: rc5_skey.c:122: error: unsupported inline asm while trying to compile with llvm-2.7 In-Reply-To: References: Message-ID: This is reported against 0.9.x and/or 1.0.0; please open a new ticket if still a problem with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 19:27:48 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 19:27:48 +0000 Subject: [openssl-dev] [openssl.org #2361] win32: non-blocking BIO_do_connect() returns wrong value In-Reply-To: <20101019181301.GD35796@shatter.hsd1.ma.comcast.net> References: <20101019181301.GD35796@shatter.hsd1.ma.comcast.net> Message-ID: as andy said, the work-around is really the right thing to do. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 19:28:07 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 19:28:07 +0000 Subject: [openssl-dev] [openssl.org #2362] Bug report In-Reply-To: References: Message-ID: This is reported against 0.9.x and/or 1.0.0; please open a new ticket if still a problem with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 19:28:51 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 19:28:51 +0000 Subject: [openssl-dev] [openssl.org #2392] Haiku patch for openssl-1.0.0c In-Reply-To: References: Message-ID: This is reported against 0.9.x and/or 1.0.0; please open a new ticket if still a problem with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 19:30:30 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 19:30:30 +0000 Subject: [openssl-dev] [openssl.org #2417] [Enhancement] X509 verification with OCSP support In-Reply-To: References: Message-ID: Thnanks for the patch. Sorry it took so long to reply, but its' been five years and having the openssl runtime connect out to servers (ocsp even) is not supported. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 19:31:02 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 19:31:02 +0000 Subject: [openssl-dev] [openssl.org #2420] patch enabling OpenSSL to be built with LSB compilers In-Reply-To: References: Message-ID: This is reported against 0.9.x and/or 1.0.0; please open a new ticket if still a problem with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 19:31:18 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 19:31:18 +0000 Subject: [openssl-dev] [openssl.org #2437] [PATCH] config on aix assumes cc is not gcc, can cause build to fail In-Reply-To: References: Message-ID: This is reported against 0.9.x and/or 1.0.0; please open a new ticket if still a problem with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 19:32:52 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 19:32:52 +0000 Subject: [openssl-dev] [openssl.org #2500] [bug-report] Configure with shared option on BSD systems In-Reply-To: References: Message-ID: This is reported against 0.9.x and/or 1.0.0; please open a new ticket if still a problem with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 19:33:23 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 19:33:23 +0000 Subject: [openssl-dev] [openssl.org #2512] [PATCH] Fix for BIO_new_accept() In-Reply-To: <3CC40DCA-561A-4737-B4F1-B73EDCE718B8@fh-muenster.de> References: <3CC40DCA-561A-4737-B4F1-B73EDCE718B8@fh-muenster.de> Message-ID: ipv6 support will be in openssl 1.1 -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 19:34:33 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 19:34:33 +0000 Subject: [openssl-dev] [openssl.org #2597] bug report (pkcs12.c) In-Reply-To: References: Message-ID: This is reported against 0.9.x and/or 1.0.0; please open a new ticket if still a problem with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 19:35:40 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 19:35:40 +0000 Subject: [openssl-dev] [openssl.org #2610] Bug(?): both the "!SSLv3" and the "!TLSv1" cipher strings seem to mutually delete the ciphersuites from the other set as well In-Reply-To: <4E78C763.80702@muzso.hu> References: <4E78C763.80702@muzso.hu> Message-ID: Not a bug. It's when the ciphers were first defined, not the name of them. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 19:35:56 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 19:35:56 +0000 Subject: [openssl-dev] [openssl.org #2615] BIO_flush segmentation fault with SSL BIO In-Reply-To: <4E7CB9C9.40908@systech.com> References: <4E7CB9C9.40908@systech.com> Message-ID: This is reported against 0.9.x and/or 1.0.0; please open a new ticket if still a problem with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 19:36:37 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 19:36:37 +0000 Subject: [openssl-dev] [openssl.org #2631] Incompatibility with iOS 5 ? In-Reply-To: <4EA672E8.7080508@msgid.danisch.de> References: <4EA672E8.7080508@msgid.danisch.de> Message-ID: This is reported against 0.9.x and/or 1.0.0; please open a new ticket if still a problem with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 19:38:21 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 19:38:21 +0000 Subject: [openssl-dev] [openssl.org #2692] [OpenSSL 1.0.1 beta 2] SHLIB_VERSION_NUMBER In-Reply-To: References: Message-ID: the version number is not being changed. in 1.1 things "get better" -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 19:38:50 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 19:38:50 +0000 Subject: [openssl-dev] [openssl.org #2699] openssl dgst -sha1 -verify ... sais verification failure whet it is ok in a concrete set of data In-Reply-To: References: Message-ID: This is reported against 0.9.x and/or 1.0.0; please open a new ticket if still a problem with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 19:39:16 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 19:39:16 +0000 Subject: [openssl-dev] [openssl.org #2718] openssl-fips-1.2.3: testsuite failures (SIGILL / Illegal instruction) In-Reply-To: <1329098754.2149.13.camel@vortex> References: <1329098754.2149.13.camel@vortex> Message-ID: This is reported against 0.9.x and/or 1.0.0; please open a new ticket if still a problem with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 19:40:51 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 19:40:51 +0000 Subject: [openssl-dev] [openssl.org #2768] Bug: internal_verify() hides errors from callbacks after X509_V_ERR_UNABLE_TO_VERIFY_LEAF_SIGNATURE In-Reply-To: <4F68E7F6.7080305@measurement-factory.com> References: <4F68E7F6.7080305@measurement-factory.com> Message-ID: there does not seem to be anything for openssl to do here. also the verify_chain code is changigng a lot in 1.1 -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 19:42:19 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 19:42:19 +0000 Subject: [openssl-dev] [openssl.org #2824] Bug ? - Not Thread-safety for SSL Key usage im requests ? In-Reply-To: References: Message-ID: The objects are not MT-safe. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 19:45:59 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 19:45:59 +0000 Subject: [openssl-dev] [openssl.org #2944] PVS-Studio and OpenSSL In-Reply-To: <50CEF1F6.3000200@viva64.com> References: <50CEF1F6.3000200@viva64.com> Message-ID: This is reported against 0.9.x and/or 1.0.0; please open a new ticket if still a problem with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 19:47:42 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 19:47:42 +0000 Subject: [openssl-dev] [openssl.org #2960] protocol bug in s2_pkt.c In-Reply-To: <1f030eb6-3159-4d4e-ae86-8e939e15c62b@bhv.softing.com> References: <1f030eb6-3159-4d4e-ae86-8e939e15c62b@bhv.softing.com> Message-ID: SSLv2 is no longer supported. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 19:49:49 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 19:49:49 +0000 Subject: [openssl-dev] [openssl.org #3028] PEM_X509_INFO_read_bio() fails to process RSA private key if in initial position (regression in OpenSSL 1.0.0 and later) In-Reply-To: <51592F88.7040300@velox.ch> References: <51592F88.7040300@velox.ch> Message-ID: clmments in the ticket indicate this has been fixed. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 19:50:43 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 19:50:43 +0000 Subject: [openssl-dev] [openssl.org #3072] Strange behaviour when talking to microsoft exchange In-Reply-To: <20130612184354.GA4998@roeckx.be> References: <20130612184354.GA4998@roeckx.be> Message-ID: protocol limit in MSFT TLS implementation, not an openssl bug. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 19:52:03 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 19:52:03 +0000 Subject: [openssl-dev] [openssl.org #3155] Bug report: S/MIME base64 decoding fails on files that have 76 base64 characters per line In-Reply-To: References: Message-ID: We believe this is fixed, please re-open the ticket if not. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 19:54:49 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 19:54:49 +0000 Subject: [openssl-dev] [openssl.org #3915] BUG/PATCH: ssl_sess.c no longer compiles when no-tlsext is specified In-Reply-To: <28a8d7a0c911455c9b1e255dca52a2fa@MIVEXUSR1N01.corpzone.internalzone.com> References: <28a8d7a0c911455c9b1e255dca52a2fa@MIVEXUSR1N01.corpzone.internalzone.com> Message-ID: old unsupported release, and unsupportd build option. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 19:59:45 2016 From: rt at openssl.org (Jun Sun via RT) Date: Mon, 01 Feb 2016 19:59:45 +0000 Subject: [openssl-dev] [openssl.org #4284] Bug in nistz256 assembly code. In-Reply-To: References: Message-ID: Hi openssl team, In function ecp_nistz256_point_add (in ecp_nistz256.c), in the case when U1 == U2 and S1 == S2, in C reference code, the logic is call ecp_nistz256_point_double (line 339) to do a point double operation: 337 if (is_equal(U1, U2) && !in1infty && !in2infty) { 338 if (is_equal(S1, S2)) { 339 ecp_nistz256_point_double(r, a); 340 return; 341 } else { 342 memset(r, 0, sizeof(*r)); 343 return; 344 } 345 } This is correct and follow what is described in S.Gueron and V.Krasnov's paper. But in x86_64 assembly code (ecp_nistz256-x86_64.pl), this logic is not implemented, it fall back to point adding code again: 2385 .byte 0x3e # predict taken 2386 jnz .Ladd_proceed$x # is_equal(U1,U2)? 2387 movq %xmm2, $acc0 2388 movq %xmm3, $acc1 2389 test $acc0, $acc0 2390 jnz .Ladd_proceed$x # (in1infty || in2infty)? 2391 test $acc1, $acc1 2392 jz .Ladd_proceed$x # is_equal(S1,S2)? The difference be seen in the latest ectest.c for the group order tests, even though both C code and assembly code does not generate any error, but they generate different values: 201 scalars[0] = n1; 202 points[0] = Q; /* => infinity */ 203 scalars[1] = n2; 204 points[1] = P; /* => -P */ 205 scalars[2] = n1; 206 points[2] = Q; /* => infinity */ 207 scalars[3] = n2; 208 points[3] = Q; /* => infinity */ 209 scalars[4] = n1; 210 points[4] = P; /* => P */ 211 scalars[5] = n2; 212 points[5] = Q; /* => infinity */ 213 if (!EC_POINTs_mul(group, P, NULL, 6, points, scalars, ctx)) 214 ABORT; 215 if (!EC_POINT_is_at_infinity(group, P)) 216 ABORT; P is holding different values between C reference C code and assembly code. This should not happen if the point doubling function is called in assembly code as well. Jun Sun This email and any attachments are for the sole use of the intended recipients and may be privileged or confidential. Any distribution, printing or other use by anyone else is prohibited. If you are not an intended recipient, please contact the sender immediately, and permanently delete this email and attachments. From rt at openssl.org Mon Feb 1 20:31:18 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 20:31:18 +0000 Subject: [openssl-dev] [openssl.org #3420] Magic constants in SSL_CTX_set_tlsext_ticket_key_cb() and .pod In-Reply-To: References: Message-ID: 16 is the defined size (RFC 5077) so closing this. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 20:34:44 2016 From: rt at openssl.org (Alex Rousskov via RT) Date: Mon, 01 Feb 2016 20:34:44 +0000 Subject: [openssl-dev] [openssl.org #2768] Bug: internal_verify() hides errors from callbacks after X509_V_ERR_UNABLE_TO_VERIFY_LEAF_SIGNATURE In-Reply-To: <56AFBFC9.7020305@measurement-factory.com> References: <4F68E7F6.7080305@measurement-factory.com> <56AFBFC9.7020305@measurement-factory.com> Message-ID: On 02/01/2016 12:40 PM, Rich Salz via RT wrote: > there does not seem to be anything for openssl to do here. OpenSSL can do one of these two things (at least): * Start reporting post-X509_V_ERR_UNABLE_TO_VERIFY_LEAF_SIGNATURE errors to callbacks [instead of hiding them]. * Adjust SSL_CTX_set_verify documentation to indicate that no errors are reported to callbacks after X509_V_ERR_UNABLE_TO_VERIFY_LEAF_SIGNATURE [instead of saying that all errors are reported]. > also the verify_chain code is changigng a lot in 1.1 I hope this problem will be taken into consideration during the rewrite. Thank you, Alex. From loganaden at gmail.com Mon Feb 1 20:36:36 2016 From: loganaden at gmail.com (Loganaden Velvindron) Date: Mon, 1 Feb 2016 20:36:36 +0000 Subject: [openssl-dev] Fwd: latest OpenSSL causes OpenSMTPD to segv In-Reply-To: <20160201201035.GA30500@poolp.org> References: <20160201201035.GA30500@poolp.org> Message-ID: Hi guys, Any place where this API change is documented ? It would be nice if each release came with a list of API changes. ---------- Forwarded message ---------- From: Gilles Chehade Date: Mon, Feb 1, 2016 at 8:10 PM Subject: latest OpenSSL causes OpenSMTPD to segv To: misc at opensmtpd.org Hi, It seems that the OpenSSL guys have managed to slip an API change inside their latest "patchlevel" release and this unsurprisingly breaks our RSA engine... This impact all users who upgrade to OpenSSL 1.0.2f and will cause smtpd to crash as soon as the RSA engine is used (ie: whenever there's crypto) A quick workaround is to not upgrade to 1.0.2f yet and maybe ask OpenSSL why a "patchlevel" release contains more than patches. Meanwhile, we're investigating how we're going to unfuck this. -- Gilles Chehade https://www.poolp.org @poolpOrg -- You received this mail because you are subscribed to misc at opensmtpd.org To unsubscribe, send a mail to: misc+unsubscribe at opensmtpd.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Mon Feb 1 20:49:01 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 20:49:01 +0000 Subject: [openssl-dev] [openssl.org #3663] [PATCH] clarify 'verify' command operation In-Reply-To: <1421395664-8660-1-git-send-email-awilliam@redhat.com> References: <1421395664-8660-1-git-send-email-awilliam@redhat.com> Message-ID: fixed in master by viktor -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rsalz at akamai.com Mon Feb 1 20:56:16 2016 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 1 Feb 2016 20:56:16 +0000 Subject: [openssl-dev] Fwd: latest OpenSSL causes OpenSMTPD to segv In-Reply-To: References: <20160201201035.GA30500@poolp.org> Message-ID: <9a22f87f39a149d699f2e597be816865@usma1ex-dag1mb1.msg.corp.akamai.com> > This impact all users who upgrade to OpenSSL 1.0.2f and will cause smtpd > to crash as soon as the RSA engine is used (ie: whenever there's crypto) It would be interesting to see what they think was wrong. Our intent is to NOT change API's across letter releases. From rt at openssl.org Mon Feb 1 20:56:28 2016 From: rt at openssl.org (Timo Sirainen via RT) Date: Mon, 01 Feb 2016 20:56:28 +0000 Subject: [openssl-dev] [openssl.org #4285] SSL_CTX_load_verify_locations() fails without error with invalid files In-Reply-To: <01CDF0AB-B090-41FA-8047-56E7433128F0@iki.fi> References: <01CDF0AB-B090-41FA-8047-56E7433128F0@iki.fi> Message-ID: If loaded file isn't valid, SSL_CTX_load_verify_locations() returns 0, but ERR_get_error() reports 0. Debian unstable Version: 1.0.2f-2 Example: // create "empty-file" by e.g. touching it (or containing whatever garbage) #include #include int main(void) { SSL_CTX *ssl_ctx; SSL_library_init(); SSL_load_error_strings(); ssl_ctx = SSL_CTX_new(SSLv23_server_method()); if (!SSL_CTX_load_verify_locations(ssl_ctx, "empty-file", NULL)) { printf("error = %lu\n", ERR_get_error()); } return 0; } From levitte at openssl.org Mon Feb 1 21:08:23 2016 From: levitte at openssl.org (Richard Levitte) Date: Mon, 01 Feb 2016 22:08:23 +0100 (CET) Subject: [openssl-dev] openssl-1.1.0-pre2 make failure with perl-5.8.8 on Linux In-Reply-To: References: Message-ID: <20160201.220823.1777750271705855500.levitte@openssl.org> In message on Tue, 2 Feb 2016 00:04:57 +0530, J Mohan Rao Arisankala said: mohan> I have a development environment, which uses a very old perl version mohan> (5.8.8). That is a very old perl indeed. That particular issue has been fixed. However, with such an old perl version, you might end up in more trouble when testing... nothing that can't be fixed with a CPAN install, but... Is that something that we need to talk about? Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From rt at openssl.org Mon Feb 1 21:13:26 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 21:13:26 +0000 Subject: [openssl-dev] [openssl.org #4211] Document Perl requirements for OpenSSL 1.1.0 In-Reply-To: <56855038.4000105@kippdata.de> References: <56855038.4000105@kippdata.de> Message-ID: Fixed, please see README.PERL now. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From levitte at openssl.org Mon Feb 1 21:18:05 2016 From: levitte at openssl.org (Richard Levitte) Date: Mon, 01 Feb 2016 22:18:05 +0100 (CET) Subject: [openssl-dev] [openssl.org #1682] BIO_snprintf can NOT work properly on HPUX 11.23 IA for 32bits mode In-Reply-To: <771c166256b14b789991b53780291c69@usma1ex-dag1mb1.msg.corp.akamai.com> References: <771c166256b14b789991b53780291c69@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <20160201.221805.586286261654828528.levitte@openssl.org> Could it be the empty message from kong don ? I'm seeing them too, that subscription is going. 3... 2... 1... gone In message <771c166256b14b789991b53780291c69 at usma1ex-dag1mb1.msg.corp.akamai.com> on Mon, 1 Feb 2016 19:14:56 +0000, "Salz, Rich" said: rsalz> But you ARE getting messages. You quoted it below. J rsalz> rsalz> Sorry for the flurry of bug activity. We?re cleaning up ticket list. rsalz> rsalz> -- rsalz> rsalz> Senior Architect, Akamai Technologies rsalz> rsalz> IM: richsalz at jabber.at Twitter: RichSalz rsalz> rsalz> From: Nich Ramsey [mailto:onicrypt at gmail.com] rsalz> Sent: Monday, February 01, 2016 2:13 PM rsalz> To: rt at openssl.org; openssl-dev at openssl.org rsalz> Subject: Re: [openssl-dev] [openssl.org #1682] BIO_snprintf can NOT rsalz> work properly on HPUX 11.23 IA for 32bits mode rsalz> rsalz> I'm continually getting repeat messages and messages with no text rsalz> body. So annoying, please make it stop!! rsalz> rsalz> On Feb 1, 2016 11:10 AM, "Rich Salz via RT" wrote: rsalz> rsalz> Andy, I assume you're not going to fix this or it's no longer a rsalz> problem. rsalz> rsalz> This is reported against 0.9.8; please open a new ticket if still a rsalz> problem rsalz> with current releases. rsalz> -- rsalz> Rich Salz, OpenSSL dev team; rsalz at openssl.org rsalz> rsalz> _______________________________________________ rsalz> openssl-dev mailing list rsalz> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev rsalz> From rt at openssl.org Mon Feb 1 21:28:59 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 21:28:59 +0000 Subject: [openssl-dev] [openssl.org #2108] [PATCH] Message digest functions In-Reply-To: <1258681894.3441.55.camel@tesla.lan> References: <1258681894.3441.55.camel@tesla.lan> Message-ID: The conditional compiliation is correct. The manpages are now "generic" -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 21:29:54 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 21:29:54 +0000 Subject: [openssl-dev] [openssl.org #2232] OpenSSL 1.0.0 - Mac OS X Univesal Binary Build Link errors In-Reply-To: <562333929.5189171270944674155.JavaMail.root@spooler9-g27.priv.proxad.net> References: <1619910882.5189111270944529875.JavaMail.root@spooler9-g27.priv.proxad.net> <562333929.5189171270944674155.JavaMail.root@spooler9-g27.priv.proxad.net> Message-ID: This is an issue reported against 0.9.x/1.0.0 If still an issue with current release, please open a new ticket. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 21:31:52 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 21:31:52 +0000 Subject: [openssl-dev] [openssl.org #2357] openssl-1.0.0a -- PATCH for 'make -n install' In-Reply-To: References: Message-ID: If still an issue with the current release please open a new ticket. We are rewriting the make system for 1.1. From openssl-users at dukhovni.org Mon Feb 1 21:31:57 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 1 Feb 2016 21:31:57 +0000 Subject: [openssl-dev] [openssl.org #2768] Bug: internal_verify() hides errors from callbacks after X509_V_ERR_UNABLE_TO_VERIFY_LEAF_SIGNATURE In-Reply-To: References: <4F68E7F6.7080305@measurement-factory.com> <56AFBFC9.7020305@measurement-factory.com> Message-ID: <20160201213157.GA4987@mournblade.imrryr.org> On Mon, Feb 01, 2016 at 08:34:44PM +0000, Alex Rousskov via RT wrote: > On 02/01/2016 12:40 PM, Rich Salz via RT wrote: > > there does not seem to be anything for openssl to do here. > > OpenSSL can do one of these two things (at least): > > * Start reporting post-X509_V_ERR_UNABLE_TO_VERIFY_LEAF_SIGNATURE errors > to callbacks [instead of hiding them]. This error is only reported when the chain contains exactly one certificate that is not self-issued. It is hard to see what other errors you might hope to see reported, since there's nothing else in the chain. The error is reported late in chain construction, when all other errors have been reported, so it is naturally the last one reported. > * Adjust SSL_CTX_set_verify documentation to indicate that no errors are > reported to callbacks after X509_V_ERR_UNABLE_TO_VERIFY_LEAF_SIGNATURE > [instead of saying that all errors are reported]. All errors were reported. > > also the verify_chain code is changigng a lot in 1.1 > > I hope this problem will be taken into consideration during the rewrite. Please be more explicit about what errors you feel were not reported. -- Viktor. From rt at openssl.org Mon Feb 1 21:32:34 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 21:32:34 +0000 Subject: [openssl-dev] [openssl.org #2349] build problems with 1.0.0a windows 64 bit AMD In-Reply-To: References: Message-ID: This is an issue reported against 0.9.x/1.0.0 If still an issue with current release, please open a new ticket. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 21:32:58 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 21:32:58 +0000 Subject: [openssl-dev] [openssl.org #2348] OpenSSL doesn't work with Linksys WRT54G In-Reply-To: <4C9CFC14.2030508@sgi.com> References: <4C9CFC14.2030508@sgi.com> Message-ID: This is an issue reported against 0.9.x/1.0.0 If still an issue with current release, please open a new ticket. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 21:33:36 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 21:33:36 +0000 Subject: [openssl-dev] [openssl.org #2316] Build issue on Tru64 (Dl_info must specify a type) In-Reply-To: References: Message-ID: This is an issue reported against 0.9.x/1.0.0 If still an issue with current release, please open a new ticket. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 21:35:45 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 21:35:45 +0000 Subject: [openssl-dev] [openssl.org #2242] Win64 build enhancements In-Reply-To: References: Message-ID: This is an issue reported against 0.9.x/1.0.0 If still an issue with current release, please open a new ticket. Also, we are going to have a new build system for 1.1 -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 21:38:31 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 21:38:31 +0000 Subject: [openssl-dev] [openssl.org #2317] Whitespace bug in ./config for Openssl 1.0.0a (OS X 10.6.4) In-Reply-To: References: Message-ID: This is an issue reported against 0.9.x/1.0.0 If still an issue with current release, please open a new ticket. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 21:40:38 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 21:40:38 +0000 Subject: [openssl-dev] [openssl.org #2384] [PATCH] no-hw Install Fail In-Reply-To: <260646.47890.qm@web52002.mail.re2.yahoo.com> References: <260646.47890.qm@web52002.mail.re2.yahoo.com> Message-ID: This is an issue reported against 0.9.x/1.0.0 If still an issue with current release, please open a new ticket. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 21:41:03 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 21:41:03 +0000 Subject: [openssl-dev] [openssl.org #2398] [PATCH] gost code cleanup In-Reply-To: <20101216013454.B27337EC3F3@drugs.dv.isc.org> References: <20101216013454.B27337EC3F3@drugs.dv.isc.org> Message-ID: GOST is now a separately-maintained engine. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 21:41:41 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 21:41:41 +0000 Subject: [openssl-dev] [openssl.org #2414] [critical bug]openssl1.0.0c coredump, if compile option "shared" is enabled In-Reply-To: <00f801cba025$aab083c0$3201080a@array261dc498d> References: <00f801cba025$aab083c0$3201080a@array261dc498d> Message-ID: This is an issue reported against 0.9.x/1.0.0 If still an issue with current release, please open a new ticket. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 21:42:30 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 21:42:30 +0000 Subject: [openssl-dev] [openssl.org #2445] openssl-1.0.0c loses base64 data if newline missing In-Reply-To: <20110202135830.6db9ff6b@pkts.ca> References: <20110202135830.6db9ff6b@pkts.ca> Message-ID: This is an issue reported against 0.9.x/1.0.0 If still an issue with current release, please open a new ticket. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 21:43:20 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 21:43:20 +0000 Subject: [openssl-dev] [openssl.org #2450] bug report: open ssl configuration problem with "no-idea" In-Reply-To: <915FE6C0089CF44798917A819C38AC4B01838220B3D8@HOLLYCLUSTER.windows.tees.ac.uk> References: <915FE6C0089CF44798917A819C38AC4B01838220B3D8@HOLLYCLUSTER.windows.tees.ac.uk> Message-ID: This is an issue reported against 0.9.x/1.0.0 If still an issue with current release, please open a new ticket. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 21:44:43 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 21:44:43 +0000 Subject: [openssl-dev] [openssl.org #2479] Fix for runtime exception when linking against win64a static libraries In-Reply-To: <4D8AA816.5090201@gmail.com> References: <4D8AA816.5090201@gmail.com> Message-ID: This is an issue reported against 0.9.x/1.0.0 If still an issue with current release, please open a new ticket. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 21:45:09 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 21:45:09 +0000 Subject: [openssl-dev] [openssl.org #2494] [SEC FIX]: Add premaster cleaning for GOST ciphersuites: All platforms, 1.0.0d In-Reply-To: References: Message-ID: GOST is now a separately maintained engine. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 21:46:07 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 21:46:07 +0000 Subject: [openssl-dev] [openssl.org #2498] [PATCH] iOS Support In-Reply-To: References: Message-ID: This is an issue reported against 0.9.x/1.0.0 If still an issue with current release, please open a new ticket. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 21:47:17 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 21:47:17 +0000 Subject: [openssl-dev] [openssl.org #2520] Bug Report In-Reply-To: <382092.27363.qm@web110505.mail.gq1.yahoo.com> References: <382092.27363.qm@web110505.mail.gq1.yahoo.com> Message-ID: we only distribute source, not binaries. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 21:49:08 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 21:49:08 +0000 Subject: [openssl-dev] [openssl.org #2545] Openssl-1.0.0d fails to install on MacBook Air In-Reply-To: References: Message-ID: This is an issue reported against 0.9.x/1.0.0 If still an issue with current release, please open a new ticket. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 21:52:21 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 21:52:21 +0000 Subject: [openssl-dev] [openssl.org #2581] bug: Why do these 12 lines of Win32 code work on XP but hang forever in Vista and Windows 7? In-Reply-To: References: Message-ID: Old release, but also poitns to a possible firewall in the way. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 21:52:55 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 21:52:55 +0000 Subject: [openssl-dev] [openssl.org #2583] confusing output on windows build in openssl1.0.0d In-Reply-To: <45282936A11F374E9592C1F4C7AB9AFE3208DAE124@NLBAWEXMB4.infor.com> References: <45282936A11F374E9592C1F4C7AB9AFE3208DAE124@NLBAWEXMB4.infor.com> Message-ID: This is an issue reported against 0.9.x/1.0.0 If still an issue with current release, please open a new ticket. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 21:55:59 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 21:55:59 +0000 Subject: [openssl-dev] [openssl.org #2643] Possible bug in 1.0.0e - make fails when using "no-ecdh" config option In-Reply-To: References: Message-ID: This is an issue reported against 0.9.x/1.0.0 If still an issue with current release, please open a new ticket. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 21:57:22 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 21:57:22 +0000 Subject: [openssl-dev] [openssl.org #2653] [BUG] OpenSSL 1.0.1 OpenVMS issues on VAX In-Reply-To: References: Message-ID: master is building on vms and passing tests. so closing this. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 21:58:26 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 21:58:26 +0000 Subject: [openssl-dev] [openssl.org #2669] make test failure In-Reply-To: References: Message-ID: This is an issue reported against 0.9.x/1.0.0 If still an issue with current release, please open a new ticket. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 21:59:15 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 21:59:15 +0000 Subject: [openssl-dev] [openssl.org #2674] [PATCH] Fix compilation on GNU/Hurd and GNU/kFreeBSD In-Reply-To: References: Message-ID: This is an issue reported against 0.9.x/1.0.0 If still an issue with current release, please open a new ticket. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 22:00:15 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 22:00:15 +0000 Subject: [openssl-dev] [openssl.org #2691] [Bug] gost89_get_asn1_parameters fails In-Reply-To: <356271327303254@web107.yandex.ru> References: <356271327303254@web107.yandex.ru> Message-ID: This is an issue reported against 0.9.x/1.0.0 If still an issue with current release, please open a new ticket. Also, in 1.1 gost is now a separately engine not maintained by openssl. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 22:02:41 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 22:02:41 +0000 Subject: [openssl-dev] [openssl.org #2816] bug report on openssl version 1.0.0d , windows server 2008 64 bit In-Reply-To: References: Message-ID: This is an issue reported against 0.9.x/1.0.0 If still an issue with current release, please open a new ticket. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 22:03:27 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 22:03:27 +0000 Subject: [openssl-dev] [openssl.org #2825] Bug: Unable to connect to WPA enterprise wireless In-Reply-To: References: Message-ID: This is an issue reported against 0.9.x/1.0.0 If still an issue with current release, please open a new ticket. Also, no reply from originator in three years. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 22:08:37 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 22:08:37 +0000 Subject: [openssl-dev] [openssl.org #2885] SSL_accept segfault In-Reply-To: References: Message-ID: This is an issue reported against 0.9.x/1.0.0 If still an issue with current release, please open a new ticket. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 22:09:11 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 22:09:11 +0000 Subject: [openssl-dev] [openssl.org #2889] safestack macros fail for C++ compilers that care about extern "C" function types In-Reply-To: References: Message-ID: This is an issue reported against 0.9.x/1.0.0 If still an issue with current release, please open a new ticket. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 22:09:34 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 22:09:34 +0000 Subject: [openssl-dev] [openssl.org #2904] genpkey ignores "-outform DER" In-Reply-To: <1351588366.2847.1.camel@vpodzime.anaconda.englab.brq.redhat.com> References: <1351588366.2847.1.camel@vpodzime.anaconda.englab.brq.redhat.com> Message-ID: This is an issue reported against 0.9.x/1.0.0 If still an issue with current release, please open a new ticket. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 22:10:20 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 22:10:20 +0000 Subject: [openssl-dev] [openssl.org #2916] EAP-TLS error: RSA_padding_check_PKCS1_type_1:block type is not 01 In-Reply-To: <50AB8C44.5080808@redpinesignals.com> References: <50AB79CF.7020402@redpinesignals.com> <50AB8C44.5080808@redpinesignals.com> Message-ID: This is an issue reported against 0.9.x/1.0.0 If still an issue with current release, please open a new ticket. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 22:11:20 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 22:11:20 +0000 Subject: [openssl-dev] [openssl.org #2939] Re: [FIX] 1.0.0d: All platforms: GOST server MUST check correctness of shared UKM In-Reply-To: References: Message-ID: This is an issue reported against 0.9.x/1.0.0 If still an issue with current release, please open a new ticket. Also, GOST is now an external engine. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 22:12:05 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 22:12:05 +0000 Subject: [openssl-dev] [openssl.org #2980] bug report: s_time slow with -www and -reuse In-Reply-To: <20130208201606.GA2106@imp.flyn.org> References: <20130208201606.GA2106@imp.flyn.org> Message-ID: This is an issue reported against 0.9.x/1.0.0 If still an issue with current release, please open a new ticket. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From openssl-users at dukhovni.org Mon Feb 1 22:13:03 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 1 Feb 2016 22:13:03 +0000 Subject: [openssl-dev] [openssl.org #4285] SSL_CTX_load_verify_locations() fails without error with invalid files In-Reply-To: References: <01CDF0AB-B090-41FA-8047-56E7433128F0@iki.fi> Message-ID: <20160201221303.GD4987@mournblade.imrryr.org> On Mon, Feb 01, 2016 at 08:56:28PM +0000, Timo Sirainen via RT wrote: > If loaded file isn't valid, SSL_CTX_load_verify_locations() returns 0, > but ERR_get_error() reports 0. Actually, the processing of invalid files (that contain malformed data) will push errors onto the error stack, but the processing of *empty* files does not. When a file is valid, but contains no objects the return value of X509_load_cert_crl_file(), which is the number of objects loaded, will be 0, this ultimately becomes the return value of X509_LOOKUP_load_file(), and SSL_CTX_load_verify_locations() returns early. So indeed we should either decide that empty CAfiles or CRLfiles are OK, or push a suitable error onto the stack if we found nothing in the file at all. I think that an empty CAfile is still a CAfile, that happens to trust an empty set of CAs (mathematically sound degenerate case), but that may not be the most useful behaviour in real life. I'll leave it to others to decide what to do. -- Viktor. From rt at openssl.org Mon Feb 1 22:13:56 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 22:13:56 +0000 Subject: [openssl-dev] [openssl.org #3167] openssl pkcs8 does not convert from PKCS8 to "traditional format private key" In-Reply-To: References: Message-ID: This is an issue reported against 0.9.x/1.0.0 If still an issue with current release, please open a new ticket. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 22:14:17 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 01 Feb 2016 22:14:17 +0000 Subject: [openssl-dev] [openssl.org #3186] Problem in configuring SSL in OPENLDAP In-Reply-To: References: Message-ID: This is an issue reported against 0.9.x/1.0.0 If still an issue with current release, please open a new ticket. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Feb 1 22:21:30 2016 From: rt at openssl.org (Tiantian Liu via RT) Date: Mon, 01 Feb 2016 22:21:30 +0000 Subject: [openssl-dev] [openssl.org #4286] Debug in OpenSSL In-Reply-To: References: Message-ID: Hi, ALL, I am software developer who is struggling with encryption and decryption issues in my application. Our customer complained our application crashed at the point where OpenSSL method, PEM_read_RSAPrivateKey, being called. While I can't duplicate the crash in my machine. So I want to enable debug in OpenSSL and core dumping on their machine, then I can get the core dump file upon the crash on customer's side. And I can use GDB to debug the core dump to see what happened in side the so-called PEM_read_RSAPrivateKey. Today, I re-compiled my OpenSSL (version openssl-1.0.1p). However, when I set the breakpoint at PEM_read_RSAPrivateKey, my GDB can't step into that function, just bypassed directly. My machine is 32-bit RedHat Enterprise 5. What I did in configure and installation: #./Configure -g debug-linux-elf -prefix=/usr shared # make # make install All the new generated libs were installed under /usr/lib I use GDB command to check my setup. It looks like my GDB can recognize all the OpenSSL source code and loaded OpenSSL shared library symbols. I post the part of information from GDB: (gdb) info sharedlibrary >From To Syms Read Shared Object Library 0x00561a30 0x005c6364 Yes /usr/lib/libkrb5.so.3 0x0064f590 0x00666e94 Yes /usr/lib/libk5crypto.so.3 0x002407c0 0x004446c4 Yes /usr/lib/libptcoresdk.so.2 0x0070a7f0 0x0070af84 Yes /lib/libcom_err.so.2 0x008c55d0 0x00940594 Yes /usr/lib/libstdc++.so.6 0x005e86b0 0x00631eb4 Yes /usr/lib/libssl.so.1.0.0 0x00a73f00 0x00b81704 Yes /usr/lib/libcrypto.so.1.0.0 0x004f7a50 0x004f8a64 Yes /lib/libdl.so.2 0x004ff210 0x00509e34 Yes /lib/i686/nosegneg/libpthread.so.0 0x00722bd0 0x0081a7d0 Yes /lib/i686/nosegneg/libc.so.6 0x00513430 0x00517794 Yes /usr/lib/libkrb5support.so.0 0x0053f0d0 0x0054a064 Yes /lib/libresolv.so.2 0x0085a670 0x00861ea4 Yes /lib/libgcc_s.so.1 0x00675410 0x00690654 Yes /lib/i686/nosegneg/libm.so.6 0x00a1c7f0 0x00a3172f Yes /lib/ld-linux.so.2 And I also ran command: (gdb) info source ......................................... pem_pkey.c, /home/tyler28/openssl-1.0.1p/crypto/pem/pem_pkey.c, pem_pk8.c, /home/tyler28/openssl-1.0.1p/crypto/pem/pem_pk8.c, pem_oth.c, /home/tyler28/openssl-1.0.1p/crypto/pem/pem_oth.c, pem_xaux.c, /home/tyler28/openssl-1.0.1p/crypto/pem/pem_xaux.c, pem_x509.c, /home/tyler28/openssl-1.0.1p/crypto/pem/pem_x509.c, pem_err.c, /home/tyler28/openssl-1.0.1p/crypto/pem/pem_err.c, pem_all.c, /home/tyler28/openssl-1.0.1p/crypto/pem/pem_all.c, pem_lib.c, /home/tyler28/openssl-1.0.1p/crypto/pem/pem_lib.c, pem_info.c, /home/tyler28/openssl-1.0.1p/crypto/pem/pem_info.c, pem_seal.c, /home/tyler28/openssl-1.0.1p/crypto/pem/pem_seal.c, pem_sign.c, /home/tyler28/openssl-1.0.1p/crypto/pem/pem_sign.c, asn_moid.c, /home/tyler28/openssl-1.0.1p/crypto/asn1/asn_moid.c, ............................................... Then during debug, my GDB showed: (gdb) break PEM_read_RSAPrivateKey Breakpoint 2 at 0xb373fd: file pem_all.c, line 184. (gdb) c Continuing. [Switching to Thread 14957456 (LWP 8796)] Breakpoint 1, createRSAWithFilename (filename=0x82ef65a "out/private.pem", diag=0xe3ebdc "/MerchantConnectMulti/log/262.dg", public=0) at ../multi_client/source_Host_C_Code/ssl_open.c:1385 1385 FILE * fp = fopen(filename,"rb"); (gdb) n 1387 if(fp == NULL) (gdb) n 1393 RSA *rsa= RSA_new() ; (gdb) n 1394 if(diag) SerialWriteTestLine_string_Time("FILE open on:", filename, diag); (gdb) n 1395 if(diag) SerialWriteTestLine_Time("after RSA_new", diag); (gdb) n 1398 if (rsa == NULL) { (gdb) n 1408 if(public >0) (gdb) n 1415 rsa = PEM_read_RSAPrivateKey(fp, &rsa,NULL, NULL); (gdb) s <<<<<<<<---------- GDB bypassed, I can't step into the function! 1419 if(diag) SerialWriteTestLine_Time("after PEM_read_RSAPrivateKey/PEM_read_RSA_PUBKEY", diag); Beside that function, I found I can't step into any OpenSSL standard function either. For example, I can't step into the RSA_new too. Based on the message I offered above, could you help me to figure out what mistakes I did? Could you help me? In another word, I just want to step into the OpenSSL standard library functions. How can I do that? I am eagerly waiting for your response and help, thank you in advance. Thanks, Tyler From rsalz at akamai.com Mon Feb 1 22:23:20 2016 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 1 Feb 2016 22:23:20 +0000 Subject: [openssl-dev] RT purge done Message-ID: <5840a8dd20a3478cbbd3b8b678dd6df0@usma1ex-dag1mb1.msg.corp.akamai.com> Thanks for your patience, and your mailbox's understanding. -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Mon Feb 1 22:27:24 2016 From: rt at openssl.org (Tiantian Liu via RT) Date: Mon, 01 Feb 2016 22:27:24 +0000 Subject: [openssl-dev] [openssl.org #4286] AutoReply: Debug in OpenSSL In-Reply-To: References: Message-ID: Thanks for open the ticket [openssl.org #4286] for me. Thanks, Tyler -----Original Message----- From: The default queue via RT [mailto:rt at openssl.org] Sent: February-01-16 5:21 PM To: Tiantian (Tyler) Liu Subject: [openssl.org #4286] AutoReply: Debug in OpenSSL Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Debug in OpenSSL", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [openssl.org #4286]. Please include the string: [openssl.org #4286] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, rt at openssl.org ------------------------------------------------------------------------- Hi, ALL, I am software developer who is struggling with encryption and decryption issues in my application. Our customer complained our application crashed at the point where OpenSSL method, PEM_read_RSAPrivateKey, being called. While I can't duplicate the crash in my machine. So I want to enable debug in OpenSSL and core dumping on their machine, then I can get the core dump file upon the crash on customer's side. And I can use GDB to debug the core dump to see what happened in side the so-called PEM_read_RSAPrivateKey. Today, I re-compiled my OpenSSL (version openssl-1.0.1p). However, when I set the breakpoint at PEM_read_RSAPrivateKey, my GDB can't step into that function, just bypassed directly. My machine is 32-bit RedHat Enterprise 5. What I did in configure and installation: #./Configure -g debug-linux-elf -prefix=/usr shared # make # make install All the new generated libs were installed under /usr/lib I use GDB command to check my setup. It looks like my GDB can recognize all the OpenSSL source code and loaded OpenSSL shared library symbols. I post the part of information from GDB: (gdb) info sharedlibrary >From To Syms Read Shared Object Library 0x00561a30 0x005c6364 Yes /usr/lib/libkrb5.so.3 0x0064f590 0x00666e94 Yes /usr/lib/libk5crypto.so.3 0x002407c0 0x004446c4 Yes /usr/lib/libptcoresdk.so.2 0x0070a7f0 0x0070af84 Yes /lib/libcom_err.so.2 0x008c55d0 0x00940594 Yes /usr/lib/libstdc++.so.6 0x005e86b0 0x00631eb4 Yes /usr/lib/libssl.so.1.0.0 0x00a73f00 0x00b81704 Yes /usr/lib/libcrypto.so.1.0.0 0x004f7a50 0x004f8a64 Yes /lib/libdl.so.2 0x004ff210 0x00509e34 Yes /lib/i686/nosegneg/libpthread.so.0 0x00722bd0 0x0081a7d0 Yes /lib/i686/nosegneg/libc.so.6 0x00513430 0x00517794 Yes /usr/lib/libkrb5support.so.0 0x0053f0d0 0x0054a064 Yes /lib/libresolv.so.2 0x0085a670 0x00861ea4 Yes /lib/libgcc_s.so.1 0x00675410 0x00690654 Yes /lib/i686/nosegneg/libm.so.6 0x00a1c7f0 0x00a3172f Yes /lib/ld-linux.so.2 And I also ran command: (gdb) info source ......................................... pem_pkey.c, /home/tyler28/openssl-1.0.1p/crypto/pem/pem_pkey.c, pem_pk8.c, /home/tyler28/openssl-1.0.1p/crypto/pem/pem_pk8.c, pem_oth.c, /home/tyler28/openssl-1.0.1p/crypto/pem/pem_oth.c, pem_xaux.c, /home/tyler28/openssl-1.0.1p/crypto/pem/pem_xaux.c, pem_x509.c, /home/tyler28/openssl-1.0.1p/crypto/pem/pem_x509.c, pem_err.c, /home/tyler28/openssl-1.0.1p/crypto/pem/pem_err.c, pem_all.c, /home/tyler28/openssl-1.0.1p/crypto/pem/pem_all.c, pem_lib.c, /home/tyler28/openssl-1.0.1p/crypto/pem/pem_lib.c, pem_info.c, /home/tyler28/openssl-1.0.1p/crypto/pem/pem_info.c, pem_seal.c, /home/tyler28/openssl-1.0.1p/crypto/pem/pem_seal.c, pem_sign.c, /home/tyler28/openssl-1.0.1p/crypto/pem/pem_sign.c, asn_moid.c, /home/tyler28/openssl-1.0.1p/crypto/asn1/asn_moid.c, ............................................... Then during debug, my GDB showed: (gdb) break PEM_read_RSAPrivateKey Breakpoint 2 at 0xb373fd: file pem_all.c, line 184. (gdb) c Continuing. [Switching to Thread 14957456 (LWP 8796)] Breakpoint 1, createRSAWithFilename (filename=0x82ef65a "out/private.pem", diag=0xe3ebdc "/MerchantConnectMulti/log/262.dg", public=0) at ../multi_client/source_Host_C_Code/ssl_open.c:1385 1385 FILE * fp = fopen(filename,"rb"); (gdb) n 1387 if(fp == NULL) (gdb) n 1393 RSA *rsa= RSA_new() ; (gdb) n 1394 if(diag) SerialWriteTestLine_string_Time("FILE open on:", filename, diag); (gdb) n 1395 if(diag) SerialWriteTestLine_Time("after RSA_new", diag); (gdb) n 1398 if (rsa == NULL) { (gdb) n 1408 if(public >0) (gdb) n 1415 rsa = PEM_read_RSAPrivateKey(fp, &rsa,NULL, NULL); (gdb) s <<<<<<<<---------- GDB bypassed, I can't step into the function! 1419 if(diag) SerialWriteTestLine_Time("after PEM_read_RSAPrivateKey/PEM_read_RSA_PUBKEY", diag); Beside that function, I found I can't step into any OpenSSL standard function either. For example, I can't step into the RSA_new too. Based on the message I offered above, could you help me to figure out what mistakes I did? Could you help me? In another word, I just want to step into the OpenSSL standard library functions. How can I do that? I am eagerly waiting for your response and help, thank you in advance. Thanks, Tyler From openssl-users at dukhovni.org Mon Feb 1 22:52:57 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 1 Feb 2016 22:52:57 +0000 Subject: [openssl-dev] Fwd: latest OpenSSL causes OpenSMTPD to segv In-Reply-To: <9a22f87f39a149d699f2e597be816865@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20160201201035.GA30500@poolp.org> <9a22f87f39a149d699f2e597be816865@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <20160201225256.GE4987@mournblade.imrryr.org> On Mon, Feb 01, 2016 at 08:56:16PM +0000, Salz, Rich wrote: > > This impact all users who upgrade to OpenSSL 1.0.2f and will cause smtpd > > to crash as soon as the RSA engine is used (ie: whenever there's crypto) > > It would be interesting to see what they think was wrong. > > Our intent is to NOT change API's across letter releases. The only thing I see that's plausibly pertinent is: commit 6656ba7152dfe4bba865e327dd362ea08544aa80 Author: Dr. Stephen Henson Date: Sun Dec 20 18:18:43 2015 +0000 Don't check RSA_FLAG_SIGN_VER. Reviewed-by: Richard Levitte diff --git a/crypto/rsa/rsa_sign.c b/crypto/rsa/rsa_sign.c index 82ca832..ed63a1d 100644 --- a/crypto/rsa/rsa_sign.c +++ b/crypto/rsa/rsa_sign.c @@ -84,7 +84,7 @@ int RSA_sign(int type, const unsigned char *m, unsigned int m_len, return 0; } #endif - if ((rsa->flags & RSA_FLAG_SIGN_VER) && rsa->meth->rsa_sign) { + if (rsa->meth->rsa_sign) { return rsa->meth->rsa_sign(type, m, m_len, sigret, siglen, rsa); } /* Special case: SSL signature, just check the length */ @@ -293,7 +293,7 @@ int RSA_verify(int dtype, const unsigned char *m, unsigned int m_len, const unsigned char *sigbuf, unsigned int siglen, RSA *rsa) { - if ((rsa->flags & RSA_FLAG_SIGN_VER) && rsa->meth->rsa_verify) { + if (rsa->meth->rsa_verify) { return rsa->meth->rsa_verify(dtype, m, m_len, sigbuf, siglen, rsa); } -- Viktor. From openssl-users at dukhovni.org Mon Feb 1 23:16:50 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 1 Feb 2016 23:16:50 +0000 Subject: [openssl-dev] Fwd: latest OpenSSL causes OpenSMTPD to segv In-Reply-To: <20160201225256.GE4987@mournblade.imrryr.org> References: <20160201201035.GA30500@poolp.org> <9a22f87f39a149d699f2e597be816865@usma1ex-dag1mb1.msg.corp.akamai.com> <20160201225256.GE4987@mournblade.imrryr.org> Message-ID: <20160201231650.GF4987@mournblade.imrryr.org> On Mon, Feb 01, 2016 at 10:52:56PM +0000, Viktor Dukhovni wrote: > The only thing I see that's plausibly pertinent is: > > commit 6656ba7152dfe4bba865e327dd362ea08544aa80 > Author: Dr. Stephen Henson > Date: Sun Dec 20 18:18:43 2015 +0000 > > Don't check RSA_FLAG_SIGN_VER. > > Reviewed-by: Richard Levitte > This is related to: commit 1c80019a2c8f59410552197723829fd72ab45a5e Author: Dr. Stephen Henson Date: Sat Sep 18 22:37:44 1999 +0000 Add new sign and verify members to RSA_METHOD and change SSL code to use sign and verify rather than direct encrypt/decrypt. Which was already present in 0.9.7. Thus, presumably engines have been expected to implement the "new" methods, if they were ported to OpenSSL 0.9.7 or later. It seems that perhaps the need to implemnt sign/verify and not just encrypt/decrypt has not been communicated to the engine maintainers. The master branch has: commit 19c6d3ea2d3b4e0ad3e978e42cc7cbdf0c09891f Author: Dr. Stephen Henson Date: Wed Dec 2 14:30:39 2015 +0000 Remove RSA_FLAG_SIGN_VER flag. Remove RSA_FLAG_SIGN_VER: this was origininally used to retain binary compatibility after RSA_METHOD was extended to include rsa_sign and rsa_verify fields. It is no longer needed. Reviewed-by: Richard Levitte And while indeed the structure has been stable with sign/verify methods for ages, engines that don't implement sign/verify may well exist, so dropping the flag check can break some engines. -- Viktor. From rt at openssl.org Mon Feb 1 23:21:29 2016 From: rt at openssl.org (=?UTF-8?B?RW1pbGlhIEvDpHNwZXI=?= via RT) Date: Mon, 01 Feb 2016 23:21:29 +0000 Subject: [openssl-dev] [openssl.org #3854] openssl.cnf in openssl-1.0.1m still uses default_bits=1024 In-Reply-To: <2533734.QspX2uaRnp@gaston.colazone> References: <2533734.QspX2uaRnp@gaston.colazone> Message-ID: 1.0.1m predates Logjam. We changed DH key generation to use 2048 bits by default in OpenSSL 1.0.1n which is the first 1.0.1 release after. The default_bits in apps/openssl.cnf is a sample certificate request configuration and isn't really related to Logjam. But we changed it as well as other key generation apps to use 2048 bits more comprehensively in 1.0.2. More context: https://www.openssl.org/blog/blog/2015/05/20/logjam-freak-upcoming-changes/ All these other conf files look like very old demo examples. They should probably be cleaned up. I'm leaving this ticket open to remind us. Cheers, Emilia From onicrypt at gmail.com Mon Feb 1 23:24:59 2016 From: onicrypt at gmail.com (Nich Ramsey) Date: Mon, 1 Feb 2016 15:24:59 -0800 Subject: [openssl-dev] [openssl.org #1682] BIO_snprintf can NOT work properly on HPUX 11.23 IA for 32bits mode In-Reply-To: <20160201.221805.586286261654828528.levitte@openssl.org> References: <771c166256b14b789991b53780291c69@usma1ex-dag1mb1.msg.corp.akamai.com> <20160201.221805.586286261654828528.levitte@openssl.org> Message-ID: Thank you Richard, and yeah those were the messages I was referring to. You all had a ton of tickets you got to today, big ups on the great work! Thank you for taking the time to address my minor quibble. Best, Nich On Feb 1, 2016 1:18 PM, "Richard Levitte" wrote: > Could it be the empty message from kong don ? I'm > seeing them too, that subscription is going. 3... 2... 1... gone > > In message < > 771c166256b14b789991b53780291c69 at usma1ex-dag1mb1.msg.corp.akamai.com> on > Mon, 1 Feb 2016 19:14:56 +0000, "Salz, Rich" said: > > rsalz> But you ARE getting messages. You quoted it below. J > rsalz> > rsalz> Sorry for the flurry of bug activity. We?re cleaning up ticket list. > rsalz> > rsalz> -- > rsalz> > rsalz> Senior Architect, Akamai Technologies > rsalz> > rsalz> IM: richsalz at jabber.at Twitter: RichSalz > rsalz> > rsalz> From: Nich Ramsey [mailto:onicrypt at gmail.com] > rsalz> Sent: Monday, February 01, 2016 2:13 PM > rsalz> To: rt at openssl.org; openssl-dev at openssl.org > rsalz> Subject: Re: [openssl-dev] [openssl.org #1682] BIO_snprintf can NOT > rsalz> work properly on HPUX 11.23 IA for 32bits mode > rsalz> > rsalz> I'm continually getting repeat messages and messages with no text > rsalz> body. So annoying, please make it stop!! > rsalz> > rsalz> On Feb 1, 2016 11:10 AM, "Rich Salz via RT" wrote: > rsalz> > rsalz> Andy, I assume you're not going to fix this or it's no longer a > rsalz> problem. > rsalz> > rsalz> This is reported against 0.9.8; please open a new ticket if still a > rsalz> problem > rsalz> with current releases. > rsalz> -- > rsalz> Rich Salz, OpenSSL dev team; rsalz at openssl.org > rsalz> > rsalz> _______________________________________________ > rsalz> openssl-dev mailing list > rsalz> To unsubscribe: > https://mta.openssl.org/mailman/listinfo/openssl-dev > rsalz> > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Mon Feb 1 23:30:41 2016 From: rt at openssl.org (Kurt Roeckx via RT) Date: Mon, 01 Feb 2016 23:30:41 +0000 Subject: [openssl-dev] [openssl.org #4286] Debug in OpenSSL In-Reply-To: <20160201233038.GA25608@roeckx.be> References: <20160201233038.GA25608@roeckx.be> Message-ID: On Mon, Feb 01, 2016 at 10:21:30PM +0000, Tiantian Liu via RT wrote: > Hi, ALL, > > I am software developer who is struggling with encryption and decryption issues in my application. > > Our customer complained our application crashed at the point where OpenSSL method, PEM_read_RSAPrivateKey, being called. > > While I can't duplicate the crash in my machine. So I want to enable debug in OpenSSL and core dumping on their machine, then I can get the core dump file upon the crash on customer's side. And I can use GDB to debug the core dump to see what happened in side the so-called PEM_read_RSAPrivateKey. > > Today, I re-compiled my OpenSSL (version openssl-1.0.1p). However, when I set the breakpoint at PEM_read_RSAPrivateKey, my GDB can't step into that function, just bypassed directly. > My machine is 32-bit RedHat Enterprise 5. What I did in configure and installation: > > #./Configure -g debug-linux-elf -prefix=/usr shared > # make > # make install Are you sure it doesn't get stripped at some point? Can you check that the files actually contain debug info? Try: readelf -S /usr/lib/libcrypto.so.1.0.0 Kurt From kurt at roeckx.be Mon Feb 1 23:34:01 2016 From: kurt at roeckx.be (Kurt Roeckx) Date: Tue, 2 Feb 2016 00:34:01 +0100 Subject: [openssl-dev] Fwd: latest OpenSSL causes OpenSMTPD to segv In-Reply-To: <20160201231650.GF4987@mournblade.imrryr.org> References: <20160201201035.GA30500@poolp.org> <9a22f87f39a149d699f2e597be816865@usma1ex-dag1mb1.msg.corp.akamai.com> <20160201225256.GE4987@mournblade.imrryr.org> <20160201231650.GF4987@mournblade.imrryr.org> Message-ID: <20160201233401.GB25608@roeckx.be> On Mon, Feb 01, 2016 at 11:16:50PM +0000, Viktor Dukhovni wrote: > On Mon, Feb 01, 2016 at 10:52:56PM +0000, Viktor Dukhovni wrote: > > > The only thing I see that's plausibly pertinent is: > > > > commit 6656ba7152dfe4bba865e327dd362ea08544aa80 > > Author: Dr. Stephen Henson > > Date: Sun Dec 20 18:18:43 2015 +0000 > > > > Don't check RSA_FLAG_SIGN_VER. > > > > Reviewed-by: Richard Levitte > > > > This is related to: > > commit 1c80019a2c8f59410552197723829fd72ab45a5e > Author: Dr. Stephen Henson > Date: Sat Sep 18 22:37:44 1999 +0000 > > Add new sign and verify members to RSA_METHOD and change SSL code to use sign > and verify rather than direct encrypt/decrypt. > > Which was already present in 0.9.7. Thus, presumably engines have > been expected to implement the "new" methods, if they were ported > to OpenSSL 0.9.7 or later. > > It seems that perhaps the need to implemnt sign/verify and not just > encrypt/decrypt has not been communicated to the engine maintainers. > > The master branch has: > > commit 19c6d3ea2d3b4e0ad3e978e42cc7cbdf0c09891f > Author: Dr. Stephen Henson > Date: Wed Dec 2 14:30:39 2015 +0000 > > Remove RSA_FLAG_SIGN_VER flag. > > Remove RSA_FLAG_SIGN_VER: this was origininally used to retain binary > compatibility after RSA_METHOD was extended to include rsa_sign and > rsa_verify fields. It is no longer needed. > > Reviewed-by: Richard Levitte > > And while indeed the structure has been stable with sign/verify > methods for ages, engines that don't implement sign/verify may well > exist, so dropping the flag check can break some engines. This looks like a change in behaviour that's not just a bug fix, and we should properly revert that. Kurt From rt at openssl.org Mon Feb 1 23:38:49 2016 From: rt at openssl.org (Alex Rousskov via RT) Date: Mon, 01 Feb 2016 23:38:49 +0000 Subject: [openssl-dev] [openssl.org #2768] Bug: internal_verify() hides errors from callbacks after X509_V_ERR_UNABLE_TO_VERIFY_LEAF_SIGNATURE In-Reply-To: <56AFEC82.4000505@measurement-factory.com> References: <4F68E7F6.7080305@measurement-factory.com> <56AFBFC9.7020305@measurement-factory.com> <20160201213157.GA4987@mournblade.imrryr.org> <56AFEC82.4000505@measurement-factory.com> Message-ID: On 02/01/2016 02:32 PM, openssl-dev at openssl.org via RT wrote: > Please be more explicit about what errors you feel were not reported. One specific error mentioned during the previous discussion was "expired certificate". This was ~four years ago, so my recollection may be faulty, but I believe that was _not_ the only hidden error. Back then, Stephen Henson semi-confirmed that some errors were hidden [because they were considered meaningless], so I hope we did not misdiagnose the issue. I do not know whether the code has changed since then. If you have not seen the previous discussion, you can see it at [1] but there is probably a better/RT-specific place for that (which I do not have access to). [1] http://openssl.6102.n7.nabble.com/openssl-org-2768-Bug-internal-verify-hides-errors-from-callbacks-after-X509-V-ERR-UNABLE-TO-VERIFY-LE-td34778.html HTH, Alex. From levitte at openssl.org Mon Feb 1 23:39:40 2016 From: levitte at openssl.org (Richard Levitte) Date: Tue, 02 Feb 2016 00:39:40 +0100 (CET) Subject: [openssl-dev] Fwd: latest OpenSSL causes OpenSMTPD to segv In-Reply-To: <20160201231650.GF4987@mournblade.imrryr.org> References: <9a22f87f39a149d699f2e597be816865@usma1ex-dag1mb1.msg.corp.akamai.com> <20160201225256.GE4987@mournblade.imrryr.org> <20160201231650.GF4987@mournblade.imrryr.org> Message-ID: <20160202.003940.2270696010208807774.levitte@openssl.org> In message <20160201231650.GF4987 at mournblade.imrryr.org> on Mon, 1 Feb 2016 23:16:50 +0000, Viktor Dukhovni said: openssl-users> On Mon, Feb 01, 2016 at 10:52:56PM +0000, Viktor Dukhovni wrote: openssl-users> openssl-users> > The only thing I see that's plausibly pertinent is: openssl-users> > openssl-users> > commit 6656ba7152dfe4bba865e327dd362ea08544aa80 openssl-users> > Author: Dr. Stephen Henson openssl-users> > Date: Sun Dec 20 18:18:43 2015 +0000 openssl-users> > openssl-users> > Don't check RSA_FLAG_SIGN_VER. openssl-users> > openssl-users> > Reviewed-by: Richard Levitte openssl-users> > openssl-users> openssl-users> This is related to: openssl-users> openssl-users> commit 1c80019a2c8f59410552197723829fd72ab45a5e openssl-users> Author: Dr. Stephen Henson openssl-users> Date: Sat Sep 18 22:37:44 1999 +0000 openssl-users> openssl-users> Add new sign and verify members to RSA_METHOD and change SSL code to use sign openssl-users> and verify rather than direct encrypt/decrypt. openssl-users> openssl-users> Which was already present in 0.9.7. Thus, presumably engines have openssl-users> been expected to implement the "new" methods, if they were ported openssl-users> to OpenSSL 0.9.7 or later. openssl-users> openssl-users> It seems that perhaps the need to implemnt sign/verify and not just openssl-users> encrypt/decrypt has not been communicated to the engine maintainers. openssl-users> openssl-users> The master branch has: openssl-users> openssl-users> commit 19c6d3ea2d3b4e0ad3e978e42cc7cbdf0c09891f openssl-users> Author: Dr. Stephen Henson openssl-users> Date: Wed Dec 2 14:30:39 2015 +0000 openssl-users> openssl-users> Remove RSA_FLAG_SIGN_VER flag. openssl-users> openssl-users> Remove RSA_FLAG_SIGN_VER: this was origininally used to retain binary openssl-users> compatibility after RSA_METHOD was extended to include rsa_sign and openssl-users> rsa_verify fields. It is no longer needed. openssl-users> openssl-users> Reviewed-by: Richard Levitte openssl-users> openssl-users> And while indeed the structure has been stable with sign/verify openssl-users> methods for ages, engines that don't implement sign/verify may well openssl-users> exist, so dropping the flag check can break some engines. Hold on a minute... there is a test that the function pointer is assigned: if (rsa->meth->rsa_sign) { return rsa->meth->rsa_sign(type, m, m_len, sigret, siglen, rsa); } So what I can conclude without looking is that one of two things have happened: 1. the RSA_METHOD hasn't been fully initialised, so the rsa_sign pointer is garbage. 2. the function that rsa_sign points as is faulty in some way, but has never been called before now because there was no RSA_FLAG_SIGN_VER bit present. I just downloaded the latest portable OpenSMTPD and am noticing that rsa_sign, rsa_verify and rsa_keygen are filled in (with rsae_sign, rsae_verify and rsae_keygen), but that there are no bits at all assigned to the flags field. As far as I can see, this means that these functions have never been called... before now. Ref: opensmtpd-5.7.3p1.tar.gz, smtpd/ca.c Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From openssl-users at dukhovni.org Mon Feb 1 23:46:20 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 1 Feb 2016 23:46:20 +0000 Subject: [openssl-dev] [openssl.org #2768] Bug: internal_verify() hides errors from callbacks after X509_V_ERR_UNABLE_TO_VERIFY_LEAF_SIGNATURE In-Reply-To: References: <4F68E7F6.7080305@measurement-factory.com> <56AFBFC9.7020305@measurement-factory.com> <20160201213157.GA4987@mournblade.imrryr.org> <56AFEC82.4000505@measurement-factory.com> Message-ID: <20160201234620.GH4987@mournblade.imrryr.org> On Mon, Feb 01, 2016 at 11:38:49PM +0000, Alex Rousskov via RT wrote: > On 02/01/2016 02:32 PM, openssl-dev at openssl.org via RT wrote: > > > Please be more explicit about what errors you feel were not reported. > > One specific error mentioned during the previous discussion was "expired > certificate". This was ~four years ago, so my recollection may be > faulty, but I believe that was _not_ the only hidden error. Expiration makes no sense for a certificate at the top of the chain, it has no issuer, so the date is unsigned and meaningless. > Back then, Stephen Henson semi-confirmed that some errors were hidden > [because they were considered meaningless], so I hope we did not > misdiagnose the issue. I do not know whether the code has changed since > then. I agree that the date is meaningless. I do not agree that not reporting "expiration" of such certificates is "hiding" an error. IMHO, the code is correct as it stands. -- Viktor. From levitte at openssl.org Mon Feb 1 23:58:03 2016 From: levitte at openssl.org (Richard Levitte) Date: Tue, 02 Feb 2016 00:58:03 +0100 (CET) Subject: [openssl-dev] Fwd: latest OpenSSL causes OpenSMTPD to segv In-Reply-To: <20160202.003940.2270696010208807774.levitte@openssl.org> References: <20160201225256.GE4987@mournblade.imrryr.org> <20160201231650.GF4987@mournblade.imrryr.org> <20160202.003940.2270696010208807774.levitte@openssl.org> Message-ID: <20160202.005803.2254526463550910330.levitte@openssl.org> In message <20160202.003940.2270696010208807774.levitte at openssl.org> on Tue, 02 Feb 2016 00:39:40 +0100 (CET), Richard Levitte said: levitte> In message <20160201231650.GF4987 at mournblade.imrryr.org> on Mon, 1 Feb 2016 23:16:50 +0000, Viktor Dukhovni said: levitte> levitte> openssl-users> On Mon, Feb 01, 2016 at 10:52:56PM +0000, Viktor Dukhovni wrote: levitte> openssl-users> levitte> openssl-users> > The only thing I see that's plausibly pertinent is: levitte> openssl-users> > levitte> openssl-users> > commit 6656ba7152dfe4bba865e327dd362ea08544aa80 levitte> openssl-users> > Author: Dr. Stephen Henson levitte> openssl-users> > Date: Sun Dec 20 18:18:43 2015 +0000 levitte> openssl-users> > levitte> openssl-users> > Don't check RSA_FLAG_SIGN_VER. levitte> openssl-users> > levitte> openssl-users> > Reviewed-by: Richard Levitte levitte> openssl-users> > levitte> openssl-users> levitte> openssl-users> This is related to: levitte> openssl-users> levitte> openssl-users> commit 1c80019a2c8f59410552197723829fd72ab45a5e levitte> openssl-users> Author: Dr. Stephen Henson levitte> openssl-users> Date: Sat Sep 18 22:37:44 1999 +0000 levitte> openssl-users> levitte> openssl-users> Add new sign and verify members to RSA_METHOD and change SSL code to use sign levitte> openssl-users> and verify rather than direct encrypt/decrypt. levitte> openssl-users> levitte> openssl-users> Which was already present in 0.9.7. Thus, presumably engines have levitte> openssl-users> been expected to implement the "new" methods, if they were ported levitte> openssl-users> to OpenSSL 0.9.7 or later. levitte> openssl-users> levitte> openssl-users> It seems that perhaps the need to implemnt sign/verify and not just levitte> openssl-users> encrypt/decrypt has not been communicated to the engine maintainers. levitte> openssl-users> levitte> openssl-users> The master branch has: levitte> openssl-users> levitte> openssl-users> commit 19c6d3ea2d3b4e0ad3e978e42cc7cbdf0c09891f levitte> openssl-users> Author: Dr. Stephen Henson levitte> openssl-users> Date: Wed Dec 2 14:30:39 2015 +0000 levitte> openssl-users> levitte> openssl-users> Remove RSA_FLAG_SIGN_VER flag. levitte> openssl-users> levitte> openssl-users> Remove RSA_FLAG_SIGN_VER: this was origininally used to retain binary levitte> openssl-users> compatibility after RSA_METHOD was extended to include rsa_sign and levitte> openssl-users> rsa_verify fields. It is no longer needed. levitte> openssl-users> levitte> openssl-users> Reviewed-by: Richard Levitte levitte> openssl-users> levitte> openssl-users> And while indeed the structure has been stable with sign/verify levitte> openssl-users> methods for ages, engines that don't implement sign/verify may well levitte> openssl-users> exist, so dropping the flag check can break some engines. levitte> levitte> Hold on a minute... there is a test that the function pointer is levitte> assigned: levitte> levitte> if (rsa->meth->rsa_sign) { levitte> return rsa->meth->rsa_sign(type, m, m_len, sigret, siglen, rsa); levitte> } levitte> levitte> So what I can conclude without looking is that one of two things have levitte> happened: levitte> levitte> 1. the RSA_METHOD hasn't been fully initialised, so the rsa_sign levitte> pointer is garbage. levitte> levitte> 2. the function that rsa_sign points as is faulty in some way, but has levitte> never been called before now because there was no RSA_FLAG_SIGN_VER levitte> bit present. levitte> levitte> I just downloaded the latest portable OpenSMTPD and am noticing that levitte> rsa_sign, rsa_verify and rsa_keygen are filled in (with rsae_sign, levitte> rsae_verify and rsae_keygen), but that there are no bits at all levitte> assigned to the flags field. As far as I can see, this means that levitte> these functions have never been called... before now. levitte> levitte> Ref: opensmtpd-5.7.3p1.tar.gz, smtpd/ca.c Further exploration shows that rsae_sign flatly calls rsa_default->rsa_sign. So where does rsa_default come from? Quick look shows RSA_get_default_method(), which defaults to returning a pointer to rsa_pkcs1_ossl_meth, found in crypto/rsa/rsa_ossl.c, and that structure... does. not. assign. rsa_sign, rsa_verify and rsa_keygen. I would say that the issue here lies with rsae_sign, rsae_verify and rsae_keygen for not checking that those pointers are non-NULL before using them, regardless of if flags is checked for RSA_FLAG_SIGN_VER is checked or not. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From openssl-users at dukhovni.org Tue Feb 2 00:32:11 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 2 Feb 2016 00:32:11 +0000 Subject: [openssl-dev] [openssl.org #2500] [bug-report] Configure with shared option on BSD systems In-Reply-To: References: Message-ID: <20160202003210.GK4987@mournblade.imrryr.org> On Mon, Feb 01, 2016 at 07:32:52PM +0000, Rich Salz via RT wrote: > This is reported against 0.9.x and/or 1.0.0; please open a new ticket if still > a problem with current releases. Note, the BSD rpath issue just got fixed in 1.1.0-dev (aka master). We should perhaps do the same in 1.0.2. Let's keep this one open until that's resolved. -- Viktor. From openssl-users at dukhovni.org Tue Feb 2 00:52:16 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 2 Feb 2016 00:52:16 +0000 Subject: [openssl-dev] [openssl.org #1482] [PATCH] add "ciphertext stealing" support to the EVP library In-Reply-To: References: <8552a3bc0702072342v5d364daby44bde5d25111bd38@mail.gmail.com> Message-ID: <20160202005215.GL4987@mournblade.imrryr.org> On Mon, Feb 01, 2016 at 07:00:14PM +0000, Rich Salz via RT wrote: > This is reported against 0.9.8; please open a new ticket if still a problem > with current releases. > It's been eight years, unlikely to happen with a new patch. Mind you, CTS mode would be quite useful so that, for example, Heimdal and MIT Kerberos could link against libcrypto for AES-NI with CTS, without having to jump through hoops converting CBC to CTS. So it would be good to have this on the TODO list. -- Viktor. From rt at openssl.org Tue Feb 2 01:23:23 2016 From: rt at openssl.org (Chatrath, Neha via RT) Date: Tue, 02 Feb 2016 01:23:23 +0000 Subject: [openssl-dev] [openssl.org #607]: Openssl v1.0.2e: t1_lib.c: Check for incorrect return value leading to SSL negotiation failure In-Reply-To: References: Message-ID: Hello, I upgraded from OpenSSL version v1.0.2 to v1.0.2e and started observing issues in SSL negotiations randomly. I observed that as part of v1.0.2e, while processing CLIENT_HELLO message in t1_lib.c, extra checks for checking return value of HMAC_Update() have been added while decrypting the ticket IE. Following is the code flow: ssl3_get_client_hello() |-ssl_get_prev_session |-tls1_process_ticket |-tls_decrypt_ticket |-HMAC_Update --------> Check for this function to return a value has been added as part of OpenSSL v1.0.2e. |-EVP_DigestUpdate |-ctx->update(ctx, data, count) The update function in EVP_MD_CTX has a return type void. Thus, HMAC_Update function end up checking for random values. When the value is greater than 0, SSL negotiations are successful but for other values, the failure is percolated to the calling functions which typically lead to ssl3_accept() failures in my case. Following is the reference to the issue in GitHub: https://github.com/openssl/openssl/issues/607 As part of the fix, I suggest removing the check for checking the return type of HMAC_Update function in tls_decrypt_ticket(). Please find attached patch for the same. Thanks and regards Neha Chatrath DISCLAIMER: Privileged and/or Confidential information may be contained in this message. If you are not the addressee of this message, you may not copy, use or deliver this message to anyone. In such event, you should destroy the message and kindly notify the sender by reply e-mail. It is understood that opinions or conclusions that do not relate to the official business of the company are neither given nor endorsed by the company. Thank You. -------------- next part -------------- diff -ur openssl-1.0.2f/ssl/t1_lib.c openssl-1.0.2f_work/ssl/t1_lib.c --- openssl-1.0.2f/ssl/t1_lib.c 2016-01-28 08:56:08.000000000 -0500 +++ openssl-1.0.2f_work/ssl/t1_lib.c 2016-02-01 19:58:57.000000000 -0500 @@ -3401,8 +3401,8 @@ } eticklen -= mlen; /* Check HMAC of encrypted ticket */ - if (HMAC_Update(&hctx, etick, eticklen) <= 0 - || HMAC_Final(&hctx, tick_hmac, NULL) <= 0) { + HMAC_Update(&hctx, etick, eticklen); + if (HMAC_Final(&hctx, tick_hmac, NULL) <= 0) { goto err; } HMAC_CTX_cleanup(&hctx); From rt at openssl.org Tue Feb 2 01:35:13 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Tue, 02 Feb 2016 01:35:13 +0000 Subject: [openssl-dev] [openssl.org #2653] [BUG] OpenSSL 1.0.1 OpenVMS issues on VAX In-Reply-To: References: Message-ID: It took me a moment to read "VAX". Seeing that we currently can't support VAX (I don't think any of us has access to one, let alone one running VMS), I'm terminally closing this ticket. -- Richard Levitte levitte at openssl.org From openssl-users at dukhovni.org Tue Feb 2 01:44:36 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 2 Feb 2016 01:44:36 +0000 Subject: [openssl-dev] [openssl.org #1852] [BUG] Invalid Proxy Certificates Pass Validation In-Reply-To: References: <49A81357.30509@switch.ch> Message-ID: <20160202014435.GM4987@mournblade.imrryr.org> On Mon, Feb 01, 2016 at 07:18:04PM +0000, Rich Salz via RT wrote: > This is reported against 0.9.x; please open a new ticket if still a problem > with current releases. The same behaviour is present in all releases including master. I don't see any code in OpenSSL that imposes any constraints on the subject names of proxy certificates. If strict adherence to the rules in RFC3820 is important for security (I don't where proxy certs are used and what real semantics applications expect), then this issue remains to be addressed. Perhaps reopen this one. -- Viktor. From rsalz at akamai.com Tue Feb 2 02:55:13 2016 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 2 Feb 2016 02:55:13 +0000 Subject: [openssl-dev] Fwd: latest OpenSSL causes OpenSMTPD to segv In-Reply-To: <20160201225256.GE4987@mournblade.imrryr.org> References: <20160201201035.GA30500@poolp.org> <9a22f87f39a149d699f2e597be816865@usma1ex-dag1mb1.msg.corp.akamai.com> <20160201225256.GE4987@mournblade.imrryr.org> Message-ID: <88acf56d0052493f8d660ea6d6c4bf7f@usma1ex-dag1mb1.msg.corp.akamai.com> > > It would be interesting to see what they think was wrong. > > > > Our intent is to NOT change API's across letter releases. > > The only thing I see that's plausibly pertinent is: Which hardly counts as an API change, does it? I wonder if we'll see what they found, or an apology? From openssl-users at dukhovni.org Tue Feb 2 07:46:38 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 2 Feb 2016 02:46:38 -0500 Subject: [openssl-dev] [openssl.org #2018] BUG: rsautl reports "RSA operation error" when decryption output is empty In-Reply-To: References: <592936F6-B1F8-4B11-A6F6-8945B9354879@trusteer.com> Message-ID: <3FB01956-68A4-4462-9EA2-A71243E7A728@dukhovni.org> > On Feb 1, 2016, at 2:21 PM, Rich Salz via RT wrote: > > This is reported against 0.9.x; please open a new ticket if still a problem > with current releases. Fixes for this problem are slated to appear in the next 1.0.2 patch level and next 1.1.0 alpha release after initial internal review. I also took the opportunity to fix not only the handling of empty encrypt input and decrypt output, but also some unnecessary limitations on the allowed order of command-line switches for the related pkeyutl command, which largely supersedes rsautl and also could not handle empty inputs/outputs. -- Viktor. From rt at openssl.org Tue Feb 2 07:46:49 2016 From: rt at openssl.org (Viktor Dukhovni via RT) Date: Tue, 02 Feb 2016 07:46:49 +0000 Subject: [openssl-dev] [openssl.org #2018] BUG: rsautl reports "RSA operation error" when decryption output is empty In-Reply-To: <3FB01956-68A4-4462-9EA2-A71243E7A728@dukhovni.org> References: <592936F6-B1F8-4B11-A6F6-8945B9354879@trusteer.com> <3FB01956-68A4-4462-9EA2-A71243E7A728@dukhovni.org> Message-ID: > On Feb 1, 2016, at 2:21 PM, Rich Salz via RT wrote: > > This is reported against 0.9.x; please open a new ticket if still a problem > with current releases. Fixes for this problem are slated to appear in the next 1.0.2 patch level and next 1.1.0 alpha release after initial internal review. I also took the opportunity to fix not only the handling of empty encrypt input and decrypt output, but also some unnecessary limitations on the allowed order of command-line switches for the related pkeyutl command, which largely supersedes rsautl and also could not handle empty inputs/outputs. -- Viktor. From bbrumley at gmail.com Tue Feb 2 07:48:32 2016 From: bbrumley at gmail.com (Billy Brumley) Date: Tue, 2 Feb 2016 09:48:32 +0200 Subject: [openssl-dev] [openssl.org #4284] Bug in nistz256 assembly code. In-Reply-To: References: Message-ID: I verified this bug. At least, I think so. Input point: P 88c38b77f62c7646 8761482ed66be7ec e29c7ff650f1ad3d a075da5d50ae8d0f 7aecc07d9b4b9a78 11c14dd2ab2cc516 e11dc6d90097e6b6 0ccfcffded344d8c 5723476edeccc439 0ad224b227c5b4e8 c2f7280137f60ac6 c97c65b4fe0fa310 after ecp_nistz256_point_add(A, P, P) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 after ecp_nistz256_point_double(B, P) 5dc647edcf585e47 8a1234279b722778 d1fe20832426c68a 8854b03358f4812f fe8c5c9008a694e5 5187b8b82213bc83 0c1da0ab8aced06c cc08ba7a7c7c7474 88cc2b97e5151f2f fe3275dcd154755a e98898ead6ffac57 282dd53b1eea1cf2 Basically the asm degenerates to 337 if (is_equal(U1, U2) && !in1infty && !in2infty) { 342 memset(r, 0, sizeof(*r)); 343 return; 345 } Since the subsequent (after jz branch taken) point_add arithmetic causes everything to zero out, so you're left with the point at infinity. Note that ecp_nistz256_point_add adds two projective points, so it doesn't get called for all EC_POINT_mul code paths. BBB On Mon, Feb 1, 2016 at 9:59 PM, Jun Sun via RT wrote: > Hi openssl team, > > In function ecp_nistz256_point_add (in ecp_nistz256.c), in the case when U1 == U2 and S1 == S2, in C reference code, the logic is call ecp_nistz256_point_double (line 339) to do a point double operation: > > > 337 if (is_equal(U1, U2) && !in1infty && !in2infty) { > > 338 if (is_equal(S1, S2)) { > > 339 ecp_nistz256_point_double(r, a); > > 340 return; > > 341 } else { > > 342 memset(r, 0, sizeof(*r)); > > 343 return; > > 344 } > > 345 } > > > > > This is correct and follow what is described in S.Gueron and V.Krasnov's paper. But in x86_64 assembly code (ecp_nistz256-x86_64.pl), this logic is not implemented, it fall back to point adding code again: > > > 2385 .byte 0x3e # predict taken > > 2386 jnz .Ladd_proceed$x # is_equal(U1,U2)? > > 2387 movq %xmm2, $acc0 > > 2388 movq %xmm3, $acc1 > > 2389 test $acc0, $acc0 > > 2390 jnz .Ladd_proceed$x # (in1infty || in2infty)? > > 2391 test $acc1, $acc1 > > 2392 jz .Ladd_proceed$x # is_equal(S1,S2)? > > > > > The difference be seen in the latest ectest.c for the group order tests, even though both C code and assembly code does not generate any error, but they generate different values: > > > 201 scalars[0] = n1; > > 202 points[0] = Q; /* => infinity */ > > 203 scalars[1] = n2; > > 204 points[1] = P; /* => -P */ > > 205 scalars[2] = n1; > > 206 points[2] = Q; /* => infinity */ > > 207 scalars[3] = n2; > > 208 points[3] = Q; /* => infinity */ > > 209 scalars[4] = n1; > > 210 points[4] = P; /* => P */ > > 211 scalars[5] = n2; > > 212 points[5] = Q; /* => infinity */ > > 213 if (!EC_POINTs_mul(group, P, NULL, 6, points, scalars, ctx)) > > 214 ABORT; > > 215 if (!EC_POINT_is_at_infinity(group, P)) > > 216 ABORT; > > > P is holding different values between C reference C code and assembly code. This should not happen if the point doubling function is called in assembly code as well. > > > > Jun Sun > > This email and any attachments are for the sole use of the intended recipients and may be privileged or confidential. Any distribution, printing or other use by anyone else is prohibited. If you are not an intended recipient, please contact the sender immediately, and permanently delete this email and attachments. > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From rt at openssl.org Tue Feb 2 07:48:41 2016 From: rt at openssl.org (Billy Brumley via RT) Date: Tue, 02 Feb 2016 07:48:41 +0000 Subject: [openssl-dev] [openssl.org #4284] Bug in nistz256 assembly code. In-Reply-To: References: Message-ID: I verified this bug. At least, I think so. Input point: P 88c38b77f62c7646 8761482ed66be7ec e29c7ff650f1ad3d a075da5d50ae8d0f 7aecc07d9b4b9a78 11c14dd2ab2cc516 e11dc6d90097e6b6 0ccfcffded344d8c 5723476edeccc439 0ad224b227c5b4e8 c2f7280137f60ac6 c97c65b4fe0fa310 after ecp_nistz256_point_add(A, P, P) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 after ecp_nistz256_point_double(B, P) 5dc647edcf585e47 8a1234279b722778 d1fe20832426c68a 8854b03358f4812f fe8c5c9008a694e5 5187b8b82213bc83 0c1da0ab8aced06c cc08ba7a7c7c7474 88cc2b97e5151f2f fe3275dcd154755a e98898ead6ffac57 282dd53b1eea1cf2 Basically the asm degenerates to 337 if (is_equal(U1, U2) && !in1infty && !in2infty) { 342 memset(r, 0, sizeof(*r)); 343 return; 345 } Since the subsequent (after jz branch taken) point_add arithmetic causes everything to zero out, so you're left with the point at infinity. Note that ecp_nistz256_point_add adds two projective points, so it doesn't get called for all EC_POINT_mul code paths. BBB On Mon, Feb 1, 2016 at 9:59 PM, Jun Sun via RT wrote: > Hi openssl team, > > In function ecp_nistz256_point_add (in ecp_nistz256.c), in the case when U1 == U2 and S1 == S2, in C reference code, the logic is call ecp_nistz256_point_double (line 339) to do a point double operation: > > > 337 if (is_equal(U1, U2) && !in1infty && !in2infty) { > > 338 if (is_equal(S1, S2)) { > > 339 ecp_nistz256_point_double(r, a); > > 340 return; > > 341 } else { > > 342 memset(r, 0, sizeof(*r)); > > 343 return; > > 344 } > > 345 } > > > > > This is correct and follow what is described in S.Gueron and V.Krasnov's paper. But in x86_64 assembly code (ecp_nistz256-x86_64.pl), this logic is not implemented, it fall back to point adding code again: > > > 2385 .byte 0x3e # predict taken > > 2386 jnz .Ladd_proceed$x # is_equal(U1,U2)? > > 2387 movq %xmm2, $acc0 > > 2388 movq %xmm3, $acc1 > > 2389 test $acc0, $acc0 > > 2390 jnz .Ladd_proceed$x # (in1infty || in2infty)? > > 2391 test $acc1, $acc1 > > 2392 jz .Ladd_proceed$x # is_equal(S1,S2)? > > > > > The difference be seen in the latest ectest.c for the group order tests, even though both C code and assembly code does not generate any error, but they generate different values: > > > 201 scalars[0] = n1; > > 202 points[0] = Q; /* => infinity */ > > 203 scalars[1] = n2; > > 204 points[1] = P; /* => -P */ > > 205 scalars[2] = n1; > > 206 points[2] = Q; /* => infinity */ > > 207 scalars[3] = n2; > > 208 points[3] = Q; /* => infinity */ > > 209 scalars[4] = n1; > > 210 points[4] = P; /* => P */ > > 211 scalars[5] = n2; > > 212 points[5] = Q; /* => infinity */ > > 213 if (!EC_POINTs_mul(group, P, NULL, 6, points, scalars, ctx)) > > 214 ABORT; > > 215 if (!EC_POINT_is_at_infinity(group, P)) > > 216 ABORT; > > > P is holding different values between C reference C code and assembly code. This should not happen if the point doubling function is called in assembly code as well. > > > > Jun Sun > > This email and any attachments are for the sole use of the intended recipients and may be privileged or confidential. Any distribution, printing or other use by anyone else is prohibited. If you are not an intended recipient, please contact the sender immediately, and permanently delete this email and attachments. > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From openssl-users at dukhovni.org Tue Feb 2 07:53:29 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 2 Feb 2016 02:53:29 -0500 Subject: [openssl-dev] [openssl.org #2500] [bug-report] Configure with shared option on BSD systems In-Reply-To: References: Message-ID: > On Feb 1, 2016, at 2:32 PM, Rich Salz via RT wrote: > > This is reported against 0.9.x and/or 1.0.0; please open a new ticket if still > a problem with current releases. This was recently fixed in 1.0.2 and 1.1.0-dev. Since 1.0.1 now gets security fixes only, it will likely remain unfixed in 1.0.1. -- Viktor. From rt at openssl.org Tue Feb 2 07:53:32 2016 From: rt at openssl.org (Viktor Dukhovni via RT) Date: Tue, 02 Feb 2016 07:53:32 +0000 Subject: [openssl-dev] [openssl.org #2500] [bug-report] Configure with shared option on BSD systems In-Reply-To: References: Message-ID: > On Feb 1, 2016, at 2:32 PM, Rich Salz via RT wrote: > > This is reported against 0.9.x and/or 1.0.0; please open a new ticket if still > a problem with current releases. This was recently fixed in 1.0.2 and 1.1.0-dev. Since 1.0.1 now gets security fixes only, it will likely remain unfixed in 1.0.1. -- Viktor. From gvanem at yahoo.no Tue Feb 2 08:17:51 2016 From: gvanem at yahoo.no (Gisle Vanem) Date: Tue, 2 Feb 2016 09:17:51 +0100 Subject: [openssl-dev] Gource visualisation of OpenSSL commits Message-ID: <56B0662F.6070804@yahoo.no> FYI. Take a look at how the commit logs of OpenSSL can be visualised using the cool program Gource [1]: https://www.youtube.com/watch?v=068ePuZ5OWw Notice how the Heartbleed (?) bug caused the commit rate and number of contributors increases at time 8:10 (May 2014). [1] https://github.com/acaudwell/Gource/ -- --gv From bbrumley at gmail.com Tue Feb 2 12:11:59 2016 From: bbrumley at gmail.com (Billy Brumley) Date: Tue, 2 Feb 2016 14:11:59 +0200 Subject: [openssl-dev] recent EC_PRE_COMP changes In-Reply-To: References: <44663e46724241dea23d28a25d7a4d36@ustx2ex-dag1mb1.msg.corp.akamai.com> Message-ID: >> Well I don't see an ex_data attached to EC_GROUP or EC_METHOD. > > No, do you need those? We can add them. > >> When I look at ec_lib.c, pre_comp_type is only being checked in switch >> statements in _free and _dup style wrappers. Seems out of place and oddly >> specific. Just one dude's opinion :) > > The precomp stuff is internal to openssl, so I think it's reasonable to put there. So when I see original comments like this in the EC structures: /* The following members are handled by the method functions, even if they appear generic */ What I expect, and was the behavior at least into 2014, is that e.g. in ec_lib.c group->foo can happen for members "foo" above that comment, but not below that comment. Am I interpreting this wrong? BBB From Frank.Broda at ipb-halle.de Tue Feb 2 12:50:27 2016 From: Frank.Broda at ipb-halle.de (Broda, Frank) Date: Tue, 02 Feb 2016 12:50:27 +0000 Subject: [openssl-dev] Option -attime for "openssl ts -verify" Message-ID: Dear all, is there a reason, why "openssl ts -verify" does not provide an "-attime" option, comparable to "openssl verify"? I have a timestamp response which was made in 2009 using a certificate which is now expired. Currently it is impossible to verify this timestamp using the command line tool, because verification fails with a "certificate expired" error. The error is thrown before any checks to the timestamped object (file or digest) are made. Detecting manipulations is therefore not possible. An -attime option should provide means to perform the certificate check at a chosen point in time when the certificate was still valid. I'd suggest a patch, which introduces an -attime option (see https://github.com/fbroda/openssl/tree/fbroda_ts_date). I'm willing to make a pull request if there are no objections. Kind regards, Frank Broda From rt at openssl.org Tue Feb 2 13:18:35 2016 From: rt at openssl.org (=?UTF-8?B?RW1pbGlhIEvDpHNwZXI=?= via RT) Date: Tue, 02 Feb 2016 13:18:35 +0000 Subject: [openssl-dev] [openssl.org #4078] remove MDC2 support (1.1 dev branch) In-Reply-To: References: Message-ID: This was rejected by the team. From rsalz at akamai.com Tue Feb 2 13:56:10 2016 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 2 Feb 2016 13:56:10 +0000 Subject: [openssl-dev] recent EC_PRE_COMP changes In-Reply-To: References: <44663e46724241dea23d28a25d7a4d36@ustx2ex-dag1mb1.msg.corp.akamai.com> Message-ID: <878eb41fbb5240f9bc6522af36e57815@usma1ex-dag1mb1.msg.corp.akamai.com> > What I expect, and was the behavior at least into 2014, is that e.g. > in ec_lib.c group->foo can happen for members "foo" above that comment, > but not below that comment. Am I interpreting this wrong? Not really. But in 1.1 we are doing a great deal of work to make all structures opaque. So it was right before, but it's wrong now. :) How's that for an answer? If you need EX_DATA on other EC structures, please open a ticket. From rsalz at akamai.com Tue Feb 2 13:59:05 2016 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 2 Feb 2016 13:59:05 +0000 Subject: [openssl-dev] Option -attime for "openssl ts -verify" In-Reply-To: References: Message-ID: <5696b3f255064e6580d0b3bb194370a2@usma1ex-dag1mb1.msg.corp.akamai.com> > I'd suggest a patch, which introduces an -attime option (see > https://github.com/fbroda/openssl/tree/fbroda_ts_date). I'm willing to > make a pull request if there are no objections. Please make the PR. And include doc update. From rsalz at akamai.com Tue Feb 2 14:24:00 2016 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 2 Feb 2016 14:24:00 +0000 Subject: [openssl-dev] Gource visualisation of OpenSSL commits In-Reply-To: <56B0662F.6070804@yahoo.no> References: <56B0662F.6070804@yahoo.no> Message-ID: > Take a look at how the commit logs of OpenSSL can be visualised using the > cool program Gource [1]: > https://www.youtube.com/watch?v=068ePuZ5OWw > > Notice how the Heartbleed (?) bug caused the commit rate and number of > contributors increases at time 8:10 (May 2014). > > [1] https://github.com/acaudwell/Gource/ That was very cool. Need a drum machine and fog machines to get the full effect tho :) From rt at openssl.org Tue Feb 2 15:52:06 2016 From: rt at openssl.org (Tiantian Liu via RT) Date: Tue, 02 Feb 2016 15:52:06 +0000 Subject: [openssl-dev] [openssl.org #4286] Debug in OpenSSL In-Reply-To: References: <20160201233038.GA25608@roeckx.be> Message-ID: Hi Kurt, Thanks for your response! I tried the command, now I give you the result: 1. #readelf -S /usr/lib/libcryptio.so.1.0.0 There are 37 section headers, starting at offset 0x5081d0: Section Headers: [Nr] Name Type Addr Off Size ES Flg Lk Inf Al [ 0] NULL 00000000 000000 000000 00 0 0 0 [ 1] .gnu.hash GNU_HASH 000000d4 0000d4 006ee4 04 A 2 0 4 [ 2] .dynsym DYNSYM 00006fb8 006fb8 010230 10 A 3 1 4 [ 3] .dynstr STRTAB 000171e8 0171e8 012dd2 00 A 0 0 1 [ 4] .gnu.version VERSYM 00029fba 029fba 002046 02 A 2 0 2 [ 5] .gnu.version_r VERNEED 0002c000 02c000 0000b0 00 A 3 3 4 [ 6] .rel.dyn REL 0002c0b0 02c0b0 0104a0 08 A 2 0 4 [ 7] .rel.plt REL 0003c550 03c550 000320 08 A 2 9 4 [ 8] .init PROGBITS 0003c870 03c870 00001c 00 AX 0 0 4 [ 9] .plt PROGBITS 0003c88c 03c88c 000650 04 AX 0 0 4 [10] .text PROGBITS 0003cf00 03cf00 10d804 00 AX 0 0 64 [11] .fini PROGBITS 0014a704 14a704 00001c 00 AX 0 0 4 [12] .rodata PROGBITS 0014a720 14a720 0282e1 00 A 0 0 32 [13] .eh_frame_hdr PROGBITS 00172a04 172a04 00001c 00 A 0 0 4 [14] .eh_frame PROGBITS 00172a20 172a20 00005c 00 A 0 0 4 [15] .ctors PROGBITS 00173a7c 172a7c 000008 00 WA 0 0 4 [16] .dtors PROGBITS 00173a84 172a84 000008 00 WA 0 0 4 [17] .jcr PROGBITS 00173a8c 172a8c 000004 00 WA 0 0 4 [18] .data.rel.ro PROGBITS 00173aa0 172aa0 00e8e8 00 WA 0 0 32 [19] .dynamic DYNAMIC 00182388 181388 0000e8 08 WA 3 0 4 [20] .got PROGBITS 00182470 181470 000500 04 WA 0 0 4 [21] .got.plt PROGBITS 00182970 181970 00019c 04 WA 0 0 4 [22] .data PROGBITS 00182b20 181b20 0061fc 00 WA 0 0 32 [23] .bss NOBITS 00188d20 187d1c 003234 00 WA 0 0 32 [24] .comment PROGBITS 00000000 187d1c 006838 00 0 0 1 [25] .debug_aranges PROGBITS 00000000 18e558 004868 00 0 0 8 [26] .debug_pubnames PROGBITS 00000000 192dc0 018c23 00 0 0 1 [27] .debug_info PROGBITS 00000000 1ab9e3 28dcb1 00 0 0 1 [28] .debug_abbrev PROGBITS 00000000 439694 02f509 00 0 0 1 [29] .debug_line PROGBITS 00000000 468b9d 034b00 00 0 0 1 [30] .debug_frame PROGBITS 00000000 49d6a0 02be04 00 0 0 4 [31] .debug_str PROGBITS 00000000 4c94a4 009f7b 00 0 0 1 [32] .debug_loc PROGBITS 00000000 4d341f 034c40 00 0 0 1 [33] .debug_ranges PROGBITS 00000000 50805f 000018 00 0 0 1 [34] .shstrtab STRTAB 00000000 508077 000156 00 0 0 1 [35] .symtab SYMTAB 00000000 508798 01dd00 10 36 3502 4 [36] .strtab STRTAB 00000000 526498 01dd95 00 0 0 1 Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings) I (info), L (link order), G (group), x (unknown) O (extra OS processing required) o (OS specific), p (processor specific) I also tried another command as 2. #readelf --debug-dump /usr/lib/libcryptio.so.1.0.0 13519 pem_check_suffix 13707 PEM_version Length: 1698 Version: 2 Offset into .debug_info section: 1475134 Size of area in .debug_info section: 17241 Offset Name 10875 PEM_read_bio_X509_REQ 10991 PEM_read_X509_REQ 11091 PEM_write_bio_X509_REQ 11165 PEM_write_X509_REQ 11235 PEM_write_bio_X509_REQ_NEW 11313 PEM_write_X509_REQ_NEW 11387 PEM_read_bio_X509_CRL 11485 PEM_read_X509_CRL 11579 PEM_write_bio_X509_CRL 11653 PEM_write_X509_CRL 11723 PEM_read_bio_PKCS7 11830 PEM_read_PKCS7 11921 PEM_write_bio_PKCS7 11992 PEM_write_PKCS7 12059 PEM_read_bio_NETSCAPE_CERT_SEQUENCE 12183 PEM_read_NETSCAPE_CERT_SEQUENCE 12291 PEM_write_bio_NETSCAPE_CERT_SEQUENCE 12379 PEM_write_NETSCAPE_CERT_SEQUENCE 12550 PEM_read_bio_RSAPrivateKey 12669 PEM_read_RSAPrivateKey 12784 PEM_write_bio_RSAPrivateKey 12930 PEM_write_RSAPrivateKey 13072 PEM_read_bio_RSAPublicKey 13174 PEM_read_RSAPublicKey 13272 PEM_write_bio_RSAPublicKey 13350 PEM_write_RSAPublicKey 13424 PEM_read_bio_RSA_PUBKEY 13524 PEM_read_RSA_PUBKEY 13620 PEM_write_bio_RSA_PUBKEY 13696 PEM_write_RSA_PUBKEY 13855 PEM_read_bio_DSAPrivateKey 13980 PEM_write_bio_DSAPrivateKey 14134 PEM_write_DSAPrivateKey 14284 PEM_read_bio_DSA_PUBKEY 14389 PEM_read_DSA_PUBKEY 14490 PEM_write_bio_DSA_PUBKEY 14569 PEM_write_DSA_PUBKEY I can see the debug symbols PEM_write_RSAPrivateKey, but why I can't step into that function? And I also used ldd command and confirmed that my application does reference the /usr/lib/libcryptio.so.1.0.0 [root at lin5ent Multi]# ldd myApp_serv4 linux-gate.so.1 => (0x00882000) libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x00552000) libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x0064c000) libptcoresdk.so.2 => /usr/lib/libptcoresdk.so.2 (0x00110000) libcom_err.so.2 => /lib/libcom_err.so.2 (0x0070a000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00885000) libssl.so.1.0.0 => /usr/lib/libssl.so.1.0.0 (0x0071b000) libcrypto.so.1.0.0 => /usr/lib/libcrypto.so.1.0.0 (0x00ceb000) libdl.so.2 => /lib/libdl.so.2 (0x00ba4000) libpthread.so.0 => /lib/i686/nosegneg/libpthread.so.0 (0x00baa000) libc.so.6 => /lib/i686/nosegneg/libc.so.6 (0x00a39000) libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0x0083f000) libresolv.so.2 => /lib/libresolv.so.2 (0x0053d000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00859000) libm.so.6 => /lib/i686/nosegneg/libm.so.6 (0x00b7b000) /lib/ld-linux.so.2 (0x00a1c000) Please help me. Thanks, Tyler -----Original Message----- From: Kurt Roeckx via RT [mailto:rt at openssl.org] Sent: February-01-16 6:31 PM To: Tiantian (Tyler) Liu Cc: openssl-dev at openssl.org Subject: Re: [openssl-dev] [openssl.org #4286] Debug in OpenSSL On Mon, Feb 01, 2016 at 10:21:30PM +0000, Tiantian Liu via RT wrote: > Hi, ALL, > > I am software developer who is struggling with encryption and decryption issues in my application. > > Our customer complained our application crashed at the point where OpenSSL method, PEM_read_RSAPrivateKey, being called. > > While I can't duplicate the crash in my machine. So I want to enable debug in OpenSSL and core dumping on their machine, then I can get the core dump file upon the crash on customer's side. And I can use GDB to debug the core dump to see what happened in side the so-called PEM_read_RSAPrivateKey. > > Today, I re-compiled my OpenSSL (version openssl-1.0.1p). However, when I set the breakpoint at PEM_read_RSAPrivateKey, my GDB can't step into that function, just bypassed directly. > My machine is 32-bit RedHat Enterprise 5. What I did in configure and installation: > > #./Configure -g debug-linux-elf -prefix=/usr shared # make # make > install Are you sure it doesn't get stripped at some point? Can you check that the files actually contain debug info? Try: readelf -S /usr/lib/libcrypto.so.1.0.0 Kurt From rt at openssl.org Tue Feb 2 15:56:01 2016 From: rt at openssl.org (Broda, Frank via RT) Date: Tue, 02 Feb 2016 15:56:01 +0000 Subject: [openssl-dev] [openssl.org #4287] Option -attime for "openssl ts -verify" In-Reply-To: References: Message-ID: Hi, please find my pull request on https://github.com/openssl/openssl/pull/610 These two patches add an -attime option to "openssl ts -verify" similar to the same option in "openssl verify". This allows checking of timestamp responses with expired certificates. Documentation has been updated as well. Please excuse the stupid subject line of my pull request. Kind regards, Frank Broda -- Dr. Frank Broda * Tel.: +49-345-5582-1361 Leibniz-Inst. f. Pflanzenbiochemie * Fax: +49-345-5582-1309 Abt. Natur- und Wirkstoffchemie * Email: fbroda at ipb-halle.de Weinberg 3, 06120 Halle (Saale), Germany * http://www.ipb-halle.de From rt at openssl.org Tue Feb 2 16:02:32 2016 From: rt at openssl.org (Stephen Henson via RT) Date: Tue, 02 Feb 2016 16:02:32 +0000 Subject: [openssl-dev] [openssl.org #4287] Option -attime for "openssl ts -verify" In-Reply-To: References: Message-ID: On Tue Feb 02 15:56:01 2016, Frank.Broda at ipb-halle.de wrote: > Hi, > please find my pull request on > https://github.com/openssl/openssl/pull/610 > > These two patches add an -attime option to "openssl ts -verify" > similar to the same option in "openssl verify". This allows checking > of timestamp responses with expired certificates. Documentation has > been updated as well. > IMHO a better way to handle this is to make "ts" handle general verify options the same way that ocsp, verify, cms, s_client and s_server do then you get -attime support automatically. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From rt at openssl.org Tue Feb 2 16:58:07 2016 From: rt at openssl.org (Tiantian Liu via RT) Date: Tue, 02 Feb 2016 16:58:07 +0000 Subject: [openssl-dev] [openssl.org #4286] Debug in OpenSSL In-Reply-To: References: Message-ID: Hi All, Good morning. I reported a OpenSSL function (PEM_read_RSAPrivateKey) crash yesterday. Honestly, I doubt it's the issue of OpenSSL. After all, it has being used years. I am suspecting maybe something, happened at the background on our customer's server, which caused OpenSSL crash. I think I should give you more information about how that function is used in our application. My code is: RSA * createRSAWithFilename(char * filename,char* diag, int public) { FILE * fp = fopen(filename,"rb"); if(fp == NULL) { if(diag) SerialWriteTestLine_string_Time("Unable to open file:", filename, diag); return NULL; } RSA *rsa= RSA_new() ; if(diag) SerialWriteTestLine_string_Time("FILE open on:", filename, diag); if(public >0) { rsa = PEM_read_RSA_PUBKEY(fp, &rsa, NULL, NULL); } else { rsa = PEM_read_RSAPrivateKey(fp, &rsa, NULL, NULL); <- CRASH HERE! } if(diag) SerialWriteTestLine_Time("after PEM_read_RSAPrivateKey/PEM_read_RSA_PUBKEY", diag); fclose(fp); ......................................................... The code above is being used by our customer. They have 2 or 3 times crash every day. There are only 2 parameters passed to the rsa = PEM_read_RSAPrivateKey(fp, &rsa, NULL, NULL), I found the code does not validate the value of rsa (if RSA_new successfully returned or not). But when I assigned NULL to rsa before calling PEM_read_RSAPrivateKey, it didn't crash. But the first parameter, handle fp is not the cause of crash either. Because I also wrote another test program which keep opening and closing and overwriting the file, again it didn't crash. So from your OpenSSL developer's perspective, what may cause the crash of PEM_read_RSAPrivateKey? For me, I can only control the parameters passed to it. I know there are only 2 kinds of value returned by RSA_new(). Valid address upon success and NULL for failure. I am wondering does it possibly return a not NULL value but illegal memory address to rsa, which may cause the crash of PEM_read_RSAPrivateKey? This is way I asked you guys about how can I step into the OpenSSL functions. Thanks, Tyler From: Tiantian (Tyler) Liu Sent: February-01-16 5:00 PM To: 'rt at openssl.org' Subject: Debug in OpenSSL Hi, ALL, I am software developer who is struggling with encryption and decryption issues in my application. Our customer complained our application crashed at the point where OpenSSL method, PEM_read_RSAPrivateKey, being called. While I can't duplicate the crash in my machine. So I want to enable debug in OpenSSL and core dumping on their machine, then I can get the core dump file upon the crash on customer's side. And I can use GDB to debug the core dump to see what happened in side the so-called PEM_read_RSAPrivateKey. Today, I re-compiled my OpenSSL (version openssl-1.0.1p). However, when I set the breakpoint at PEM_read_RSAPrivateKey, my GDB can't step into that function, just bypassed directly. My machine is 32-bit RedHat Enterprise 5. What I did in configure and installation: #./Configure -g debug-linux-elf -prefix=/usr shared # make # make install All the new generated libs were installed under /usr/lib I use GDB command to check my setup. It looks like my GDB can recognize all the OpenSSL source code and loaded OpenSSL shared library symbols. I post the part of information from GDB: (gdb) info sharedlibrary >From To Syms Read Shared Object Library 0x00561a30 0x005c6364 Yes /usr/lib/libkrb5.so.3 0x0064f590 0x00666e94 Yes /usr/lib/libk5crypto.so.3 0x002407c0 0x004446c4 Yes /usr/lib/libptcoresdk.so.2 0x0070a7f0 0x0070af84 Yes /lib/libcom_err.so.2 0x008c55d0 0x00940594 Yes /usr/lib/libstdc++.so.6 0x005e86b0 0x00631eb4 Yes /usr/lib/libssl.so.1.0.0 0x00a73f00 0x00b81704 Yes /usr/lib/libcrypto.so.1.0.0 0x004f7a50 0x004f8a64 Yes /lib/libdl.so.2 0x004ff210 0x00509e34 Yes /lib/i686/nosegneg/libpthread.so.0 0x00722bd0 0x0081a7d0 Yes /lib/i686/nosegneg/libc.so.6 0x00513430 0x00517794 Yes /usr/lib/libkrb5support.so.0 0x0053f0d0 0x0054a064 Yes /lib/libresolv.so.2 0x0085a670 0x00861ea4 Yes /lib/libgcc_s.so.1 0x00675410 0x00690654 Yes /lib/i686/nosegneg/libm.so.6 0x00a1c7f0 0x00a3172f Yes /lib/ld-linux.so.2 And I also ran command: (gdb) info source ......................................... pem_pkey.c, /home/tyler28/openssl-1.0.1p/crypto/pem/pem_pkey.c, pem_pk8.c, /home/tyler28/openssl-1.0.1p/crypto/pem/pem_pk8.c, pem_oth.c, /home/tyler28/openssl-1.0.1p/crypto/pem/pem_oth.c, pem_xaux.c, /home/tyler28/openssl-1.0.1p/crypto/pem/pem_xaux.c, pem_x509.c, /home/tyler28/openssl-1.0.1p/crypto/pem/pem_x509.c, pem_err.c, /home/tyler28/openssl-1.0.1p/crypto/pem/pem_err.c, pem_all.c, /home/tyler28/openssl-1.0.1p/crypto/pem/pem_all.c, pem_lib.c, /home/tyler28/openssl-1.0.1p/crypto/pem/pem_lib.c, pem_info.c, /home/tyler28/openssl-1.0.1p/crypto/pem/pem_info.c, pem_seal.c, /home/tyler28/openssl-1.0.1p/crypto/pem/pem_seal.c, pem_sign.c, /home/tyler28/openssl-1.0.1p/crypto/pem/pem_sign.c, asn_moid.c, /home/tyler28/openssl-1.0.1p/crypto/asn1/asn_moid.c, ............................................... Then during debug, my GDB showed: (gdb) break PEM_read_RSAPrivateKey Breakpoint 2 at 0xb373fd: file pem_all.c, line 184. (gdb) c Continuing. [Switching to Thread 14957456 (LWP 8796)] Breakpoint 1, createRSAWithFilename (filename=0x82ef65a "out/private.pem", diag=0xe3ebdc "/MerchantConnectMulti/log/262.dg", public=0) at ../multi_client/source_Host_C_Code/ssl_open.c:1385 1385 FILE * fp = fopen(filename,"rb"); (gdb) n 1387 if(fp == NULL) (gdb) n 1393 RSA *rsa= RSA_new() ; (gdb) n 1394 if(diag) SerialWriteTestLine_string_Time("FILE open on:", filename, diag); (gdb) n 1395 if(diag) SerialWriteTestLine_Time("after RSA_new", diag); (gdb) n 1398 if (rsa == NULL) { (gdb) n 1408 if(public >0) (gdb) n 1415 rsa = PEM_read_RSAPrivateKey(fp, &rsa,NULL, NULL); (gdb) s <<<<<<<<---------- GDB bypassed, I can't step into the function! 1419 if(diag) SerialWriteTestLine_Time("after PEM_read_RSAPrivateKey/PEM_read_RSA_PUBKEY", diag); Beside that function, I found I can't step into any OpenSSL standard function either. For example, I can't step into the RSA_new too. Based on the message I offered above, could you help me to figure out what mistakes I did? Could you help me? In another word, I just want to step into the OpenSSL standard library functions. How can I do that? I am eagerly waiting for your response and help, thank you in advance. Thanks, Tyler From rt at openssl.org Tue Feb 2 19:08:18 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 19:08:18 +0000 Subject: [openssl-dev] [openssl.org #3203] Normalize PFS key exchange labels In-Reply-To: <87ioujykgn.fsf@alice.fifthhorseman.net> References: <1387528669-26823-1-git-send-email-dkg@fifthhorseman.net> <87ioujykgn.fsf@alice.fifthhorseman.net> Message-ID: DKG, any chance you can refresh your 1.0.2 patch? I'm interested in being able to accept the common names but not changing the output for compatibility.. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 19:23:37 2016 From: rt at openssl.org (Erik Olofsson via RT) Date: Tue, 02 Feb 2016 19:23:37 +0000 Subject: [openssl-dev] [openssl.org #4288] [BUG] Xmm7 register is cobbered in aesni_gcm_decrypt on win64 In-Reply-To: <36D6AF88-C3E6-4FEC-A6F9-CD92E25FB66D@hansoft.com> References: <36D6AF88-C3E6-4FEC-A6F9-CD92E25FB66D@hansoft.com> Message-ID: For OpenSSL 1.0.2f In crypto\modes\asm\aesni-gcm-x86_64.pl: Registers are saved like this: ___ $code.=<<___ if ($win64); lea -0xa8(%rsp),%rsp movaps %xmm6,-0xd8(%rax) movaps %xmm7,-0xc8(%rax) movaps %xmm8,-0xb8(%rax) movaps %xmm9,-0xa8(%rax) movaps %xmm10,-0x98(%rax) movaps %xmm11,-0x88(%rax) movaps %xmm12,-0x78(%rax) movaps %xmm13,-0x68(%rax) movaps %xmm14,-0x58(%rax) movaps %xmm15,-0x48(%rax) .Lgcm_dec_body: ___ And restored like this: $code.=<<___ if ($win64); movaps -0xd8(%rax),%xmm6 movaps -0xd8(%rax),%xmm7 movaps -0xb8(%rax),%xmm8 movaps -0xa8(%rax),%xmm9 movaps -0x98(%rax),%xmm10 movaps -0x88(%rax),%xmm11 movaps -0x78(%rax),%xmm12 movaps -0x68(%rax),%xmm13 movaps -0x58(%rax),%xmm14 movaps -0x48(%rax),%xmm15 ___ Notice that xmm6 register contents -0xd8(%rax) are used as source to restore both xmm6 and xmm7. From rt at openssl.org Tue Feb 2 19:26:54 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 19:26:54 +0000 Subject: [openssl-dev] [openssl.org #1099] Problem with keysize operations In-Reply-To: <200506052153.47840.bradh@frogmouth.net> References: <200506052153.47840.bradh@frogmouth.net> Message-ID: EVP_PKEY_bits works, and as we're moving to EVP as the main public interface, nothing more to be done. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 19:30:32 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 19:30:32 +0000 Subject: [openssl-dev] [openssl.org #1210] Bug: CRL and Certificates In-Reply-To: <6.2.3.4.2.20051004143628.02a9c228@mariasiebert.de> References: <6.2.3.4.2.20051004143628.02a9c228@mariasiebert.de> Message-ID: Re-thinking about this a bit more, OpenSSL doesn't do any key-usage verification of things when it does signatures. So I am closing this ticket. As a work-around, verifying the signature and usage of the signed data maybe? (If someone wants to do a PR to fix this, great.) -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 19:38:55 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 19:38:55 +0000 Subject: [openssl-dev] [openssl.org #2352] PATCH: Add new extended key usage ipsecIKE In-Reply-To: <8739stzgsk.fsf@algae.riseup.net> References: <8739stzgsk.fsf@algae.riseup.net> Message-ID: fixed in master. finally :) -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 19:54:22 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 19:54:22 +0000 Subject: [openssl-dev] [openssl.org #1556] CRYPTO_set_id_callback/CRYPTO_set_idptr_callback issues In-Reply-To: References: Message-ID: Please see https://github.com/openssl/openssl/pull/451 which is what we'll be doing moving forward. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 19:55:02 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 19:55:02 +0000 Subject: [openssl-dev] [openssl.org #2591] bug report : cryptlib.c : within CRYPTO_thread_id() use pthread_self() instead of getpid() In-Reply-To: <25A73B94D772B0499FE933B70839BD4702FB4ED6@mail-srv1.secumail.de> References: <25A73B94D772B0499FE933B70839BD4702FB4ED6@mail-srv1.secumail.de> Message-ID: Please see https://github.com/openssl/openssl/pull/451 which is what we'll be doing for threads moving forward -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 19:55:26 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 19:55:26 +0000 Subject: [openssl-dev] [openssl.org #3196] Default CRYPTO_THREADID for Mac OS X with Posix Threads In-Reply-To: References: Message-ID: Please see https://github.com/openssl/openssl/pull/451 which is what we'll be doing for threads moving forward -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 19:55:56 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 19:55:56 +0000 Subject: [openssl-dev] [openssl.org #3806] change request - cleanup thread ERR state In-Reply-To: References: Message-ID: Please see https://github.com/openssl/openssl/pull/451 which is what we'll be doing for threads moving forward -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 19:59:59 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 19:59:59 +0000 Subject: [openssl-dev] [openssl.org #3957] BUG:Double free in int_thread_del_item in crypto/err/err.c In-Reply-To: References: Message-ID: Believed fixed. Also see https://github.com/openssl/openssl/pull/451 From rt at openssl.org Tue Feb 2 20:03:11 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 20:03:11 +0000 Subject: [openssl-dev] [openssl.org #2901] no-rsa build bug in 1.0.1c In-Reply-To: <20121025201707.Horde.5lNsb1E4yRVQiZAzUurl83A@www.ev6.net> References: <20121025201707.Horde.5lNsb1E4yRVQiZAzUurl83A@www.ev6.net> Message-ID: Sorry it took so long to get to this. We're only doing security fixes for 1.0.1 now. Closing. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 20:21:04 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 20:21:04 +0000 Subject: [openssl-dev] [openssl.org #2949] OpenSSL bug In-Reply-To: <1537991824.1751128.1356645890403.JavaMail.root@sz0088a.emeryville.ca.mail.comcast.net> References: <2112080121.1751088.1356645815576.JavaMail.root@sz0088a.emeryville.ca.mail.comcast.net> <1537991824.1751128.1356645890403.JavaMail.root@sz0088a.emeryville.ca.mail.comcast.net> Message-ID: 0.9.8 not supported, please re-test and re-open if still an issue on current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 20:25:16 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 20:25:16 +0000 Subject: [openssl-dev] [openssl.org #2906] enhancement: test suite won't work when parent directories have spaces In-Reply-To: References: Message-ID: 1.0.1 only gets security fixes now. might be fixed in 1.0.2 definitely fixed in 1.1 -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 20:28:37 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 20:28:37 +0000 Subject: [openssl-dev] [openssl.org #2993] Openssl manual pages In-Reply-To: References: Message-ID: not a bug. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 20:36:09 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 20:36:09 +0000 Subject: [openssl-dev] [openssl.org #2640] [PATCH] support xmpp servers in starttls In-Reply-To: <20111120162844.67bd479a@laverne> References: <20111120162844.67bd479a@laverne> Message-ID: this feature is in openssl 1.1 -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 20:37:04 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 20:37:04 +0000 Subject: [openssl-dev] [openssl.org #2670] [BUG] OpenSSL 1.0.1 beta 1 released (on VMS FAILED) In-Reply-To: <20ef94945a2a52983638c6e0ee40f31cc9560a30@localhost> References: <20120103141748.EBD451322C@master.openssl.org> <20ef94945a2a52983638c6e0ee40f31cc9560a30@localhost> Message-ID: 1.0.1 is only getting security fixes now. we think current releases work. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 20:39:29 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 20:39:29 +0000 Subject: [openssl-dev] [openssl.org #2688] OpenSSL 1.0.1 beta 2 report on Cygwin 1.5.25 In-Reply-To: References: Message-ID: fixed in later versions; 1.0.1 only gets security fixes now. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 20:40:13 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 20:40:13 +0000 Subject: [openssl-dev] [openssl.org #2720] can't build with no-tlsext In-Reply-To: <4F3A75CF.3080103@cisco.com> References: <4F3A75CF.3080103@cisco.com> Message-ID: we no longer support building without all tls extensions. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 20:41:01 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 20:41:01 +0000 Subject: [openssl-dev] [openssl.org #2741] [PATCH] 1.0.1-beta3 fails to build on Windows if --with-fipsdir is used In-Reply-To: <804nubq9vq.fsf@tinier.isode.net> References: <804nubq9vq.fsf@tinier.isode.net> Message-ID: believed fixed; 1.0.1 only gets security fixes now. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 20:41:51 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 20:41:51 +0000 Subject: [openssl-dev] [openssl.org #2747] valgrind suppressions file to suppress warnings from Python/openssl In-Reply-To: References: Message-ID: Are these issues still present in the current releases(s)? If so, please open a new ticket. The 1.0.1 release only gets security fixes now. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 20:43:41 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 20:43:41 +0000 Subject: [openssl-dev] [openssl.org #2763] Possible bug - TLS 1.2 compliance In-Reply-To: <4F638DD7.1010706@cisco.com> References: <4F638DD7.1010706@cisco.com> Message-ID: Since everyone disagrees with the RFC about sending "sigalg-agreeing" certs, we're not going to change this. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 20:45:04 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 20:45:04 +0000 Subject: [openssl-dev] [openssl.org #2767] test/testssl script does not exercise TLS 1.2 In-Reply-To: <4F678FC8.7020300@cisco.com> References: <4F678FC8.7020300@cisco.com> Message-ID: fixed in current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 20:47:07 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 20:47:07 +0000 Subject: [openssl-dev] [openssl.org #2774] OpenSSL 1.0.1 doesn't compile when configured with "no-tls1" In-Reply-To: <4F70DEDB.1070708@free.fr> References: <4F70DEDB.1070708@free.fr> Message-ID: We're only taking security fixes for 1.0.1 now. Sorry we didn't get to look at this sooner. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 20:48:32 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 20:48:32 +0000 Subject: [openssl-dev] [openssl.org #2779] OpenSSL 1.0.1 doesn't compile with NO_STDIO/NO_FP_API In-Reply-To: References: Message-ID: fixed in master. too invasive to fix in earlier releases -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 20:49:27 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 20:49:27 +0000 Subject: [openssl-dev] [openssl.org #2805] uplink-x86_64-pl-script error when running "ms\do_win64a" on windows 7-64bit command line In-Reply-To: References: Message-ID: We're only doing security fixes in 1.0.1 now, sorry we didn't get to this sooner. Believed fixed in 1.0.2 Definitely fixed in master. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 20:50:03 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 20:50:03 +0000 Subject: [openssl-dev] [openssl.org #2812] BUG: infinite loop when using s_client's xmpp starttls operation In-Reply-To: References: Message-ID: Is this still an issue in 1.0.2 or master? If so, please re-open this ticket. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 20:51:06 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 20:51:06 +0000 Subject: [openssl-dev] [openssl.org #2831] patches for openssl 1.0.1c digest stuff In-Reply-To: References: Message-ID: Too late for 1.0.1 and too much work for 1.0.2 :) We fixed it in master (1.1) by saying "any supported digest" which isn't ideal, admittedly. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 20:51:33 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 20:51:33 +0000 Subject: [openssl-dev] [openssl.org #2835] question/proposal for openssl 1.0.1c to make do_ms.bat and do_win64a.bat somewhat more consisent + solve build errors for WIN64a. In-Reply-To: <45282936A11F374E9592C1F4C7AB9AFE32E6C6CD50@NLBAWEXMB4.infor.com> References: <45282936A11F374E9592C1F4C7AB9AFE32E6C6CD50@NLBAWEXMB4.infor.com> Message-ID: We're only doing security fixes in 1.0.1 now; sorry we didn't get to this sooner. Fixed in current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 20:52:43 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 20:52:43 +0000 Subject: [openssl-dev] [openssl.org #2840] [PATCH] Restore alg_section to 1.0.1c In-Reply-To: <20120629003205.GA12678@mcafee.com> References: <20120629003205.GA12678@mcafee.com> Message-ID: sorry we diddn't get to this sooner. we're only taking 1.0.1 security fixes now. and if you so much as *sneeze* on source code, you need a FIPS change letter :) -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 20:54:17 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 20:54:17 +0000 Subject: [openssl-dev] [openssl.org #2856] cryptlib.c: dynlock destroy call during (un)locking In-Reply-To: References: Message-ID: Please see https://github.com/openssl/openssl/pull/451 -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 20:56:00 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 20:56:00 +0000 Subject: [openssl-dev] [openssl.org #2865] Shared build broken in 1.0.1c In-Reply-To: References: Message-ID: Sorry we didn't get to this sooner, we are only taking security fixes for 1.0.1 now. If still an issue on current releases, please open a new ticket. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 21:02:19 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 21:02:19 +0000 Subject: [openssl-dev] [openssl.org #2891] deadlock in X509_PUBKEY_get without recursive mutexes In-Reply-To: References: Message-ID: for 1.0.1 we're only doing security fixes now. for threads stuff, please see https://github.com/openssl/openssl/pull/451 -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 21:03:22 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 21:03:22 +0000 Subject: [openssl-dev] [openssl.org #2912] Error in SSLv23 connection to some servers In-Reply-To: References: Message-ID: Old release, Tried to reproduce the problem and could not do so. Please open a new ticket if this is still an issue with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 21:04:07 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 21:04:07 +0000 Subject: [openssl-dev] [openssl.org #2915] [PATCH] Add an option to Configure to set the include directory for FIPS enabled builds In-Reply-To: <20121119115817.GA25641@fsmat.at> References: <20121119115817.GA25641@fsmat.at> Message-ID: sorry, we're not doing any FIPS changes at this time. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 21:04:47 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 21:04:47 +0000 Subject: [openssl-dev] [openssl.org #2920] Problems building openssl-1.0.1c on 64bit PA-RISC HPUX In-Reply-To: References: Message-ID: Sorry we didn't get to this sooner. We're only taking security fixes for 1.0.1 now. Please open a new ticket if this is still an issue with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 21:06:35 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 21:06:35 +0000 Subject: [openssl-dev] [openssl.org #2928] openSSL 1.0.1c serious bug in Win32 makefiles, easy to fix: linker binary variable name LINK collides with buildsystem variable LINK . please rename In-Reply-To: References: Message-ID: Sorry we didn't get to this sooner. We're only taking security fixes for 1.0.1 now. Please open a new ticket if this is still an issue with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 21:08:12 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 21:08:12 +0000 Subject: [openssl-dev] [openssl.org #2945] bug: linking static OpenSSL 1.0.1c on EL6 seems to cause breakage In-Reply-To: References: Message-ID: Sorry we didn't get to this sooner. We're only taking security fixes for 1.0.1 now. Please open a new ticket if this is still an issue with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 21:09:18 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 21:09:18 +0000 Subject: [openssl-dev] [openssl.org #2986] aix building of openssl-1.0.1e In-Reply-To: <511AC79D.4050202@ballytech.com> References: <511AC79D.4050202@ballytech.com> Message-ID: Sorry we didn't get to this sooner. We're only taking security fixes for 1.0.1 now. Please open a new ticket if this is still an issue with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 21:10:05 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 21:10:05 +0000 Subject: [openssl-dev] [openssl.org #2997] Problems with build because of compiler warnings, etc. In-Reply-To: <5128DC4D.5000706@gmx.de> References: <5128DC4D.5000706@gmx.de> Message-ID: Sorry we didn't get to this sooner. We're only taking security fixes for 1.0.1 now. Please open a new ticket if this is still an issue with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 21:10:31 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 21:10:31 +0000 Subject: [openssl-dev] [openssl.org #2998] Linking libgost.so In-Reply-To: <1361785771.31064.11.camel@shrek.rexursive.com> References: <1361785771.31064.11.camel@shrek.rexursive.com> Message-ID: GOST is now a separately-maintained engine. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 21:10:44 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 21:10:44 +0000 Subject: [openssl-dev] [openssl.org #3007] BUG: OpenSSL 1.0.1e VC-WIN64A build fails when configured with 'no-ec' In-Reply-To: References: Message-ID: Sorry we didn't get to this sooner. We're only taking security fixes for 1.0.1 now. Please open a new ticket if this is still an issue with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 21:10:56 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 21:10:56 +0000 Subject: [openssl-dev] [openssl.org #3009] test failure, x64 openssl 1.0.1.e on OS X In-Reply-To: <9E62105979A71E488956F3FBD081D4BC81294B10B4@MBX13.EXCHPROD.USA.NET> References: <9E62105979A71E488956F3FBD081D4BC81294B10B4@MBX13.EXCHPROD.USA.NET> Message-ID: Sorry we didn't get to this sooner. We're only taking security fixes for 1.0.1 now. Please open a new ticket if this is still an issue with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 21:11:51 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 21:11:51 +0000 Subject: [openssl-dev] [openssl.org #3035] Patch to properly detect and default to 64bit on OSX In-Reply-To: References: Message-ID: Sorry we didn't get to this sooner. We're only taking security fixes for 1.0.1 now. We believe this works now. Please open a new ticket if this is still an issue with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 21:13:49 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 21:13:49 +0000 Subject: [openssl-dev] [openssl.org #3048] [Bug] openssl-1.0.1e-fips-2.0.3 Illegal instruction In-Reply-To: <5192ACB5.5080504@bru.lan> References: <518C0072.5050103@bru.lan> <518DEEB0.5060209@bru.lan> <5192ACB5.5080504@bru.lan> Message-ID: Sorry we didn't get to this sooner. We're only taking security fixes for 1.0.1 now. Please open a new ticket if this is still an issue with current releases. But we're not doing FIPS work now, either. Sorry. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 21:16:28 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 21:16:28 +0000 Subject: [openssl-dev] [openssl.org #3133] minor make install improvement for Windows/Visual Studio in ms\nt.mak In-Reply-To: <858F859BB4F2824EBAB5D4ED58214CB76284B0A9@NLBAWEXMBX3.infor.com> References: <858F859BB4F2824EBAB5D4ED58214CB76284B0A9@NLBAWEXMBX3.infor.com> Message-ID: Sorry we didn't get to this sooner. We're only taking security fixes for 1.0.1 now. Please open a new ticket if this is still an issue with current releases. Also the build system in changed in master. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 21:17:21 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 21:17:21 +0000 Subject: [openssl-dev] [openssl.org #3137] The behavior of CRYPTO_set_mem_functions() in FIPS mode In-Reply-To: <14340B47B36F4F45AA620B220F3FB9F37610535F@DEWDFEMB17B.global.corp.sap> References: <14340B47B36F4F45AA620B220F3FB9F37610535F@DEWDFEMB17B.global.corp.sap> Message-ID: Sorry we didn't get to this sooner. We're only taking security fixes for 1.0.1 now and not doing any FIPS stuff for now. Please open a new ticket if this is still an issue with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 21:18:30 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 21:18:30 +0000 Subject: [openssl-dev] [openssl.org #3157] PATCH Win32/64 openssl 1.0.1e fixes In-Reply-To: <752F2B42-2BB3-4058-82E5-6220FD962F9C@izotope.com> References: <752F2B42-2BB3-4058-82E5-6220FD962F9C@izotope.com> Message-ID: Sorry we didn't get to this sooner. We're only taking security fixes for 1.0.1 now. Please open a new ticket if this is still an issue with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 21:19:01 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 21:19:01 +0000 Subject: [openssl-dev] [openssl.org #3158] [bug] bad output for 'openssl ciphers -ssl2' built with 'no-ssl2' In-Reply-To: References: Message-ID: Sorry we didn't get to this sooner. We're only taking security fixes for 1.0.1 now. also, sslv2 is gone. :) Please open a new ticket if this is still an issue with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 21:19:42 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 21:19:42 +0000 Subject: [openssl-dev] [openssl.org #3165] tru64-alpha-cc compatibility fixes In-Reply-To: <1383781128.305.44025421.6DD9232D@webmail.messagingengine.com> References: <1383781128.305.44025421.6DD9232D@webmail.messagingengine.com> Message-ID: Many of these are probably fixed now. Sorry we didn't get to this sooner. We're only taking security fixes for 1.0.1 now. Please open a new ticket if this is still an issue with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 21:21:32 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 21:21:32 +0000 Subject: [openssl-dev] [openssl.org #3182] Bug in OpenSSL 1.0.1e 586 assembly optimized AES_cbc_encrypt In-Reply-To: References: Message-ID: The public interface is EVP_xxx which does the right thing. From rt at openssl.org Tue Feb 2 21:22:01 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 21:22:01 +0000 Subject: [openssl-dev] [openssl.org #3204] J-PAKE test fails In-Reply-To: References: Message-ID: Sorry we didn't get to this sooner. We're only taking security fixes for 1.0.1 now. Please open a new ticket if this is still an issue with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 21:23:14 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 21:23:14 +0000 Subject: [openssl-dev] [openssl.org #3217] [PATCH] changes in 1.0.0l and 1.0.1f required for OpenVMS In-Reply-To: References: Message-ID: Sorry we didn't get to this sooner. We're only taking security fixes for 1.0.1 now. Please open a new ticket if this is still an issue with current releases. VMS gets a major uplift in 1.1 -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 21:24:03 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 21:24:03 +0000 Subject: [openssl-dev] [openssl.org #3233] 'make depend' emits warnings on OSX wth 1.0.1f In-Reply-To: References: Message-ID: Sorry we didn't get to this sooner. We're only taking security fixes for 1.0.1 now. Please open a new ticket if this is still an issue with current releases. This is already fixed in master, as well. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 21:25:13 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 21:25:13 +0000 Subject: [openssl-dev] [openssl.org #3252] OpenSSL v1.0.1f issue: decryption failed or bad record mac:s3_pkt.c:484 In-Reply-To: <7C17D902-2846-44CB-ADC6-73A158BBC81B@sterch.net> References: <7C17D902-2846-44CB-ADC6-73A158BBC81B@sterch.net> Message-ID: Sorry we didn't get to this sooner. We're only taking security fixes for 1.0.1 now. Is this still an issue? (Hubert?) -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 21:26:39 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 21:26:39 +0000 Subject: [openssl-dev] [openssl.org #3322] [PATCH] ccgost to use configured params for 28147-89 in CNT and IMIT mode In-Reply-To: References: Message-ID: GOST is now a separately-maintained engine. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 21:27:42 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 21:27:42 +0000 Subject: [openssl-dev] [openssl.org #3358] openssl should create private keys with stricter permissions In-Reply-To: <20140516004629.GR3444@dirac.q-ix.net> References: <20140516004629.GR3444@dirac.q-ix.net> Message-ID: this is fixed in master (openssl 1.1 release) -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 21:29:31 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 21:29:31 +0000 Subject: [openssl-dev] [openssl.org #3455] Compile error on Tandem NonStop (including patch) In-Reply-To: <43271ca9e50747de80fe4900a47b824d@phx-exmbprd-03.adprod.bmc.com> References: <43271ca9e50747de80fe4900a47b824d@phx-exmbprd-03.adprod.bmc.com> Message-ID: Sorry we didn't get to this sooner. We're only taking security fixes for 1.0.1 now. Also, Tandem isn't much supported... Please open a new ticket if this is still an issue with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 21:32:27 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 21:32:27 +0000 Subject: [openssl-dev] [openssl.org #3520] [PATCH] 1.0.1e: Configure: Correctly Handle GCC/clang/LLVM -arch and -isysroot Options In-Reply-To: <1410194372-41009-1-git-send-email-marathon96@gmail.com> References: <1410194372-41009-1-git-send-email-marathon96@gmail.com> Message-ID: Sorry we didn't get to this sooner. We're only taking security fixes for 1.0.1 now. Please open a new ticket if this is still an issue with current releases. Also, the new build process should handle this more cleanly. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 21:33:04 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 21:33:04 +0000 Subject: [openssl-dev] [openssl.org #3521] [PATCH] 1.0.1e: Configure: Correctly Handle GCC --sysroot Option In-Reply-To: <1410194930-44559-1-git-send-email-marathon96@gmail.com> References: <1410194930-44559-1-git-send-email-marathon96@gmail.com> Message-ID: Sorry we didn't get to this sooner. We're only taking security fixes for 1.0.1 now. Please open a new ticket if this is still an issue with current releases. also the new build process handles this correctl. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 21:33:42 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 21:33:42 +0000 Subject: [openssl-dev] [openssl.org #3522] [PATCH] 1.0.1e: Configure: Allow the apps, test and tools directories to be configured out of DIRS. In-Reply-To: <1410195494-48118-1-git-send-email-marathon96@gmail.com> References: <1410195494-48118-1-git-send-email-marathon96@gmail.com> Message-ID: Sorry we didn't get to this sooner. We're only taking security fixes for 1.0.1 now. Please open a new ticket if this is still an issue with current releases. Also fixed in 1.1 -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rainer.jung at kippdata.de Tue Feb 2 21:34:32 2016 From: rainer.jung at kippdata.de (Rainer Jung) Date: Tue, 2 Feb 2016 22:34:32 +0100 Subject: [openssl-dev] OpenSSL Security Advisory In-Reply-To: <20160128150547.GA26799@openssl.org> References: <20160128150547.GA26799@openssl.org> Message-ID: <56B120E8.7080704@kippdata.de> Hi there, reading the last advisory again, I noticed, that there's one logical inconsistency. First: OpenSSL before 1.0.2f will reuse the key if: ... - Static DH ciphersuites are used. The key is part of the certificate and so it will always reuse it. This is only supported in 1.0.2. and then: It will not reuse the key for DHE ciphers suites if: - SSL_OP_SINGLE_DH_USE is set ... So what's the situation if both situations apply, static DH ciphersuites are used and SSL_OP_SINGLE_DH_USE is set is set. Which of these is stronger? Will the key be reused? Or is that combination impossible? It doesn't seem to be clear to me from the wording in the advisory. Thanks for any clarification. Regards, Rainer From rt at openssl.org Tue Feb 2 21:35:28 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 21:35:28 +0000 Subject: [openssl-dev] [openssl.org #3566] openssl-1.0.1j make depend failes In-Reply-To: <300968.28810.qm@web101201.mail.kks.yahoo.co.jp> References: <300968.28810.qm@web101201.mail.kks.yahoo.co.jp> Message-ID: Sorry we didn't get to this sooner. We're only taking security fixes for 1.0.1 now. Please open a new ticket if this is still an issue with current releases. Also, fixed in master (and maybe 1.0.2) -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 21:36:08 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 21:36:08 +0000 Subject: [openssl-dev] [openssl.org #3573] Building win64 openssl static library with no-ssl3 option fails on 1.0.1j In-Reply-To: <5442BB3C.8010600@mediture.com> References: <5442BB3C.8010600@mediture.com> Message-ID: Sorry we didn't get to this sooner. We're only taking security fixes for 1.0.1 now. Please open a new ticket if this is still an issue with current releases. Also fixed in master, and probably 1.0.2 -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 21:36:30 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 21:36:30 +0000 Subject: [openssl-dev] [openssl.org #3587] openssl-1.0.1j configuration for solaris-x86/x64 should be changed In-Reply-To: <459066.65272.qm@web101220.mail.kks.yahoo.co.jp> References: <459066.65272.qm@web101220.mail.kks.yahoo.co.jp> Message-ID: Sorry we didn't get to this sooner. We're only taking security fixes for 1.0.1 now. Please open a new ticket if this is still an issue with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 21:38:21 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 21:38:21 +0000 Subject: [openssl-dev] [openssl.org #3630] BUG - Building OpenSSL on Windows with zlib and fips object module fails. Possible fix included. In-Reply-To: References: Message-ID: Sorry we didn't get to this sooner. We're only taking security fixes for 1.0.1 now. Please open a new ticket if this is still an issue with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 21:39:01 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 21:39:01 +0000 Subject: [openssl-dev] [openssl.org #3640] Bug report: PKCS7_decrypt memory leak In-Reply-To: References: Message-ID: No reply, cannot reproduce the bug, closing the ticket. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 21:42:12 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 21:42:12 +0000 Subject: [openssl-dev] [openssl.org #3642] Bug in OpenSSL 1.0.1j version: Decode error in TLS 1.2 handshake failure from client In-Reply-To: References: Message-ID: No reply, cannot reproduce it, closing the ticket. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 21:44:16 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 21:44:16 +0000 Subject: [openssl-dev] [openssl.org #3677] bug report - open ssl interactive command interface In-Reply-To: <09DED2AD0503184390C12250C5676819136C2063@SKDAMBXM03.mb.skoda.vwg> References: <09DED2AD0503184390C12250C5676819136C2063@SKDAMBXM03.mb.skoda.vwg> Message-ID: this sounds like a windows display issue, not an openssl issue. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 21:45:26 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 21:45:26 +0000 Subject: [openssl-dev] [openssl.org #3685] crash in 32-bit OpenSSL (1.0.1j-fips) when external .so dynamically loads libcrypto.so In-Reply-To: References: Message-ID: Sorry we didn't get to this sooner. We're only taking security fixes for 1.0.1 now. Please open a new ticket if this is still an issue with current releases. Also, we're not touching FIPS stuff right now. Also also, pascal inter-language calling stuff? :) -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 21:46:00 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 21:46:00 +0000 Subject: [openssl-dev] [openssl.org #3696] openssl 1.0.1k s_client app bug? In-Reply-To: <1423674868.1930.15.camel@fit.cvut.cz> References: <1423674868.1930.15.camel@fit.cvut.cz> Message-ID: Sorry we didn't get to this sooner. We're only taking security fixes for 1.0.1 now. Please open a new ticket if this is still an issue with current releases. fixed in master and perhaps 1.0.2 -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 21:46:59 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 21:46:59 +0000 Subject: [openssl-dev] [openssl.org #3699] openssl-1.0.2, fips sparc multiply defined _sparcv9_vis1_instrument_bus, _sparcv9_vis1_instrument_bus2 In-Reply-To: <54DC8E6A0200002800011D4C@prv-mh.provo.novell.com> References: <54DC8E6A0200002800011D4C@prv-mh.provo.novell.com> Message-ID: Sorry, we can't touch the FIPS code any more without sponsorship. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 21:48:15 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 21:48:15 +0000 Subject: [openssl-dev] [openssl.org #3733] ZOS 1.0.1k bug report with fix. In-Reply-To: <40093139-6706-4699-8bbb-a915c523c5dd@default> References: <40093139-6706-4699-8bbb-a915c523c5dd@default> Message-ID: Sorry we didn't get to this sooner. We're only taking security fixes for 1.0.1 now. Please open a new ticket if this is still an issue with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 21:50:08 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 21:50:08 +0000 Subject: [openssl-dev] [openssl.org #3739] regression: syswrite payloads >90kb can trigger EFAULT "Bad address" error on 1.0.2 In-Reply-To: References: Message-ID: sorry, we can't do anything about this without more detail. inter-language bindings are tough. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 21:50:27 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 21:50:27 +0000 Subject: [openssl-dev] [openssl.org #3747] Bug Report - Segmentation fault thrown from engine_unlocked_finish() In-Reply-To: References: Message-ID: Sorry we didn't get to this sooner. We're only taking security fixes for 1.0.1 now. Please open a new ticket if this is still an issue with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 21:51:16 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 21:51:16 +0000 Subject: [openssl-dev] [openssl.org #3766] OS/400 port of OpenSSL 1.0.1m In-Reply-To: References: Message-ID: Sorry we didn't get to this sooner. We're only taking security fixes for 1.0.1 now. Please open a new ticket if this is still an issue with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 21:51:42 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 21:51:42 +0000 Subject: [openssl-dev] [openssl.org #3770] Bug In-Reply-To: References: Message-ID: Sorry we didn't get to this sooner. We're only taking security fixes for 1.0.1 now. Please open a new ticket if this is still an issue with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 21:55:09 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 21:55:09 +0000 Subject: [openssl-dev] [openssl.org #3916] [PATCH] Fix Uninitialized Values In-Reply-To: References: Message-ID: Sorry we didn't get to this sooner. We're only taking security fixes for 1.0.1 now. Believe fixed in current releases. Please open a new ticket if this is still an issue with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 21:55:41 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 21:55:41 +0000 Subject: [openssl-dev] [openssl.org #3929] Crash in EVP_PKEY_CTX_free in the client code .. In-Reply-To: References: Message-ID: Sorry we didn't get to this sooner. We're only taking security fixes for 1.0.1 now. We cannot reproduce the error. Please open a new ticket if this is still an issue with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 21:56:54 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 21:56:54 +0000 Subject: [openssl-dev] [openssl.org #3987] Bug report about crash related to ASN1_primitive_free In-Reply-To: <007101d0cf3c$e9904d00$bcb0e700$@lge.com> References: <007101d0cf3c$e9904d00$bcb0e700$@lge.com> Message-ID: Not enough information to reproduce the bug. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 21:57:39 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 21:57:39 +0000 Subject: [openssl-dev] [openssl.org #4008] Building statically OpenSSL 1.0.1p with MSVC2015 fails In-Reply-To: <55CF0F44.2000409@npcglib.org> References: <55CF0F44.2000409@npcglib.org> Message-ID: Sorry we didn't get to this sooner. We're only taking security fixes for 1.0.1 now. Please open a new ticket if this is still an issue with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 21:58:06 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 21:58:06 +0000 Subject: [openssl-dev] [openssl.org #4014] RE: bug /fix to INSTALL_W64 In-Reply-To: References: Message-ID: Sorry we didn't get to this sooner. We're only taking security fixes for 1.0.1 now. Also this is fixed in master. Please open a new ticket if this is still an issue with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 21:58:37 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 21:58:37 +0000 Subject: [openssl-dev] [openssl.org #4034] mkstack.pl does generate new safestack.h until release 1.0.1m In-Reply-To: References: Message-ID: Sorry we didn't get to this sooner. We're only taking security fixes for 1.0.1 now. Fixed in master. Please open a new ticket if this is still an issue with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 22:02:42 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 22:02:42 +0000 Subject: [openssl-dev] [openssl.org #4143] bug: fips_premain_dso.exe does not include applink.c on dll fips builds In-Reply-To: References: Message-ID: We're not maintaining FIPS stuff right now. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 22:04:26 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 22:04:26 +0000 Subject: [openssl-dev] [openssl.org #4225] OpenSSL 1.1-pre2 EC_KEY_ex_data regression of functionality from 1.0.2 to 1.1 In-Reply-To: <568ECA47.9010900@gmail.com> References: <568ECA47.9010900@gmail.com> Message-ID: Believed all in now :) -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 22:06:06 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 22:06:06 +0000 Subject: [openssl-dev] [openssl.org #4261] BUG unable to connect to Mysql via ssl connection. In-Reply-To: References: Message-ID: not an openssl issue, closing ticket. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 22:06:18 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 22:06:18 +0000 Subject: [openssl-dev] [openssl.org #4270] OpenSSL 1.0.1 Installation bug In-Reply-To: References: Message-ID: Sorry we didn't get to this sooner. We're only taking security fixes for 1.0.1 now. Please open a new ticket if this is still an issue with current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 22:21:27 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 22:21:27 +0000 Subject: [openssl-dev] [openssl.org #2399] Request: Allow "-no-xxx" options in ./config for FIPS build In-Reply-To: References: Message-ID: If you sneeze on the FIPS code, you need a new CMVP change letter. Setting realistic expectations, there are no plans at this time for any FIPS work. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 22:21:47 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 22:21:47 +0000 Subject: [openssl-dev] [openssl.org #3079] FIPS Capable 1.0.1e with no-shared and -no-comp fails to compile In-Reply-To: References: Message-ID: If you sneeze on the FIPS code, you need a new CMVP change letter. Setting realistic expectations, there are no plans at this time for any FIPS work. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 22:22:01 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 22:22:01 +0000 Subject: [openssl-dev] [openssl.org #3081] openssl-fips-2.0.N In-Reply-To: References: Message-ID: If you sneeze on the FIPS code, you need a new CMVP change letter. Setting realistic expectations, there are no plans at this time for any FIPS work. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 22:22:18 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 22:22:18 +0000 Subject: [openssl-dev] [openssl.org #3150] Bug Report (with trivial fix): fips module segfault In-Reply-To: <5266C648.3010703@akamai.com> References: <5266C648.3010703@akamai.com> Message-ID: If you sneeze on the FIPS code, you need a new CMVP change letter. Setting realistic expectations, there are no plans at this time for any FIPS work. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 22:22:21 2016 From: rt at openssl.org (Kent Fredric via RT) Date: Tue, 02 Feb 2016 22:22:21 +0000 Subject: [openssl-dev] [openssl.org #3739] regression: syswrite payloads >90kb can trigger EFAULT "Bad address" error on 1.0.2 In-Reply-To: References: Message-ID: On 3 February 2016 at 10:50, Rich Salz via RT wrote: > sorry, we can't do anything about this without more detail. > inter-language bindings are tough Fortunately, I haven't seen this issue since 1.0.2a, so I suspect it was some other bug being exposed in a strange way, that has since been resolved. Specifically, my best guess based on the behaviour seen is this code was the "corrupted multiblock pointer" bug that was mentioned as resolved in the 1.0.2a changelog. Thanks. -- Kent KENTNL - https://metacpan.org/author/KENTNL From rt at openssl.org Tue Feb 2 22:22:38 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 22:22:38 +0000 Subject: [openssl-dev] [openssl.org #3089] Building OpenSSL 1.0.1e with FIPS on Win64A In-Reply-To: References: Message-ID: If you sneeze on the FIPS code, you need a new CMVP change letter. Setting realistic expectations, there are no plans at this time for any FIPS work. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 22:22:51 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 22:22:51 +0000 Subject: [openssl-dev] [openssl.org #3805] Re: Error while building FIPS capable OpenSSL In-Reply-To: References: Message-ID: If you sneeze on the FIPS code, you need a new CMVP change letter. Setting realistic expectations, there are no plans at this time for any FIPS work. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 22:23:14 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 22:23:14 +0000 Subject: [openssl-dev] [openssl.org #3531] [PATCH] fix a crash in dsa_do_sign() from openssl-fips-2.0.7 In-Reply-To: <516F21EE7BE5764DBF8DF596BC1AA58F6413A54E@otwlxg21.opentext.net> References: <516F21EE7BE5764DBF8DF596BC1AA58F6413A54E@otwlxg21.opentext.net> Message-ID: If you sneeze on the FIPS code, you need a new CMVP change letter. Setting realistic expectations, there are no plans at this time for any FIPS work. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 22:23:28 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 22:23:28 +0000 Subject: [openssl-dev] [openssl.org #3713] Bug: openssl-1.0.1l, FIPS, HP-UX ia64, Duplicate Symbol "AES_Te" and "AES_Td" In-Reply-To: <54E457700200002800011EFF@prv-mh.provo.novell.com> References: <54E457700200002800011EFF@prv-mh.provo.novell.com> Message-ID: If you sneeze on the FIPS code, you need a new CMVP change letter. Setting realistic expectations, there are no plans at this time for any FIPS work. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 22:23:53 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 22:23:53 +0000 Subject: [openssl-dev] [openssl.org #4000] Bug in Branch OpenSSL-fips-2_0-stable; file rsa_x931g.c In-Reply-To: <9872E68DAF3EF5498FBA2777898A9D5F656417@pwsvl-excmbx-05.internal.cacheflow.com> References: <9872E68DAF3EF5498FBA2777898A9D5F656417@pwsvl-excmbx-05.internal.cacheflow.com> Message-ID: If you sneeze on the FIPS code, you need a new CMVP change letter. Setting realistic expectations, there are no plans at this time for any FIPS work. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 22:24:11 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 02 Feb 2016 22:24:11 +0000 Subject: [openssl-dev] [openssl.org #4001] Bug in branch OpenSSL-fips-2_0-stable, file fips_rsa_sign.c In-Reply-To: <9872E68DAF3EF5498FBA2777898A9D5F656437@pwsvl-excmbx-05.internal.cacheflow.com> References: <9872E68DAF3EF5498FBA2777898A9D5F656437@pwsvl-excmbx-05.internal.cacheflow.com> Message-ID: If you sneeze on the FIPS code, you need a new CMVP change letter. Setting realistic expectations, there are no plans at this time for any FIPS work. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From matt at openssl.org Tue Feb 2 23:00:51 2016 From: matt at openssl.org (Matt Caswell) Date: Tue, 2 Feb 2016 23:00:51 +0000 Subject: [openssl-dev] OpenSSL Security Advisory In-Reply-To: <56B120E8.7080704@kippdata.de> References: <20160128150547.GA26799@openssl.org> <56B120E8.7080704@kippdata.de> Message-ID: <56B13523.8010308@openssl.org> On 02/02/16 21:34, Rainer Jung wrote: > Hi there, > > reading the last advisory again, I noticed, that there's one logical > inconsistency. > > First: > > OpenSSL before 1.0.2f will reuse the key if: > ... > - Static DH ciphersuites are used. The key is part of the certificate > and so it will always reuse it. This is only supported in 1.0.2. > > > and then: > > It will not reuse the key for DHE ciphers suites if: > - SSL_OP_SINGLE_DH_USE is set > ... > > So what's the situation if both situations apply, static DH ciphersuites > are used and SSL_OP_SINGLE_DH_USE is set is set. Which of these is > stronger? Will the key be reused? Or is that combination impossible? It > doesn't seem to be clear to me from the wording in the advisory. DH ciphersuites come in two forms: static DH and ephemeral DH (aka DHE). You can't have both at the same time. SSL_OP_SINGLE_DH_USE does not apply to static DH ciphersuites. Matt From kurt at roeckx.be Tue Feb 2 23:30:24 2016 From: kurt at roeckx.be (Kurt Roeckx) Date: Wed, 3 Feb 2016 00:30:24 +0100 Subject: [openssl-dev] OpenSSL Security Advisory In-Reply-To: <56B120E8.7080704@kippdata.de> References: <20160128150547.GA26799@openssl.org> <56B120E8.7080704@kippdata.de> Message-ID: <20160202233023.GA20364@roeckx.be> On Tue, Feb 02, 2016 at 10:34:32PM +0100, Rainer Jung wrote: > Hi there, > > reading the last advisory again, I noticed, that there's one logical > inconsistency. > > First: > > OpenSSL before 1.0.2f will reuse the key if: > ... > - Static DH ciphersuites are used. The key is part of the certificate and so > it will always reuse it. This is only supported in 1.0.2. > > > and then: > > It will not reuse the key for DHE ciphers suites if: > - SSL_OP_SINGLE_DH_USE is set > ... > > So what's the situation if both situations apply, static DH ciphersuites are > used and SSL_OP_SINGLE_DH_USE is set is set. Note that it says DHE ciphers, excluding the DH ciphers. Kurt From rt at openssl.org Tue Feb 2 23:38:51 2016 From: rt at openssl.org (Stuart Kemp via RT) Date: Tue, 02 Feb 2016 23:38:51 +0000 Subject: [openssl-dev] [openssl.org #3713] Bug: openssl-1.0.1l, FIPS, HP-UX ia64, Duplicate Symbol "AES_Te" and "AES_Td" In-Reply-To: <5B5209CB698EEC4D9710CEF6A83600EE35A45697@prvxmb04.microfocus.com> References: <54E457700200002800011EFF@prv-mh.provo.novell.com>, <5B5209CB698EEC4D9710CEF6A83600EE35A45697@prvxmb04.microfocus.com> Message-ID: The SecurityPolicy.pdf claims that HP-UX 11i IA64 is a Supported Configuration; how can this claim be made when the code does nto even compile correctly? ________________________________________ From: Rich Salz via RT [rt at openssl.org] Sent: Tuesday, February 02, 2016 4:23 PM To: Stuart Kemp Cc: openssl-dev at openssl.org Subject: [openssl.org #3713] Bug: openssl-1.0.1l, FIPS, HP-UX ia64, Duplicate Symbol "AES_Te" and "AES_Td" If you sneeze on the FIPS code, you need a new CMVP change letter. Setting realistic expectations, there are no plans at this time for any FIPS work. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Feb 2 23:51:30 2016 From: rt at openssl.org (Stephen Henson via RT) Date: Tue, 02 Feb 2016 23:51:30 +0000 Subject: [openssl-dev] [openssl.org #3699] openssl-1.0.2, fips sparc multiply defined _sparcv9_vis1_instrument_bus, _sparcv9_vis1_instrument_bus2 In-Reply-To: References: <54DC8E6A0200002800011D4C@prv-mh.provo.novell.com> Message-ID: On Tue Feb 02 21:46:59 2016, rsalz wrote: > Sorry, we can't touch the FIPS code any more without sponsorship. Though if this is still a problem a workaround is to rename the symbols on the OpenSSL side outside the FIPS code. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From rainer.jung at kippdata.de Wed Feb 3 00:11:17 2016 From: rainer.jung at kippdata.de (Rainer Jung) Date: Wed, 3 Feb 2016 01:11:17 +0100 Subject: [openssl-dev] OpenSSL Security Advisory In-Reply-To: <20160202233023.GA20364@roeckx.be> References: <20160128150547.GA26799@openssl.org> <56B120E8.7080704@kippdata.de> <20160202233023.GA20364@roeckx.be> Message-ID: <56B145A5.4000202@kippdata.de> Am 03.02.2016 um 00:30 schrieb Kurt Roeckx: > On Tue, Feb 02, 2016 at 10:34:32PM +0100, Rainer Jung wrote: >> Hi there, >> >> reading the last advisory again, I noticed, that there's one logical >> inconsistency. >> >> First: >> >> OpenSSL before 1.0.2f will reuse the key if: >> ... >> - Static DH ciphersuites are used. The key is part of the certificate and so >> it will always reuse it. This is only supported in 1.0.2. >> >> >> and then: >> >> It will not reuse the key for DHE ciphers suites if: >> - SSL_OP_SINGLE_DH_USE is set >> ... >> >> So what's the situation if both situations apply, static DH ciphersuites are >> used and SSL_OP_SINGLE_DH_USE is set is set. > > Note that it says DHE ciphers, excluding the DH ciphers. Thanks Matt and Kurt for enlightening me. Regards, Rainer From rt at openssl.org Wed Feb 3 00:11:25 2016 From: rt at openssl.org (Stephen Henson via RT) Date: Wed, 03 Feb 2016 00:11:25 +0000 Subject: [openssl-dev] [openssl.org #3641] [PATCH] EC_KEY_generate always overwrites private key All OS 1.0.1j In-Reply-To: <549A465A.1070809@ix.netcom.com> References: <549A465A.1070809@ix.netcom.com> Message-ID: The existing functionality reuses an EC_KEY structure and generates a new key. We can't really change this because any application relying on that would end up getting the same key back instead of a new one. However I think a separate function which calculates the public key based on the set private key is a good idea. This may well make it into 1.1.0. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From rt at openssl.org Wed Feb 3 00:18:50 2016 From: rt at openssl.org (Stephen Henson via RT) Date: Wed, 03 Feb 2016 00:18:50 +0000 Subject: [openssl-dev] [openssl.org #3713] Bug: openssl-1.0.1l, FIPS, HP-UX ia64, Duplicate Symbol "AES_Te" and "AES_Td" In-Reply-To: References: <54E457700200002800011EFF@prv-mh.provo.novell.com>, <5B5209CB698EEC4D9710CEF6A83600EE35A45697@prvxmb04.microfocus.com> Message-ID: On Tue Feb 02 23:38:51 2016, Stuart.Kemp at microfocus.com wrote: > The SecurityPolicy.pdf claims that HP-UX 11i IA64 is a Supported > Configuration; how can this claim be made when the code does nto even > compile correctly? The FIPS module compiles correctly but there is the duplicated symbol issue when you use the FIPS capable OpenSSL. Although we can't change the FIPS module symbols without a change letter you can change the symbols on the OpenSSL side. So if you change them to (say) ossl_AES_Te and ossl_AES_Td and make sure the non-FIPS capable OpenSSL still compiles it should work. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From rt at openssl.org Wed Feb 3 00:39:52 2016 From: rt at openssl.org (Rich Salz via RT) Date: Wed, 03 Feb 2016 00:39:52 +0000 Subject: [openssl-dev] [openssl.org #2937] Handshake performance degradation in 1.0.1 and up. In-Reply-To: References: Message-ID: The patches were large and added new features and API's which isn't appropriate for bugfix releases. In the master branch, branch the PRF functionality has been redirected to libcrypto so it's possible it can be optimised by using a more efficient implementation in crypto/kdf or in an engine. There is already one optimisation: the number of updates should be reduced because all the seed values are now concatenated -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From hareesh.sai at gmail.com Wed Feb 3 01:52:05 2016 From: hareesh.sai at gmail.com (Hareesh D) Date: Wed, 3 Feb 2016 07:22:05 +0530 Subject: [openssl-dev] Rgd. CVE-2015-3197 fix test verification !! Message-ID: Can someone please tell me how to verify the fix done for CVE-2015-3197. I want to test 1.0.1r version for this issue. >From the issue description I'm not able to understand what exactly client and server doing. Please tell me what packet client has to send or else please provide me the packet capture of the issue. Please help. Thanks !! -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Wed Feb 3 06:42:53 2016 From: rt at openssl.org (Kees Dekker via RT) Date: Wed, 03 Feb 2016 06:42:53 +0000 Subject: [openssl-dev] [openssl.org #3133] minor make install improvement for Windows/Visual Studio in ms\nt.mak In-Reply-To: <858F859BB4F2824EBAB5D4ED58214CB7011DEFDB54@NLBAWEXMBX3.infor.com> References: <858F859BB4F2824EBAB5D4ED58214CB76284B0A9@NLBAWEXMBX3.infor.com> <858F859BB4F2824EBAB5D4ED58214CB7011DEFDB54@NLBAWEXMBX3.infor.com> Message-ID: No matter. As soon as we have to perform a new build (will be done on Visual Studio 2015 later this year) and I discover the same issue, I will report it. Kees -----Original Message----- From: Rich Salz via RT [mailto:rt at openssl.org] Sent: Tuesday, February 02, 2016 22:16 To: Kees Dekker Cc: openssl-dev at openssl.org Subject: [openssl.org #3133] minor make install improvement for Windows/Visual Studio in ms\nt.mak Sorry we didn't get to this sooner. We're only taking security fixes for 1.0.1 now. Please open a new ticket if this is still an issue with current releases. Also the build system in changed in master. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Wed Feb 3 09:58:49 2016 From: rt at openssl.org (Andy Polyakov via RT) Date: Wed, 03 Feb 2016 09:58:49 +0000 Subject: [openssl-dev] [openssl.org #4284] Bug in nistz256 assembly code. In-Reply-To: <56B1CF54.2050200@openssl.org> References: <56B1CF54.2050200@openssl.org> Message-ID: Hi, Thanks! Verify attached diff. -------------- next part -------------- A non-text attachment was scrubbed... Name: RT4284.diff Type: text/x-patch Size: 1278 bytes Desc: not available URL: From bbrumley at gmail.com Wed Feb 3 11:05:23 2016 From: bbrumley at gmail.com (Billy Brumley) Date: Wed, 3 Feb 2016 13:05:23 +0200 Subject: [openssl-dev] [openssl.org #4284] Bug in nistz256 assembly code. In-Reply-To: References: <56B1CF54.2050200@openssl.org> Message-ID: > Thanks! Verify attached diff. Without looking too closely at the asm, at least the output now looks OK to me: Input point: P ad4cfe7307736330 5a390846abdb19e5 bc92e079b12de03f 3a6b3ebcbf24755d 5ed0dbce609dcf3b 091a794357eca9ee acb4d5512ea7232f 09d787c5915c070a d482c016856ed40a 4a9e64127c9216d7 308267a3a3c72f6c 99a4ef25b90c6499 after ecp_nistz256_point_add(A, P, P) 52d422c756922166 033fb71af0fd3251 b38e0f88b5a2b2a4 bd964cc28ad2bf39 61c01cf1c0a9b7f9 5acaf8aa07f449fc 62b8600cf22cec6b ab80a212e72fb53d b4a67dfe55eb1133 ec19e9f97640f280 1a3caeebc962ab48 19a5d850b22fa55b after ecp_nistz256_point_double(B, P) 52d422c756922166 033fb71af0fd3251 b38e0f88b5a2b2a4 bd964cc28ad2bf39 61c01cf1c0a9b7f9 5acaf8aa07f449fc 62b8600cf22cec6b ab80a212e72fb53d b4a67dfe55eb1133 ec19e9f97640f280 1a3caeebc962ab48 19a5d850b22fa55b I will say that I don't understand how ecp_nistz256_point_add_affine does not have these conditions. Maybe that's a question for the original authors. BBB From rt at openssl.org Wed Feb 3 11:05:34 2016 From: rt at openssl.org (Billy Brumley via RT) Date: Wed, 03 Feb 2016 11:05:34 +0000 Subject: [openssl-dev] [openssl.org #4284] Bug in nistz256 assembly code. In-Reply-To: References: <56B1CF54.2050200@openssl.org> Message-ID: > Thanks! Verify attached diff. Without looking too closely at the asm, at least the output now looks OK to me: Input point: P ad4cfe7307736330 5a390846abdb19e5 bc92e079b12de03f 3a6b3ebcbf24755d 5ed0dbce609dcf3b 091a794357eca9ee acb4d5512ea7232f 09d787c5915c070a d482c016856ed40a 4a9e64127c9216d7 308267a3a3c72f6c 99a4ef25b90c6499 after ecp_nistz256_point_add(A, P, P) 52d422c756922166 033fb71af0fd3251 b38e0f88b5a2b2a4 bd964cc28ad2bf39 61c01cf1c0a9b7f9 5acaf8aa07f449fc 62b8600cf22cec6b ab80a212e72fb53d b4a67dfe55eb1133 ec19e9f97640f280 1a3caeebc962ab48 19a5d850b22fa55b after ecp_nistz256_point_double(B, P) 52d422c756922166 033fb71af0fd3251 b38e0f88b5a2b2a4 bd964cc28ad2bf39 61c01cf1c0a9b7f9 5acaf8aa07f449fc 62b8600cf22cec6b ab80a212e72fb53d b4a67dfe55eb1133 ec19e9f97640f280 1a3caeebc962ab48 19a5d850b22fa55b I will say that I don't understand how ecp_nistz256_point_add_affine does not have these conditions. Maybe that's a question for the original authors. BBB From rt at openssl.org Wed Feb 3 11:35:39 2016 From: rt at openssl.org (Andy Polyakov via RT) Date: Wed, 03 Feb 2016 11:35:39 +0000 Subject: [openssl-dev] [openssl.org #3713] Bug: openssl-1.0.1l, FIPS, HP-UX ia64, Duplicate Symbol "AES_Te" and "AES_Td" In-Reply-To: <56B1E60A.6010706@openssl.org> References: <54E457700200002800011EFF@prv-mh.provo.novell.com> <5B5209CB698EEC4D9710CEF6A83600EE35A45697@prvxmb04.microfocus.com> <56B1E60A.6010706@openssl.org> Message-ID: >> The SecurityPolicy.pdf claims that HP-UX 11i IA64 is a Supported >> Configuration; how can this claim be made when the code does nto even >> compile correctly? > > The FIPS module compiles correctly but there is the duplicated symbol issue > when you use the FIPS capable OpenSSL. > > Although we can't change the FIPS module symbols without a change letter you > can change the symbols on the OpenSSL side. So if you change them to (say) > ossl_AES_Te and ossl_AES_Td and make sure the non-FIPS capable OpenSSL still > compiles it should work. Presumably simpler option should be to remove .global AES_T[ed]# directives in crypto/aes/asm/aes-ia64.S (see attached). I don't have possibility to actually verify it on HP-UX, but at least Linux linker output look proper (can't execute either, only look at binaries). -------------- next part -------------- A non-text attachment was scrubbed... Name: aes-ia64.diff Type: text/x-patch Size: 702 bytes Desc: not available URL: From shyamal.nirmal at gmail.com Wed Feb 3 11:41:34 2016 From: shyamal.nirmal at gmail.com (Shyamal Bhowmik) Date: Wed, 3 Feb 2016 17:11:34 +0530 Subject: [openssl-dev] Fwd: CVE-2014-8730 TLS CBC Incorrect Padding Abuse Vulnerability In-Reply-To: References: Message-ID: Hello, I am using OpenSSL 1.0.1i 6 Aug 2014 version... Following is my understanding of the issue: This is an implementation specific issue and there is no general patch available. The vulnerability depends on how the padding bytes in TLS data are handled in CBC mode and is more specific to TLS v1.0. If the padding bytes in the TLS data received, are handled in the same way as SSLv3 i.e. they are ignored then this issue can arise. If the TLS data padding bytes are handled as per standard i.e. every byte in the padding data should be filled with the total padding length value, then this vulnerability does not occur. I have tested this with a TLS v1.0 browser connecting to my server, and the code flow and debug statements show that during decryption of cipher, function tls1_cbc_remove_padding() in file libssl/ssl/s3_cbc.c is invoked which handles padding data. This function checks for validity of every pad byte value with the last pad byte which holds the total pad length and returns success or failure as per the validation. In file libssl/ssl/s3_pkt.c, function ssl3_get_record is called to decrypt the cipher. Below is a code snippet of this function: /* decrypt in place in 'rr->input' */ rr->data=rr->input; enc_err = s->method->ssl3_enc->enc(s,0); // Calls TLS decrypt function i.e. invoke tls1_enc function in file t1_enc.c that calls tls1_cbc_remove_padding /* enc_err is: * 0: (in non-constant time) if the record is publically invalid. * 1: if the padding is valid * -1: if the padding is invalid */ if (enc_err == 0) { al=SSL_AD_DECRYPTION_FAILED; SSLerr(SSL_F_SSL3_GET_RECORD,SSL_R_BLOCK_CIPHER_PAD_IS_WRONG); goto f_err; } As seen from above, error is thrown only for 0 return value and -1 return value is not handled. So if i change the code if (enc_err == 0) to if (enc_err <= 0) will solve my problem? There was no specific way to reproduce this issue and it was seen very sporadically. - Shyamal -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Wed Feb 3 11:46:19 2016 From: rt at openssl.org (Andy Polyakov via RT) Date: Wed, 03 Feb 2016 11:46:19 +0000 Subject: [openssl-dev] [openssl.org #3699] openssl-1.0.2, fips sparc multiply defined _sparcv9_vis1_instrument_bus, _sparcv9_vis1_instrument_bus2 In-Reply-To: <56B1E88A.40902@openssl.org> References: <54DC8E6A0200002800011D4C@prv-mh.provo.novell.com> <56B1E88A.40902@openssl.org> Message-ID: >> Sorry, we can't touch the FIPS code any more without sponsorship. > > Though if this is still a problem a workaround is to rename the symbols on the > OpenSSL side outside the FIPS code. Another possibility is to add .weak directives to sparccpuid.S so that linker can tolerate multiple symbols. -------------- next part -------------- A non-text attachment was scrubbed... Name: sparccpuid.diff Type: text/x-patch Size: 627 bytes Desc: not available URL: From rt at openssl.org Wed Feb 3 11:52:15 2016 From: rt at openssl.org (Hubert Kario via RT) Date: Wed, 03 Feb 2016 11:52:15 +0000 Subject: [openssl-dev] [openssl.org #3252] OpenSSL v1.0.1f issue: decryption failed or bad record mac:s3_pkt.c:484 In-Reply-To: <6556172.3UBLTXGVDI@pintsize.usersys.redhat.com> References: <7C17D902-2846-44CB-ADC6-73A158BBC81B@sterch.net> <6556172.3UBLTXGVDI@pintsize.usersys.redhat.com> Message-ID: On Tuesday 02 February 2016 21:25:13 Rich Salz via RT wrote: > Sorry we didn't get to this sooner. We're only taking security fixes > for 1.0.1 now. > Is this still an issue? (Hubert?) courtapps.utcourts.gov:443 is down and myrta.com:443 doesn't show the problem any more -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From hkario at redhat.com Wed Feb 3 12:22:54 2016 From: hkario at redhat.com (Hubert Kario) Date: Wed, 03 Feb 2016 13:22:54 +0100 Subject: [openssl-dev] Rgd. CVE-2015-3197 fix test verification !! In-Reply-To: References: Message-ID: <2228378.3GTQSJzNiA@pintsize.usersys.redhat.com> On Wednesday 03 February 2016 07:22:05 Hareesh D wrote: > Can someone please tell me how to verify the fix done for > > CVE-2015-3197. I want to test 1.0.1r version for this issue. > > From the issue description I'm not able to understand what exactly > client and server doing. > > Please tell me what packet client has to send or else please provide > me the packet capture of the issue. > > Please help. Thanks !! I have "published" a reproducer but it is a bit hairy - you will need development versions of few python modules, but nothing too crazy. You will also need Python 2.6, 3.2 or later. The relevant libraries are tlslite-ng, tlsfuzzer and python-ecdsa. To start, download tlsfuzzer and switch to branch with new code: git clone https://github.com/tomato42/tlsfuzzer cd tlsfuzzer git checkout ssl2 Then get the crypto library, switch to its development branch and make it available to the tlsfuzzer: git clone https://github.com/tomato42/tlslite-ng.git .tlslite-ng pushd .tlslite-ng git checkout sslv2 popd ln -s .tlslite-ng/tlslite tlslite Then get the dependency of the crypto library: git clone https://github.com/warner/python-ecdsa .python-ecdsa ln -s .python-ecdsa/ecdsa ecdsa Note: In future checking out the development branches will not be necessary (the lines with `git checkout` can be skipped). The relevant test to check if SSLv2 is completely disabled and client can't force a connection is scripts/test-sslv2-force-cipher.py It will test if the server rejects the SSLv2 style client hello by either closing the connection or sending an alert and closing a connection. To run it use the following command: PYTHONPATH=. python scripts/test-sslv2-force-cipher.py -h hostname \ -p port-number For example: PYTHONPATH=. python scripts/test-sslv2-force-cipher.py -h localhost\ -p 4433 All tests returning "OK" and the summary being: Test end successful: 21 failed: 0 means that the server is most likely NOT vulnerable. Any error in form of Unexpected message from peer: Handshake(43) (or any other number) and an exit value of non-zero means that the server IS vulnerable. -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From rt at openssl.org Wed Feb 3 13:11:43 2016 From: rt at openssl.org (Tom Francis via RT) Date: Wed, 03 Feb 2016 13:11:43 +0000 Subject: [openssl-dev] [openssl.org #3713] Bug: openssl-1.0.1l, FIPS, HP-UX ia64, Duplicate Symbol "AES_Te" and "AES_Td" In-Reply-To: <74AF4309-61C1-45EE-8195-3DBDB8260CA3@tcsaf.com> References: <54E457700200002800011EFF@prv-mh.provo.novell.com> <5B5209CB698EEC4D9710CEF6A83600EE35A45697@prvxmb04.microfocus.com> <74AF4309-61C1-45EE-8195-3DBDB8260CA3@tcsaf.com> Message-ID: Use an older version of OpenSSL for your FIPS-enabled OpenSSL? Yes, it might have security problems, but it you?re using the FIPS module! It?s got worse security problems, so you shouldn?t worry. :) I can say for sure the FIPS 2.0 module compiled and worked at the time the Security Policy was approved for HP-UX on IA64 and PA-RISC, in both 32- and 64-bit flavors. But it was pretty picky about the link editor and compiler. Two other issues to be aware of (and maybe fixing this will let the more recent versions of OpenSSL work): 1) HP?s link editor is very brittle. You should be sure you?re using the proper patch level for it. I no longer have access to the box I was building on, and I?m not sure what the status of the box that was sent for testing is, so I can?t check the patch-level for the link editor. Take a look at the dates in the Security Policy, it was the patch that came out about a month (or less?) prior to the submission of the FIPS 2.0 module for approval. The previous patch wouldn?t link anything except the HP-UX kernel, so it was released outside the normal schedule (and the next patch broke it again, the patch after that was OK, but I never tried that one with building the FIPS module or FIPS-enabled OpenSSL). 2) You?re definitely using a newer version of the compiler; A.06.25 was the current version when the FIPS stuff was approved; depending on your auditors, you may need to be using that one. Especially since the prior versions wouldn?t compile the FIPS module correctly, I wouldn?t be surprised if newer ones are incapable, too. TOM > On Feb 2, 2016, at 6:38 PM, Stuart Kemp via RT wrote: > > The SecurityPolicy.pdf claims that HP-UX 11i IA64 is a Supported Configuration; how can this claim be made when the code does nto even compile correctly? > ________________________________________ > From: Rich Salz via RT [rt at openssl.org] > Sent: Tuesday, February 02, 2016 4:23 PM > To: Stuart Kemp > Cc: openssl-dev at openssl.org > Subject: [openssl.org #3713] Bug: openssl-1.0.1l, FIPS, HP-UX ia64, Duplicate Symbol "AES_Te" and "AES_Td" > > If you sneeze on the FIPS code, you need a new CMVP change letter. > Setting realistic expectations, there are no plans at this time for any FIPS > work. > -- > Rich Salz, OpenSSL dev team; rsalz at openssl.org > > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > From rt at openssl.org Wed Feb 3 13:40:03 2016 From: rt at openssl.org (Rich Salz via RT) Date: Wed, 03 Feb 2016 13:40:03 +0000 Subject: [openssl-dev] [openssl.org #636] Example in man page for BIO_new_bio_pair incorrect? References: Message-ID: I've had this ticket open in my list for a long time. I am reluctantly closing it now. It would be great if someone had a simple testcase or doc fix against current releases. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Wed Feb 3 13:53:45 2016 From: rt at openssl.org (Rich Salz via RT) Date: Wed, 03 Feb 2016 13:53:45 +0000 Subject: [openssl-dev] [openssl.org #1852] [BUG] Invalid Proxy Certificates Pass Validation In-Reply-To: <49A81357.30509@switch.ch> References: <49A81357.30509@switch.ch> Message-ID: Re-opening it. It would be good to decide soon if we should do this. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Wed Feb 3 13:57:36 2016 From: rt at openssl.org (Andy Polyakov via RT) Date: Wed, 03 Feb 2016 13:57:36 +0000 Subject: [openssl-dev] [openssl.org #3713] Bug: openssl-1.0.1l, FIPS, HP-UX ia64, Duplicate Symbol "AES_Te" and "AES_Td" In-Reply-To: <56B2074F.1030805@openssl.org> References: <54E457700200002800011EFF@prv-mh.provo.novell.com> <5B5209CB698EEC4D9710CEF6A83600EE35A45697@prvxmb04.microfocus.com> <74AF4309-61C1-45EE-8195-3DBDB8260CA3@tcsaf.com> <56B2074F.1030805@openssl.org> Message-ID: > Use an older version of OpenSSL for your FIPS-enabled OpenSSL? For this specific problem it wouldn't help. I mean even older versions should/would exhibit same problem. And renaming symbols or removing .global directives (in whatever OpenSSL version being linked with FIPS module, not FIPS module) would have to be performed for all of them. The reason for why the problem in question (and similar) slip through is that FIPS module validation procedure, exhausting as it is, does not involve linking with "big" OpenSSL. As result one risks to remain oblivious of them on rare platforms such as one in question till it becomes too late. But luckily enough one can modify "big" OpenSSL to accommodate such mishaps. Renaming symbols as general method or case-specific workarounds like removing .global directives in this case is the way to go. > Yes, > it might have security problems, but it you?re using the FIPS module! > It?s got worse security problems, so you shouldn?t worry. :) > > I can say for sure the FIPS 2.0 module compiled and worked at the > time the Security Policy was approved for HP-UX on IA64 and PA-RISC, > in both 32- and 64-bit flavors. But it was pretty picky about the > link editor and compiler. > > Two other issues to be aware of (and maybe fixing this will let the > more recent versions of OpenSSL work): > > 1) HP?s link editor is very brittle. You should be sure you?re using > the proper patch level for it. I no longer have access to the box I > was building on, and I?m not sure what the status of the box that was > sent for testing is, so I can?t check the patch-level for the link > editor. Take a look at the dates in the Security Policy, it was the > patch that came out about a month (or less?) prior to the submission > of the FIPS 2.0 module for approval. The previous patch wouldn?t > link anything except the HP-UX kernel, so it was released outside the > normal schedule (and the next patch broke it again, the patch after > that was OK, but I never tried that one with building the FIPS module > or FIPS-enabled OpenSSL). > > 2) You?re definitely using a newer version of the compiler; A.06.25 > was the current version when the FIPS stuff was approved; depending > on your auditors, you may need to be using that one. Especially > since the prior versions wouldn?t compile the FIPS module correctly, > I wouldn?t be surprised if newer ones are incapable, too. Seconded. From rt at openssl.org Wed Feb 3 13:57:56 2016 From: rt at openssl.org (Rich Salz via RT) Date: Wed, 03 Feb 2016 13:57:56 +0000 Subject: [openssl-dev] [openssl.org #3592] bug report. Crash. Critical? Security bug? In-Reply-To: References: Message-ID: There were some openssl DTLS bugs that MAtt found and fixed, and the last word in this ticket was that there were Asterisk bugs causing memory corruption. Closing ticket. From rt at openssl.org Wed Feb 3 14:12:19 2016 From: rt at openssl.org (Rich Salz via RT) Date: Wed, 03 Feb 2016 14:12:19 +0000 Subject: [openssl-dev] [openssl.org #1915] Bug Report : Abort when race condition occurs in ERR_get_state In-Reply-To: <49F88305.70306@free.fr> References: <49F88305.70306@free.fr> Message-ID: We're cleaning up the threads stuff, see GitHub PR 451. Thanks! -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Wed Feb 3 14:22:54 2016 From: rt at openssl.org (Stephen Henson via RT) Date: Wed, 03 Feb 2016 14:22:54 +0000 Subject: [openssl-dev] [openssl.org #4274] OpenSSL 1.1 X509_NAME_der() In-Reply-To: References: <56A7C890.7060706@symas.com> <56AB7E4E.90909@highlandsun.com> <56ABBA15.50501@symas.com> Message-ID: On Fri Jan 29 19:14:50 2016, hyc at symas.com wrote: > > Just to be clear - in our use case we already know the length. But if > the > function you're proposing is returning only a success/error code, then > the > function should probably also provide the length as a return > parameter, for > more general users. I've added a new function: int X509_NAME_get0_der(const unsigned char **pder, size_t *pderlen, X509_NAME *nm) Let me know if that suits your needs. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From rt at openssl.org Wed Feb 3 14:31:41 2016 From: rt at openssl.org (Howard Chu via RT) Date: Wed, 03 Feb 2016 14:31:41 +0000 Subject: [openssl-dev] [openssl.org #4274] OpenSSL 1.1 X509_NAME_der() In-Reply-To: <56B20F3D.5060808@symas.com> References: <56A7C890.7060706@symas.com> <56AB7E4E.90909@highlandsun.com> <56ABBA15.50501@symas.com> <56B20F3D.5060808@symas.com> Message-ID: Stephen Henson via RT wrote: > On Fri Jan 29 19:14:50 2016, hyc at symas.com wrote: >> >> Just to be clear - in our use case we already know the length. But if >> the >> function you're proposing is returning only a success/error code, then >> the >> function should probably also provide the length as a return >> parameter, for >> more general users. > > I've added a new function: > > int X509_NAME_get0_der(const unsigned char **pder, size_t *pderlen, > X509_NAME *nm) > > Let me know if that suits your needs. Thanks, yes, works fine. I saw your commit and merged our support for it already. http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=commit;h=6bb6d5e3c6269589f5e64805bd849174d62bd3ea -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ From rt at openssl.org Wed Feb 3 14:55:40 2016 From: rt at openssl.org (Jeroen Pluimers via RT) Date: Wed, 03 Feb 2016 14:55:40 +0000 Subject: [openssl-dev] [openssl.org #3155] Bug report: S/MIME base64 decoding fails on files that have 76 base64 characters per line In-Reply-To: References: Message-ID: Hi Rich, Wow, thanks for reminding me about that. I know how hard it is to prioritise efforts, especially on open source projects, so I am really glad there is a fix meaning a workaround for these files isn't needed any more. Keep up the good work! Regards, Groet, -- Jeroen W. Pluimers - specialist in .NET, Win32, SQL, Visual Studio & Delphi tel: +31 20 610 8322 fax: +31 20 610 8323 GSM: +31 654 385 135 mailto:jeroen at pluimers.com Pluimers Software Ontwikkeling BV, Amsterdam, Trade-register 34152606 http://wiert.me ; http://jwpluimers.myplaxo.com/ On Mon, Feb 1, 2016 at 8:52 PM, Rich Salz via RT wrote: > We believe this is fixed, please re-open the ticket if not. > -- > Rich Salz, OpenSSL dev team; rsalz at openssl.org > > From rt at openssl.org Wed Feb 3 14:56:15 2016 From: rt at openssl.org (Stephen Henson via RT) Date: Wed, 03 Feb 2016 14:56:15 +0000 Subject: [openssl-dev] [openssl.org #4274] OpenSSL 1.1 X509_NAME_der() In-Reply-To: <56A7C890.7060706@symas.com> References: <56A7C890.7060706@symas.com> Message-ID: OK thanks for the update, ticket resolved. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From rt at openssl.org Wed Feb 3 15:23:34 2016 From: rt at openssl.org (HM via RT) Date: Wed, 03 Feb 2016 15:23:34 +0000 Subject: [openssl-dev] [openssl.org #4290] HMAC_Init_ex() return bug In-Reply-To: <75375288-D03A-4B51-ACC3-0995877DF1AF@high-mobility.com> References: <75375288-D03A-4B51-ACC3-0995877DF1AF@high-mobility.com> Message-ID: Hey, i?m writing to let you know, that the HMAC_Init_ex() function returns a random int whenever i use it. This is in contrast to the documentation, that says ?1 for success, 0 for an error?. I?m running OS X 10.11.3 and OpenSSL 1.0.206 Best of wishes, -- Mikk R?tsep Developer mikk at high-mobility.com +372 51 54 052 HIGH MOBILITY berlin . tallinn . high-mobility.com From rt at openssl.org Wed Feb 3 15:23:34 2016 From: rt at openssl.org (Dannhauer Torben via RT) Date: Wed, 03 Feb 2016 15:23:34 +0000 Subject: [openssl-dev] [openssl.org #4289] OpenSSL 1.0.2f serious bug in Win32 makefiles, easy to fix, solution provided (was: [OpenSSL Bug #2928]) In-Reply-To: <6437c65f043f4f66b4b01a7930000a29@pmuex06.pmu.local> References: <6437c65f043f4f66b4b01a7930000a29@pmuex06.pmu.local> Message-ID: This bug affects 1.0.2.f and supposedly also 1.1.0 alpha, I reported it already 3 years (!!) ago as Bug #2928 for OpenSSL 1.0.1c, but it was closed yesterday since 1.0.1 development is finished. Please find attached the Bug description again for OpenSSL 1.0.2f. I provide already a solution, so please apply the bug fix to trunk, 1.0.2 and 1.1.0 branches The bug is not obvious since only few people use the MSBuild System in this extend. However, it is clearly defined by MS how it's build system works and thus why OpenSSL building fails in certain conditions. -- BUG DESCRIPTION (Copied and updated from Bug #2928) -- Dear OpenSSL Team, I recently tried to build OpenSSL with Visual Studio and I discovered a very annoying but easy to fix bug: In the makefile created by Perl, the linker binary name is assigned to a variable named LINK. This variable $(LINK) is called to execute the linker call. This causes a serious collision with the MS Visual Studio build system which also relies on a variable named LINK: In Visual Studio, the compiler is called cl.exe and the linker is called link.exe. On invocation, they append the command line arguments to the environment variable identical to their name (if they exist). This allows to define "global" linker or compiler flags which are not part of the makefile. On the backside this also implies that a makefile must not use internal variable names identical to the build systems env-vars "LINK" and "CL". This error was observed with MS VS 2013 Update 5 but applies to older Visual Studios as well. ## Example with the CURRENT (WRONG) status ##### Build Environment (Visual Studio Command line): SET LINK= Makefile of OpenSSL SET LINK=link.exe SET LINKER_ARGS= The resulting linker call triggered by the makefile script is then: $(LINK) $(LINKER_ARGS) Which is extended by the MSVC build system to (because MSVC adds the content of the variable LINK after the linker command) $(LINK) $(LINK) $(LINKER_ARGS) and finally stripped to: link.exe link.exe This is a double invocation of link.exe which causes link to try linking itself, which of course fails. ### CORRECTED Example ##### Build Environment (Visual Studio Command line): SET LINK= Makefile: SET LINKER_BIN=link.exe SET LINKER_ARGS= The call should be: $(LINKER_BIN) $(LINKER_ARGS) Which would be extended by the MSVC build system to $(LINKER_BIN) $(LINK) $(LINKER_ARGS) and finally be stripped to: link.exe ==>This would be correct and working #### How to solve it: ##### - Never use the variables named LINK and CL inside the makefiles or their generator scripts. - Please call the binary variables different, e.g. LINKER_BIN and COMPILER_BIN - Adapt your build scripts to generate such corrected makefiles Thank you for your help Kind regards, Torben Dannhauer From jun.sun at infosecglobal.com Wed Feb 3 15:21:56 2016 From: jun.sun at infosecglobal.com (Jun Sun) Date: Wed, 3 Feb 2016 15:21:56 +0000 Subject: [openssl-dev] [openssl.org #4284] Bug in nistz256 assembly code. In-Reply-To: References: <56B1CF54.2050200@openssl.org> , Message-ID: Hi Billy, Thank you very much for verify the bug! The reason ecp_nistz256_point_add_affine is not affected is that this function is only used when a scalar is multiplying the generator point G. In this case, a big pre-computed table is used with a 7 bit window size for all fixed window positions (that is why the table has 37x64 entries and you do not see a point doubling function called there). So at the point when ecp_nistz256_point_add_affine is called, p.p is holding the accumulated previous window scalar data (lower bits of scalar) by G, and t.a is holding the current window scalar value by G, they will never meet each other. So inside ecp_nistz256_point_add_affine, no logic to check for doubling. Jun Sun ________________________________________ From: Billy Brumley via RT Sent: February 3, 2016 6:05 AM To: Jun Sun Cc: openssl-dev at openssl.org Subject: Re: [openssl-dev] [openssl.org #4284] Bug in nistz256 assembly code. > Thanks! Verify attached diff. Without looking too closely at the asm, at least the output now looks OK to me: Input point: P ad4cfe7307736330 5a390846abdb19e5 bc92e079b12de03f 3a6b3ebcbf24755d 5ed0dbce609dcf3b 091a794357eca9ee acb4d5512ea7232f 09d787c5915c070a d482c016856ed40a 4a9e64127c9216d7 308267a3a3c72f6c 99a4ef25b90c6499 after ecp_nistz256_point_add(A, P, P) 52d422c756922166 033fb71af0fd3251 b38e0f88b5a2b2a4 bd964cc28ad2bf39 61c01cf1c0a9b7f9 5acaf8aa07f449fc 62b8600cf22cec6b ab80a212e72fb53d b4a67dfe55eb1133 ec19e9f97640f280 1a3caeebc962ab48 19a5d850b22fa55b after ecp_nistz256_point_double(B, P) 52d422c756922166 033fb71af0fd3251 b38e0f88b5a2b2a4 bd964cc28ad2bf39 61c01cf1c0a9b7f9 5acaf8aa07f449fc 62b8600cf22cec6b ab80a212e72fb53d b4a67dfe55eb1133 ec19e9f97640f280 1a3caeebc962ab48 19a5d850b22fa55b I will say that I don't understand how ecp_nistz256_point_add_affine does not have these conditions. Maybe that's a question for the original authors. BBB This email and any attachments are for the sole use of the intended recipients and may be privileged or confidential. Any distribution, printing or other use by anyone else is prohibited. If you are not an intended recipient, please contact the sender immediately, and permanently delete this email and attachments. From rt at openssl.org Wed Feb 3 15:37:48 2016 From: rt at openssl.org (Jun Sun via RT) Date: Wed, 03 Feb 2016 15:37:48 +0000 Subject: [openssl-dev] [openssl.org #4284] Bug in nistz256 assembly code. In-Reply-To: References: <56B1CF54.2050200@openssl.org> , Message-ID: Hi Billy, Thank you very much for verify the bug! The reason ecp_nistz256_point_add_affine is not affected is that this function is only used when a scalar is multiplying the generator point G. In this case, a big pre-computed table is used with a 7 bit window size for all fixed window positions (that is why the table has 37x64 entries and you do not see a point doubling function called there). So at the point when ecp_nistz256_point_add_affine is called, p.p is holding the accumulated previous window scalar data (lower bits of scalar) by G, and t.a is holding the current window scalar value by G, they will never meet each other. So inside ecp_nistz256_point_add_affine, no logic to check for doubling. Jun Sun ________________________________________ From: Billy Brumley via RT Sent: February 3, 2016 6:05 AM To: Jun Sun Cc: openssl-dev at openssl.org Subject: Re: [openssl-dev] [openssl.org #4284] Bug in nistz256 assembly code. > Thanks! Verify attached diff. Without looking too closely at the asm, at least the output now looks OK to me: Input point: P ad4cfe7307736330 5a390846abdb19e5 bc92e079b12de03f 3a6b3ebcbf24755d 5ed0dbce609dcf3b 091a794357eca9ee acb4d5512ea7232f 09d787c5915c070a d482c016856ed40a 4a9e64127c9216d7 308267a3a3c72f6c 99a4ef25b90c6499 after ecp_nistz256_point_add(A, P, P) 52d422c756922166 033fb71af0fd3251 b38e0f88b5a2b2a4 bd964cc28ad2bf39 61c01cf1c0a9b7f9 5acaf8aa07f449fc 62b8600cf22cec6b ab80a212e72fb53d b4a67dfe55eb1133 ec19e9f97640f280 1a3caeebc962ab48 19a5d850b22fa55b after ecp_nistz256_point_double(B, P) 52d422c756922166 033fb71af0fd3251 b38e0f88b5a2b2a4 bd964cc28ad2bf39 61c01cf1c0a9b7f9 5acaf8aa07f449fc 62b8600cf22cec6b ab80a212e72fb53d b4a67dfe55eb1133 ec19e9f97640f280 1a3caeebc962ab48 19a5d850b22fa55b I will say that I don't understand how ecp_nistz256_point_add_affine does not have these conditions. Maybe that's a question for the original authors. BBB This email and any attachments are for the sole use of the intended recipients and may be privileged or confidential. Any distribution, printing or other use by anyone else is prohibited. If you are not an intended recipient, please contact the sender immediately, and permanently delete this email and attachments. From dragon at dancingdragon.be Wed Feb 3 16:15:56 2016 From: dragon at dancingdragon.be (Joey Yandle) Date: Wed, 3 Feb 2016 08:15:56 -0800 Subject: [openssl-dev] [openssl.org #4289] OpenSSL 1.0.2f serious bug in Win32 makefiles, easy to fix, solution provided In-Reply-To: References: <6437c65f043f4f66b4b01a7930000a29@pmuex06.pmu.local> Message-ID: <56B227BC.2020909@dancingdragon.be> > In the makefile created by Perl, the linker binary name is assigned to a variable named LINK. This variable $(LINK) is called to execute the linker call. > This causes a serious collision with the MS Visual Studio build system which also relies on a variable named LINK: Are you invoking msbuild.exe to build openssl? The supported build instructions use nmake.exe directly on the generated makefiles. What is your build invocation? cheers, Joey From rt at openssl.org Wed Feb 3 16:15:48 2016 From: rt at openssl.org (Joey Yandle via RT) Date: Wed, 03 Feb 2016 16:15:48 +0000 Subject: [openssl-dev] [openssl.org #4289] OpenSSL 1.0.2f serious bug in Win32 makefiles, easy to fix, solution provided In-Reply-To: <56B227BC.2020909@dancingdragon.be> References: <6437c65f043f4f66b4b01a7930000a29@pmuex06.pmu.local> <56B227BC.2020909@dancingdragon.be> Message-ID: > In the makefile created by Perl, the linker binary name is assigned to a variable named LINK. This variable $(LINK) is called to execute the linker call. > This causes a serious collision with the MS Visual Studio build system which also relies on a variable named LINK: Are you invoking msbuild.exe to build openssl? The supported build instructions use nmake.exe directly on the generated makefiles. What is your build invocation? cheers, Joey From rt at openssl.org Wed Feb 3 16:27:15 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Wed, 03 Feb 2016 16:27:15 +0000 Subject: [openssl-dev] [openssl.org #4290] HMAC_Init_ex() return bug In-Reply-To: References: <75375288-D03A-4B51-ACC3-0995877DF1AF@high-mobility.com> Message-ID: > I?m running OS X 10.11.3 and OpenSSL 1.0.206 I cannot reproduce this. Did you build from source, or is that a vendor-provided version? The ".206" isn't part of our release naming. Did you mean 1.0.2f? Do you have a sample program to show the error? From cata.vasile at nxp.com Wed Feb 3 16:34:44 2016 From: cata.vasile at nxp.com (Catalin Vasile) Date: Wed, 3 Feb 2016 16:34:44 +0000 Subject: [openssl-dev] [crypto engine]: API users try to find separate external library for new engine Message-ID: I'm trying to make a new crypto engine. Any application that tries to use my custom OpenSSL library that includes my engine gives me an error trying to find an external library for my new engine (it tries to locate /usr/lib/libhwrng.so, where hwrng is my engine), although if I run a "grep -R 'hwrng' . " in the install folder it finds references in the libcrypto.so . I have done a "grep -R 'cryptodev' ." and it is referenced the same amount of times and in the same files. What could I be missing that cryptodev is loaded "naturally" (it knows it's inside libcrypto.so), but engine hwrng is seen as being something totally external? Cata -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Wed Feb 3 17:12:24 2016 From: rt at openssl.org (=?UTF-8?B?RW1pbGlhIEvDpHNwZXI=?= via RT) Date: Wed, 03 Feb 2016 17:12:24 +0000 Subject: [openssl-dev] [openssl.org #3234] [bug] openssl defaults to using tls compression In-Reply-To: References: Message-ID: 1.1.0 now defaults to no compression: dc5744cb78da6f2bcafeeefe22c604a51b52dfc5. From cata.vasile at nxp.com Wed Feb 3 17:00:44 2016 From: cata.vasile at nxp.com (Catalin Vasile) Date: Wed, 3 Feb 2016 17:00:44 +0000 Subject: [openssl-dev] [crypto engine]: API users try to find separate external library for new engine Message-ID: I'm trying to make a new crypto engine. Any application that tries to use my custom OpenSSL library?that includes my engine gives me an error trying to find an external library for my new engine (it tries to locate /usr/lib/libhwrng.so, where hwrng is my engine), although if I run a "grep -R 'hwrng' . " in the install folder?it finds references in the libcrypto.so . I have done a "grep -R 'cryptodev' ." and it is referenced the same amount of times and in the same files. What could I be missing that cryptodev is loaded "naturally" (it knows it's inside libcrypto.so), but engine hwrng is seen as being something totally external? Cata From agostrer at gmail.com Wed Feb 3 17:20:14 2016 From: agostrer at gmail.com (Alexander Gostrer) Date: Wed, 3 Feb 2016 09:20:14 -0800 Subject: [openssl-dev] [crypto engine]: API users try to find separate external library for new engine In-Reply-To: References: Message-ID: Hi Cata, We solved this problem in our project: https://github.com/AtmelCSO/cryptoauth-openssl-engine I may be wrong but I think it was done using "export LD_LIBRARY_PATH=". Try it. If it will not work then you dig into our engine. Regards, Alex Gostrer On Wed, Feb 3, 2016 at 9:00 AM, Catalin Vasile wrote: > > > I'm trying to make a new crypto engine. > > Any application that tries to use my custom OpenSSL library that includes > my engine gives me an error trying to find an external library for my new > engine (it tries to locate /usr/lib/libhwrng.so, where hwrng is my > engine), although if I run a "grep -R 'hwrng' . " in the install folder it > finds references in the libcrypto.so . > > I have done a "grep -R 'cryptodev' ." and it is referenced the same amount > of times and in the same files. > What could I be missing that cryptodev is loaded "naturally" (it knows > it's inside libcrypto.so), but engine hwrng is seen as being something > totally external? > > > Cata > > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Wed Feb 3 17:21:54 2016 From: rt at openssl.org (Andy Polyakov via RT) Date: Wed, 03 Feb 2016 17:21:54 +0000 Subject: [openssl-dev] [openssl.org #4289] OpenSSL 1.0.2f serious bug in Win32 makefiles, easy to fix, solution provided In-Reply-To: <56B23730.1090306@openssl.org> References: <6437c65f043f4f66b4b01a7930000a29@pmuex06.pmu.local> <56B227BC.2020909@dancingdragon.be> <56B23730.1090306@openssl.org> Message-ID: On 02/03/16 17:15, Joey Yandle via RT wrote: >> In the makefile created by Perl, the linker binary name is assigned to a variable named LINK. This variable $(LINK) is called to execute the linker call. >> This causes a serious collision with the MS Visual Studio build system which also relies on a variable named LINK: > > Are you invoking msbuild.exe to build openssl? The supported build > instructions use nmake.exe directly on the generated makefiles. > > What is your build invocation? That was my initial reaction too. The problem description sounds like as if something else is being talked about. Indeed, it refers to SET LINK=link.exe (there is not *SET* LINK in generated makefile), and you can't help wondering how would such problem go unnoticed for such long time. But as it turns out... Consider FOO=bar all: echo %%FOO%% If passed to nmake, it prints "%FOO%" as long as there is no environment variable named FOO. But as soon as you assign FOO variable prior invoking nmake it prints "bar" irregardless[!] FOO's original value. LINK (as well as _LINK_) and CL (as well as _CL_) are indeed variables that can be used to specify kind of site-specific defaults. I find it hard to imagine how LINK would be useful in general case, i.e. as something that would be applicable to *all* linked binaries, but I suppose one can't deny the option to do so. Out of curiosity what's yours? And verify attached diff and report back. -------------- next part -------------- A non-text attachment was scrubbed... Name: RT4289.diff Type: text/x-patch Size: 6663 bytes Desc: not available URL: From levitte at openssl.org Wed Feb 3 17:30:29 2016 From: levitte at openssl.org (Richard Levitte) Date: Wed, 03 Feb 2016 18:30:29 +0100 (CET) Subject: [openssl-dev] [crypto engine]: API users try to find separate external library for new engine In-Reply-To: References: Message-ID: <20160203.183029.1902727104752252373.levitte@openssl.org> In message on Wed, 3 Feb 2016 16:34:44 +0000, Catalin Vasile said: cata.vasile> I'm trying to make a new crypto engine. cata.vasile> cata.vasile> Any application that tries to use my custom OpenSSL cata.vasile> library that includes my engine gives me an error trying cata.vasile> to find an external library for my new engine (it tries cata.vasile> to locate /usr/lib/libhwrng.so, where hwrng is my cata.vasile> engine), although if I run a "grep -R 'hwrng' . " in the cata.vasile> install folder it finds references in the libcrypto.so . cata.vasile> cata.vasile> I have done a "grep -R 'cryptodev' ." and it is cata.vasile> referenced the same amount of times and in the same cata.vasile> files. cata.vasile> cata.vasile> What could I be missing that cryptodev is loaded cata.vasile> "naturally" (it knows it's inside libcrypto.so), but cata.vasile> engine hwrng is seen as being something totally external? So it sounds like you've make your engine part of libcrypto.so instead of making it a separate dynamic lib, is that correct? We don't really support that, even if it is possible. Can I encourage you to make your engine a separate dynamic lib? If you want a quick crash course on how to do that, may I suggest you have a look at the blog series I started a few months ago? This blog will tell you the basics (*very* basic, but does demonstrate the dynamic library solution): https://www.openssl.org/blog/blog/2015/10/08/engine-building-lesson-1-a-minimum-useless-engine/ Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From rt at openssl.org Wed Feb 3 17:31:59 2016 From: rt at openssl.org (=?UTF-8?B?RW1pbGlhIEvDpHNwZXI=?= via RT) Date: Wed, 03 Feb 2016 17:31:59 +0000 Subject: [openssl-dev] [openssl.org #4148] PCKS1 type 1 Padding check error In-Reply-To: <81BFD559DE725D46BA495E091789F8DD016AF6C497@MAILSERV2A.lorien.fkie.fgan.de> References: <81BFD559DE725D46BA495E091789F8DD016AF6C497@MAILSERV2A.lorien.fkie.fgan.de> Message-ID: Resolved in ba2de73b185016e0a98e62f75b368ab6ae673919 for master (1.1.0). This isn't really a bug so we won't be backporting to stable branches, though. From kurt at roeckx.be Wed Feb 3 18:12:29 2016 From: kurt at roeckx.be (Kurt Roeckx) Date: Wed, 3 Feb 2016 19:12:29 +0100 Subject: [openssl-dev] Fwd: CVE-2014-8730 TLS CBC Incorrect Padding Abuse Vulnerability In-Reply-To: References: Message-ID: <20160203181229.GA4282@roeckx.be> On Wed, Feb 03, 2016 at 05:11:34PM +0530, Shyamal Bhowmik wrote: > > /* enc_err is: > * 0: (in non-constant time) if the record is publically invalid. > * 1: if the padding is valid > * -1: if the padding is invalid */ > if (enc_err == 0) > { > al=SSL_AD_DECRYPTION_FAILED; > SSLerr(SSL_F_SSL3_GET_RECORD,SSL_R_BLOCK_CIPHER_PAD_IS_WRONG); > goto f_err; > } > > As seen from above, error is thrown only for 0 return value and -1 return > value is not handled. So if i change the code if (enc_err == 0) to if > (enc_err <= 0) will solve my problem? If you change that to <= 0 you will introduce a security problem by leaking timing information. There is an other check for < 0 below. > There was no specific way to reproduce this issue and it was seen very > sporadically. I'm not sure what you're trying to fix, but if you're getting padding it's also possible that you actually received a padding error. This also doesn't seem to have anything to do with CVE-2014-8730 which we weren't vulnerable to, as you actually explained yourself. Kurt From rt at openssl.org Wed Feb 3 18:32:20 2016 From: rt at openssl.org (HM via RT) Date: Wed, 03 Feb 2016 18:32:20 +0000 Subject: [openssl-dev] [openssl.org #4290] HMAC_Init_ex() return bug In-Reply-To: <3FB3F54A-CD47-4FD4-A3D1-5877646B2118@gmail.com> References: <75375288-D03A-4B51-ACC3-0995877DF1AF@high-mobility.com> <3FB3F54A-CD47-4FD4-A3D1-5877646B2118@gmail.com> Message-ID: I built it using cocoapods, the OpenSSL headers show 1.0.2f. I?ll try to make some sample program tomorrow. > On 3 veebr 2016, at 18:27, Salz, Rich via RT wrote: > >> I?m running OS X 10.11.3 and OpenSSL 1.0.206 > > I cannot reproduce this. Did you build from source, or is that a vendor-provided version? The ".206" isn't part of our release naming. Did you mean 1.0.2f? Do you have a sample program to show the error? > > From rt at openssl.org Wed Feb 3 19:24:48 2016 From: rt at openssl.org (Torben Dannhauer via RT) Date: Wed, 03 Feb 2016 19:24:48 +0000 Subject: [openssl-dev] [openssl.org #4289] OpenSSL 1.0.2f serious bug in Win32 makefiles, easy to fix, solution provided In-Reply-To: <20160203201617.Horde.EoMOVndd8H4N65C2EUikDDP@www.dannhauer.de> References: <6437c65f043f4f66b4b01a7930000a29@pmuex06.pmu.local> <56B227BC.2020909@dancingdragon.be> <56B23730.1090306@openssl.org> <20160203201617.Horde.EoMOVndd8H4N65C2EUikDDP@www.dannhauer.de> Message-ID: Zitat von Andy Polyakov via RT : > On 02/03/16 17:15, Joey Yandle via RT wrote: >>> In the makefile created by Perl, the linker binary name is assigned to a >>> variable named LINK. This variable $(LINK) is called to execute the >>> linker call. >>> This causes a serious collision with the MS Visual Studio build system >>> which also relies on a variable named LINK: >> >> Are you invoking msbuild.exe to build openssl? The supported build >> instructions use nmake.exe directly on the generated makefiles. >> >> What is your build invocation? > > That was my initial reaction too. The problem description sounds like as > if something else is being talked about. Indeed, it refers to SET > LINK=link.exe (there is not *SET* LINK in generated makefile), and you > can't help wondering how would such problem go unnoticed for such long > time. But as it turns out... Consider > > FOO=bar > > all: > echo %%FOO%% > > If passed to nmake, it prints "%FOO%" as long as there is no environment > variable named FOO. But as soon as you assign FOO variable prior > invoking nmake it prints "bar" irregardless[!] FOO's original value. > LINK (as well as _LINK_) and CL (as well as _CL_) are indeed variables > that can be used to specify kind of site-specific defaults. I find it > hard to imagine how LINK would be useful in general case, i.e. as > something that would be applicable to *all* linked binaries, but I > suppose one can't deny the option to do so. Out of curiosity what's > yours? And verify attached diff and report back. Hi, thanks for feedback, I use nmake as described in the instructions. Indeed, as I discovered and reported the bug 3 years ago, my first question was how such a problem was undiscovered for so a long time. At least now we are talking about it and agree we should fix it. Technical details: The env variable LINK is only evaluated by link.exe if it is set in the commandline (e.g. as required for compiling WinXP compatible binaries with VS 2012 and newer: setting another subsystem version) Since WinXP compiling is more than only setting linker flags, we simulate it by setting instead a empty LINK variable- the key aspect is that the COMMANDLINE has a set LINK variable , then the LINK variable is evaluated by link.exe and the error occurs. This happens because the OpenSSL makefile uses a also variable named LINK. To reproduce the error, open visual studio x64 commandline and enter: Set link="" perl Configure VC-WIN64A --prefix=c:\tmp_open_ssl_x64 ms\do_win64a nmake -f "ms\ntdll.mak" -> wait and see the linker step failing.. The provided patch is exactly what I did the last 3 years manually in the ntdll.mak makefile before starting the compilation. I would be very glad to see it marger into trunk. regards, Torben PS.: The full story to compile WinXP compatible binaries on commandline in VS2012 and newer is this: ------- x86 ----------------- @set INCLUDE=%ProgramFiles(x86)%\Microsoft SDKs\Windows\7.1A\Include;%INCLUDE% @set PATH=%ProgramFiles(x86)%\Microsoft SDKs\Windows\7.1A\Bin;%PATH% @set LIB=%ProgramFiles(x86)%\Microsoft SDKs\Windows\7.1A\Lib;%LIB% @set CL=/D_USING_V110_SDK71_;%CL% @set LINK=/SUBSYSTEM:CONSOLE,5.01 /MANIFEST %LINK% @echo Switched to XP target x86 ----------- x64 (WinXp x64 is quite rare) @set INCLUDE=%ProgramFiles(x86)%\Microsoft SDKs\Windows\7.1A\Include;%INCLUDE% @set PATH=%ProgramFiles(x86)%\Microsoft SDKs\Windows\7.1A\Bin;%PATH% @set LIB=%ProgramFiles(x86)%\Microsoft SDKs\Windows\7.1A\Lib\x64;%LIB% @set CL=/D_USING_V110_SDK71_;%CL% @set LINK=/SUBSYSTEM:CONSOLE,5.02 /MANIFEST %LINK% @echo Switched to XP target x64 From dragon at dancingdragon.be Wed Feb 3 19:33:49 2016 From: dragon at dancingdragon.be (Joey Yandle) Date: Wed, 3 Feb 2016 11:33:49 -0800 Subject: [openssl-dev] [openssl.org #4289] OpenSSL 1.0.2f serious bug in Win32 makefiles, easy to fix, solution provided In-Reply-To: References: <6437c65f043f4f66b4b01a7930000a29@pmuex06.pmu.local> <56B227BC.2020909@dancingdragon.be> <56B23730.1090306@openssl.org> <20160203201617.Horde.EoMOVndd8H4N65C2EUikDDP@www.dannhauer.de> Message-ID: <56B2561D.1080803@dancingdragon.be> I verified the problem on both 1.0.2f and master: set LINK=/DEBUG perl Configure VC-WIN64A ms\do_win64a.bat nmake -f ms\nt.make link /nologo /subsystem:console /opt:ref /debug /out:out32\openssl.exe @C:\Users\oscar\AppData\Local\Temp\nm45EB.tmp LINK : fatal error LNK1181: cannot open input file 'link.obj' NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\BIN\amd64\link.EXE"' : return code '0x49d' From rt at openssl.org Wed Feb 3 19:33:58 2016 From: rt at openssl.org (Joey Yandle via RT) Date: Wed, 03 Feb 2016 19:33:58 +0000 Subject: [openssl-dev] [openssl.org #4289] OpenSSL 1.0.2f serious bug in Win32 makefiles, easy to fix, solution provided In-Reply-To: <56B2561D.1080803@dancingdragon.be> References: <6437c65f043f4f66b4b01a7930000a29@pmuex06.pmu.local> <56B227BC.2020909@dancingdragon.be> <56B23730.1090306@openssl.org> <20160203201617.Horde.EoMOVndd8H4N65C2EUikDDP@www.dannhauer.de> <56B2561D.1080803@dancingdragon.be> Message-ID: I verified the problem on both 1.0.2f and master: set LINK=/DEBUG perl Configure VC-WIN64A ms\do_win64a.bat nmake -f ms\nt.make link /nologo /subsystem:console /opt:ref /debug /out:out32\openssl.exe @C:\Users\oscar\AppData\Local\Temp\nm45EB.tmp LINK : fatal error LNK1181: cannot open input file 'link.obj' NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\BIN\amd64\link.EXE"' : return code '0x49d' From rt at openssl.org Wed Feb 3 19:35:35 2016 From: rt at openssl.org (Torben Dannhauer via RT) Date: Wed, 03 Feb 2016 19:35:35 +0000 Subject: [openssl-dev] [openssl.org #4289] OpenSSL 1.0.2f serious bug in Win32 makefiles, easy to fix, solution provided In-Reply-To: <004e01d15eba$0c903380$25b09a80$@dannhauer.info> References: <004e01d15eba$0c903380$25b09a80$@dannhauer.info> Message-ID: Zitat von Andy Polyakov via RT < rt at openssl.org>: > On 02/03/16 17:15, Joey Yandle via RT wrote: >>> In the makefile created by Perl, the linker binary name is assigned >>> to a variable named LINK. This variable $(LINK) is called to execute >>> the linker call. >>> This causes a serious collision with the MS Visual Studio build >>> system which also relies on a variable named LINK: >> >> Are you invoking msbuild.exe to build openssl? The supported build >> instructions use nmake.exe directly on the generated makefiles. >> >> What is your build invocation? > > That was my initial reaction too. The problem description sounds like > as if something else is being talked about. Indeed, it refers to SET > LINK=link.exe (there is not *SET* LINK in generated makefile), and you > can't help wondering how would such problem go unnoticed for such long > time. But as it turns out... Consider > > FOO=bar > > all: > echo %%FOO%% > > If passed to nmake, it prints "%FOO%" as long as there is no > environment variable named FOO. But as soon as you assign FOO variable > prior invoking nmake it prints "bar" irregardless[!] FOO's original value. > LINK (as well as _LINK_) and CL (as well as _CL_) are indeed variables > that can be used to specify kind of site-specific defaults. I find it > hard to imagine how LINK would be useful in general case, i.e. as > something that would be applicable to *all* linked binaries, but I > suppose one can't deny the option to do so. Out of curiosity what's > yours? And verify attached diff and report back. Hi, thanks for feedback, I use nmake as described in the instructions. Indeed, as I discovered and reported the bug 3 years ago, my first question was how such a problem was undiscovered for so a long time. At least now we are talking about it and agree we should fix it. Technical details: The env variable LINK is only evaluated by link.exe if it is set in the commandline (e.g. as required for compiling WinXP compatible binaries with VS 2012 and newer: setting another subsystem version) Since WinXP compiling is more than only setting linker flags, we simulate it by setting instead a empty LINK variable- the key aspect is that the COMMANDLINE has a set LINK variable , then the LINK variable is evaluated by link.exe and the error occurs. This happens because the OpenSSL makefile uses a also variable named LINK. To reproduce the error, open visual studio x64 commandline and enter: Set link="" perl Configure VC-WIN64A --prefix=c:\tmp_open_ssl_x64 ms\do_win64a nmake -f "ms\ntdll.mak" -> wait and see the linker step failing.. The provided patch is exactly what I did the last 3 years manually in the ntdll.mak makefile before starting the compilation. I would be very glad to see it marger into trunk. regards, Torben PS.: The full story to compile WinXP compatible binaries on commandline in VS2012 and newer is this: ------- x86 ----------------- @set INCLUDE=%ProgramFiles(x86)%\Microsoft SDKs\Windows\7.1A\Include;%INCLUDE% @set PATH=%ProgramFiles(x86)%\Microsoft SDKs\Windows\7.1A\Bin;%PATH% @set LIB=%ProgramFiles(x86)%\Microsoft SDKs\Windows\7.1A\Lib;%LIB% @set CL=/D_USING_V110_SDK71_;%CL% @set LINK=/SUBSYSTEM:CONSOLE,5.01 /MANIFEST %LINK% @echo Switched to XP target x86 ----------- x64 (WinXp x64 is quite rare) @set INCLUDE=%ProgramFiles(x86)%\Microsoft SDKs\Windows\7.1A\Include;%INCLUDE% @set PATH=%ProgramFiles(x86)%\Microsoft SDKs\Windows\7.1A\Bin;%PATH% @set LIB=%ProgramFiles(x86)%\Microsoft SDKs\Windows\7.1A\Lib\x64;%LIB% @set CL=/D_USING_V110_SDK71_;%CL% @set LINK=/SUBSYSTEM:CONSOLE,5.02 /MANIFEST %LINK% @echo Switched to XP target x64 From dragon at dancingdragon.be Wed Feb 3 19:41:42 2016 From: dragon at dancingdragon.be (Joey Yandle) Date: Wed, 3 Feb 2016 11:41:42 -0800 Subject: [openssl-dev] [openssl.org #4289] OpenSSL 1.0.2f serious bug in Win32 makefiles, easy to fix, solution provided In-Reply-To: References: <6437c65f043f4f66b4b01a7930000a29@pmuex06.pmu.local> <56B227BC.2020909@dancingdragon.be> <56B23730.1090306@openssl.org> Message-ID: <56B257F6.7060101@dancingdragon.be> > And verify attached diff and report back. The diff works perfectly on master, but exposed a new bug (bare snprintf). The following patch fixes it. I can make a PR (or add it to my existing PR #512) if you'd like. diff --git a/test/ssltest.c b/test/ssltest.c index 5d6700e..9cd2a53 100644 --- a/test/ssltest.c +++ b/test/ssltest.c @@ -1890,7 +1890,7 @@ int doit_localhost(SSL *s_ssl, SSL *c_ssl, int family, long count, if (BIO_do_accept(acpt) <= 0) goto err; - snprintf(addr_str, sizeof(addr_str), ":%s", BIO_get_accept_port(acpt)); + BIO_snprintf(addr_str, sizeof(addr_str), ":%s", BIO_get_accept_port(acpt)); client = BIO_new_connect(addr_str); BIO_set_conn_ip_family(client, family); From rt at openssl.org Wed Feb 3 19:41:48 2016 From: rt at openssl.org (Joey Yandle via RT) Date: Wed, 03 Feb 2016 19:41:48 +0000 Subject: [openssl-dev] [openssl.org #4289] OpenSSL 1.0.2f serious bug in Win32 makefiles, easy to fix, solution provided In-Reply-To: <56B257F6.7060101@dancingdragon.be> References: <6437c65f043f4f66b4b01a7930000a29@pmuex06.pmu.local> <56B227BC.2020909@dancingdragon.be> <56B23730.1090306@openssl.org> <56B257F6.7060101@dancingdragon.be> Message-ID: > And verify attached diff and report back. The diff works perfectly on master, but exposed a new bug (bare snprintf). The following patch fixes it. I can make a PR (or add it to my existing PR #512) if you'd like. diff --git a/test/ssltest.c b/test/ssltest.c index 5d6700e..9cd2a53 100644 --- a/test/ssltest.c +++ b/test/ssltest.c @@ -1890,7 +1890,7 @@ int doit_localhost(SSL *s_ssl, SSL *c_ssl, int family, long count, if (BIO_do_accept(acpt) <= 0) goto err; - snprintf(addr_str, sizeof(addr_str), ":%s", BIO_get_accept_port(acpt)); + BIO_snprintf(addr_str, sizeof(addr_str), ":%s", BIO_get_accept_port(acpt)); client = BIO_new_connect(addr_str); BIO_set_conn_ip_family(client, family); From rt at openssl.org Wed Feb 3 19:43:43 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Wed, 03 Feb 2016 19:43:43 +0000 Subject: [openssl-dev] [openssl.org #4289] OpenSSL 1.0.2f serious bug in Win32 makefiles, easy to fix, solution provided In-Reply-To: <2fff15c8a72742c88f15bced48195faa@usma1ex-dag1mb1.msg.corp.akamai.com> References: <6437c65f043f4f66b4b01a7930000a29@pmuex06.pmu.local> <56B227BC.2020909@dancingdragon.be> <56B23730.1090306@openssl.org> <56B257F6.7060101@dancingdragon.be> <2fff15c8a72742c88f15bced48195faa@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: > The diff works perfectly on master, but exposed a new bug (bare snprintf). > The following patch fixes it. I can make a PR (or add it to my existing PR #512) > if you'd like. Please do as a separate PR. Thanks. From rt at openssl.org Wed Feb 3 19:45:04 2016 From: rt at openssl.org (Rich Salz via RT) Date: Wed, 03 Feb 2016 19:45:04 +0000 Subject: [openssl-dev] [openssl.org #1683] OPENSSL_NO_{RSA, DSA, DH} defines not honored In-Reply-To: <483FD49D.3010207@sun.com> References: <483FD49D.3010207@sun.com> Message-ID: For 1.1 we did a cleanup pass that should have fixed all of these. Please open a new ticket if there are still issues. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Wed Feb 3 19:50:58 2016 From: rt at openssl.org (Rich Salz via RT) Date: Wed, 03 Feb 2016 19:50:58 +0000 Subject: [openssl-dev] [openssl.org #1876] cross compilation patch from TANDBERG In-Reply-To: <49CB9A1A.30805@tandberg.com> References: <49CB9A1A.30805@tandberg.com> Message-ID: This is patch is for 0.9.8 The current releases have much better cross-compile support. Please open a new ticket if this is still an issue. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Wed Feb 3 19:53:51 2016 From: rt at openssl.org (Rich Salz via RT) Date: Wed, 03 Feb 2016 19:53:51 +0000 Subject: [openssl-dev] [openssl.org #1995] Man pages for the "rsa" utility should clearly state what output formats are used In-Reply-To: <1c690d740907230509r5cc04093q9f5983aa97833fc@mail.gmail.com> References: <1c690d740907230509r5cc04093q9f5983aa97833fc@mail.gmail.com> Message-ID: everything is now the standard format, except where noted. if i'm wrong, please re-open the ticket and give specifics so we can fix it. thanks. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Wed Feb 3 20:22:07 2016 From: rt at openssl.org (Broda, Frank via RT) Date: Wed, 03 Feb 2016 20:22:07 +0000 Subject: [openssl-dev] [openssl.org #4287] Option -attime for "openssl ts -verify" In-Reply-To: References: Message-ID: On 2016-02-02 15:56, Stephen Henson via RT [rt at openssl.org] wrote: > IMHO a better way to handle this is to make "ts" handle general verify options > the same way that ocsp, verify, cms, s_client and s_server do then you get > -attime support automatically. Your argument seems valid to me. I'll try, but it will take me some days. Frank From rt at openssl.org Wed Feb 3 21:14:01 2016 From: rt at openssl.org (Daniel Kahn Gillmor via RT) Date: Wed, 03 Feb 2016 21:14:01 +0000 Subject: [openssl-dev] [openssl.org #3203] Normalize PFS key exchange labels In-Reply-To: <87k2mlmr91.fsf@alice.fifthhorseman.net> References: <1387528669-26823-1-git-send-email-dkg@fifthhorseman.net> <87ioujykgn.fsf@alice.fifthhorseman.net> <87k2mlmr91.fsf@alice.fifthhorseman.net> Message-ID: On Tue 2016-02-02 14:08:18 -0500, Rich Salz via RT wrote: > any chance you can refresh your 1.0.2 patch? I'm interested in being able to > accept the common names but not changing the output for compatibility.. I am too :) it looks like it was already merged, though, as 0ec6898c67aeddc3c414f3cc1af2275d81329c20. 0 dkg at alice:~$ openssl version OpenSSL 1.0.2f 28 Jan 2016 0 dkg at alice:~$ openssl ciphers -v DHE-DSS-DES-CBC3-SHA EDH-DSS-DES-CBC3-SHA SSLv3 Kx=DH Au=DSS Enc=3DES(168) Mac=SHA1 0 dkg at alice:~$ openssl ciphers -v EDH-DSS-DES-CBC3-SHA EDH-DSS-DES-CBC3-SHA SSLv3 Kx=DH Au=DSS Enc=3DES(168) Mac=SHA1 0 dkg at alice:~$ do you think there are pieces that aren't yet merged? have you tried using the common names with 1.0.2 and they don't work? --dkg From rt at openssl.org Wed Feb 3 21:18:15 2016 From: rt at openssl.org (Daniel Kahn Gillmor via RT) Date: Wed, 03 Feb 2016 21:18:15 +0000 Subject: [openssl-dev] [openssl.org #2768] Bug: internal_verify() hides errors from callbacks after X509_V_ERR_UNABLE_TO_VERIFY_LEAF_SIGNATURE In-Reply-To: <87h9hpmr1n.fsf@alice.fifthhorseman.net> References: <4F68E7F6.7080305@measurement-factory.com> <56AFBFC9.7020305@measurement-factory.com> <20160201213157.GA4987@mournblade.imrryr.org> <56AFEC82.4000505@measurement-factory.com> <20160201234620.GH4987@mournblade.imrryr.org> <87h9hpmr1n.fsf@alice.fifthhorseman.net> Message-ID: On Mon 2016-02-01 18:46:20 -0500, Viktor Dukhovni wrote: > On Mon, Feb 01, 2016 at 11:38:49PM +0000, Alex Rousskov via RT wrote: > >> On 02/01/2016 02:32 PM, openssl-dev at openssl.org via RT wrote: >> >> > Please be more explicit about what errors you feel were not reported. >> >> One specific error mentioned during the previous discussion was "expired >> certificate". This was ~four years ago, so my recollection may be >> faulty, but I believe that was _not_ the only hidden error. > > Expiration makes no sense for a certificate at the top of the chain, > it has no issuer, so the date is unsigned and meaningless. if the cert at the top of the chain is self-signed, it's entirely reasonable to say that the expiration date is meaningful. For example, I could distribute a certificate for a root authority which i intend to only be useful for 2 years. How else should i indicate to the end user that the cert should be be considered unusable after that time? the fact that a root cert is *not* expired is maybe not too meaningful. But if it *is* limited in time, then we should take it at its word and not rely on it after that point, in the same way that if the root cert is limited via nameConstraints, we should take it at its word and not rely on it for names outside the bounds of what it declares itself valid for. --dkg From matt at openssl.org Wed Feb 3 21:48:09 2016 From: matt at openssl.org (Matt Caswell) Date: Wed, 3 Feb 2016 21:48:09 +0000 Subject: [openssl-dev] [openssl.org #4289] OpenSSL 1.0.2f serious bug in Win32 makefiles, easy to fix, solution provided In-Reply-To: References: <6437c65f043f4f66b4b01a7930000a29@pmuex06.pmu.local> <56B227BC.2020909@dancingdragon.be> <56B23730.1090306@openssl.org> <56B257F6.7060101@dancingdragon.be> <2fff15c8a72742c88f15bced48195faa@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <56B27599.6090509@openssl.org> On 03/02/16 19:43, Salz, Rich via RT wrote: >> The diff works perfectly on master, but exposed a new bug (bare snprintf). >> The following patch fixes it. I can make a PR (or add it to my existing PR #512) >> if you'd like. > > Please do as a separate PR. Thanks. I think Richard is already on the case, so no need for a PR. Matt From rt at openssl.org Wed Feb 3 21:48:11 2016 From: rt at openssl.org (Matt Caswell via RT) Date: Wed, 03 Feb 2016 21:48:11 +0000 Subject: [openssl-dev] [openssl.org #4289] OpenSSL 1.0.2f serious bug in Win32 makefiles, easy to fix, solution provided In-Reply-To: <56B27599.6090509@openssl.org> References: <6437c65f043f4f66b4b01a7930000a29@pmuex06.pmu.local> <56B227BC.2020909@dancingdragon.be> <56B23730.1090306@openssl.org> <56B257F6.7060101@dancingdragon.be> <2fff15c8a72742c88f15bced48195faa@usma1ex-dag1mb1.msg.corp.akamai.com> <56B27599.6090509@openssl.org> Message-ID: On 03/02/16 19:43, Salz, Rich via RT wrote: >> The diff works perfectly on master, but exposed a new bug (bare snprintf). >> The following patch fixes it. I can make a PR (or add it to my existing PR #512) >> if you'd like. > > Please do as a separate PR. Thanks. I think Richard is already on the case, so no need for a PR. Matt From openssl-users at dukhovni.org Wed Feb 3 22:00:00 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 3 Feb 2016 17:00:00 -0500 Subject: [openssl-dev] [openssl.org #2768] Bug: internal_verify() hides errors from callbacks after X509_V_ERR_UNABLE_TO_VERIFY_LEAF_SIGNATURE In-Reply-To: References: <4F68E7F6.7080305@measurement-factory.com> <56AFBFC9.7020305@measurement-factory.com> <20160201213157.GA4987@mournblade.imrryr.org> <56AFEC82.4000505@measurement-factory.com> <20160201234620.GH4987@mournblade.imrryr.org> <87h9hpmr1n.fsf@alice.fifthhorseman.net> Message-ID: > On Feb 3, 2016, at 4:18 PM, Daniel Kahn Gillmor via RT wrote: > > if the cert at the top of the chain is self-signed, it's entirely > reasonable to say that the expiration date is meaningful. For example, > I could distribute a certificate for a root authority which i intend to > only be useful for 2 years. That's expressly not the case here, as the certificate is not even self-issued, let alone self-signed. -- Viktor. From rt at openssl.org Wed Feb 3 22:00:04 2016 From: rt at openssl.org (Viktor Dukhovni via RT) Date: Wed, 03 Feb 2016 22:00:04 +0000 Subject: [openssl-dev] [openssl.org #2768] Bug: internal_verify() hides errors from callbacks after X509_V_ERR_UNABLE_TO_VERIFY_LEAF_SIGNATURE In-Reply-To: References: <4F68E7F6.7080305@measurement-factory.com> <56AFBFC9.7020305@measurement-factory.com> <56AFEC82.4000505@measurement-factory.com> <20160201234620.GH4987@mournblade.imrryr.org> <87h9hpmr1n.fsf@alice.fifthhorseman.net> Message-ID: > On Feb 3, 2016, at 4:18 PM, Daniel Kahn Gillmor via RT wrote: > > if the cert at the top of the chain is self-signed, it's entirely > reasonable to say that the expiration date is meaningful. For example, > I could distribute a certificate for a root authority which i intend to > only be useful for 2 years. That's expressly not the case here, as the certificate is not even self-issued, let alone self-signed. -- Viktor. From rsalz at akamai.com Wed Feb 3 22:12:41 2016 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 3 Feb 2016 22:12:41 +0000 Subject: [openssl-dev] [openssl.org #3203] Normalize PFS key exchange labels In-Reply-To: References: <1387528669-26823-1-git-send-email-dkg@fifthhorseman.net> <87ioujykgn.fsf@alice.fifthhorseman.net> <87k2mlmr91.fsf@alice.fifthhorseman.net> Message-ID: > do you think there are pieces that aren't yet merged? have you tried using > the common names with 1.0.2 and they don't work? Nope, I was just reading through all the tickets to do some basic triage. I will close this one. Thanks ! From rt at openssl.org Wed Feb 3 22:12:50 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Wed, 03 Feb 2016 22:12:50 +0000 Subject: [openssl-dev] [openssl.org #3203] Normalize PFS key exchange labels In-Reply-To: References: <1387528669-26823-1-git-send-email-dkg@fifthhorseman.net> <87ioujykgn.fsf@alice.fifthhorseman.net> <87k2mlmr91.fsf@alice.fifthhorseman.net> Message-ID: > do you think there are pieces that aren't yet merged? have you tried using > the common names with 1.0.2 and they don't work? Nope, I was just reading through all the tickets to do some basic triage. I will close this one. Thanks ! From rt at openssl.org Wed Feb 3 22:13:16 2016 From: rt at openssl.org (Rich Salz via RT) Date: Wed, 03 Feb 2016 22:13:16 +0000 Subject: [openssl-dev] [openssl.org #3203] Normalize PFS key exchange labels In-Reply-To: <87ioujykgn.fsf@alice.fifthhorseman.net> References: <1387528669-26823-1-git-send-email-dkg@fifthhorseman.net> <87ioujykgn.fsf@alice.fifthhorseman.net> Message-ID: 0ec6898c67aeddc3c414f3cc1af2275d81329c20 -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Thu Feb 4 01:25:00 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 04 Feb 2016 01:25:00 +0000 Subject: [openssl-dev] [openssl.org #2752] objects.txt - update of extended key usage In-Reply-To: <4F536F23.8010403@roumenpetrov.info> References: <4F536F23.8010403@roumenpetrov.info> Message-ID: I'm going to add these: id-kp 21 : secureShellClient : SSH Client id-kp 22 : secureShellServer : SSH Server I also found 22-26 from RFC 6495. Any others? From rt at openssl.org Thu Feb 4 02:00:15 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 04 Feb 2016 02:00:15 +0000 Subject: [openssl-dev] [openssl.org #1979] Add uClibc support In-Reply-To: <4A4D15C2.9020404@redfish-solutions.com> References: <4A4D15C2.9020404@redfish-solutions.com> Message-ID: This might be interesting to support, but unfortunately nobody looked at the bug in years and the build process has changed a great deal. If you could re-integrate this against what's in master, we'd look at it. If that's too much work, I understand. We don't have/use this particular run-time environment. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Thu Feb 4 02:27:18 2016 From: rt at openssl.org (Stephen Henson via RT) Date: Thu, 04 Feb 2016 02:27:18 +0000 Subject: [openssl-dev] [openssl.org #3557] -nameopt utf8 behaviour in openssl 1.0.1i In-Reply-To: References: Message-ID: Duplicate of ticket #2397 which is now resolved. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From rt at openssl.org Thu Feb 4 03:04:48 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 04 Feb 2016 03:04:48 +0000 Subject: [openssl-dev] [openssl.org #3964] Fix OPENSSL_NO_STDIO build In-Reply-To: <1438170735.26511.33.camel@intel.com> References: <1438170735.26511.33.camel@intel.com> Message-ID: So guys, sorry for dropping the ball. Where are we on this now? -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Thu Feb 4 03:26:47 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 04 Feb 2016 03:26:47 +0000 Subject: [openssl-dev] [openssl.org #2248] CVS HEAD: bug in evp_locl.h - wrong number of bytes/bits passed to encrypt routine in loop In-Reply-To: References: Message-ID: Seems that code had been rewritten/removed; closing ticket. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Thu Feb 4 03:29:50 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 04 Feb 2016 03:29:50 +0000 Subject: [openssl-dev] [openssl.org #2275] CVS HEAD: BIO b_sock: ioctl(FIONBIO) is not available everywhere; completed BIO_socket_nbio() so the #ifdef clutter in apps/* and other spots can be discarded after this In-Reply-To: References: Message-ID: Anyone interested in looking at this and porting it to master? -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Thu Feb 4 03:32:07 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 04 Feb 2016 03:32:07 +0000 Subject: [openssl-dev] [openssl.org #2237] Building Openssl on OpenVMS using "extended parse-style" In-Reply-To: <10041609300859_2260026E@hrem.nano.tudelft.nl> References: <10041609300859_2260026E@hrem.nano.tudelft.nl> Message-ID: all fixed in master with the perl-based test framework. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Thu Feb 4 04:35:54 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 04 Feb 2016 04:35:54 +0000 Subject: [openssl-dev] [openssl.org #2752] objects.txt - update of extended key usage In-Reply-To: <4F536F23.8010403@roumenpetrov.info> References: <4F536F23.8010403@roumenpetrov.info> Message-ID: pushed a bunch of new eku's to master. please open a new ticket (or a PR for objectds.txt) if there are OID's you want to see added. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Thu Feb 4 04:36:52 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 04 Feb 2016 04:36:52 +0000 Subject: [openssl-dev] [openssl.org #3080] Android NEON and CFLAGS options In-Reply-To: References: Message-ID: As discussed in the ticket: you can add the flags on your own if needed; they're not necessary. Closing ticket. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Thu Feb 4 04:38:45 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 04 Feb 2016 04:38:45 +0000 Subject: [openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites In-Reply-To: <5615B03F.9020303@palemoon.org> References: <5615B03F.9020303@palemoon.org> Message-ID: We're not taking on these new Camellia ciphers for now. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Thu Feb 4 04:40:02 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 04 Feb 2016 04:40:02 +0000 Subject: [openssl-dev] [openssl.org #4091] Openssl make depends gives errors when no-md5 is specified In-Reply-To: <0DD21876FF6D2243AAA252365EAF85C604DCAE2B@SACMBXIP02.sdcorp.global.sandisk.com> References: <0DD21876FF6D2243AAA252365EAF85C604DCAE2B@SACMBXIP02.sdcorp.global.sandisk.com> Message-ID: fixed in master. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Thu Feb 4 04:41:14 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 04 Feb 2016 04:41:14 +0000 Subject: [openssl-dev] [openssl.org #4098] Pull request In-Reply-To: References: Message-ID: we'll be doing the work in https://github.com/openssl/openssl/pull/451 -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Thu Feb 4 04:43:48 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 04 Feb 2016 04:43:48 +0000 Subject: [openssl-dev] [openssl.org #3839] [BUG][PATCH] Compilation error when building with EVP_CHECK_DES_KEY In-Reply-To: <554B7198.4010505@privatewave.com> References: <554B7198.4010505@privatewave.com> Message-ID: we removed the feature from master. if it's necessary for 1.0.2 please re-open the ticket and we'll take the patch. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From dragon at dancingdragon.be Thu Feb 4 04:53:37 2016 From: dragon at dancingdragon.be (Joey Yandle) Date: Wed, 3 Feb 2016 20:53:37 -0800 Subject: [openssl-dev] [openssl.org #2275] CVS HEAD: BIO b_sock: ioctl(FIONBIO) is not available everywhere; completed BIO_socket_nbio() so the #ifdef clutter in apps/* and other spots can be discarded after this In-Reply-To: References: Message-ID: <56B2D951.2090109@dancingdragon.be> > Anyone interested in looking at this and porting it to master? Looks pretty easy, I'll do it. From rt at openssl.org Thu Feb 4 04:53:28 2016 From: rt at openssl.org (Joey Yandle via RT) Date: Thu, 04 Feb 2016 04:53:28 +0000 Subject: [openssl-dev] [openssl.org #2275] CVS HEAD: BIO b_sock: ioctl(FIONBIO) is not available everywhere; completed BIO_socket_nbio() so the #ifdef clutter in apps/* and other spots can be discarded after this In-Reply-To: <56B2D951.2090109@dancingdragon.be> References: <56B2D951.2090109@dancingdragon.be> Message-ID: > Anyone interested in looking at this and porting it to master? Looks pretty easy, I'll do it. From rt at openssl.org Thu Feb 4 05:43:36 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 04 Feb 2016 05:43:36 +0000 Subject: [openssl-dev] [openssl.org #2551] [PATCH] All platforms: Option to disable sending renegotiation_info extension. In-Reply-To: References: Message-ID: no longer an issue. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Thu Feb 4 05:45:47 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 04 Feb 2016 05:45:47 +0000 Subject: [openssl-dev] [openssl.org #2654] [PATCH] support LDFLAGS in Makefiles In-Reply-To: <20111210134353.795757d9@laverne> References: <20111210134353.795757d9@laverne> Message-ID: Sorry, nobody looked at this in years. It's too late for 1.0.1, it might be fixed in 1.0.2, and it's definiltey fixed in master. Closing ticket. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Thu Feb 4 05:46:23 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 04 Feb 2016 05:46:23 +0000 Subject: [openssl-dev] [openssl.org #2584] ssltest -test_cipherlist bug incorrectly skipping ciphers In-Reply-To: References: Message-ID: Fixed in the next release (master branch; 1.1) -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Thu Feb 4 05:48:22 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 04 Feb 2016 05:48:22 +0000 Subject: [openssl-dev] [openssl.org #2673] Bug report: OpenSSL Memory leak in B64 encode In-Reply-To: References: Message-ID: An OpenSSL cleanup call (such as clean_ex_data) must be called before existing, else internal data will be kept around. Closing ticket. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Thu Feb 4 05:49:58 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 04 Feb 2016 05:49:58 +0000 Subject: [openssl-dev] [openssl.org #3003] Enhancement Request - RFC6698 (DANE) TLSA Support In-Reply-To: <51309969.4030809@willows7.myzen.co.uk> References: <51309969.4030809@willows7.myzen.co.uk> Message-ID: currently in master, planned for 1.1 scheculed for april 2017 -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Thu Feb 4 05:50:53 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 04 Feb 2016 05:50:53 +0000 Subject: [openssl-dev] [openssl.org #3058] support for intel compiler on Windows In-Reply-To: <71CD13EB3ADA784F8754CB85314931952B0C4B@mailsrv01.corp.intrinsic-mi.com> References: <71CD13EB3ADA784F8754CB85314931952B0C4B@mailsrv01.corp.intrinsic-mi.com> Message-ID: correct, intel compiler not supported. (as I'm sure you figured out, since you opened this ticket years ago) -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Thu Feb 4 05:52:20 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 04 Feb 2016 05:52:20 +0000 Subject: [openssl-dev] [openssl.org #3077] rbuf_freelist and wbuf_freelist corrupted. In-Reply-To: References: Message-ID: We still doubt it is an openssl defect. if you can recreate this on a current release, please open a new ticket. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Thu Feb 4 05:53:17 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 04 Feb 2016 05:53:17 +0000 Subject: [openssl-dev] [openssl.org #2999] Incomplete fix to remove SSL3_RECORD->orig_len In-Reply-To: <2B830C10D3A65B42856BB9DDF148069009A1FD@MIVEXAMER1N2.corp.nai.org> References: <2B830C10D3A65B42856BB9DDF148069009A1FD@MIVEXAMER1N2.corp.nai.org> Message-ID: 0.9.8? :) since been fixed. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Thu Feb 4 05:54:35 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 04 Feb 2016 05:54:35 +0000 Subject: [openssl-dev] [openssl.org #3145] openssl auto install to /usr/local/lib64 In-Reply-To: References: Message-ID: no longer an issue, explicitly set the install tree during config. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Thu Feb 4 05:56:14 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 04 Feb 2016 05:56:14 +0000 Subject: [openssl-dev] [openssl.org #3050] x509 PEM certificate input parsing bug In-Reply-To: References: Message-ID: the base64 decoding routines were rewritten to be more flexible in the 1.1 release. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Thu Feb 4 05:57:28 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 04 Feb 2016 05:57:28 +0000 Subject: [openssl-dev] [openssl.org #3096] OpenSSL 1.0.1e: valgrind errors with -DPURIFY set In-Reply-To: References: Message-ID: We think this is a false positive, please try to recreate against current releases and open a new ticket if still an issue. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Thu Feb 4 05:58:47 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 04 Feb 2016 05:58:47 +0000 Subject: [openssl-dev] [openssl.org #3083] [PATCH] Adds sanity checking to malloc()/calloc()/alloca() calls in OpenSSL 1.0.1c In-Reply-To: References: Message-ID: we are much better about checking return values now. if (when, really) you find more cases where it's not checked in current releases, please open a new ticket. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Thu Feb 4 05:59:18 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 04 Feb 2016 05:59:18 +0000 Subject: [openssl-dev] [openssl.org #3085] config on *nix does not reject incorrect arguments In-Reply-To: References: Message-ID: Fixed in the next release. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Thu Feb 4 05:59:51 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 04 Feb 2016 05:59:51 +0000 Subject: [openssl-dev] [openssl.org #3084] openssl-1.0.1e: Configure lacks disable of SSLV2 and Compression by default In-Reply-To: References: Message-ID: Fixed in 1.0.2 and 1.1 -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Thu Feb 4 06:02:03 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 04 Feb 2016 06:02:03 +0000 Subject: [openssl-dev] [openssl.org #3082] [PATCH] Filter listed protocols from help options based on compile settings In-Reply-To: <51C8273B.2030009@aquaorange.net> References: <51C8273B.2030009@aquaorange.net> Message-ID: kinda fixed in 1.0.2 and really fixed in 1.1 -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Thu Feb 4 06:03:21 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 04 Feb 2016 06:03:21 +0000 Subject: [openssl-dev] [openssl.org #3098] Enhancement - Validation of country code In-Reply-To: <000001ce8acb$6f37dfd0$4da79f70$@boettger@gmx.de> References: <000001ce8acb$6f37dfd0$4da79f70$@boettger@gmx.de> Message-ID: Sorry, but I doubt we will do this. Being able to create lowercase CC's is useful for testing. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Thu Feb 4 06:07:27 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 04 Feb 2016 06:07:27 +0000 Subject: [openssl-dev] [openssl.org #3019] [PATCH] avoid null pointer dereference in ubsec_dh_generate_key() In-Reply-To: <1363372907-31962-1-git-send-email-xi@mit.edu> References: <1363372907-31962-1-git-send-email-xi@mit.edu> Message-ID: someone already fixed this in 1.0.2 -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From dragon at dancingdragon.be Thu Feb 4 06:09:11 2016 From: dragon at dancingdragon.be (Joey Yandle) Date: Wed, 3 Feb 2016 22:09:11 -0800 Subject: [openssl-dev] [openssl.org #2275] CVS HEAD: BIO b_sock: ioctl(FIONBIO) is not available everywhere; completed BIO_socket_nbio() so the #ifdef clutter in apps/* and other spots can be discarded after this In-Reply-To: References: Message-ID: <56B2EB07.3070709@dancingdragon.be> > Anyone interested in looking at this and porting it to master? https://github.com/openssl/openssl/pull/620 From rt at openssl.org Thu Feb 4 06:08:59 2016 From: rt at openssl.org (Joey Yandle via RT) Date: Thu, 04 Feb 2016 06:08:59 +0000 Subject: [openssl-dev] [openssl.org #2275] CVS HEAD: BIO b_sock: ioctl(FIONBIO) is not available everywhere; completed BIO_socket_nbio() so the #ifdef clutter in apps/* and other spots can be discarded after this In-Reply-To: <56B2EB07.3070709@dancingdragon.be> References: <56B2EB07.3070709@dancingdragon.be> Message-ID: > Anyone interested in looking at this and porting it to master? https://github.com/openssl/openssl/pull/620 From rt at openssl.org Thu Feb 4 06:14:13 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 04 Feb 2016 06:14:13 +0000 Subject: [openssl-dev] [openssl.org #3369] 1.0.1g / Windows / patch - missing ZLIB define in cms_lcl.h In-Reply-To: <53875CEB.3030004@ica.cz> References: <53875CEB.3030004@ica.cz> Message-ID: old release, reason for change never justified/explained, closing the ticket. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Thu Feb 4 06:15:30 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 04 Feb 2016 06:15:30 +0000 Subject: [openssl-dev] [openssl.org #3528] [PATCH] ssl: SSL_MODE_ASYNC_KEY_EX In-Reply-To: References: Message-ID: our plan for async work is here: https://github.com/openssl/openssl/pull/451 -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Thu Feb 4 06:18:09 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 04 Feb 2016 06:18:09 +0000 Subject: [openssl-dev] [openssl.org #3527] [PATCH] OpenSSL doesn't build as a DLL on Windows In-Reply-To: <48bc6932c8874579808e68f5d68c15e9@CY1PR0301MB0713.namprd03.prod.outlook.com> References: <48bc6932c8874579808e68f5d68c15e9@CY1PR0301MB0713.namprd03.prod.outlook.com> Message-ID: we fixed this by being better about public/private DLL ordinals. please re-open ticket if still an issue. thanks. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Thu Feb 4 06:21:21 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 04 Feb 2016 06:21:21 +0000 Subject: [openssl-dev] [openssl.org #3537] Bug in TS_check_status_info() and misleading comments In-Reply-To: <1411112849.22930.13.camel@vespa.frost.loc> References: <1411112849.22930.13.camel@vespa.frost.loc> Message-ID: fixed in 1.1 -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Thu Feb 4 06:26:04 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 04 Feb 2016 06:26:04 +0000 Subject: [openssl-dev] [openssl.org #3778] [PATCH] change RSA modulus length to 2048 in all examples for req In-Reply-To: <1427893868.4373.5.camel@datenzone.de> References: <1427893868.4373.5.camel@datenzone.de> Message-ID: This was done before, forgot to close this ticket. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Thu Feb 4 06:31:14 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 04 Feb 2016 06:31:14 +0000 Subject: [openssl-dev] [openssl.org #4017] [PATCH] Implement Camellia GCM suites (RFC 6367) In-Reply-To: <20150822102131.GA15009@kronk.local> References: <20150822102131.GA15009@kronk.local> Message-ID: I think this is a duplicate. We're still not implementing Camellia-GCM :) -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From fedor at indutny.com Thu Feb 4 06:31:05 2016 From: fedor at indutny.com (Fedor Indutny) Date: Thu, 4 Feb 2016 01:31:05 -0500 Subject: [openssl-dev] [openssl.org #3528] [PATCH] ssl: SSL_MODE_ASYNC_KEY_EX In-Reply-To: References: Message-ID: Rich, Thank you for response. There is quite a lengthy discussion on that github PR. Is there any TL;DR version of it? That PR's diff doesn't really look similar to changes proposed here, as I was mostly curious about splitting the state maching to allow deferring things until the required data (RSA-encrypted pre-master) will be available. I will be more than happy to revive this patch if it sounds interesting to you. Please let me know. Thank you, Fedor. On Thu, Feb 4, 2016 at 1:15 AM, Rich Salz via RT wrote: > our plan for async work is here: > https://github.com/openssl/openssl/pull/451 > > -- > Rich Salz, OpenSSL dev team; rsalz at openssl.org > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Thu Feb 4 06:31:35 2016 From: rt at openssl.org (Fedor Indutny via RT) Date: Thu, 04 Feb 2016 06:31:35 +0000 Subject: [openssl-dev] [openssl.org #3528] [PATCH] ssl: SSL_MODE_ASYNC_KEY_EX In-Reply-To: References: Message-ID: Rich, Thank you for response. There is quite a lengthy discussion on that github PR. Is there any TL;DR version of it? That PR's diff doesn't really look similar to changes proposed here, as I was mostly curious about splitting the state maching to allow deferring things until the required data (RSA-encrypted pre-master) will be available. I will be more than happy to revive this patch if it sounds interesting to you. Please let me know. Thank you, Fedor. On Thu, Feb 4, 2016 at 1:15 AM, Rich Salz via RT wrote: > our plan for async work is here: > https://github.com/openssl/openssl/pull/451 > > -- > Rich Salz, OpenSSL dev team; rsalz at openssl.org > > From rt at openssl.org Thu Feb 4 06:32:17 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 04 Feb 2016 06:32:17 +0000 Subject: [openssl-dev] [openssl.org #4066] bug: openssl clean up crash In-Reply-To: <830657612.2927488.1443584266236.JavaMail.yahoo@mail.yahoo.com> References: <830657612.2927488.1443584266236.JavaMail.yahoo@mail.yahoo.com> Message-ID: No information to reproduce. Please open a new ticket if still an issue. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Thu Feb 4 06:34:43 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Thu, 04 Feb 2016 06:34:43 +0000 Subject: [openssl-dev] [openssl.org #3528] [PATCH] ssl: SSL_MODE_ASYNC_KEY_EX In-Reply-To: <44073f2d4c9442249288671457b7abaa@usma1ex-dag1mb1.msg.corp.akamai.com> References: <44073f2d4c9442249288671457b7abaa@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: It?s late and my response was incomplete. The other part has already landed in master, and that's the "async engine" support. From rt at openssl.org Thu Feb 4 07:57:25 2016 From: rt at openssl.org (Casey McGinty via RT) Date: Thu, 04 Feb 2016 07:57:25 +0000 Subject: [openssl-dev] [openssl.org #3050] x509 PEM certificate input parsing bug In-Reply-To: References: Message-ID: Thanks for the follow up, and thanks for all your work on such a critical tool! Casey McGinty On Wed, Feb 3, 2016, 7:56 PM Rich Salz via RT wrote: > the base64 decoding routines were rewritten to be more flexible in the 1.1 > release. > -- > Rich Salz, OpenSSL dev team; rsalz at openssl.org > > From rt at openssl.org Thu Feb 4 08:59:49 2016 From: rt at openssl.org (Annie Yousar via RT) Date: Thu, 04 Feb 2016 08:59:49 +0000 Subject: [openssl-dev] [openssl.org #2752] objects.txt - update of extended key usage In-Reply-To: <56B31027.208@informatik.hu-berlin.de> References: <4F536F23.8010403@roumenpetrov.info> <56B31027.208@informatik.hu-berlin.de> Message-ID: Am 04.02.2016 um 02:25 schrieb Rich Salz via RT: > I'm going to add these: > id-kp 21 : secureShellClient : SSH Client > id-kp 22 : secureShellServer : SSH Server > I also found 22-26 from RFC 6495. Any others? > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev What about the following OIDs? Sorry for not using the syntax of objects.txt. Regards /Ann. 1 3 6 1 5 5 7 11 2 : id-qcs-pkixQCSyntax-v2 : QC Syntax version 2 (RFC 3739) 1 2 840 113549 1 9 16 2 47 : signingCertificateV2 : S/MIME Attribute SigningCertificate V2 (RFC 5032) 2 23 140 1 2 2 : CABF-baseline_req : CAB Forum Baseline Requirements (verified identity) 1 0 14888 3 0 5 : id-dswa-dl-EC-KCDSA : Korean EC-KDSA 1 0 14888 3 0 6 : id-dswa-dl-EC-GDSA : German EC-GDSA 1 0 14888 3 0 9 : id-dswa-dl-EC-RDSA : Russian EC-RDSA 1 0 14888 3 0 11 : id-dswa-dl-EC-SDSA : Schnorr EC-SDSA 1 0 14888 3 0 12 : id-dswa-dl-EC-FSDSA : Full Schnorr EC-FSDSA 2 16 840 1 101 3 4 2 4 5 : sha512-224 2 16 840 1 101 3 4 2 4 6 : sha512-256 2 16 840 1 101 3 4 2 4 7 : sha3-224 2 16 840 1 101 3 4 2 4 8 : sha3-256 2 16 840 1 101 3 4 2 4 9 : sha3-384 2 16 840 1 101 3 4 2 4 10 : sha3-512 2 16 840 1 101 3 4 2 4 11 : shake128 2 16 840 1 101 3 4 2 4 12 : shake256 1 2 250 1 223 101 256 1 : frp256v1 : ANSSI 256 bit elliptic curve 1 2 156 197 10045 3 1 1 : sm2GB192 : OSCCA elliptic prime curve with 192 bit 1 2 156 197 10045 3 1 7 : sm2GB256 : OSCCA elliptic prime curve with 256 bit From matt at openssl.org Thu Feb 4 09:23:10 2016 From: matt at openssl.org (Matt Caswell) Date: Thu, 4 Feb 2016 09:23:10 +0000 Subject: [openssl-dev] [openssl.org #3003] Enhancement Request - RFC6698 (DANE) TLSA Support In-Reply-To: References: <51309969.4030809@willows7.myzen.co.uk> Message-ID: <56B3187E.4020606@openssl.org> On 04/02/16 05:49, Rich Salz via RT wrote: > currently in master, planned for 1.1 scheculed for april 2017 That would be April 2016!! Matt From rt at openssl.org Thu Feb 4 09:23:12 2016 From: rt at openssl.org (Matt Caswell via RT) Date: Thu, 04 Feb 2016 09:23:12 +0000 Subject: [openssl-dev] [openssl.org #3003] Enhancement Request - RFC6698 (DANE) TLSA Support In-Reply-To: <56B3187E.4020606@openssl.org> References: <51309969.4030809@willows7.myzen.co.uk> <56B3187E.4020606@openssl.org> Message-ID: On 04/02/16 05:49, Rich Salz via RT wrote: > currently in master, planned for 1.1 scheculed for april 2017 That would be April 2016!! Matt From matt at openssl.org Thu Feb 4 09:29:57 2016 From: matt at openssl.org (Matt Caswell) Date: Thu, 4 Feb 2016 09:29:57 +0000 Subject: [openssl-dev] [openssl.org #3528] [PATCH] ssl: SSL_MODE_ASYNC_KEY_EX In-Reply-To: References: <44073f2d4c9442249288671457b7abaa@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <56B31A15.80601@openssl.org> On 04/02/16 06:34, Salz, Rich via RT wrote: > It?s late and my response was incomplete. > The other part has already landed in master, and that's the "async engine" support. See: https://www.openssl.org/docs/manmaster/crypto/ASYNC_start_job.html https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_set_mode.html (i.e. the SSL_MODE_ASYNC bit) https://www.openssl.org/docs/manmaster/ssl/SSL_waiting_for_async.html I'm working on a patch that may make some tweaks to this API, but you should get the idea. Matt From rt at openssl.org Thu Feb 4 09:29:59 2016 From: rt at openssl.org (Matt Caswell via RT) Date: Thu, 04 Feb 2016 09:29:59 +0000 Subject: [openssl-dev] [openssl.org #3528] [PATCH] ssl: SSL_MODE_ASYNC_KEY_EX In-Reply-To: <56B31A15.80601@openssl.org> References: <44073f2d4c9442249288671457b7abaa@usma1ex-dag1mb1.msg.corp.akamai.com> <56B31A15.80601@openssl.org> Message-ID: On 04/02/16 06:34, Salz, Rich via RT wrote: > It?s late and my response was incomplete. > The other part has already landed in master, and that's the "async engine" support. See: https://www.openssl.org/docs/manmaster/crypto/ASYNC_start_job.html https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_set_mode.html (i.e. the SSL_MODE_ASYNC bit) https://www.openssl.org/docs/manmaster/ssl/SSL_waiting_for_async.html I'm working on a patch that may make some tweaks to this API, but you should get the idea. Matt From fedor at indutny.com Thu Feb 4 09:55:53 2016 From: fedor at indutny.com (Fedor Indutny) Date: Thu, 4 Feb 2016 04:55:53 -0500 Subject: [openssl-dev] [openssl.org #3528] [PATCH] ssl: SSL_MODE_ASYNC_KEY_EX In-Reply-To: References: <44073f2d4c9442249288671457b7abaa@usma1ex-dag1mb1.msg.corp.akamai.com> <56B31A15.80601@openssl.org> Message-ID: Thank you very much, Matt, Rich. I will read through these docs tomorrow. On Thu, Feb 4, 2016 at 4:29 AM, Matt Caswell via RT wrote: > > > On 04/02/16 06:34, Salz, Rich via RT wrote: > > It?s late and my response was incomplete. > > The other part has already landed in master, and that's the "async > engine" support. > > See: > > https://www.openssl.org/docs/manmaster/crypto/ASYNC_start_job.html > https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_set_mode.html (i.e. > the SSL_MODE_ASYNC bit) > https://www.openssl.org/docs/manmaster/ssl/SSL_waiting_for_async.html > > I'm working on a patch that may make some tweaks to this API, but you > should get the idea. > > Matt > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Thu Feb 4 09:56:25 2016 From: rt at openssl.org (Fedor Indutny via RT) Date: Thu, 04 Feb 2016 09:56:25 +0000 Subject: [openssl-dev] [openssl.org #3528] [PATCH] ssl: SSL_MODE_ASYNC_KEY_EX In-Reply-To: References: <44073f2d4c9442249288671457b7abaa@usma1ex-dag1mb1.msg.corp.akamai.com> <56B31A15.80601@openssl.org> Message-ID: Thank you very much, Matt, Rich. I will read through these docs tomorrow. On Thu, Feb 4, 2016 at 4:29 AM, Matt Caswell via RT wrote: > > > On 04/02/16 06:34, Salz, Rich via RT wrote: > > It?s late and my response was incomplete. > > The other part has already landed in master, and that's the "async > engine" support. > > See: > > https://www.openssl.org/docs/manmaster/crypto/ASYNC_start_job.html > https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_set_mode.html (i.e. > the SSL_MODE_ASYNC bit) > https://www.openssl.org/docs/manmaster/ssl/SSL_waiting_for_async.html > > I'm working on a patch that may make some tweaks to this API, but you > should get the idea. > > Matt > > > From rt at openssl.org Thu Feb 4 10:02:42 2016 From: rt at openssl.org (Matt Caswell via RT) Date: Thu, 04 Feb 2016 10:02:42 +0000 Subject: [openssl-dev] [openssl.org #4290] HMAC_Init_ex() return bug In-Reply-To: References: <75375288-D03A-4B51-ACC3-0995877DF1AF@high-mobility.com> <3FB3F54A-CD47-4FD4-A3D1-5877646B2118@gmail.com> Message-ID: On Wed Feb 03 18:32:20 2016, mikkratsep at gmail.com wrote: > I built it using cocoapods, the OpenSSL headers show 1.0.2f. > I?ll try to make some sample program tomorrow. > > > > On 3 veebr 2016, at 18:27, Salz, Rich via RT wrote: > > > >> I?m running OS X 10.11.3 and OpenSSL 1.0.206 > > > > I cannot reproduce this. Did you build from source, or is that a > > vendor-provided version? The ".206" isn't part of our release > > naming. Did you mean 1.0.2f? Do you have a sample program to show > > the error? > > > > Please do as it looks like someone else has a similar problem. It's not quite the same (different HMAC function) but still in HMAC and very similar symptoms: https://github.com/openssl/openssl/issues/607 I can't reproduce it though, and the diagnosis in the above github issue doesn't look right. One other question: are you using FIPS mode, or standard OpenSSL? Matt From rt at openssl.org Thu Feb 4 10:10:06 2016 From: rt at openssl.org (Moonchild via RT) Date: Thu, 04 Feb 2016 10:10:06 +0000 Subject: [openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites In-Reply-To: <56B32224.6060207@palemoon.org> References: <5615B03F.9020303@palemoon.org> <56B32224.6060207@palemoon.org> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Really? That's all we get, a one-liner, no explanation, no rationale, response? It's not even "brand new" functionality, Camellia as a raw cipher is already in there, the only difference is wrapping it into GCM-based suites. Patches are available, too. Sounds like OpenSSL isn't as open as one might think. On 04/02/2016 05:38, Rich Salz via RT wrote: > We're not taking on these new Camellia ciphers for now. -- Rich Salz, > OpenSSL dev team; rsalz at openssl.org > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) iF4EAREIAAYFAlazIiQACgkQEguw022l8qw2wQD8CuBYlCXVKk2VUvMSxYcqnKDg LULZr0x5hCfalVbl/cIA/3Ro3hbllmrL6RqBy6ir/l6bUSmlWnB+nG++scYIkNem =koMx -----END PGP SIGNATURE----- From rt at openssl.org Thu Feb 4 10:10:16 2016 From: rt at openssl.org (Moonchild via RT) Date: Thu, 04 Feb 2016 10:10:16 +0000 Subject: [openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites In-Reply-To: <56B3237E.8060700@palemoon.org> References: <5615B03F.9020303@palemoon.org> <56B3237E.8060700@palemoon.org> Message-ID: Really? That's all we get, a one-liner, no explanation, no rationale, response? It's not even "brand new" functionality, Camellia as a raw cipher is already in there, the only difference is wrapping it into GCM-based suites. Patches are available, too. Sounds like OpenSSL isn't as open as one might think. On 04/02/2016 05:38, Rich Salz via RT wrote: > We're not taking on these new Camellia ciphers for now. -- Rich Salz, > OpenSSL dev team; rsalz at openssl.org > > > From rt at openssl.org Thu Feb 4 10:12:40 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Thu, 04 Feb 2016 10:12:40 +0000 Subject: [openssl-dev] [openssl.org #3830] [PATCH] Fix test execution on Windows In-Reply-To: References: Message-ID: I just tried this and can't verify this, it works beautifully and as intended when I try. The issue appears to be a non-issue, as the command should create the serial file and therefore not require its presence beforehand. See '-CAcreateserial'. Cheers, Richard Vid Sat, 02 May 2015 kl. 06.05.21, skrev gunnarku at exchange.microsoft.com: > Hello, > > Summary: fix test case execution on Windows so that all the tests will > be run. > > Additional data: > > 1) Operating systems affected: all versions of Windows. > > 2) OpenSSL versions affected: all versions running on Windows. > > Thank you, > Gunnar Kudrjavets -- Richard Levitte levitte at openssl.org From onicrypt at gmail.com Thu Feb 4 10:18:11 2016 From: onicrypt at gmail.com (Nich Ramsey) Date: Thu, 4 Feb 2016 02:18:11 -0800 Subject: [openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites In-Reply-To: References: <5615B03F.9020303@palemoon.org> <56B3237E.8060700@palemoon.org> Message-ID: Moonchild: what advantages does Camellia have over AES? Sincerely asking since I'm not familiar. OpenSSL team: I second Moonchild's curiosity, why is there no plan for integration when the raw cipher is already present in the code base? If it's a lack of resources you can dedicate, would you be open to someone outside the dev team contributing the necessary code? Thanks in advance for your consideration, Nich On Feb 4, 2016 2:10 AM, "Moonchild via RT" wrote: > Really? > > That's all we get, a one-liner, no explanation, no rationale, response? > It's not even "brand new" functionality, Camellia as a raw cipher is > already > in there, the only difference is wrapping it into GCM-based suites. Patches > are available, too. > > Sounds like OpenSSL isn't as open as one might think. > > On 04/02/2016 05:38, Rich Salz via RT wrote: > > We're not taking on these new Camellia ciphers for now. -- Rich Salz, > > OpenSSL dev team; rsalz at openssl.org > > > > > > > > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Thu Feb 4 10:18:19 2016 From: rt at openssl.org (Nich Ramsey via RT) Date: Thu, 04 Feb 2016 10:18:19 +0000 Subject: [openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites In-Reply-To: References: <5615B03F.9020303@palemoon.org> <56B3237E.8060700@palemoon.org> Message-ID: Moonchild: what advantages does Camellia have over AES? Sincerely asking since I'm not familiar. OpenSSL team: I second Moonchild's curiosity, why is there no plan for integration when the raw cipher is already present in the code base? If it's a lack of resources you can dedicate, would you be open to someone outside the dev team contributing the necessary code? Thanks in advance for your consideration, Nich On Feb 4, 2016 2:10 AM, "Moonchild via RT" wrote: > Really? > > That's all we get, a one-liner, no explanation, no rationale, response? > It's not even "brand new" functionality, Camellia as a raw cipher is > already > in there, the only difference is wrapping it into GCM-based suites. Patches > are available, too. > > Sounds like OpenSSL isn't as open as one might think. > > On 04/02/2016 05:38, Rich Salz via RT wrote: > > We're not taking on these new Camellia ciphers for now. -- Rich Salz, > > OpenSSL dev team; rsalz at openssl.org > > > > > > > > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > From rt at openssl.org Thu Feb 4 10:24:49 2016 From: rt at openssl.org (Woodhouse, David via RT) Date: Thu, 04 Feb 2016 10:24:49 +0000 Subject: [openssl-dev] [openssl.org #3964] Fix OPENSSL_NO_STDIO build In-Reply-To: <1454581401.4788.207.camel@intel.com> References: <1438170735.26511.33.camel@intel.com> <1454581401.4788.207.camel@intel.com> Message-ID: On Thu, 2016-02-04 at 03:04 +0000, Rich Salz via RT wrote: > So guys, sorry for dropping the ball. Where are we on this now? I see four patches still at the top of? http://git.infradead.org/users/dwmw2/openssl.git?but I've completely forgotten. I'll update and rebase my patches on both the OpenSSL and EDK2 side, and take stock. I think we also have our own implementation of TS support in EDK2, from the 0.9.8 days when OpenSSL didn't. Qin, did you make any progress on killing that off? -- David Woodhouse Open Source Technology Centre David.Woodhouse at intel.com Intel Corporation -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3437 bytes Desc: not available URL: From rt at openssl.org Thu Feb 4 11:06:53 2016 From: rt at openssl.org (Moonchild via RT) Date: Thu, 04 Feb 2016 11:06:53 +0000 Subject: [openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites In-Reply-To: <56B330BB.7040707@palemoon.org> References: <5615B03F.9020303@palemoon.org> <56B3237E.8060700@palemoon.org> <56B330BB.7040707@palemoon.org> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 04/02/2016 11:18, Nich Ramsey via RT wrote: > Moonchild: what advantages does Camellia have over AES? Sincerely asking > since I'm not familiar. It's comparable to AES in terms of how it can theoretically be broken with algebra, as well as its processing capabilities, but as far as I know there are no known successful attacks that weaken it, and the closest anyone has come to attacking it has been against a reduced/non-full version of the 128-bit strength cipher that still required 2^116 encryptions and the same amount of plaintexts. The full one has never budged. That alone would make it a very desirable cipher. Unless, of course, you have a personal grudge against ciphers not coming from American soil (it's a Japanese-origin cipher). See also my rationale in my original post on this topic about international diversity with strong, modern encryption. Camellia is widely-adopted in a whole range of security applications. There are plenty of RFCs about Camellia, but in this context most notably RFC6367 proposing exactly this for inclusion in TLS with GCM. RFC5932 is a standards document describing Camellia in TLS as a whole. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) iF4EAREIAAYFAlazMLsACgkQEguw022l8qy+KwD9H3Rm0qaXxcts49jvKuL54frb rzpF/WlvtiMlYDNXgEUA/1k9HjoEbLp9THY3nrHZ4Rx0wXcgT0O4b/817Cr+3iJM =JoAw -----END PGP SIGNATURE----- From dwmw2 at infradead.org Thu Feb 4 10:23:21 2016 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 04 Feb 2016 10:23:21 +0000 Subject: [openssl-dev] [openssl.org #3964] Fix OPENSSL_NO_STDIO build In-Reply-To: References: <1438170735.26511.33.camel@intel.com> Message-ID: <1454581401.4788.207.camel@intel.com> On Thu, 2016-02-04 at 03:04 +0000, Rich Salz via RT wrote: > So guys, sorry for dropping the ball. Where are we on this now? I see four patches still at the top of? http://git.infradead.org/users/dwmw2/openssl.git?but I've completely forgotten. I'll update and rebase my patches on both the OpenSSL and EDK2 side, and take stock. I think we also have our own implementation of TS support in EDK2, from the 0.9.8 days when OpenSSL didn't. Qin, did you make any progress on killing that off? -- David Woodhouse Open Source Technology Centre David.Woodhouse at intel.com Intel Corporation -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3437 bytes Desc: not available URL: From rt at openssl.org Thu Feb 4 12:44:04 2016 From: rt at openssl.org (=?UTF-8?B?RW1pbGlhIEvDpHNwZXI=?= via RT) Date: Thu, 04 Feb 2016 12:44:04 +0000 Subject: [openssl-dev] [openssl.org #3095] Incorrect result in HMAC functions when key is null In-Reply-To: <68E15C38-486C-4F29-9C45-EEE41333E423@petroules.com> References: <68E15C38-486C-4F29-9C45-EEE41333E423@petroules.com> Message-ID: Fixed in master now, commit b1413d9bd9d2222823ca1ba2d6cdf4849e635231 From rt at openssl.org Thu Feb 4 13:08:15 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Thu, 04 Feb 2016 13:08:15 +0000 Subject: [openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites In-Reply-To: References: <5615B03F.9020303@palemoon.org> <56B32224.6060207@palemoon.org> Message-ID: > That's all we get, a one-liner, no explanation, no rationale, response? Take a look at some of the discussion here: https://github.com/openssl/openssl/pull/374 https://github.com/openssl/openssl/pull/154 https://github.com/openssl/openssl/pull/148 I would suggest that if you want to continue the discussion, do it on openssl-dev with a new subject line (so it doesn't get threaded into this RT ticket) From rt at openssl.org Thu Feb 4 13:21:17 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 04 Feb 2016 13:21:17 +0000 Subject: [openssl-dev] [openssl.org #2887] [PATCH] decode more message/content types in apps In-Reply-To: <370727972.318.1348972863038.JavaMail.root@zimbra.lentz.com.au> References: <1053321122.315.1348972849447.JavaMail.root@zimbra.lentz.com.au> <370727972.318.1348972863038.JavaMail.root@zimbra.lentz.com.au> Message-ID: fixed in master for next release with commit 7429b39. thanks. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org ------------------------------------------------------------------------- http://rt.openssl.org/Ticket/Display.html?id=2887 From rt at openssl.org Thu Feb 4 13:34:37 2016 From: rt at openssl.org (Matt Caswell via RT) Date: Thu, 04 Feb 2016 13:34:37 +0000 Subject: [openssl-dev] [openssl.org #2256] CVS HEAD: question: must this be hardcoded '8' or is it 'md_len' in disguise? :-S In-Reply-To: References: Message-ID: The length is specified by the standards and is less than the digest length. Closing this ticket. Matt ------------------------------------------------------------------------- http://rt.openssl.org/Ticket/Display.html?id=2256 Please log in as guest with password guest if prompted From doctor at doctor.nl2k.ab.ca Thu Feb 4 13:39:19 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Thu, 4 Feb 2016 06:39:19 -0700 Subject: [openssl-dev] Openssl SNAP 20160204 development Message-ID: <20160204133919.GA2288@doctor.nl2k.ab.ca> All right, I can compile,but test/recipes/70-test_sslcertstatus.t is hang in an infinite loop. Any explanation? -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Broadcasting the truth for 25 years From rt at openssl.org Thu Feb 4 13:47:50 2016 From: rt at openssl.org (Moonchild via RT) Date: Thu, 04 Feb 2016 13:47:50 +0000 Subject: [openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites In-Reply-To: <56B35680.8020902@palemoon.org> References: <5615B03F.9020303@palemoon.org> <56B32224.6060207@palemoon.org> <56B35680.8020902@palemoon.org> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 04/02/2016 14:08, Salz, Rich via RT wrote: > >> That's all we get, a one-liner, no explanation, no rationale, >> response? > > Take a look at some of the discussion here: > https://github.com/openssl/openssl/pull/374 > https://github.com/openssl/openssl/pull/154 > https://github.com/openssl/openssl/pull/148 None of these have any discussion. 148 and 154 are dupes and got merged. 374 was closed because nobody bothered to give it any attention and the dev got tired of rebasing when there was no indication that it would ever get attention. What did you expect, that someone would just keep working on something for naught? So, basically, you ignored someone long enough that they dropped it. Once again, no explanation is given, no rationale. Are you being put under pressure by someone? Should someone make a sane fork of OpenSSL instead? Or can we just actually work together to improve a lib here? Seriously. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) iF4EAREIAAYFAlazVn8ACgkQEguw022l8qx3rgEAndOysatLhd3j5LxxIdhfMiAS I3ZEyMQQxgewPU60CQ8A/2vkByqPlDCrHITP3+ZQTh/ffwOgMlNugvqGjDW0s2BE =qACi -----END PGP SIGNATURE----- ------------------------------------------------------------------------- http://rt.openssl.org/Ticket/Display.html?id=4075 Please log in as guest with password guest if prompted From rt at openssl.org Thu Feb 4 13:58:10 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Thu, 04 Feb 2016 13:58:10 +0000 Subject: [openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites In-Reply-To: <14677bc36ea1418bb365a1cdac03cc29@usma1ex-dag1mb1.msg.corp.akamai.com> References: <5615B03F.9020303@palemoon.org> <56B32224.6060207@palemoon.org> <56B35680.8020902@palemoon.org> <14677bc36ea1418bb365a1cdac03cc29@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: I missed a link: https://github.com/openssl/openssl/issues/320 Nobody is pressuring us. I am sure you mean that in a kind and concerned way, and are not trying to be insulting. If you can find someone on the openssl-dev team who is willing to take on the work, then it could go into OpenSSL. Otherwise, consider implementing it as an external engine (like GOST), or do your own downstream fork. ------------------------------------------------------------------------- http://rt.openssl.org/Ticket/Display.html?id=4075 Please log in as guest with password guest if prompted From kurt at roeckx.be Thu Feb 4 14:39:21 2016 From: kurt at roeckx.be (Kurt Roeckx) Date: Thu, 4 Feb 2016 15:39:21 +0100 Subject: [openssl-dev] Openssl SNAP 20160204 development In-Reply-To: <20160204133919.GA2288@doctor.nl2k.ab.ca> References: <20160204133919.GA2288@doctor.nl2k.ab.ca> Message-ID: <20160204143920.GA1164@roeckx.be> On Thu, Feb 04, 2016 at 06:39:19AM -0700, The Doctor wrote: > All right, I can compile,but > > test/recipes/70-test_sslcertstatus.t > > is hang in an infinite loop. > > Any explanation? That's an issue I'm not aware of yet, nor did I see it in any of our automated test runs. Can you give some more information about it? Kurt From rt at openssl.org Thu Feb 4 15:00:14 2016 From: rt at openssl.org (Kurt Roeckx via RT) Date: Thu, 04 Feb 2016 15:00:14 +0000 Subject: [openssl-dev] [openssl.org #4288] [BUG] Xmm7 register is cobbered in aesni_gcm_decrypt on win64 In-Reply-To: <20160204150008.GA10961@roeckx.be> References: <36D6AF88-C3E6-4FEC-A6F9-CD92E25FB66D@hansoft.com> <20160204150008.GA10961@roeckx.be> Message-ID: Fixed. Kurt ------------------------------------------------------------------------- http://rt.openssl.org/Ticket/Display.html?id=4288 Please log in as guest with password guest if prompted From dwmw2 at infradead.org Thu Feb 4 14:31:54 2016 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 04 Feb 2016 14:31:54 +0000 Subject: [openssl-dev] [openssl.org #4175] Add new macro or PKCS7 flag to disable the check for both data and content In-Reply-To: References: Message-ID: <1454596314.4788.255.camel@infradead.org> On Tue, 2015-12-08 at 12:56 +0000, Salz, Rich via RT wrote: > I think that instead of the #ifdef being removed, the if() test > should be removed.?????? > This was my mistake. What was the verdict here? I'm trying to update my builds, as promised this morning. But EDK2 has updated to 1.0.2e and in doing so, has grown a new patch for this regression. So when part of my patch series? replaces the existing patch against 1.0.2e with a cleaner patch including all the bug-fixes that have already gone upstream into HEAD, this needs a "proper" fix... -- David Woodhouse Open Source Technology Centre David.Woodhouse at intel.com Intel Corporation ? http://git.infradead.org/users/dwmw2/edk2.git/commitdiff/16d175c127ac1e -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5691 bytes Desc: not available URL: From rt at openssl.org Thu Feb 4 15:05:05 2016 From: rt at openssl.org (David Woodhouse via RT) Date: Thu, 04 Feb 2016 15:05:05 +0000 Subject: [openssl-dev] [openssl.org #4175] Add new macro or PKCS7 flag to disable the check for both data and content In-Reply-To: <1454596314.4788.255.camel@infradead.org> References: <1454596314.4788.255.camel@infradead.org> Message-ID: On Tue, 2015-12-08 at 12:56 +0000, Salz, Rich via RT wrote: > I think that instead of the #ifdef being removed, the if() test > should be removed.?????? > This was my mistake. What was the verdict here? I'm trying to update my builds, as promised this morning. But EDK2 has updated to 1.0.2e and in doing so, has grown a new patch for this regression. So when part of my patch series? replaces the existing patch against 1.0.2e with a cleaner patch including all the bug-fixes that have already gone upstream into HEAD, this needs a "proper" fix... -- David Woodhouse Open Source Technology Centre David.Woodhouse at intel.com Intel Corporation ? http://git.infradead.org/users/dwmw2/edk2.git/commitdiff/16d175c127ac1e ------------------------------------------------------------------------- http://rt.openssl.org/Ticket/Display.html?id=4175 Please log in as guest with password guest if prompted -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5691 bytes Desc: not available URL: From rt at openssl.org Thu Feb 4 15:12:10 2016 From: rt at openssl.org (Short, Todd via RT) Date: Thu, 04 Feb 2016 15:12:10 +0000 Subject: [openssl-dev] [openssl.org #1979] Add uClibc support In-Reply-To: <6DD30AA9-EB7A-4634-A7AA-A9B52C7E5A4D@akamai.com> References: <4A4D15C2.9020404@redfish-solutions.com> <6DD30AA9-EB7A-4634-A7AA-A9B52C7E5A4D@akamai.com> Message-ID: OpenSSL is generally able to compile with the musl C library (same idea as uClibc): OpenSSL 1.0.2f: ./config make depend CC=/usr/local/bin/musl-gcc ./config make ./config is run twice, because "make depend" fails since domd can?t find the makedepend command after CC is set to musl-gcc. However, after running ./config a second time (to update the CC), the make succeeds. openssl loads and run. If musl is configured with --disable-shared, then it does not require any dynamic executables. master: CC=/usr/local/bin/musl-gcc ./config make depend make "make depend" succeeds in master, even after CC is set to musl-gcc. But linking fails due to setcontext, getcontext and makecontext being undefined. They appear to be used by the async code; there doesn?t seem to be a way to turn off async (or force NULL async). I looked in the musl library, and there are declarations of these functions()s, but no definitions. A maintainer of the musl library has indicated that these are deprecated Posix APIs. Might there be a way to disable the use of these APIs, and permit only async_none so that these other libraries (uClibc and musl) could be used instead? -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." On Feb 3, 2016, at 9:00 PM, Salz, Rich via RT > wrote: This might be interesting to support, but unfortunately nobody looked at the bug in years and the build process has changed a great deal. If you could re-integrate this against what's in master, we'd look at it. If that's too much work, I understand. We don't have/use this particular run-time environment. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev ------------------------------------------------------------------------- http://rt.openssl.org/Ticket/Display.html?id=1979 Please log in as guest with password guest if prompted From rt at openssl.org Thu Feb 4 15:40:35 2016 From: rt at openssl.org (Woodhouse, David via RT) Date: Thu, 04 Feb 2016 15:40:35 +0000 Subject: [openssl-dev] [openssl.org #3964] Fix OPENSSL_NO_STDIO build In-Reply-To: <1454600429.4788.261.camel@intel.com> References: <1438170735.26511.33.camel@intel.com> <1454600429.4788.261.camel@intel.com> Message-ID: On Thu, 2016-02-04 at 03:04 +0000, Rich Salz via RT wrote: > So guys, sorry for dropping the ball. Where are we on this now? Going backwards. I don't seem to be able to configure with 'no-ui no-engines' any more. :) -- David Woodhouse Open Source Technology Centre David.Woodhouse at intel.com Intel Corporation ------------------------------------------------------------------------- http://rt.openssl.org/Ticket/Display.html?id=3964 Please log in as guest with password guest if prompted -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3437 bytes Desc: not available URL: From rt at openssl.org Thu Feb 4 16:45:11 2016 From: rt at openssl.org (Short, Todd via RT) Date: Thu, 04 Feb 2016 16:45:11 +0000 Subject: [openssl-dev] [openssl.org #1979] Add uClibc support In-Reply-To: References: <4A4D15C2.9020404@redfish-solutions.com> <6DD30AA9-EB7A-4634-A7AA-A9B52C7E5A4D@akamai.com> Message-ID: FYI: The rational for why these APIs are deprecated. http://pubs.opengroup.org/onlinepubs/009695399/functions/makecontext.html#tag_03_356_08 -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." ------------------------------------------------------------------------- http://rt.openssl.org/Ticket/Display.html?id=1979 Please log in as guest with password guest if prompted From hkario at redhat.com Thu Feb 4 16:48:39 2016 From: hkario at redhat.com (Hubert Kario) Date: Thu, 04 Feb 2016 17:48:39 +0100 Subject: [openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites In-Reply-To: References: Message-ID: <27452425.yLIb4bJQQ4@pintsize.usersys.redhat.com> On Thursday 04 February 2016 13:08:15 Salz, Rich via RT wrote: > > That's all we get, a one-liner, no explanation, no rationale, > > response? > Take a look at some of the discussion here: > https://github.com/openssl/openssl/pull/154 > https://github.com/openssl/openssl/pull/148 You mean the "Many thanks for your patch. Applied"? :> If you see ways in which the code in proposed pull requests is unmaintainable, share them. Saying "we may not have resources later" is unconvincing. Especially given that we're talking just about a new mode created by combining already implemented cipher and integrity mechanism. Mode necessary to support an ENISA recommended cipher in TLSv1.3. -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From rsalz at akamai.com Thu Feb 4 16:52:03 2016 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 4 Feb 2016 16:52:03 +0000 Subject: [openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites In-Reply-To: <27452425.yLIb4bJQQ4@pintsize.usersys.redhat.com> References: <27452425.yLIb4bJQQ4@pintsize.usersys.redhat.com> Message-ID: <98a0fffb61b944dc95740591577fc196@usma1ex-dag1mb1.msg.corp.akamai.com> > If you see ways in which the code in proposed pull requests is > unmaintainable, share them. Nobody on the team is able to take the time to do it. From kurt at roeckx.be Thu Feb 4 17:10:42 2016 From: kurt at roeckx.be (Kurt Roeckx) Date: Thu, 4 Feb 2016 18:10:42 +0100 Subject: [openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites In-Reply-To: References: <5615B03F.9020303@palemoon.org> <56B32224.6060207@palemoon.org> Message-ID: <20160204171042.GA25291@roeckx.be> On Thu, Feb 04, 2016 at 10:10:06AM +0000, Moonchild via RT wrote: > Really? > > That's all we get, a one-liner, no explanation, no rationale, response? > It's not even "brand new" functionality, Camellia as a raw cipher is already > in there, the only difference is wrapping it into GCM-based suites. Patches > are available, too. I think the concerns are: - Nobody else seems to be using Camellia - We don't have a constant time implementation of it - For processors that have AESNI, it's slower than AES - Adding more ciphers to the default list will just increase the client hello and not change anything. That being said, I don't think there should be a problem adding the support. I'm just not sure about enabling it by default. Kurt From rt at openssl.org Thu Feb 4 17:10:45 2016 From: rt at openssl.org (Kurt Roeckx via RT) Date: Thu, 04 Feb 2016 17:10:45 +0000 Subject: [openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites In-Reply-To: <20160204171042.GA25291@roeckx.be> References: <5615B03F.9020303@palemoon.org> <56B32224.6060207@palemoon.org> <20160204171042.GA25291@roeckx.be> Message-ID: On Thu, Feb 04, 2016 at 10:10:06AM +0000, Moonchild via RT wrote: > Really? > > That's all we get, a one-liner, no explanation, no rationale, response? > It's not even "brand new" functionality, Camellia as a raw cipher is already > in there, the only difference is wrapping it into GCM-based suites. Patches > are available, too. I think the concerns are: - Nobody else seems to be using Camellia - We don't have a constant time implementation of it - For processors that have AESNI, it's slower than AES - Adding more ciphers to the default list will just increase the client hello and not change anything. That being said, I don't think there should be a problem adding the support. I'm just not sure about enabling it by default. Kurt ------------------------------------------------------------------------- http://rt.openssl.org/Ticket/Display.html?id=4075 Please log in as guest with password guest if prompted From levitte at openssl.org Thu Feb 4 17:27:52 2016 From: levitte at openssl.org (Richard Levitte) Date: Thu, 04 Feb 2016 18:27:52 +0100 (CET) Subject: [openssl-dev] Evolution of build refactoring Message-ID: <20160204.182752.884677681383049423.levitte@openssl.org> Hi, some time ago, I announced the refactor-build branch on github. It has gone through a bit of rearrangement, and the commits that lay out the ground have made it into master by now. The rest is still going through internal review. Meanwhile, I would very much like to hear from Cygwin folks, Mwing folks and VMS folks, the first two because I'm not sure I got the quirks needed right, and regarding VMS, this is the only way there will be a build of upcoming 1.1, so it's rather crucial to get things right there. That branch lives as a github pull request (mostly to get travis to try building it), https://github.com/openssl/openssl/pull/623, the branch itself is found here: https://github.com/levitte/openssl/tree/refactor-build Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From uri at ll.mit.edu Thu Feb 4 17:20:11 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Thu, 4 Feb 2016 17:20:11 +0000 Subject: [openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites In-Reply-To: References: <5615B03F.9020303@palemoon.org> <56B32224.6060207@palemoon.org> <20160204171042.GA25291@roeckx.be> Message-ID: On 2/4/16, 12:10 , "openssl-dev on behalf of Kurt Roeckx via RT" wrote: >On Thu, Feb 04, 2016 at 10:10:06AM +0000, Moonchild via RT wrote: >> Really? >> >> That's all we get, a one-liner, no explanation, no rationale, response? >> It's not even "brand new" functionality, Camellia as a raw cipher is >>already >> in there, the only difference is wrapping it into GCM-based suites. >>Patches >> are available, too. > >I think the concerns are: >- Nobody else seems to be using Camellia I thought it?s used pretty widely in Asia. >- We don't have a constant time implementation of it Something to write in the documentation - not everybody needs to worry about this (contrary to what some academia publications seemed to imply). >- For processors that have AESNI, it's slower than AES So?? People who want to use it, most likely do it for reasons other than speed. >- Adding more ciphers to the default list will just increase the > client hello and not change anything. ??? >That being said, I don't think there should be a problem adding >the support. I'm just not sure about enabling it by default. Enabling by default probably is unnecessary, IMHO. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4308 bytes Desc: not available URL: From onicrypt at gmail.com Thu Feb 4 17:36:33 2016 From: onicrypt at gmail.com (Nich Ramsey) Date: Thu, 4 Feb 2016 09:36:33 -0800 Subject: [openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites In-Reply-To: References: <5615B03F.9020303@palemoon.org> <56B32224.6060207@palemoon.org> <20160204171042.GA25291@roeckx.be> Message-ID: I'm new to implementing crypto, but this seems like a great learning opportunity. What's the best way for me to get ramped up through self-study? I'm interested in the Camellia cipher, and contributing meaningful additions to the OpenSSL library. Moonchild: thank you for your detailed explanation of the Camellia cipher. This seems like a worthwhile cause, since having many alternative, strong cipher suites is of great benefit. Kurt: I agree with you, until there are more people using Camellia it shouldn't be on by default. It would be nice to have the option to manually enable it though, especially for people like Moonchild that have a special need/affinity for the cipher. Thanks to everyone for continued discussion on this topic. Nich On Feb 4, 2016 9:11 AM, "Kurt Roeckx via RT" wrote: > On Thu, Feb 04, 2016 at 10:10:06AM +0000, Moonchild via RT wrote: > > Really? > > > > That's all we get, a one-liner, no explanation, no rationale, response? > > It's not even "brand new" functionality, Camellia as a raw cipher is > already > > in there, the only difference is wrapping it into GCM-based suites. > Patches > > are available, too. > > I think the concerns are: > - Nobody else seems to be using Camellia > - We don't have a constant time implementation of it > - For processors that have AESNI, it's slower than AES > - Adding more ciphers to the default list will just increase the > client hello and not change anything. > > That being said, I don't think there should be a problem adding > the support. I'm just not sure about enabling it by default. > > > Kurt > > > > ------------------------------------------------------------------------- > http://rt.openssl.org/Ticket/Display.html?id=4075 > > Please log in as guest with password guest if prompted > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Thu Feb 4 17:36:35 2016 From: rt at openssl.org (Nich Ramsey via RT) Date: Thu, 04 Feb 2016 17:36:35 +0000 Subject: [openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites In-Reply-To: References: <5615B03F.9020303@palemoon.org> <56B32224.6060207@palemoon.org> <20160204171042.GA25291@roeckx.be> Message-ID: I'm new to implementing crypto, but this seems like a great learning opportunity. What's the best way for me to get ramped up through self-study? I'm interested in the Camellia cipher, and contributing meaningful additions to the OpenSSL library. Moonchild: thank you for your detailed explanation of the Camellia cipher. This seems like a worthwhile cause, since having many alternative, strong cipher suites is of great benefit. Kurt: I agree with you, until there are more people using Camellia it shouldn't be on by default. It would be nice to have the option to manually enable it though, especially for people like Moonchild that have a special need/affinity for the cipher. Thanks to everyone for continued discussion on this topic. Nich On Feb 4, 2016 9:11 AM, "Kurt Roeckx via RT" wrote: > On Thu, Feb 04, 2016 at 10:10:06AM +0000, Moonchild via RT wrote: > > Really? > > > > That's all we get, a one-liner, no explanation, no rationale, response? > > It's not even "brand new" functionality, Camellia as a raw cipher is > already > > in there, the only difference is wrapping it into GCM-based suites. > Patches > > are available, too. > > I think the concerns are: > - Nobody else seems to be using Camellia > - We don't have a constant time implementation of it > - For processors that have AESNI, it's slower than AES > - Adding more ciphers to the default list will just increase the > client hello and not change anything. > > That being said, I don't think there should be a problem adding > the support. I'm just not sure about enabling it by default. > > > Kurt > > > > ------------------------------------------------------------------------- > http://rt.openssl.org/Ticket/Display.html?id=4075 > > Please log in as guest with password guest if prompted > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > ------------------------------------------------------------------------- http://rt.openssl.org/Ticket/Display.html?id=4075 Please log in as guest with password guest if prompted From rt at openssl.org Thu Feb 4 18:27:15 2016 From: rt at openssl.org (Jeremy Farrell via RT) Date: Thu, 04 Feb 2016 18:27:15 +0000 Subject: [openssl-dev] [openssl.org #1979] Add uClibc support In-Reply-To: <56B397ED.1020301@oracle.com> References: <4A4D15C2.9020404@redfish-solutions.com> <6DD30AA9-EB7A-4634-A7AA-A9B52C7E5A4D@akamai.com> <56B397ED.1020301@oracle.com> Message-ID: On 04/02/2016 16:45, Short, Todd via RT wrote: > FYI: The rational for why these APIs are deprecated. > http://pubs.opengroup.org/onlinepubs/009695399/functions/makecontext.html#tag_03_356_08 That's the superseded POSIX.1-2001 standard, where these functions were made obsolescent. They're no longer part of POSIX at all, having been removed in POSIX.1-2008. See http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xsh_chap01.html#tag_22_01_01_05 Regards, jjf -- J. J. Farrell w: +44 161 493 4838 ------------------------------------------------------------------------- http://rt.openssl.org/Ticket/Display.html?id=1979 Please log in as guest with password guest if prompted From rt at openssl.org Thu Feb 4 19:31:41 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 04 Feb 2016 19:31:41 +0000 Subject: [openssl-dev] [openssl.org #2212] Override DH bits restriction In-Reply-To: References: Message-ID: Five years without commentary. Unlikely to happen, closing ticket. please re-open if still an issue. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org ------------------------------------------------------------------------- http://rt.openssl.org/Ticket/Display.html?id=2212 Please log in as guest with password guest if prompted From rt at openssl.org Thu Feb 4 19:33:38 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 04 Feb 2016 19:33:38 +0000 Subject: [openssl-dev] [openssl.org #2195] [PATCH] Set default field separator in do_name_ex() ("nameopt" switch) In-Reply-To: <4BA08E60.2090502@velox.ch> References: <4BA08E60.2090502@velox.ch> Message-ID: This was fixed. Doc not being fixed, please suggest changes. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org ------------------------------------------------------------------------- http://rt.openssl.org/Ticket/Display.html?id=2195 Please log in as guest with password guest if prompted From rt at openssl.org Thu Feb 4 19:35:23 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 04 Feb 2016 19:35:23 +0000 Subject: [openssl-dev] [openssl.org #2285] [patch] use winsock2.h In-Reply-To: <4C09261B.3000500@mabrand.nl> References: <4C09261B.3000500@mabrand.nl> Message-ID: I forget which ticket had it, but we already had some of this discussion and the code we have is correct. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org ------------------------------------------------------------------------- http://rt.openssl.org/Ticket/Display.html?id=2285 Please log in as guest with password guest if prompted From rt at openssl.org Thu Feb 4 19:55:06 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 04 Feb 2016 19:55:06 +0000 Subject: [openssl-dev] [openssl.org #2287] A bug of PKCS8? In-Reply-To: References: Message-ID: An old unsuppported release. Please open a new ticket if this is still an issue with the current release(s). thanks. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org ------------------------------------------------------------------------- http://rt.openssl.org/Ticket/Display.html?id=2287 Please log in as guest with password guest if prompted From rt at openssl.org Thu Feb 4 19:56:19 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 04 Feb 2016 19:56:19 +0000 Subject: [openssl-dev] [openssl.org #2406] Argument type warning on i2d_ASN1_SET In-Reply-To: <4D15F6DF.40700@airemix.jp> References: <4D15F6DF.40700@airemix.jp> Message-ID: fixed some time ago, works in current release(s). -- Rich Salz, OpenSSL dev team; rsalz at openssl.org ------------------------------------------------------------------------- http://rt.openssl.org/Ticket/Display.html?id=2406 Please log in as guest with password guest if prompted From rt at openssl.org Thu Feb 4 19:57:14 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 04 Feb 2016 19:57:14 +0000 Subject: [openssl-dev] [openssl.org #2386] Bug Report and Patch: Incompatible types in SKM_ASN1_SET_OF_d2i In-Reply-To: <4CF7B374.30501@adnovum.ch> References: <4CF7B374.30501@adnovum.ch> Message-ID: fixed some time ago. works in 1.0.2 and fixed even better in next release :) -- Rich Salz, OpenSSL dev team; rsalz at openssl.org ------------------------------------------------------------------------- http://rt.openssl.org/Ticket/Display.html?id=2386 Please log in as guest with password guest if prompted From rt at openssl.org Thu Feb 4 19:58:52 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 04 Feb 2016 19:58:52 +0000 Subject: [openssl-dev] [openssl.org #2402] PATCH: config and Configure for Xcode Awareness In-Reply-To: References: Message-ID: Please open a new ticket (and patch or GitHub PR) against master if this is still an issue. I don't think it is. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org ------------------------------------------------------------------------- http://rt.openssl.org/Ticket/Display.html?id=2402 Please log in as guest with password guest if prompted From rt at openssl.org Thu Feb 4 20:04:47 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 04 Feb 2016 20:04:47 +0000 Subject: [openssl-dev] [openssl.org #2281] Bug in 1.0.0: SSL_new() leaks s->param if s->method->ssl_new() fails In-Reply-To: <29221480030D334F991AD0FA98E831B63ACB8799BD@EMBX01-HQ.jnpr.net> References: <29221480030D334F991AD0FA98E831B63ACB8799BD@EMBX01-HQ.jnpr.net> Message-ID: this is fixed in master. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org ------------------------------------------------------------------------- http://rt.openssl.org/Ticket/Display.html?id=2281 Please log in as guest with password guest if prompted From rt at openssl.org Thu Feb 4 20:05:48 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 04 Feb 2016 20:05:48 +0000 Subject: [openssl-dev] [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS In-Reply-To: References: Message-ID: VMS support is back in master (openssl 1.1) -- Rich Salz, OpenSSL dev team; rsalz at openssl.org ------------------------------------------------------------------------- http://rt.openssl.org/Ticket/Display.html?id=2449 Please log in as guest with password guest if prompted From rt at openssl.org Thu Feb 4 20:06:39 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 04 Feb 2016 20:06:39 +0000 Subject: [openssl-dev] [openssl.org #2496] [PATCH] Fix compile problems when various ciphers are disabled In-Reply-To: References: Message-ID: most of this is fixed in master, maybe all. if there are still issues, please open a new ticket. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org ------------------------------------------------------------------------- http://rt.openssl.org/Ticket/Display.html?id=2496 Please log in as guest with password guest if prompted From rt at openssl.org Thu Feb 4 20:07:15 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 04 Feb 2016 20:07:15 +0000 Subject: [openssl-dev] [openssl.org #2460] OCSP server uses only IP6 In-Reply-To: <4D6623AB.8070304@mobica.com> References: <4D597C56.5020903@nist.gov> <4D6623AB.8070304@mobica.com> Message-ID: i think -- Rich Salz, OpenSSL dev team; rsalz at openssl.org ------------------------------------------------------------------------- http://rt.openssl.org/Ticket/Display.html?id=2460 Please log in as guest with password guest if prompted From rt at openssl.org Thu Feb 4 20:09:43 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 04 Feb 2016 20:09:43 +0000 Subject: [openssl-dev] [openssl.org #2493] [PATCH] Engines: Eliminate the unneccesary null check In-Reply-To: References: Message-ID: sureware engine is no longer supported. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org ------------------------------------------------------------------------- http://rt.openssl.org/Ticket/Display.html?id=2493 Please log in as guest with password guest if prompted From rt at openssl.org Thu Feb 4 20:20:38 2016 From: rt at openssl.org (Kurt Roeckx via RT) Date: Thu, 04 Feb 2016 20:20:38 +0000 Subject: [openssl-dev] [openssl.org #2460] OCSP server uses only IP6 In-Reply-To: <20160204202031.GA27529@roeckx.be> References: <4D597C56.5020903@nist.gov> <4D6623AB.8070304@mobica.com> <20160204202031.GA27529@roeckx.be> Message-ID: On Thu, Feb 04, 2016 at 08:07:15PM +0000, Rich Salz via RT wrote: > i think -- I'm not sure what you think. But all the apps currently only create 1 socket, which on some OSes could mean that it's IPv6 (or IPv4) only. It needs more work. Kurt ------------------------------------------------------------------------- http://rt.openssl.org/Ticket/Display.html?id=2460 Please log in as guest with password guest if prompted From rt at openssl.org Thu Feb 4 20:27:06 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Thu, 04 Feb 2016 20:27:06 +0000 Subject: [openssl-dev] [openssl.org #2460] OCSP server uses only IP6 In-Reply-To: <420582b3fa684ab2b99e37291461d1c1@usma1ex-dag1mb1.msg.corp.akamai.com> References: <4D597C56.5020903@nist.gov> <4D6623AB.8070304@mobica.com> <20160204202031.GA27529@roeckx.be> <420582b3fa684ab2b99e37291461d1c1@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: > I'm not sure what you think. But all the apps currently only create 1 socket, > which on some OSes could mean that it's IPv6 (or > IPv4) only. It needs more work. Yes, I meant to close the window not the ticket :) Re-opened. ------------------------------------------------------------------------- http://rt.openssl.org/Ticket/Display.html?id=2460 Please log in as guest with password guest if prompted From rt at openssl.org Thu Feb 4 20:33:45 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 04 Feb 2016 20:33:45 +0000 Subject: [openssl-dev] [openssl.org #2521] Enhancement Request In-Reply-To: <138607.52762.qm@web110513.mail.gq1.yahoo.com> References: <138607.52762.qm@web110513.mail.gq1.yahoo.com> Message-ID: you can build/install the docs locally ... -- Rich Salz, OpenSSL dev team; rsalz at openssl.org ------------------------------------------------------------------------- http://rt.openssl.org/Ticket/Display.html?id=2521 Please log in as guest with password guest if prompted From rt at openssl.org Thu Feb 4 20:37:39 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 04 Feb 2016 20:37:39 +0000 Subject: [openssl-dev] [openssl.org #2532] [PATCH] Fix insufficient privilege checking In-Reply-To: <20110523080137.GA4632@suse.de> References: <20110523080137.GA4632@suse.de> Message-ID: This is interesting, although unfortunately it's been years since we looked at it and it is out of date. Rather than replacing all the getenv() calls, a simple wrapper like OPENSSL_safe_getenv() that includes the issetguid test seems a lot cleaner. And the config changes needed to be ported up to master. If anyone does that and makes a PR on github, we'll review it. Closing this for now. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org ------------------------------------------------------------------------- http://rt.openssl.org/Ticket/Display.html?id=2532 Please log in as guest with password guest if prompted From rt at openssl.org Thu Feb 4 20:45:19 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 04 Feb 2016 20:45:19 +0000 Subject: [openssl-dev] [openssl.org #2536] Memory leak in d2i_RSA_PUBKEY() (concise test code included) In-Reply-To: <956166.64807.qm@web59410.mail.ac4.yahoo.com> References: <956166.64807.qm@web59410.mail.ac4.yahoo.com> Message-ID: The d2i routines move the pointer to the next thing. So you have do save key, pass in a copy, and then delete the original key. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org ------------------------------------------------------------------------- http://rt.openssl.org/Ticket/Display.html?id=2536 Please log in as guest with password guest if prompted From rt at openssl.org Thu Feb 4 20:46:01 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 04 Feb 2016 20:46:01 +0000 Subject: [openssl-dev] [openssl.org #2554] Patch: AF_ALG dynamic engine for linux >= 2.6.38 In-Reply-To: References: Message-ID: support for this is in-progress for 1.1 -- Rich Salz, OpenSSL dev team; rsalz at openssl.org ------------------------------------------------------------------------- http://rt.openssl.org/Ticket/Display.html?id=2554 Please log in as guest with password guest if prompted From rt at openssl.org Thu Feb 4 20:50:39 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 04 Feb 2016 20:50:39 +0000 Subject: [openssl-dev] [openssl.org #2571] OCSP send request fails if OCSP server with vhost or reverse proxy In-Reply-To: <4E2B4E61.103@nimastelecom.com> References: <4E2B4E61.103@nimastelecom.com> Message-ID: As listed in the ticket, the -host heade can be used to do what you need. Open a new ticket if the docs need more explanation; thanks. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org ------------------------------------------------------------------------- http://rt.openssl.org/Ticket/Display.html?id=2571 Please log in as guest with password guest if prompted From openssl-users at dukhovni.org Thu Feb 4 20:50:27 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 4 Feb 2016 15:50:27 -0500 Subject: [openssl-dev] [openssl.org #2532] [PATCH] Fix insufficient privilege checking In-Reply-To: References: <20110523080137.GA4632@suse.de> Message-ID: <24C70FBA-9143-49E2-AF43-53DEA25411F2@dukhovni.org> > On Feb 4, 2016, at 3:37 PM, Rich Salz via RT wrote: > > Rather than replacing all the getenv() calls, a simple wrapper like > OPENSSL_safe_getenv() that includes the issetguid test seems a lot cleaner. And > the config changes needed to be ported up to master. Where available, this should use the native safe getenv() interface, rather than just do issetugid() directly: http://man7.org/linux/man-pages/man3/getenv.3.html -- Viktor. From rt at openssl.org Thu Feb 4 20:50:40 2016 From: rt at openssl.org (Viktor Dukhovni via RT) Date: Thu, 04 Feb 2016 20:50:40 +0000 Subject: [openssl-dev] [openssl.org #2532] [PATCH] Fix insufficient privilege checking In-Reply-To: <24C70FBA-9143-49E2-AF43-53DEA25411F2@dukhovni.org> References: <20110523080137.GA4632@suse.de> <24C70FBA-9143-49E2-AF43-53DEA25411F2@dukhovni.org> Message-ID: > On Feb 4, 2016, at 3:37 PM, Rich Salz via RT wrote: > > Rather than replacing all the getenv() calls, a simple wrapper like > OPENSSL_safe_getenv() that includes the issetguid test seems a lot cleaner. And > the config changes needed to be ported up to master. Where available, this should use the native safe getenv() interface, rather than just do issetugid() directly: http://man7.org/linux/man-pages/man3/getenv.3.html -- Viktor. ------------------------------------------------------------------------- http://rt.openssl.org/Ticket/Display.html?id=2532 Please log in as guest with password guest if prompted From rt at openssl.org Thu Feb 4 21:00:33 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 04 Feb 2016 21:00:33 +0000 Subject: [openssl-dev] [openssl.org #2638] s_client -servername BLAH not honoured with -starttls xmpp In-Reply-To: <20111104003443.GD26859@cancey.dynhost.nicta.com.au> References: <20111104003443.GD26859@cancey.dynhost.nicta.com.au> Message-ID: the -xmpphost flag does what you want. In next release. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org ------------------------------------------------------------------------- http://rt.openssl.org/Ticket/Display.html?id=2638 Please log in as guest with password guest if prompted From rt at openssl.org Thu Feb 4 21:02:03 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 04 Feb 2016 21:02:03 +0000 Subject: [openssl-dev] [openssl.org #2664] config does not allow disabling npn In-Reply-To: References: Message-ID: fixed in master: ; ./config no-npn Operating system: x86_64-whatever-linux2 Configuring for linux-x86_64 Configuring OpenSSL version 1.1.0-pre3-dev (0x0x10100003L) ***** Unsupported options: no-npn -- Rich Salz, OpenSSL dev team; rsalz at openssl.org ------------------------------------------------------------------------- http://rt.openssl.org/Ticket/Display.html?id=2664 Please log in as guest with password guest if prompted From rt at openssl.org Thu Feb 4 21:03:49 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 04 Feb 2016 21:03:49 +0000 Subject: [openssl-dev] [openssl.org #2918] [PATCH] Testcase for GOST R 34.11-94 (openssl/engines/ccgost/gosthash.c) In-Reply-To: <65C0C42A-ABE9-4309-9922-35D57CDCEB44@sai.msu.ru> References: <65C0C42A-ABE9-4309-9922-35D57CDCEB44@sai.msu.ru> Message-ID: GOST is now a separately-maintained engine. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org ------------------------------------------------------------------------- http://rt.openssl.org/Ticket/Display.html?id=2918 Please log in as guest with password guest if prompted From rt at openssl.org Thu Feb 4 21:05:13 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 04 Feb 2016 21:05:13 +0000 Subject: [openssl-dev] [openssl.org #2712] Be more liberal when trying to recognize the XMPP starttls headers In-Reply-To: <1328864019.11189.25.camel@vespa.frost.loc> References: <1328864019.11189.25.camel@vespa.frost.loc> Message-ID: is strcasestr common? -- Rich Salz, OpenSSL dev team; rsalz at openssl.org ------------------------------------------------------------------------- http://rt.openssl.org/Ticket/Display.html?id=2712 Please log in as guest with password guest if prompted From rt at openssl.org Thu Feb 4 21:18:24 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 04 Feb 2016 21:18:24 +0000 Subject: [openssl-dev] [openssl.org #3121] Request concerning revoke system for openSSL In-Reply-To: References: Message-ID: There is no defect here. Or at least not enough information. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org ------------------------------------------------------------------------- http://rt.openssl.org/Ticket/Display.html?id=3121 Please log in as guest with password guest if prompted From rt at openssl.org Thu Feb 4 21:23:06 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Thu, 04 Feb 2016 21:23:06 +0000 Subject: [openssl-dev] [openssl.org #2712] Be more liberal when trying to recognize the XMPP starttls headers In-Reply-To: References: <1328864019.11189.25.camel@vespa.frost.loc> Message-ID: Doesn't seem that way. Not present on VMS, and I can't find it on MDSN either. Vid Thu, 04 Feb 2016 kl. 21.05.13, skrev rsalz: > is strcasestr common? -- Richard Levitte levitte at openssl.org ------------------------------------------------------------------------- http://rt.openssl.org/Ticket/Display.html?id=2712 Please log in as guest with password guest if prompted From rsalz at akamai.com Fri Feb 5 03:41:58 2016 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 5 Feb 2016 03:41:58 +0000 Subject: [openssl-dev] [openssl.org #2712] Be more liberal when trying to recognize the XMPP starttls headers In-Reply-To: References: <1328864019.11189.25.camel@vespa.frost.loc> Message-ID: <578e67a06fe44fdaac44a407df2a1b76@usma1ex-dag1mb1.msg.corp.akamai.com> > Doesn't seem that way. Not present on VMS, and I can't find it on MDSN > either. So what I'd have to do is downcase the string and do strstr on all lowercase. Might be reasonable From rt at openssl.org Fri Feb 5 03:42:06 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Fri, 05 Feb 2016 03:42:06 +0000 Subject: [openssl-dev] [openssl.org #2712] Be more liberal when trying to recognize the XMPP starttls headers In-Reply-To: <578e67a06fe44fdaac44a407df2a1b76@usma1ex-dag1mb1.msg.corp.akamai.com> References: <1328864019.11189.25.camel@vespa.frost.loc> <578e67a06fe44fdaac44a407df2a1b76@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: > Doesn't seem that way. Not present on VMS, and I can't find it on MDSN > either. So what I'd have to do is downcase the string and do strstr on all lowercase. Might be reasonable ------------------------------------------------------------------------- http://rt.openssl.org/Ticket/Display.html?id=2712 Please log in as guest with password guest if prompted From openssl-users at dukhovni.org Fri Feb 5 07:30:46 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 5 Feb 2016 02:30:46 -0500 Subject: [openssl-dev] [openssl.org #1596] wrong AKI in cert In-Reply-To: References: <20110523080137.GA4632@suse.de> Message-ID: When a certificate is re-signed via "x509 -signkey" while keeping the existing extensions (i.e. without "-clrext"), the (unwritten) expectation is that that all that's being changed is the validity dates, and the previous certificate content remains unchanged. Yes, the issuer is updated to match the subject if they are not already the same, and the key is replaced with the new key if different, but otherwise the certificate remains the same. This is useful for extending the dates of existing self-signed certificates with as little change as possible. What this means in practice is that if something other than just the dates is changing, one really should use "-clrext" and specify the new desired extensions. For example ("bash" inline file syntax): $ openssl x509 -clrext \ -in old-cert.pem -out new-cert.pem -signkey key.pem \ -extfile <(printf "%s\n%s\n" \ "subjectKeyIdentifier = hash" \ "authorityKeyIdentifier = keyid:always" ) In such cases one of course also needs to specify any other desired extensions. Now it may be argued that a more complicated strategy is possible, in which: * It is determined whether the original certificate is self-signed * If so whether the new key is the original signer and if either condition fails then, while retaining all other extensions the subject key identifier and authority key identifier extensions are dropped and regenerated as specified in the extant configuration. Logic of that complexity is not in place, and it is not entirely clear that its absence is a bug in the code, rather than a matter of incomplete documentation of the limitations of this feature. My take is that this is best addressed at the documentation level, but if someone is really keen to try to make the code automatically perform the right extension surgery, a pull request on Github might be the way to go. -- Viktor. From rt at openssl.org Fri Feb 5 07:31:01 2016 From: rt at openssl.org (Viktor Dukhovni via RT) Date: Fri, 05 Feb 2016 07:31:01 +0000 Subject: [openssl-dev] [openssl.org #1596] wrong AKI in cert In-Reply-To: References: <20110523080137.GA4632@suse.de> Message-ID: When a certificate is re-signed via "x509 -signkey" while keeping the existing extensions (i.e. without "-clrext"), the (unwritten) expectation is that that all that's being changed is the validity dates, and the previous certificate content remains unchanged. Yes, the issuer is updated to match the subject if they are not already the same, and the key is replaced with the new key if different, but otherwise the certificate remains the same. This is useful for extending the dates of existing self-signed certificates with as little change as possible. What this means in practice is that if something other than just the dates is changing, one really should use "-clrext" and specify the new desired extensions. For example ("bash" inline file syntax): $ openssl x509 -clrext \ -in old-cert.pem -out new-cert.pem -signkey key.pem \ -extfile <(printf "%s\n%s\n" \ "subjectKeyIdentifier = hash" \ "authorityKeyIdentifier = keyid:always" ) In such cases one of course also needs to specify any other desired extensions. Now it may be argued that a more complicated strategy is possible, in which: * It is determined whether the original certificate is self-signed * If so whether the new key is the original signer and if either condition fails then, while retaining all other extensions the subject key identifier and authority key identifier extensions are dropped and regenerated as specified in the extant configuration. Logic of that complexity is not in place, and it is not entirely clear that its absence is a bug in the code, rather than a matter of incomplete documentation of the limitations of this feature. My take is that this is best addressed at the documentation level, but if someone is really keen to try to make the code automatically perform the right extension surgery, a pull request on Github might be the way to go. -- Viktor. ------------------------------------------------------------------------- http://rt.openssl.org/Ticket/Display.html?id=1596 Please log in as guest with password guest if prompted From rt at openssl.org Fri Feb 5 14:52:28 2016 From: rt at openssl.org (sav_ix@ukr.net via RT) Date: Fri, 05 Feb 2016 14:52:28 +0000 Subject: [openssl-dev] [openssl.org #4255] OpenSSL-1.1.0-pre2 failures using MinGW-W64 In-Reply-To: <1454683351.356524788.0b0itpc2@frv39.fwdcdn.com> References: <1453060954.186021958.y9vnrjtk@frv39.fwdcdn.com> <1454683351.356524788.0b0itpc2@frv39.fwdcdn.com> Message-ID: ??? Hi, Got suggestion from Viktor Szakats (https://github.com/vszakats) concerning OpenSSL build errors using MinGW-W64 with? -std=c11 parameter: ============================================== [snip] The error details indicate that some source code is not compliant with the C11 standard and therefore fail to compile in this mode. It doesn't seem to be gcc/mingw/Windows/64-bit specific: In file included from md4_locl.h:87:0, from md4_dgst.c:62: md4_dgst.c: In function 'md4_block_data_order': ../md32_common.h:167:33: warning: implicit declaration of function 'asm' [-Wimplicit-function-declaration] asm ( \ ^ md4_locl.h:105:11: note: in expansion of macro 'ROTATE' Try with -std=gnu11 instead to leave some optional C extensions enabled, like inline asm support. Current OpenSSL code seems to require it. [snip] I wouldn't call it an error per se. Fully standard compliant modes are rarely used in real-life projects, and I assume this was not a goal when creating this piece of code. Speaking of this specific error, IMO it's also generally cleaner not to mix languages inside the same source file. I can't see the full scope of this in case of OpenSSL, but it probably be useful to report this and suggest to move assembly code into separate .s files. Such practice is already used in quite a few places, so this exception may well be an oversight or heritage waiting to be updated. ============================================== Regards, Alexander ------------------------------------------------------------------------- http://rt.openssl.org/Ticket/Display.html?id=4255 Please log in as guest with password guest if prompted From rt at openssl.org Fri Feb 5 15:09:48 2016 From: rt at openssl.org (Rich Salz via RT) Date: Fri, 05 Feb 2016 15:09:48 +0000 Subject: [openssl-dev] [openssl.org #2439] bug report: memory leak In-Reply-To: <8f009499d39b234f72ff066b52fe7e4e@mail.gmail.com> References: <8f009499d39b234f72ff066b52fe7e4e@mail.gmail.com> Message-ID: In our review, the code is correct and there is no leak. Please provide a patch against the current release if you think otherwise. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org ------------------------------------------------------------------------- http://rt.openssl.org/Ticket/Display.html?id=2439 Please log in as guest with password guest if prompted From rt at openssl.org Fri Feb 5 15:26:09 2016 From: rt at openssl.org (Rich Salz via RT) Date: Fri, 05 Feb 2016 15:26:09 +0000 Subject: [openssl-dev] [openssl.org #2024] [doc bug] missing .pods In-Reply-To: <4A9597A1.8070609@nospam.hackery.net> References: <4A9597A1.8070609@nospam.hackery.net> Message-ID: fixed in 6c884ed by removing the "see also" to non-existant pages. some aren't appropriate for public docs, and some still need to be written, but at least the docs are accurate now. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org ------------------------------------------------------------------------- http://rt.openssl.org/Ticket/Display.html?id=2024 Please log in as guest with password guest if prompted From rt at openssl.org Fri Feb 5 15:26:45 2016 From: rt at openssl.org (Rich Salz via RT) Date: Fri, 05 Feb 2016 15:26:45 +0000 Subject: [openssl-dev] [openssl.org #2890] ERR_string_error passes wrong buffer size In-Reply-To: <20121002104909.GA4111@wilbur.25thandClement.com> References: <20121002104909.GA4111@wilbur.25thandClement.com> Message-ID: fixed in 6c884ed. also added more words about "use the safer routine err_string_eror_n" :) -- Rich Salz, OpenSSL dev team; rsalz at openssl.org ------------------------------------------------------------------------- http://rt.openssl.org/Ticket/Display.html?id=2890 Please log in as guest with password guest if prompted From rt at openssl.org Fri Feb 5 15:28:02 2016 From: rt at openssl.org (Rich Salz via RT) Date: Fri, 05 Feb 2016 15:28:02 +0000 Subject: [openssl-dev] [openssl.org #3461] PATCH: expanded explanation of PEM ENCRYPTION In-Reply-To: References: Message-ID: fixed with 6c884ed. thanks! we also bad code style (plaintext private keys) and the netscape_cert routines. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org ------------------------------------------------------------------------- http://rt.openssl.org/Ticket/Display.html?id=3461 Please log in as guest with password guest if prompted From rt at openssl.org Fri Feb 5 15:29:00 2016 From: rt at openssl.org (Rich Salz via RT) Date: Fri, 05 Feb 2016 15:29:00 +0000 Subject: [openssl-dev] [openssl.org #4240] Document some of the speed options In-Reply-To: <1452853997.4141.1.camel@redhat.com> References: <1452853997.4141.1.camel@redhat.com> Message-ID: fixed in master with 6c884ed thank you! -- Rich Salz, OpenSSL dev team; rsalz at openssl.org ------------------------------------------------------------------------- http://rt.openssl.org/Ticket/Display.html?id=4240 Please log in as guest with password guest if prompted From rt at openssl.org Fri Feb 5 15:29:27 2016 From: rt at openssl.org (Rich Salz via RT) Date: Fri, 05 Feb 2016 15:29:27 +0000 Subject: [openssl-dev] [openssl.org #4260] [PATCH] Update the return value documented for X509_REQ_sign and X509_sign In-Reply-To: References: Message-ID: fixed in master with 6c884ed thanks! -- Rich Salz, OpenSSL dev team; rsalz at openssl.org ------------------------------------------------------------------------- http://rt.openssl.org/Ticket/Display.html?id=4260 Please log in as guest with password guest if prompted From rt at openssl.org Fri Feb 5 16:02:46 2016 From: rt at openssl.org (J Mohan Rao Arisankala via RT) Date: Fri, 05 Feb 2016 16:02:46 +0000 Subject: [openssl-dev] [openssl.org #4291] [PATCH] <-help> option in man pages In-Reply-To: References: Message-ID: Hi, [-help] option in most of the commands documentation was missing and in ciphers and rehash commands it was wrongly specified as [-h], which is not considered as a valid option. I have create the below pull request with the changes. Please have a look. https://github.com/openssl/openssl/pull/628 Thanks, Mohan ------------------------------------------------------------------------- http://rt.openssl.org/Ticket/Display.html?id=4291 Please log in as guest with password guest if prompted From rt at openssl.org Fri Feb 5 16:18:56 2016 From: rt at openssl.org (Rich Salz via RT) Date: Fri, 05 Feb 2016 16:18:56 +0000 Subject: [openssl-dev] [openssl.org #4291] [PATCH] <-help> option in man pages In-Reply-To: References: Message-ID: fixed in master with 0ae9e2926654657862e104a111a4e3028b0be8f6 thanks! -- Rich Salz, OpenSSL dev team; rsalz at openssl.org ------------------------------------------------------------------------- http://rt.openssl.org/Ticket/Display.html?id=4291 Please log in as guest with password guest if prompted From dwmw2 at infradead.org Fri Feb 5 16:34:29 2016 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 05 Feb 2016 16:34:29 +0000 Subject: [openssl-dev] [openssl.org #3964] Fix OPENSSL_NO_STDIO build In-Reply-To: References: <1438170735.26511.33.camel@intel.com> Message-ID: <1454690069.4788.309.camel@infradead.org> On Thu, 2016-02-04 at 03:04 +0000, Rich Salz via RT wrote: > So guys, sorry for dropping the ball. Where are we on this now? Dropping rt@ since the OPENSSL_NO_STDIO build is actually solved now so RT#3964 looks like it can be closed. I'm choosing to interpret your question in the wider sense of the UEFI build. I have submitted https://github.com/openssl/openssl/pull/631?which matches the EDK2 tree at?http://git.infradead.org/users/dwmw2/edk2.git The OpenSSL bits look OK to me; it's mostly just a few fixes for some of the recent cleanups, along with the patch that's been outstanding for a while for RT#3628. I am moderately unhappy with the last commit on the EDK2 side, though. The problem is that the API that the EDK2 CryptoPkg offers to its clients includes a function to get the size of the context. Perhaps we should change that... Qin, is that feasible? In the mean time, I have a horrid "#include <../hmac/hmac_lcl.h>' to make it actually work. Having already done that, I was desensitised enough that elsewhere in the patch I include <../evp/evp_locl.h> just so that we can continue to have an EVP_MD_CTX locally on the stack instead of having to use dynamic allocation for it. Which I concede probably wants cleaning up. But I don't *like* being forced to switch to dynamic allocation. That just introduces failure modes that didn't exist before. -- David Woodhouse Open Source Technology Centre David.Woodhouse at intel.com Intel Corporation -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5691 bytes Desc: not available URL: From rt at openssl.org Fri Feb 5 16:43:52 2016 From: rt at openssl.org (Rich Salz via RT) Date: Fri, 05 Feb 2016 16:43:52 +0000 Subject: [openssl-dev] [openssl.org #3964] Fix OPENSSL_NO_STDIO build In-Reply-To: <1438170735.26511.33.camel@intel.com> References: <1438170735.26511.33.camel@intel.com> Message-ID: This has been fixed. Still some work to do for UEFI, but that will be separate RT's and/or PR's. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org ------------------------------------------------------------------------- http://rt.openssl.org/Ticket/Display.html?id=3964 Please log in as guest with password guest if prompted From rt at openssl.org Fri Feb 5 17:20:15 2016 From: rt at openssl.org (Rich Salz via RT) Date: Fri, 05 Feb 2016 17:20:15 +0000 Subject: [openssl-dev] [openssl.org #4175] Add new macro or PKCS7 flag to disable the check for both data and content In-Reply-To: References: Message-ID: can you make a PR (separate from the one you have for UEFI) that does the right thing? Or attach it to this ticket? I've kinda lost track :( -- Rich Salz, OpenSSL dev team; rsalz at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4175 Please log in as guest with password guest if prompted From dwmw2 at infradead.org Fri Feb 5 17:29:08 2016 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 05 Feb 2016 17:29:08 +0000 Subject: [openssl-dev] [openssl.org #4175] Add new macro or PKCS7 flag to disable the check for both data and content In-Reply-To: References: Message-ID: <1454693348.4788.326.camel@infradead.org> On Fri, 2016-02-05 at 17:20 +0000, Rich Salz via RT wrote: > can you make a PR (separate from the one you have for UEFI) that does > the right > thing? Or attach it to this ticket? > I've kinda lost track :( Oops, forgot this one in the set of patches I lined up today. Will add it.? -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5691 bytes Desc: not available URL: From rt at openssl.org Fri Feb 5 17:31:34 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Fri, 05 Feb 2016 17:31:34 +0000 Subject: [openssl-dev] [openssl.org #4175] Add new macro or PKCS7 flag to disable the check for both data and content In-Reply-To: <61551bf6bbf4437cb15217814c5e7195@usma1ex-dag1mb1.msg.corp.akamai.com> References: <1454693348.4788.326.camel@infradead.org> <61551bf6bbf4437cb15217814c5e7195@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: And update the PR to say that it also closes this ticket :) -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4175 Please log in as guest with password guest if prompted From rt at openssl.org Fri Feb 5 17:37:28 2016 From: rt at openssl.org (Rich Salz via RT) Date: Fri, 05 Feb 2016 17:37:28 +0000 Subject: [openssl-dev] [openssl.org #4087] Patch for openssl_1_0_2 link failure when OPENSSL_NO_SHA512 defined In-Reply-To: <1159314437.8385055.1444501607462.JavaMail.zimbra@bay2sierra.com> References: <1413788390.7650808.1444410505375.JavaMail.zimbra@bay2sierra.com> <1159314437.8385055.1444501607462.JavaMail.zimbra@bay2sierra.com> Message-ID: Can you re-org the patch so that it doesn't break into the middle if a compound statement? (across the else) thanks. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4087 Please log in as guest with password guest if prompted From rt at openssl.org Fri Feb 5 17:39:11 2016 From: rt at openssl.org (Rainer Jung via RT) Date: Fri, 05 Feb 2016 17:39:11 +0000 Subject: [openssl-dev] [openssl.org #4292] SSL_CTX_set_mode.pod:101: Unknown command paragraph "======" In-Reply-To: <56B4DE08.3060300@kippdata.de> References: <56B4DE08.3060300@kippdata.de> Message-ID: OpenSSL 1.1.0 produces the error SSL_CTX_set_mode.pod:101: Unknown command paragraph "======" during "make install". It looks like line 101 is indeed an unintended addition introduced by https://github.com/openssl/openssl/commit/bc8857bf70f5428bc2f0d26162ed59e3abb11fb1 The error does only show up when using old tools, e.g. no error for "Pod::Man 2.16 (Pod::Simple 3.05)" but error for "Pod::Man v1.37, Pod::Parser v1.14". But in this case I think the right solution is to simply remove the offending line from the pod. It looks like it shouldn't be there. Thanks and regards, Rainer -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4292 Please log in as guest with password guest if prompted From rt at openssl.org Fri Feb 5 17:47:10 2016 From: rt at openssl.org (Rich Salz via RT) Date: Fri, 05 Feb 2016 17:47:10 +0000 Subject: [openssl-dev] [openssl.org #1596] Re: wrong AKI in cert In-Reply-To: <713B34B4-2F61-4590-9079-4BD50D7B71E7@gmail.com> References: <713B34B4-2F61-4590-9079-4BD50D7B71E7@gmail.com> Message-ID: we updated the doc in commit 724a1d2 for master. closing ticket. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=1596 Please log in as guest with password guest if prompted From rt at openssl.org Fri Feb 5 17:48:43 2016 From: rt at openssl.org (Rich Salz via RT) Date: Fri, 05 Feb 2016 17:48:43 +0000 Subject: [openssl-dev] [openssl.org #4292] SSL_CTX_set_mode.pod:101: Unknown command paragraph "======" In-Reply-To: <56B4DE08.3060300@kippdata.de> References: <56B4DE08.3060300@kippdata.de> Message-ID: fixed in commit 0dc2255 thanks -- Rich Salz, OpenSSL dev team; rsalz at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4292 Please log in as guest with password guest if prompted From dwmw2 at infradead.org Fri Feb 5 18:26:30 2016 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 05 Feb 2016 18:26:30 +0000 Subject: [openssl-dev] [openssl.org #4175] Add new macro or PKCS7 flag to disable the check for both data and content In-Reply-To: References: <1454693348.4788.326.camel@infradead.org> <61551bf6bbf4437cb15217814c5e7195@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <1454696790.4788.327.camel@infradead.org> On Fri, 2016-02-05 at 17:31 +0000, Salz, Rich via RT wrote: > And update the PR to say that it also closes this ticket :) Well, it can be a separate PR if the first is already merged... -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5691 bytes Desc: not available URL: From rt at openssl.org Fri Feb 5 18:26:36 2016 From: rt at openssl.org (David Woodhouse via RT) Date: Fri, 05 Feb 2016 18:26:36 +0000 Subject: [openssl-dev] [openssl.org #4175] Add new macro or PKCS7 flag to disable the check for both data and content In-Reply-To: <1454696790.4788.327.camel@infradead.org> References: <1454693348.4788.326.camel@infradead.org> <61551bf6bbf4437cb15217814c5e7195@usma1ex-dag1mb1.msg.corp.akamai.com> <1454696790.4788.327.camel@infradead.org> Message-ID: On Fri, 2016-02-05 at 17:31 +0000, Salz, Rich via RT wrote: > And update the PR to say that it also closes this ticket :) Well, it can be a separate PR if the first is already merged... -- dwmw2 -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4175 Please log in as guest with password guest if prompted -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5691 bytes Desc: not available URL: From rt at openssl.org Fri Feb 5 19:28:19 2016 From: rt at openssl.org (Rich Salz via RT) Date: Fri, 05 Feb 2016 19:28:19 +0000 Subject: [openssl-dev] [openssl.org #4070] OpenSSL 1.0.1p bug and suggested fix: su-filter.pl regex for struct/union definitions also matches other code In-Reply-To: <393F9D5F11A7114396FEC553BE3B61FA50465CBA@G1W3776.americas.hpqcorp.net> References: <393F9D5F11A7114396FEC553BE3B61FA50465CBA@G1W3776.americas.hpqcorp.net> Message-ID: fixed in master (not worth backporting) commit 2b52de9 -- Rich Salz, OpenSSL dev team; rsalz at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4070 Please log in as guest with password guest if prompted From fedor at indutny.com Fri Feb 5 22:42:06 2016 From: fedor at indutny.com (Fedor Indutny) Date: Fri, 5 Feb 2016 17:42:06 -0500 Subject: [openssl-dev] [openssl.org #3528] [PATCH] ssl: SSL_MODE_ASYNC_KEY_EX In-Reply-To: References: <44073f2d4c9442249288671457b7abaa@usma1ex-dag1mb1.msg.corp.akamai.com> <56B31A15.80601@openssl.org> Message-ID: Matt, I have looked through the APIs. Will have to experiment with them somewhen later to see how well they will perform, but from theoretical point of view I am a bit scared of having 2 fds (and one ucontext) for every job in a pool. It seems like this could be a bit of burden in event-loop based model. For example, it is not hard to imagine a situation in node.js application with 10000 handshakes that are trying to complete in parallel. Is there any need in creating this fds unconditionally? However, again, this is only a hypothetical situation, I'm yet to see how well it will behave in real situations. Just sharing some immediate concerns with you. Thank you, Fedor. On Thu, Feb 4, 2016 at 4:56 AM, Fedor Indutny via RT wrote: > Thank you very much, Matt, Rich. > > I will read through these docs tomorrow. > > On Thu, Feb 4, 2016 at 4:29 AM, Matt Caswell via RT > wrote: > > > > > > > On 04/02/16 06:34, Salz, Rich via RT wrote: > > > It?s late and my response was incomplete. > > > The other part has already landed in master, and that's the "async > > engine" support. > > > > See: > > > > https://www.openssl.org/docs/manmaster/crypto/ASYNC_start_job.html > > https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_set_mode.html (i.e. > > the SSL_MODE_ASYNC bit) > > https://www.openssl.org/docs/manmaster/ssl/SSL_waiting_for_async.html > > > > I'm working on a patch that may make some tweaks to this API, but you > > should get the idea. > > > > Matt > > > > > > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Fri Feb 5 22:42:38 2016 From: rt at openssl.org (Fedor Indutny via RT) Date: Fri, 05 Feb 2016 22:42:38 +0000 Subject: [openssl-dev] [openssl.org #3528] [PATCH] ssl: SSL_MODE_ASYNC_KEY_EX In-Reply-To: References: <56B31A15.80601@openssl.org> Message-ID: Matt, I have looked through the APIs. Will have to experiment with them somewhen later to see how well they will perform, but from theoretical point of view I am a bit scared of having 2 fds (and one ucontext) for every job in a pool. It seems like this could be a bit of burden in event-loop based model. For example, it is not hard to imagine a situation in node.js application with 10000 handshakes that are trying to complete in parallel. Is there any need in creating this fds unconditionally? However, again, this is only a hypothetical situation, I'm yet to see how well it will behave in real situations. Just sharing some immediate concerns with you. Thank you, Fedor. On Thu, Feb 4, 2016 at 4:56 AM, Fedor Indutny via RT wrote: > Thank you very much, Matt, Rich. > > I will read through these docs tomorrow. > > On Thu, Feb 4, 2016 at 4:29 AM, Matt Caswell via RT > wrote: > > > > > > > On 04/02/16 06:34, Salz, Rich via RT wrote: > > > It?s late and my response was incomplete. > > > The other part has already landed in master, and that's the "async > > engine" support. > > > > See: > > > > https://www.openssl.org/docs/manmaster/crypto/ASYNC_start_job.html > > https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_set_mode.html (i.e. > > the SSL_MODE_ASYNC bit) > > https://www.openssl.org/docs/manmaster/ssl/SSL_waiting_for_async.html > > > > I'm working on a patch that may make some tweaks to this API, but you > > should get the idea. > > > > Matt > > > > > > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3528 Please log in as guest with password guest if prompted From matt at openssl.org Sat Feb 6 00:14:48 2016 From: matt at openssl.org (Matt Caswell) Date: Sat, 6 Feb 2016 00:14:48 +0000 Subject: [openssl-dev] [openssl.org #3528] [PATCH] ssl: SSL_MODE_ASYNC_KEY_EX In-Reply-To: References: <44073f2d4c9442249288671457b7abaa@usma1ex-dag1mb1.msg.corp.akamai.com> <56B31A15.80601@openssl.org> Message-ID: <56B53AF8.30001@openssl.org> On 05/02/16 22:42, Fedor Indutny wrote: > Matt, > > I have looked through the APIs. Will have to experiment with them > somewhen later to see how well they will perform, but from theoretical > point of view I am a bit scared of having 2 fds (and one ucontext) for > every job in a pool. It seems like this could be a bit of burden in > event-loop based model. For example, it is not hard to imagine a > situation in node.js application with 10000 handshakes that are trying > to complete in parallel. Is there any need in creating this fds > unconditionally? Well of course the number of jobs in the pool is not the same as the number of handshakes. We create a pool of jobs that are shared between the handshakes as required in order to conserve resources. With regards to the fds, I mentioned that I was working on some tweaks to the API. It is in this area where there are tweaks being made. Specifically I am moving the creation of the fds to be a responsibility of the called code (i.e. most likely an engine) and not the async framework itself. > However, again, this is only a hypothetical situation, I'm yet to see > how well it will behave in real situations. Just sharing some immediate > concerns with you. I have been collaborating with Intel on this piece of work and they have been testing the performance quite thoroughly. We are still working on optimising things, but so far so good. Matt > > Thank you, > Fedor. > > On Thu, Feb 4, 2016 at 4:56 AM, Fedor Indutny via RT > wrote: > > Thank you very much, Matt, Rich. > > I will read through these docs tomorrow. > > On Thu, Feb 4, 2016 at 4:29 AM, Matt Caswell via RT > wrote: > > > > > > > On 04/02/16 06:34, Salz, Rich via RT wrote: > > > It?s late and my response was incomplete. > > > The other part has already landed in master, and that's the "async > > engine" support. > > > > See: > > > > https://www.openssl.org/docs/manmaster/crypto/ASYNC_start_job.html > > https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_set_mode.html (i.e. > > the SSL_MODE_ASYNC bit) > > https://www.openssl.org/docs/manmaster/ssl/SSL_waiting_for_async.html > > > > I'm working on a patch that may make some tweaks to this API, but you > > should get the idea. > > > > Matt > > > > > > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > > > > From rt at openssl.org Sat Feb 6 00:14:52 2016 From: rt at openssl.org (Matt Caswell via RT) Date: Sat, 06 Feb 2016 00:14:52 +0000 Subject: [openssl-dev] [openssl.org #3528] [PATCH] ssl: SSL_MODE_ASYNC_KEY_EX In-Reply-To: <56B53AF8.30001@openssl.org> References: <56B31A15.80601@openssl.org> <56B53AF8.30001@openssl.org> Message-ID: On 05/02/16 22:42, Fedor Indutny wrote: > Matt, > > I have looked through the APIs. Will have to experiment with them > somewhen later to see how well they will perform, but from theoretical > point of view I am a bit scared of having 2 fds (and one ucontext) for > every job in a pool. It seems like this could be a bit of burden in > event-loop based model. For example, it is not hard to imagine a > situation in node.js application with 10000 handshakes that are trying > to complete in parallel. Is there any need in creating this fds > unconditionally? Well of course the number of jobs in the pool is not the same as the number of handshakes. We create a pool of jobs that are shared between the handshakes as required in order to conserve resources. With regards to the fds, I mentioned that I was working on some tweaks to the API. It is in this area where there are tweaks being made. Specifically I am moving the creation of the fds to be a responsibility of the called code (i.e. most likely an engine) and not the async framework itself. > However, again, this is only a hypothetical situation, I'm yet to see > how well it will behave in real situations. Just sharing some immediate > concerns with you. I have been collaborating with Intel on this piece of work and they have been testing the performance quite thoroughly. We are still working on optimising things, but so far so good. Matt > > Thank you, > Fedor. > > On Thu, Feb 4, 2016 at 4:56 AM, Fedor Indutny via RT > wrote: > > Thank you very much, Matt, Rich. > > I will read through these docs tomorrow. > > On Thu, Feb 4, 2016 at 4:29 AM, Matt Caswell via RT > wrote: > > > > > > > On 04/02/16 06:34, Salz, Rich via RT wrote: > > > It?s late and my response was incomplete. > > > The other part has already landed in master, and that's the "async > > engine" support. > > > > See: > > > > https://www.openssl.org/docs/manmaster/crypto/ASYNC_start_job.html > > https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_set_mode.html (i.e. > > the SSL_MODE_ASYNC bit) > > https://www.openssl.org/docs/manmaster/ssl/SSL_waiting_for_async.html > > > > I'm working on a patch that may make some tweaks to this API, but you > > should get the idea. > > > > Matt > > > > > > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > > > > -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3528 Please log in as guest with password guest if prompted From fedor at indutny.com Sat Feb 6 04:24:03 2016 From: fedor at indutny.com (Fedor Indutny) Date: Fri, 5 Feb 2016 23:24:03 -0500 Subject: [openssl-dev] [openssl.org #3528] [PATCH] ssl: SSL_MODE_ASYNC_KEY_EX In-Reply-To: <56B53AF8.30001@openssl.org> References: <44073f2d4c9442249288671457b7abaa@usma1ex-dag1mb1.msg.corp.akamai.com> <56B31A15.80601@openssl.org> <56B53AF8.30001@openssl.org> Message-ID: On Fri, Feb 5, 2016 at 7:14 PM, Matt Caswell wrote: > > > On 05/02/16 22:42, Fedor Indutny wrote: > > Matt, > > > > I have looked through the APIs. Will have to experiment with them > > somewhen later to see how well they will perform, but from theoretical > > point of view I am a bit scared of having 2 fds (and one ucontext) for > > every job in a pool. It seems like this could be a bit of burden in > > event-loop based model. For example, it is not hard to imagine a > > situation in node.js application with 10000 handshakes that are trying > > to complete in parallel. Is there any need in creating this fds > > unconditionally? > > Well of course the number of jobs in the pool is not the same as the > number of handshakes. We create a pool of jobs that are shared between > the handshakes as required in order to conserve resources. With regards > to the fds, I mentioned that I was working on some tweaks to the API. It > is in this area where there are tweaks being made. Specifically I am > moving the creation of the fds to be a responsibility of the called code > (i.e. most likely an engine) and not the async framework itself. > I understand what the pool means ;) The imaginary situation that I was talking about had lots of handshakes happening in parallel. To make it a bit real: a server that decrypts premaster secrets remotely with 2000ms latency, that receives 1000 requests per second. In such situation pool size needs to be at least 2000 to accommodate this amount of requests. While 2000ms is a bit far-fetched, it is very easy to imagine that that remote decrypting server will go absolutely down and won't respond at all. Meaning that for some period of time (maybe 5-10 seconds) all this load is going to attempt to take new job from the pool. While I'm sure that SSL structures itself will take a huge stake in resources usage, having extra fd for each of these jobs doesn't sound right to me. I'm glad to hear that this fd-behavior is going to be overridable. This sounds lovely! > > > However, again, this is only a hypothetical situation, I'm yet to see > > how well it will behave in real situations. Just sharing some immediate > > concerns with you. > > I have been collaborating with Intel on this piece of work and they have > been testing the performance quite thoroughly. We are still working on > optimising things, but so far so good. > > Fantastic! Thank you very much, Fedor. > Matt > > > > > > Thank you, > > Fedor. > > > > On Thu, Feb 4, 2016 at 4:56 AM, Fedor Indutny via RT > > wrote: > > > > Thank you very much, Matt, Rich. > > > > I will read through these docs tomorrow. > > > > On Thu, Feb 4, 2016 at 4:29 AM, Matt Caswell via RT > > wrote: > > > > > > > > > > > On 04/02/16 06:34, Salz, Rich via RT wrote: > > > > It?s late and my response was incomplete. > > > > The other part has already landed in master, and that's the > "async > > > engine" support. > > > > > > See: > > > > > > https://www.openssl.org/docs/manmaster/crypto/ASYNC_start_job.html > > > https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_set_mode.html > (i.e. > > > the SSL_MODE_ASYNC bit) > > > > https://www.openssl.org/docs/manmaster/ssl/SSL_waiting_for_async.html > > > > > > I'm working on a patch that may make some tweaks to this API, but > you > > > should get the idea. > > > > > > Matt > > > > > > > > > > > > > _______________________________________________ > > openssl-dev mailing list > > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > > > > > > > > > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Sat Feb 6 04:24:35 2016 From: rt at openssl.org (Fedor Indutny via RT) Date: Sat, 06 Feb 2016 04:24:35 +0000 Subject: [openssl-dev] [openssl.org #3528] [PATCH] ssl: SSL_MODE_ASYNC_KEY_EX In-Reply-To: References: <56B53AF8.30001@openssl.org> Message-ID: On Fri, Feb 5, 2016 at 7:14 PM, Matt Caswell wrote: > > > On 05/02/16 22:42, Fedor Indutny wrote: > > Matt, > > > > I have looked through the APIs. Will have to experiment with them > > somewhen later to see how well they will perform, but from theoretical > > point of view I am a bit scared of having 2 fds (and one ucontext) for > > every job in a pool. It seems like this could be a bit of burden in > > event-loop based model. For example, it is not hard to imagine a > > situation in node.js application with 10000 handshakes that are trying > > to complete in parallel. Is there any need in creating this fds > > unconditionally? > > Well of course the number of jobs in the pool is not the same as the > number of handshakes. We create a pool of jobs that are shared between > the handshakes as required in order to conserve resources. With regards > to the fds, I mentioned that I was working on some tweaks to the API. It > is in this area where there are tweaks being made. Specifically I am > moving the creation of the fds to be a responsibility of the called code > (i.e. most likely an engine) and not the async framework itself. > I understand what the pool means ;) The imaginary situation that I was talking about had lots of handshakes happening in parallel. To make it a bit real: a server that decrypts premaster secrets remotely with 2000ms latency, that receives 1000 requests per second. In such situation pool size needs to be at least 2000 to accommodate this amount of requests. While 2000ms is a bit far-fetched, it is very easy to imagine that that remote decrypting server will go absolutely down and won't respond at all. Meaning that for some period of time (maybe 5-10 seconds) all this load is going to attempt to take new job from the pool. While I'm sure that SSL structures itself will take a huge stake in resources usage, having extra fd for each of these jobs doesn't sound right to me. I'm glad to hear that this fd-behavior is going to be overridable. This sounds lovely! > > > However, again, this is only a hypothetical situation, I'm yet to see > > how well it will behave in real situations. Just sharing some immediate > > concerns with you. > > I have been collaborating with Intel on this piece of work and they have > been testing the performance quite thoroughly. We are still working on > optimising things, but so far so good. > > Fantastic! Thank you very much, Fedor. > Matt > > > > > > Thank you, > > Fedor. > > > > On Thu, Feb 4, 2016 at 4:56 AM, Fedor Indutny via RT > > wrote: > > > > Thank you very much, Matt, Rich. > > > > I will read through these docs tomorrow. > > > > On Thu, Feb 4, 2016 at 4:29 AM, Matt Caswell via RT > > wrote: > > > > > > > > > > > On 04/02/16 06:34, Salz, Rich via RT wrote: > > > > It?s late and my response was incomplete. > > > > The other part has already landed in master, and that's the > "async > > > engine" support. > > > > > > See: > > > > > > https://www.openssl.org/docs/manmaster/crypto/ASYNC_start_job.html > > > https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_set_mode.html > (i.e. > > > the SSL_MODE_ASYNC bit) > > > > https://www.openssl.org/docs/manmaster/ssl/SSL_waiting_for_async.html > > > > > > I'm working on a patch that may make some tweaks to this API, but > you > > > should get the idea. > > > > > > Matt > > > > > > > > > > > > > _______________________________________________ > > openssl-dev mailing list > > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > > > > > > > > > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3528 Please log in as guest with password guest if prompted From dmitry at addlive.com Sat Feb 6 06:23:33 2016 From: dmitry at addlive.com (Dmitry Sobinov) Date: Sat, 6 Feb 2016 17:23:33 +1100 Subject: [openssl-dev] [openssl.org #4214] [GitHub PR] RFC 7714 DTLS-SRTP profiles In-Reply-To: References: <166A7D6B-AF20-4490-A78B-DF168E64CE70@addlive.com> Message-ID: This ticket can be closed. The fix is in master. Regards, Dmitry On Sun, Jan 3, 2016 at 8:40 AM, Dmitry Sobinov via RT wrote: > Hi, > > I?ve created a pull request with simple changes to support two new AEAD > profiles for DTLS-SRTP. > > https://github.com/openssl/openssl/pull/521 < > https://github.com/openssl/openssl/pull/521> > > > Regards, > Dmitry Sobinov > > _______________________________________________ > openssl-bugs-mod mailing list > openssl-bugs-mod at openssl.org > https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > > -- --- Dmitry Sobinov AddLive.com Live video and voice for your application -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Sat Feb 6 06:23:47 2016 From: rt at openssl.org (Dmitry Sobinov via RT) Date: Sat, 06 Feb 2016 06:23:47 +0000 Subject: [openssl-dev] [openssl.org #4214] [GitHub PR] RFC 7714 DTLS-SRTP profiles In-Reply-To: References: <166A7D6B-AF20-4490-A78B-DF168E64CE70@addlive.com> Message-ID: This ticket can be closed. The fix is in master. Regards, Dmitry On Sun, Jan 3, 2016 at 8:40 AM, Dmitry Sobinov via RT wrote: > Hi, > > I?ve created a pull request with simple changes to support two new AEAD > profiles for DTLS-SRTP. > > https://github.com/openssl/openssl/pull/521 < > https://github.com/openssl/openssl/pull/521> > > > Regards, > Dmitry Sobinov > > _______________________________________________ > openssl-bugs-mod mailing list > openssl-bugs-mod at openssl.org > https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > > -- --- Dmitry Sobinov AddLive.com Live video and voice for your application -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4214 Please log in as guest with password guest if prompted From rt at openssl.org Sat Feb 6 14:20:38 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sat, 06 Feb 2016 14:20:38 +0000 Subject: [openssl-dev] [openssl.org #4194] engine command regression in 1.1 In-Reply-To: <5678F551.8000406@roumenpetrov.info> References: <5678F551.8000406@roumenpetrov.info> Message-ID: There's now a manpage that explains where and when engines can be named. :) Not changing the behavior back to what it was, sorry. Closing the ticket. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4194 Please log in as guest with password guest if prompted From rt at openssl.org Sat Feb 6 14:23:24 2016 From: rt at openssl.org (Matt Caswell via RT) Date: Sat, 06 Feb 2016 14:23:24 +0000 Subject: [openssl-dev] [openssl.org #4214] [GitHub PR] RFC 7714 DTLS-SRTP profiles In-Reply-To: <166A7D6B-AF20-4490-A78B-DF168E64CE70@addlive.com> References: <166A7D6B-AF20-4490-A78B-DF168E64CE70@addlive.com> Message-ID: Patch applied to master. Closing ticket. Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4214 Please log in as guest with password guest if prompted From rt at openssl.org Sat Feb 6 14:50:24 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sat, 06 Feb 2016 14:50:24 +0000 Subject: [openssl-dev] [openssl.org #2021] sni bug In-Reply-To: <4A942BF3.90905@edelweb.fr> References: <4A942BF3.90905@edelweb.fr> Message-ID: Is this still a bug? -- Rich Salz, OpenSSL dev team; rsalz at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2021 Please log in as guest with password guest if prompted From matt at openssl.org Sat Feb 6 16:01:55 2016 From: matt at openssl.org (Matt Caswell) Date: Sat, 6 Feb 2016 16:01:55 +0000 Subject: [openssl-dev] [openssl.org #3528] [PATCH] ssl: SSL_MODE_ASYNC_KEY_EX In-Reply-To: References: <56B53AF8.30001@openssl.org> Message-ID: <56B618F3.1030805@openssl.org> On 06/02/16 04:24, Fedor Indutny via RT wrote: > On Fri, Feb 5, 2016 at 7:14 PM, Matt Caswell wrote: > >> >> >> On 05/02/16 22:42, Fedor Indutny wrote: >>> Matt, >>> >>> I have looked through the APIs. Will have to experiment with them >>> somewhen later to see how well they will perform, but from theoretical >>> point of view I am a bit scared of having 2 fds (and one ucontext) for >>> every job in a pool. It seems like this could be a bit of burden in >>> event-loop based model. For example, it is not hard to imagine a >>> situation in node.js application with 10000 handshakes that are trying >>> to complete in parallel. Is there any need in creating this fds >>> unconditionally? >> >> Well of course the number of jobs in the pool is not the same as the >> number of handshakes. We create a pool of jobs that are shared between >> the handshakes as required in order to conserve resources. With regards >> to the fds, I mentioned that I was working on some tweaks to the API. It >> is in this area where there are tweaks being made. Specifically I am >> moving the creation of the fds to be a responsibility of the called code >> (i.e. most likely an engine) and not the async framework itself. >> > > I understand what the pool means ;) The imaginary situation that I was > talking about had lots of handshakes happening in parallel. To make it a > bit real: a server that decrypts premaster secrets remotely with 2000ms > latency, that receives 1000 requests per second. In such situation pool > size needs to be at least 2000 to accommodate this amount of requests. > > While 2000ms is a bit far-fetched, it is very easy to imagine that that > remote decrypting server will go absolutely down and won't respond at > all. Meaning that for some period of time (maybe 5-10 seconds) all this > load is going to attempt to take new job from the pool. While I'm sure that > SSL structures itself will take a huge stake in resources usage, having > extra fd for each of these jobs doesn't sound right to me. Right, but you can set a maximum size limit on the pool if that is something you are worried about. I would expect you would size it to the amount of jobs that your "remote decrypting server" (as you call it...I think of it as an engine) can handle, plus possibly a bit more if you are willing to have some kind of queue in the engine itself. You are of course right that there will be a limit where you attempt to throw so much load at something that it's not going to be able to take any more. Handshakes will start failing at that point. That's no different to the situation today of course. If you throw enough load at OpenSSL today, sooner or later you will hit the limits of the hardware. Matt From rt at openssl.org Sat Feb 6 16:01:55 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sat, 06 Feb 2016 16:01:55 +0000 Subject: [openssl-dev] [openssl.org #4269] Extend ECDH tests to more curves. Add more ECDH KATs. In-Reply-To: References: Message-ID: done in commit b438f0e on master. thanks! -- Rich Salz, OpenSSL dev team; rsalz at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4269 Please log in as guest with password guest if prompted From rt at openssl.org Sat Feb 6 16:02:01 2016 From: rt at openssl.org (Matt Caswell via RT) Date: Sat, 06 Feb 2016 16:02:01 +0000 Subject: [openssl-dev] [openssl.org #3528] [PATCH] ssl: SSL_MODE_ASYNC_KEY_EX In-Reply-To: <56B618F3.1030805@openssl.org> References: <56B53AF8.30001@openssl.org> <56B618F3.1030805@openssl.org> Message-ID: On 06/02/16 04:24, Fedor Indutny via RT wrote: > On Fri, Feb 5, 2016 at 7:14 PM, Matt Caswell wrote: > >> >> >> On 05/02/16 22:42, Fedor Indutny wrote: >>> Matt, >>> >>> I have looked through the APIs. Will have to experiment with them >>> somewhen later to see how well they will perform, but from theoretical >>> point of view I am a bit scared of having 2 fds (and one ucontext) for >>> every job in a pool. It seems like this could be a bit of burden in >>> event-loop based model. For example, it is not hard to imagine a >>> situation in node.js application with 10000 handshakes that are trying >>> to complete in parallel. Is there any need in creating this fds >>> unconditionally? >> >> Well of course the number of jobs in the pool is not the same as the >> number of handshakes. We create a pool of jobs that are shared between >> the handshakes as required in order to conserve resources. With regards >> to the fds, I mentioned that I was working on some tweaks to the API. It >> is in this area where there are tweaks being made. Specifically I am >> moving the creation of the fds to be a responsibility of the called code >> (i.e. most likely an engine) and not the async framework itself. >> > > I understand what the pool means ;) The imaginary situation that I was > talking about had lots of handshakes happening in parallel. To make it a > bit real: a server that decrypts premaster secrets remotely with 2000ms > latency, that receives 1000 requests per second. In such situation pool > size needs to be at least 2000 to accommodate this amount of requests. > > While 2000ms is a bit far-fetched, it is very easy to imagine that that > remote decrypting server will go absolutely down and won't respond at > all. Meaning that for some period of time (maybe 5-10 seconds) all this > load is going to attempt to take new job from the pool. While I'm sure that > SSL structures itself will take a huge stake in resources usage, having > extra fd for each of these jobs doesn't sound right to me. Right, but you can set a maximum size limit on the pool if that is something you are worried about. I would expect you would size it to the amount of jobs that your "remote decrypting server" (as you call it...I think of it as an engine) can handle, plus possibly a bit more if you are willing to have some kind of queue in the engine itself. You are of course right that there will be a limit where you attempt to throw so much load at something that it's not going to be able to take any more. Handshakes will start failing at that point. That's no different to the situation today of course. If you throw enough load at OpenSSL today, sooner or later you will hit the limits of the hardware. Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3528 Please log in as guest with password guest if prompted From rt at openssl.org Sat Feb 6 16:15:40 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sat, 06 Feb 2016 16:15:40 +0000 Subject: [openssl-dev] [openssl.org #3359] Expired certificates bug. In-Reply-To: <072d01cf712d$16825160$4386f420$@sk.ee> References: <072d01cf712d$16825160$4386f420$@sk.ee> Message-ID: It's been a couple of years :) We think this is fixed. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3359 Please log in as guest with password guest if prompted From rt at openssl.org Sat Feb 6 16:17:04 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sat, 06 Feb 2016 16:17:04 +0000 Subject: [openssl-dev] [openssl.org #3344] PATCH: don't crash or fail in ASN1_print from t_pkey.c In-Reply-To: References: Message-ID: Can't reproduce it. Maybe the machine that had the problem got infected by aliens or something :) Please open a new ticket if needed. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3344 Please log in as guest with password guest if prompted From rt at openssl.org Sat Feb 6 19:07:59 2016 From: rt at openssl.org (J Mohan Rao Arisankala via RT) Date: Sat, 06 Feb 2016 19:07:59 +0000 Subject: [openssl-dev] [openssl.org #4293] cmds help cleanup In-Reply-To: References: Message-ID: Hi, In commands help, option valtype, 0 is to be treated same as '-', but in apps/opt.c: valtype2param(), case 0 was missing. Because of this, *openssl asn1parse -help* was printing options without args wrongly. Few cleanups are also done in asn1parse/ca/ciphers. I have created the following pull request with these changes. Please have a look https://github.com/openssl/openssl/pull/635 Thanks, Mohan -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4293 Please log in as guest with password guest if prompted From rt at openssl.org Sat Feb 6 19:09:11 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sat, 06 Feb 2016 19:09:11 +0000 Subject: [openssl-dev] [openssl.org #4293] cmds help cleanup In-Reply-To: References: Message-ID: fixed in commit 6755ff1 The github PR was done before the RT moderator :) -- Rich Salz, OpenSSL dev team; rsalz at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4293 Please log in as guest with password guest if prompted From rt at openssl.org Sat Feb 6 21:24:26 2016 From: rt at openssl.org (Peter Sylvester via RT) Date: Sat, 06 Feb 2016 21:24:26 +0000 Subject: [openssl-dev] [openssl.org #2021] sni bug In-Reply-To: <56B66223.90209@on-x.com> References: <4A942BF3.90905@edelweb.fr> <56B66223.90209@on-x.com> Message-ID: On 06/02/2016 15:50, Rich Salz via RT wrote: > Is this still a bug? > -- > Rich Salz, OpenSSL dev team; rsalz at openssl.org > > I don't know, there have been many changes to the extension treatment. I have not followed the stuff since 5 years. The extension handling is not what I had in the original design and seems to be broken. There was no split into two functions two functions that communicate through the session.; Some callbacks are done in the check loop (as far as I remember) . Unfortunately this split occured almost in parallel to our contribution in 2006 when some EC stuff was added. A correct logic is one single function(the code of check and parse combined) that collects the values of extensions and then treat them calls callbacks in a defined order. Actually it seems that you could influence the server behavoiur if you change the order of extensions in the clienthello. sni first or last for example. That makes server application code difficult. best -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2021 Please log in as guest with password guest if prompted From openssl at roumenpetrov.info Sun Feb 7 10:14:11 2016 From: openssl at roumenpetrov.info (Roumen Petrov) Date: Sun, 07 Feb 2016 12:14:11 +0200 Subject: [openssl-dev] BIO_new_connect after refactoring Message-ID: <56B718F3.9070500@roumenpetrov.info> Hello, With master branch my ssh ocsp tests start to fail again. The program code call BIO_new_connect("127.0.01") and then parsing of 'name' crash. Please find attached proposed patch. Roumen -------------- next part -------------- A non-text attachment was scrubbed... Name: 0009-avoid-crash-if-hostserv-is-with-host-part-only.patch Type: text/x-diff Size: 727 bytes Desc: not available URL: From rt at openssl.org Sun Feb 7 14:35:01 2016 From: rt at openssl.org (J Mohan Rao Arisankala via RT) Date: Sun, 07 Feb 2016 14:35:01 +0000 Subject: [openssl-dev] [openssl.org #4295] help cleanup in dgst, pkeyutl cmds In-Reply-To: References: Message-ID: Hi, - In dgst, pkeyutl cmds, some help text was missing for some options and in man pages. - fixed a minor typo in openssl.pod, that fixes make install. - digest-commands was showing ?sha?, which is not a supported digest anymore. I have created the below pull request with required changes, please have a look. https://github.com/openssl/openssl/pull/637 Thanks, Mohan -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4295 Please log in as guest with password guest if prompted From rt at openssl.org Mon Feb 8 10:10:48 2016 From: rt at openssl.org (J Mohan Rao Arisankala via RT) Date: Mon, 08 Feb 2016 10:10:48 +0000 Subject: [openssl-dev] [openssl.org #4296] Fix possible crash in BIO_parse_hostserv() In-Reply-To: References: Message-ID: Hi, If BIO_parse_hostserv() is invoked with only (no port), it was running into crash when trying to check for any further colons existed in the parsed , as pointer to is NULL in this case. To reproduce the issue: $ openssl s_client -connect seg faults I have created a pull request with the required check, please check. https://github.com/openssl/openssl/pull/639 Thanks, Mohan -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4296 Please log in as guest with password guest if prompted From rainer.jung at kippdata.de Mon Feb 8 12:11:11 2016 From: rainer.jung at kippdata.de (Rainer Jung) Date: Mon, 8 Feb 2016 13:11:11 +0100 Subject: [openssl-dev] How to do reneg with client certs in 1.1.0 API Message-ID: <56B885DF.4090606@kippdata.de> I'm adding support for OpenSSL 1.1.0 to the Apache web server. I struggle to migrate the renegotiation code in the case wehere we want the client to send a client cert. The current code works like explained in http://www.linuxjournal.com/node/5487/print After using SSL_set_verify() it calls SSL_renegotiate(ssl); SSL_do_handshake(ssl); SSL_set_state(ssl, SSL_ST_ACCEPT); SSL_do_handshake(ssl); for reasons given in the article. The new 1.1.0 API no longer allows to set the state using SSL_set_state(). The old article states, that calling SSL_set_accept_state() is not the right thing to do. Looking at s_server.c doesn't give a hint what to do instead, because it looks like it reads the client certs just raw from the socket. Any hint what would replace the above sequence or at least the SSL_set_state(ssl, SSL_ST_ACCEPT)? Thanks a bunch and regards, Rainer From rt at openssl.org Mon Feb 8 12:32:20 2016 From: rt at openssl.org (Hubert Kario via RT) Date: Mon, 08 Feb 2016 12:32:20 +0000 Subject: [openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites In-Reply-To: <2902654.TQ8Vo2iRU5@pintsize.usersys.redhat.com> References: <20160204171042.GA25291@roeckx.be> <2902654.TQ8Vo2iRU5@pintsize.usersys.redhat.com> Message-ID: On Thursday 04 February 2016 17:10:45 Kurt Roeckx via RT wrote: > On Thu, Feb 04, 2016 at 10:10:06AM +0000, Moonchild via RT wrote: > > Really? > > > > That's all we get, a one-liner, no explanation, no rationale, > > response? It's not even "brand new" functionality, Camellia as a > > raw cipher is already in there, the only difference is wrapping it > > into GCM-based suites. Patches are available, too. > > I think the concerns are: > - Nobody else seems to be using Camellia over 40% of Alexa top 1 million TLS enabled servers enable Camellia GnuTLS has implementation of Camellia-GCM for quite some time already > - We don't have a constant time implementation of it I don't see it mentioned anywhere in documentation, especially not in ciphers(1) man page. So, is it not so severe, or should the Camellia be removed from DEFAULT? > - For processors that have AESNI, it's slower than AES Irrelevant, nobody proposes to replace AES with Camellia > - Adding more ciphers to the default list will just increase the > client hello and not change anything. > > That being said, I don't think there should be a problem adding > the support. I'm just not sure about enabling it by default. I don't think anyone argues that it needs to be added to DEFAULT. -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4075 Please log in as guest with password guest if prompted -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From matt at openssl.org Mon Feb 8 12:34:36 2016 From: matt at openssl.org (Matt Caswell) Date: Mon, 8 Feb 2016 12:34:36 +0000 Subject: [openssl-dev] How to do reneg with client certs in 1.1.0 API In-Reply-To: <56B885DF.4090606@kippdata.de> References: <56B885DF.4090606@kippdata.de> Message-ID: <56B88B5C.8010303@openssl.org> On 08/02/16 12:11, Rainer Jung wrote: > I'm adding support for OpenSSL 1.1.0 to the Apache web server. > > I struggle to migrate the renegotiation code in the case wehere we want > the client to send a client cert. The current code works like explained in > > http://www.linuxjournal.com/node/5487/print > > After using SSL_set_verify() it calls > > SSL_renegotiate(ssl); > SSL_do_handshake(ssl); > SSL_set_state(ssl, SSL_ST_ACCEPT); > SSL_do_handshake(ssl); > > for reasons given in the article. > > The new 1.1.0 API no longer allows to set the state using > SSL_set_state(). The old article states, that calling > SSL_set_accept_state() is not the right thing to do. Looking at > s_server.c doesn't give a hint what to do instead, because it looks like > it reads the client certs just raw from the socket. > > Any hint what would replace the above sequence or at least the > SSL_set_state(ssl, SSL_ST_ACCEPT)? > > Thanks a bunch and regards, Renegotiation isn't entirely within the control of the server. A server can request that a renegotiation takes place. It is up to the client whether it honours that request immediately; or perhaps its finishes off sending some application data before it gets around to honouring it; or perhaps it doesn't honour it at all. > SSL_renegotiate(ssl); > SSL_do_handshake(ssl); This sequence makes the server send the HelloVerifyRequest. It is then back in a state where it can continue to receive application data from the client. At some later point the client may or may not initiate a reneg. > SSL_set_state(ssl, SSL_ST_ACCEPT); > SSL_do_handshake(ssl); This is really not a good idea, and I suspect is a hack that was originally copied from s_server :-). Doing this will make the connection fail if the client sends application data next (which it is allowed to do). We don't know what we're going to get next from the client it could be more application data. It could be an immediate start of a new handshake. The correct thing for the server to do is to attempt to read application data. If we happen to get a handshake instead then it will be automatically handled. Matt From matt at openssl.org Mon Feb 8 12:36:39 2016 From: matt at openssl.org (Matt Caswell) Date: Mon, 8 Feb 2016 12:36:39 +0000 Subject: [openssl-dev] How to do reneg with client certs in 1.1.0 API In-Reply-To: <56B88B5C.8010303@openssl.org> References: <56B885DF.4090606@kippdata.de> <56B88B5C.8010303@openssl.org> Message-ID: <56B88BD7.9030001@openssl.org> On 08/02/16 12:34, Matt Caswell wrote: > > > On 08/02/16 12:11, Rainer Jung wrote: >> I'm adding support for OpenSSL 1.1.0 to the Apache web server. >> >> I struggle to migrate the renegotiation code in the case wehere we want >> the client to send a client cert. The current code works like explained in >> >> http://www.linuxjournal.com/node/5487/print >> >> After using SSL_set_verify() it calls >> >> SSL_renegotiate(ssl); >> SSL_do_handshake(ssl); >> SSL_set_state(ssl, SSL_ST_ACCEPT); >> SSL_do_handshake(ssl); >> >> for reasons given in the article. >> >> The new 1.1.0 API no longer allows to set the state using >> SSL_set_state(). The old article states, that calling >> SSL_set_accept_state() is not the right thing to do. Looking at >> s_server.c doesn't give a hint what to do instead, because it looks like >> it reads the client certs just raw from the socket. >> >> Any hint what would replace the above sequence or at least the >> SSL_set_state(ssl, SSL_ST_ACCEPT)? >> >> Thanks a bunch and regards, > > Renegotiation isn't entirely within the control of the server. A server > can request that a renegotiation takes place. It is up to the client > whether it honours that request immediately; or perhaps its finishes off > sending some application data before it gets around to honouring it; or > perhaps it doesn't honour it at all. > >> SSL_renegotiate(ssl); >> SSL_do_handshake(ssl); > > This sequence makes the server send the HelloVerifyRequest. It is then I of course meant HelloRequest (I was looking at the DTLS code earlier which sends a HelloVerifyRequest!!!) Matt From rt at openssl.org Mon Feb 8 13:01:52 2016 From: rt at openssl.org (Cristian Stoica via RT) Date: Mon, 08 Feb 2016 13:01:52 +0000 Subject: [openssl-dev] [openssl.org #4297] [PATCH] remove double initialization of cryptodev engine In-Reply-To: <1454935207-27924-1-git-send-email-cristian.stoica@nxp.com> References: <1454935207-27924-1-git-send-email-cristian.stoica@nxp.com> Message-ID: From: Cristian Stoica cryptodev engine is initialized together with the other engines in ENGINE_load_builtin_engines. The initialization done through OpenSSL_add_all_algorithms is redundant. Signed-off-by: Cristian Stoica --- crypto/engine/eng_all.c | 12 ------------ crypto/engine/engine.h | 4 ---- crypto/evp/c_all.c | 5 ----- util/libeay.num | 2 +- 4 files changed, 1 insertion(+), 22 deletions(-) diff --git a/crypto/engine/eng_all.c b/crypto/engine/eng_all.c index 48ad0d2..a198c5f 100644 --- a/crypto/engine/eng_all.c +++ b/crypto/engine/eng_all.c @@ -122,15 +122,3 @@ void ENGINE_load_builtin_engines(void) #endif ENGINE_register_all_complete(); } - -#if defined(__OpenBSD__) || defined(__FreeBSD__) || defined(HAVE_CRYPTODEV) -void ENGINE_setup_bsd_cryptodev(void) -{ - static int bsd_cryptodev_default_loaded = 0; - if (!bsd_cryptodev_default_loaded) { - ENGINE_load_cryptodev(); - ENGINE_register_all_complete(); - } - bsd_cryptodev_default_loaded = 1; -} -#endif diff --git a/crypto/engine/engine.h b/crypto/engine/engine.h index bd7b591..020d912 100644 --- a/crypto/engine/engine.h +++ b/crypto/engine/engine.h @@ -857,10 +857,6 @@ typedef int (*dynamic_bind_engine) (ENGINE *e, const char *id, */ void *ENGINE_get_static_state(void); -# if defined(__OpenBSD__) || defined(__FreeBSD__) || defined(HAVE_CRYPTODEV) -void ENGINE_setup_bsd_cryptodev(void); -# endif - /* BEGIN ERROR CODES */ /* * The following lines are auto generated by the script mkerr.pl. Any changes diff --git a/crypto/evp/c_all.c b/crypto/evp/c_all.c index a3ed00d..719e34d 100644 --- a/crypto/evp/c_all.c +++ b/crypto/evp/c_all.c @@ -82,9 +82,4 @@ void OPENSSL_add_all_algorithms_noconf(void) OPENSSL_cpuid_setup(); OpenSSL_add_all_ciphers(); OpenSSL_add_all_digests(); -#ifndef OPENSSL_NO_ENGINE -# if defined(__OpenBSD__) || defined(__FreeBSD__) || defined(HAVE_CRYPTODEV) - ENGINE_setup_bsd_cryptodev(); -# endif -#endif } diff --git a/util/libeay.num b/util/libeay.num index 7f7487d..f4a72ec 100755 --- a/util/libeay.num +++ b/util/libeay.num @@ -2803,7 +2803,7 @@ BIO_indent 3242 EXIST::FUNCTION: BUF_strlcpy 3243 EXIST::FUNCTION: OpenSSLDie 3244 EXIST::FUNCTION: OPENSSL_cleanse 3245 EXIST::FUNCTION: -ENGINE_setup_bsd_cryptodev 3246 EXIST:__FreeBSD__:FUNCTION:ENGINE +ENGINE_setup_bsd_cryptodev 3246 NOEXIST::FUNCTION: ERR_release_err_state_table 3247 EXIST::FUNCTION:LHASH EVP_aes_128_cfb8 3248 EXIST::FUNCTION:AES FIPS_corrupt_rsa 3249 NOEXIST::FUNCTION: -- 2.7.0 -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4297 Please log in as guest with password guest if prompted From tmraz at redhat.com Mon Feb 8 13:45:57 2016 From: tmraz at redhat.com (Tomas Mraz) Date: Mon, 08 Feb 2016 14:45:57 +0100 Subject: [openssl-dev] How to do reneg with client certs in 1.1.0 API In-Reply-To: <56B88B5C.8010303@openssl.org> References: <56B885DF.4090606@kippdata.de> <56B88B5C.8010303@openssl.org> Message-ID: <1454939157.21154.6.camel@redhat.com> On Po, 2016-02-08 at 12:34 +0000, Matt Caswell wrote: > > On 08/02/16 12:11, Rainer Jung wrote: > >? > Renegotiation isn't entirely within the control of the server. A > server > can request that a renegotiation takes place. It is up to the client > whether it honours that request immediately; or perhaps its finishes > off > sending some application data before it gets around to honouring it; > or > perhaps it doesn't honour it at all. > > > ? SSL_renegotiate(ssl); > > ? SSL_do_handshake(ssl); > > This sequence makes the server send the HelloVerifyRequest. It is > then > back in a state where it can continue to receive application data > from > the client. At some later point the client may or may not initiate a > reneg. > > > ? SSL_set_state(ssl, SSL_ST_ACCEPT); > > ? SSL_do_handshake(ssl); > > This is really not a good idea, and I suspect is a hack that was > originally copied from s_server :-). Doing this will make the > connection > fail if the client sends application data next (which it is allowed > to do). > > We don't know what we're going to get next from the client it could > be > more application data. It could be an immediate start of a new > handshake. The correct thing for the server to do is to attempt to > read > application data. If we happen to get a handshake instead then it > will > be automatically handled. What if the server wants to discard all the application data that was sent before the renegotiation completed? Or how the server can recognize which part of data was received before renegotiation completed and which after it? -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb (You'll never know whether the road is wrong though.) From cata.vasile at nxp.com Mon Feb 8 13:41:10 2016 From: cata.vasile at nxp.com (Catalin Vasile) Date: Mon, 8 Feb 2016 13:41:10 +0000 Subject: [openssl-dev] version script Message-ID: I'm trying to compile a custom OpenSSL library to work with nginx. nginx requires that the SSL library have version data included in the .so files, so I'm using?this patch[1] for this. The problem is that if I set the library versiont to 1.0.1 into that script, when I start nginx or trigger ldd on nginx I get: /usr/lib/libssl.so.1.0.0: version `OPENSSL_1.0.0' not found If I set that version to 1.0.0 I get: /usr/lib/libssl.so.1.0.0: version `OPENSSL_1.0.1' not found Can someone help me out to understand what is going on? Cata [1] http://stackoverflow.com/a/22634441/1310345 From matt at openssl.org Mon Feb 8 14:26:07 2016 From: matt at openssl.org (Matt Caswell) Date: Mon, 8 Feb 2016 14:26:07 +0000 Subject: [openssl-dev] How to do reneg with client certs in 1.1.0 API In-Reply-To: <1454939157.21154.6.camel@redhat.com> References: <56B885DF.4090606@kippdata.de> <56B88B5C.8010303@openssl.org> <1454939157.21154.6.camel@redhat.com> Message-ID: <56B8A57F.2070509@openssl.org> On 08/02/16 13:45, Tomas Mraz wrote: > On Po, 2016-02-08 at 12:34 +0000, Matt Caswell wrote: >> >> On 08/02/16 12:11, Rainer Jung wrote: >>> >> Renegotiation isn't entirely within the control of the server. A >> server >> can request that a renegotiation takes place. It is up to the client >> whether it honours that request immediately; or perhaps its finishes >> off >> sending some application data before it gets around to honouring it; >> or >> perhaps it doesn't honour it at all. >> >>> SSL_renegotiate(ssl); >>> SSL_do_handshake(ssl); >> >> This sequence makes the server send the HelloVerifyRequest. It is >> then >> back in a state where it can continue to receive application data >> from >> the client. At some later point the client may or may not initiate a >> reneg. >> >>> SSL_set_state(ssl, SSL_ST_ACCEPT); >>> SSL_do_handshake(ssl); >> >> This is really not a good idea, and I suspect is a hack that was >> originally copied from s_server :-). Doing this will make the >> connection >> fail if the client sends application data next (which it is allowed >> to do). >> >> We don't know what we're going to get next from the client it could >> be >> more application data. It could be an immediate start of a new >> handshake. The correct thing for the server to do is to attempt to >> read >> application data. If we happen to get a handshake instead then it >> will >> be automatically handled. > > What if the server wants to discard all the application data that was > sent before the renegotiation completed? Or how the server can > recognize which part of data was received before renegotiation > completed and which after it? > You never get app data from two different epochs returned in a single API call. In certain situations you can get a handshake finish occur followed by a read of application data all within a single API call. It's also valid that the attempt to read application data handled the handshake but doesn't actually return any app data because the client didn't send any yet (it *just* did the reneg). So if you want to discard all application data until the client has initiated a reneg and supplied a certificate then you'll want to do something like: SSL_renegotiate(ssl); SSL_do_handshake(ssl); do { read_some_app_data(); if(no_client_cert_yet()) { discard_app_data(); } } while(no_client_cert_yet()); Matt From matt at openssl.org Mon Feb 8 14:36:37 2016 From: matt at openssl.org (Matt Caswell) Date: Mon, 8 Feb 2016 14:36:37 +0000 Subject: [openssl-dev] version script In-Reply-To: References: Message-ID: <56B8A7F5.8050705@openssl.org> On 08/02/16 13:41, Catalin Vasile wrote: > I'm trying to compile a custom OpenSSL library to work with nginx. > nginx requires that the SSL library have version data included in the .so files, so I'm using this patch[1] for this. > The problem is that if I set the library versiont to 1.0.1 into that script, when I start nginx or trigger ldd on nginx I get: > /usr/lib/libssl.so.1.0.0: version `OPENSSL_1.0.0' not found > If I set that version to 1.0.0 I get: > /usr/lib/libssl.so.1.0.0: version `OPENSSL_1.0.1' not found > Can someone help me out to understand what is going on? Each symbol will have a different version depending on what version of OpenSSL it was first introduced in. If a symbol is in both 1.0.0 and 1.0.1 it will have a version of OPENSSL_1.0.0. If a symbol is only in 1.0.1 it will have a version of OPENSSL_1.0.1. You can see the symbol versions for the system supplied version of libcrypto/libssl like so: readelf -Ws /path/to/libcrypto.so.1.0.0 | grep OPENSSL_1.0 Compiling up your own version of OpenSSL and manually adding your own symbols is possible but fraught with problems. It's best to avoid it if at all possible. In spite of what you say above nginx does not require symbol versions to be present...*only* the system supplied version does. If you obtain a version of nginx from somewhere else then it won't have this issue. Also, IIRC, the warnings you get if you don't have symbol versions are just that - warnings. You should be able to ignore them and continue anyway. Matt From openssl-users at dukhovni.org Mon Feb 8 14:36:40 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 8 Feb 2016 09:36:40 -0500 Subject: [openssl-dev] How to do reneg with client certs in 1.1.0 API In-Reply-To: <56B8A57F.2070509@openssl.org> References: <56B885DF.4090606@kippdata.de> <56B88B5C.8010303@openssl.org> <1454939157.21154.6.camel@redhat.com> <56B8A57F.2070509@openssl.org> Message-ID: <50160CB1-E206-462B-A59F-E1990157ABC5@dukhovni.org> > On Feb 8, 2016, at 9:26 AM, Matt Caswell wrote: > > SSL_renegotiate(ssl); > SSL_do_handshake(ssl); > do { > read_some_app_data(); > if(no_client_cert_yet()) { > discard_app_data(); > } > } while(no_client_cert_yet()); At what point in the handshake would a query for client certificates show their presence? Is it always strictly after the new "finished" message? An additional check for the completion of the handshake may be appropriate. -- -- Viktor. From levitte at openssl.org Mon Feb 8 14:48:10 2016 From: levitte at openssl.org (Richard Levitte) Date: Mon, 08 Feb 2016 15:48:10 +0100 (CET) Subject: [openssl-dev] BIO_new_connect after refactoring In-Reply-To: <56B718F3.9070500@roumenpetrov.info> References: <56B718F3.9070500@roumenpetrov.info> Message-ID: <20160208.154810.1850336826127140760.levitte@openssl.org> That patch just got merged into master, commit 80926502986a97eed53afe1d85fc074e40829547 Cheers, Richard In message <56B718F3.9070500 at roumenpetrov.info> on Sun, 07 Feb 2016 12:14:11 +0200, Roumen Petrov said: openssl> Hello, openssl> openssl> With master branch my ssh ocsp tests start to fail again. openssl> The program code call BIO_new_connect("127.0.01") and then parsing of openssl> 'name' crash. openssl> Please find attached proposed patch. openssl> openssl> Roumen openssl> From rsalz at akamai.com Mon Feb 8 14:48:35 2016 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 8 Feb 2016 14:48:35 +0000 Subject: [openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites In-Reply-To: References: <20160204171042.GA25291@roeckx.be> <2902654.TQ8Vo2iRU5@pintsize.usersys.redhat.com> Message-ID: <3b7219c7ecb7456b88a0c530a18ab4bd@usma1ex-dag1mb1.msg.corp.akamai.com> > over 40% of Alexa top 1 million TLS enabled servers enable Camellia That's different than actual use, as you know. > I don't see it mentioned anywhere in documentation, especially not in > ciphers(1) man page. So, is it not so severe, or should the Camellia be > removed from DEFAULT? It probably will be. I think the bottom line is that nobody on the team is enthusiastic, or even willing, to put into the work to add and support it. And nobody is wiling to put it into the codebase these days without an internal commitment to support it. From rt at openssl.org Mon Feb 8 14:48:45 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Mon, 08 Feb 2016 14:48:45 +0000 Subject: [openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites In-Reply-To: <3b7219c7ecb7456b88a0c530a18ab4bd@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20160204171042.GA25291@roeckx.be> <2902654.TQ8Vo2iRU5@pintsize.usersys.redhat.com> <3b7219c7ecb7456b88a0c530a18ab4bd@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: > over 40% of Alexa top 1 million TLS enabled servers enable Camellia That's different than actual use, as you know. > I don't see it mentioned anywhere in documentation, especially not in > ciphers(1) man page. So, is it not so severe, or should the Camellia be > removed from DEFAULT? It probably will be. I think the bottom line is that nobody on the team is enthusiastic, or even willing, to put into the work to add and support it. And nobody is wiling to put it into the codebase these days without an internal commitment to support it. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4075 Please log in as guest with password guest if prompted From matt at openssl.org Mon Feb 8 14:49:07 2016 From: matt at openssl.org (Matt Caswell) Date: Mon, 8 Feb 2016 14:49:07 +0000 Subject: [openssl-dev] How to do reneg with client certs in 1.1.0 API In-Reply-To: <50160CB1-E206-462B-A59F-E1990157ABC5@dukhovni.org> References: <56B885DF.4090606@kippdata.de> <56B88B5C.8010303@openssl.org> <1454939157.21154.6.camel@redhat.com> <56B8A57F.2070509@openssl.org> <50160CB1-E206-462B-A59F-E1990157ABC5@dukhovni.org> Message-ID: <56B8AAE3.8070304@openssl.org> On 08/02/16 14:36, Viktor Dukhovni wrote: > >> On Feb 8, 2016, at 9:26 AM, Matt Caswell wrote: >> >> SSL_renegotiate(ssl); >> SSL_do_handshake(ssl); >> do { >> read_some_app_data(); >> if(no_client_cert_yet()) { >> discard_app_data(); >> } >> } while(no_client_cert_yet()); > > At what point in the handshake would a query for client > certificates show their presence? Is it always strictly > after the new "finished" message? An additional check for > the completion of the handshake may be appropriate. > Actually, yes that is a good point. There could be some subtle security issues there. You probably need to additionally check that you are not halfway through a handshake: SSL_renegotiate(ssl); SSL_do_handshake(ssl); do { read_some_app_data(); if(no_client_cert_yet() || SSL_in_init(ssl)) { discard_app_data(); } } while(no_client_cert_yet() || SSL_in_init(ssl)); Matt From tshort at akamai.com Mon Feb 8 15:06:41 2016 From: tshort at akamai.com (Short, Todd) Date: Mon, 8 Feb 2016 15:06:41 +0000 Subject: [openssl-dev] Duplicate APIs? Message-ID: <07821AB6-987F-480E-ADBF-9313EADA7FBD@akamai.com> Hi, I know OpenSSL is making 1.1 not ABI compliant to 1.0, so, maybe now is a good time to clean this up? I noticed that: * SSL_cache_hit(SSL*), and * SSL_session_reused(SSL*ssl) --> SSL_ctrl(ssl,SSL_CTRL_GET_SESSION_REUSED,0,NULL) are practically the same thing; both return s->hit. Are both really needed? -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Mon Feb 8 15:17:37 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 8 Feb 2016 10:17:37 -0500 Subject: [openssl-dev] Duplicate APIs? In-Reply-To: <07821AB6-987F-480E-ADBF-9313EADA7FBD@akamai.com> References: <07821AB6-987F-480E-ADBF-9313EADA7FBD@akamai.com> Message-ID: <6274621B-FF90-4A73-92E4-9455CE31DC7C@dukhovni.org> > On Feb 8, 2016, at 10:06 AM, Short, Todd wrote: > > I noticed that: > > * SSL_cache_hit(SSL*), and > * SSL_session_reused(SSL*ssl) --> SSL_ctrl(ssl,SSL_CTRL_GET_SESSION_REUSED,0,NULL) > > are practically the same thing; both return s->hit. > > Are both really needed? I started a thread on this very topic on the team list yesterday. What'll likely happen is that SSL_session_reused() will be the new name of the SSL_cache_hit() function, and SSL_cache_hit will become a macro referencing that function: int SSL_session_reused(const SSL *ssl); #if OPENSSL_API_COMPAT < 0x10100000L # define SSL_cache_hit(ssl) SSL_session_reused(ssl) #endif The control variant will be removed. -- Viktor. From openssl-users at dukhovni.org Mon Feb 8 15:46:35 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 8 Feb 2016 10:46:35 -0500 Subject: [openssl-dev] How to do reneg with client certs in 1.1.0 API In-Reply-To: <56B8AAE3.8070304@openssl.org> References: <56B885DF.4090606@kippdata.de> <56B88B5C.8010303@openssl.org> <1454939157.21154.6.camel@redhat.com> <56B8A57F.2070509@openssl.org> <50160CB1-E206-462B-A59F-E1990157ABC5@dukhovni.org> <56B8AAE3.8070304@openssl.org> Message-ID: > On Feb 8, 2016, at 9:49 AM, Matt Caswell wrote: > > Actually, yes that is a good point. There could be some subtle security > issues there. You probably need to additionally check that you are not > halfway through a handshake: > > SSL_renegotiate(ssl); > SSL_do_handshake(ssl); > do { > read_some_app_data(); > if(no_client_cert_yet() || SSL_in_init(ssl)) { > discard_app_data(); > } > } while(no_client_cert_yet() || SSL_in_init(ssl)); Indeed, but discarding the data may not be an option, that could lead to dead-lock, rather one might need to process it, in the proper context (pre-authentication). The proper handling of client data between the renegotiation request and its completion depends on the application protocol. The important thing is that OpenSSL should (does) not delay the visibility of data that was read before renegotiation completes, until after such completion. -- -- Viktor. From matt at openssl.org Mon Feb 8 15:52:20 2016 From: matt at openssl.org (Matt Caswell) Date: Mon, 8 Feb 2016 15:52:20 +0000 Subject: [openssl-dev] How to do reneg with client certs in 1.1.0 API In-Reply-To: References: <56B885DF.4090606@kippdata.de> <56B88B5C.8010303@openssl.org> <1454939157.21154.6.camel@redhat.com> <56B8A57F.2070509@openssl.org> <50160CB1-E206-462B-A59F-E1990157ABC5@dukhovni.org> <56B8AAE3.8070304@openssl.org> Message-ID: <56B8B9B4.8070602@openssl.org> On 08/02/16 15:46, Viktor Dukhovni wrote: > >> On Feb 8, 2016, at 9:49 AM, Matt Caswell wrote: >> >> Actually, yes that is a good point. There could be some subtle security >> issues there. You probably need to additionally check that you are not >> halfway through a handshake: >> >> SSL_renegotiate(ssl); >> SSL_do_handshake(ssl); >> do { >> read_some_app_data(); >> if(no_client_cert_yet() || SSL_in_init(ssl)) { >> discard_app_data(); >> } >> } while(no_client_cert_yet() || SSL_in_init(ssl)); > > Indeed, but discarding the data may not be an option, Sure. I was answering the specific question posed by Tomas: "What if the server wants to discard all the application data that was sent before the renegotiation completed?" Matt From GEORGE.E.SULLIVAN at leidos.com Mon Feb 8 16:07:37 2016 From: GEORGE.E.SULLIVAN at leidos.com (Sullivan, George E.) Date: Mon, 8 Feb 2016 16:07:37 +0000 Subject: [openssl-dev] Version 1.0.2 on Red Hat/Centos 5.x Message-ID: Due to IAVA 2015-A-0034 we are going to download the code and sneaker net it to our private domain. The process to sneaker net it can be rather long due to various approval steps required. Has anyone compiled this on 5.x since we would also want to grab any prereqs during this process to save time and to insure the compile goes without a hitch. Kind regards to all. George Sullivan Systems Administration Annapolis Junction, Md 240-554-6921 [cid:image002.jpg at 01CE554A.D40C4D80] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 1382 bytes Desc: image001.jpg URL: From eanupkumar at gmail.com Mon Feb 8 16:13:38 2016 From: eanupkumar at gmail.com (Anup Kumar) Date: Mon, 8 Feb 2016 21:43:38 +0530 Subject: [openssl-dev] Version 1.0.2 on Red Hat/Centos 5.x In-Reply-To: References: Message-ID: There is no issue in compilation on centos 5. On 8 Feb 2016 21:37, "Sullivan, George E." wrote: > Due to IAVA 2015-A-0034 we are going to download the code and sneaker net > it to our private domain. The process to sneaker net it can be rather long > due to various approval steps required. Has anyone compiled this on 5.x > since we would also want to grab any prereqs during this process to save > time and to insure the compile goes without a hitch. > > > > Kind regards to all. > > > > > > George Sullivan > > Systems Administration > > Annapolis Junction, Md > > 240-554-6921 > > [image: cid:image002.jpg at 01CE554A.D40C4D80] > > > > > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 1382 bytes Desc: not available URL: From doctor at doctor.nl2k.ab.ca Mon Feb 8 16:19:46 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Mon, 8 Feb 2016 09:19:46 -0700 Subject: [openssl-dev] test_sslcertstatus.t Message-ID: <20160208161946.GA24728@doctor.nl2k.ab.ca> in the OPENSSL-SNAP-20160203 this test goes no problem Since OPENSSL-SNAP-20160204 this test hangs. The script has not changed, What else could be the issue? -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Broadcasting the truth for 25 years From rainer.jung at kippdata.de Mon Feb 8 16:45:45 2016 From: rainer.jung at kippdata.de (Rainer Jung) Date: Mon, 8 Feb 2016 17:45:45 +0100 Subject: [openssl-dev] How to do reneg with client certs in 1.1.0 API In-Reply-To: <56B88B5C.8010303@openssl.org> References: <56B885DF.4090606@kippdata.de> <56B88B5C.8010303@openssl.org> Message-ID: <56B8C639.1080602@kippdata.de> Am 08.02.2016 um 13:34 schrieb Matt Caswell: > On 08/02/16 12:11, Rainer Jung wrote: >> I'm adding support for OpenSSL 1.1.0 to the Apache web server. >> >> I struggle to migrate the renegotiation code in the case wehere we want >> the client to send a client cert. The current code works like explained in >> >> http://www.linuxjournal.com/node/5487/print >> >> After using SSL_set_verify() it calls >> >> SSL_renegotiate(ssl); >> SSL_do_handshake(ssl); >> SSL_set_state(ssl, SSL_ST_ACCEPT); >> SSL_do_handshake(ssl); >> >> for reasons given in the article. >> >> The new 1.1.0 API no longer allows to set the state using >> SSL_set_state(). The old article states, that calling >> SSL_set_accept_state() is not the right thing to do. Looking at >> s_server.c doesn't give a hint what to do instead, because it looks like >> it reads the client certs just raw from the socket. >> >> Any hint what would replace the above sequence or at least the >> SSL_set_state(ssl, SSL_ST_ACCEPT)? >> >> Thanks a bunch and regards, > > Renegotiation isn't entirely within the control of the server. A server > can request that a renegotiation takes place. It is up to the client > whether it honours that request immediately; or perhaps its finishes off > sending some application data before it gets around to honouring it; or > perhaps it doesn't honour it at all. > >> SSL_renegotiate(ssl); >> SSL_do_handshake(ssl); > > This sequence makes the server send the HelloVerifyRequest. It is then > back in a state where it can continue to receive application data from > the client. At some later point the client may or may not initiate a reneg. > >> SSL_set_state(ssl, SSL_ST_ACCEPT); >> SSL_do_handshake(ssl); > > This is really not a good idea, and I suspect is a hack that was > originally copied from s_server :-). Doing this will make the connection > fail if the client sends application data next (which it is allowed to do). > > We don't know what we're going to get next from the client it could be > more application data. It could be an immediate start of a new > handshake. The correct thing for the server to do is to attempt to read > application data. If we happen to get a handshake instead then it will > be automatically handled. OK, tried it and it partially works. More precisely: when the cipher is AES128-SHA it works, bur for ECDHE-RSA-AES128-SHA256 I run into an error in tls_construct_server_key_exchange() (file statem/statem_srvr.c). The following conditions triggers the jump to err: 1773 if (type & (SSL_kECDHE | SSL_kECDHEPSK)) { 1774 int nid; 1775 1776 if (s->s3->tmp.pkey != NULL) { 1777 SSLerr(SSL_F_TLS_CONSTRUCT_SERVER_KEY_EXCHANGE, 1778 ERR_R_INTERNAL_ERROR); 1779 goto err; 1780 } By comparing the communication for the two ciphers I see the following flow: write 69/69 bytes SSLv3/TLS write hello request - try to read app data -> I/O error, 5 bytes expected to read read 5/5 bytes read 576/576 Handshake: start before SSL initialization before SSL initialization SSLv3/TLS read client hello write 149/149 SSLv3/TLS write server hello write 2021/2021 SSLv3/TLS write certificate And here for the ECDHE case the error triggered by the above check. In the AES case we proceed write 1173/1173 SSLv3/TLS write certificate request write 69/69 bytes write 3412/3412 bytes SSLv3/TLS write server done error in SSLv3/TLS write server done read 5/5 bytes read 1952/1952 SSLv3/TLS write server done Successful client certificate verification Any idea how to clear s->s3->tmp.pkey so that the check doesn't trigger? I see SSL_clear() but from its description I doubt that is should be used here. Regards, Rainer From rt at openssl.org Mon Feb 8 17:25:18 2016 From: rt at openssl.org (Armour Comms via RT) Date: Mon, 08 Feb 2016 17:25:18 +0000 Subject: [openssl-dev] [openssl.org #4298] [Bug] Random number generation failing with FIPS and Android < 5.0 In-Reply-To: References: Message-ID: I'm using OpenSSL in FIPS mode as part of an Android app. I'm using the NDK. I create an EC Curve with EC_GROUP_new_curve_GFp() and then delete it with EC_GROUP_clear_free(). This presumably uses a lot of entropy as, while this may succeed running once, all further attempts for the next several minutes will crash the app (Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1)). This occurs on two devices, one running Android 4.1 and one running Android 4.2. When FIPS mode is disabled this behavior does not occur. When EC_GROUP_free() is used instead this also does not occur. There are no problems running this on an Android 5.1 device. Any ideas? -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4298 Please log in as guest with password guest if prompted From onicrypt at gmail.com Mon Feb 8 17:30:50 2016 From: onicrypt at gmail.com (Nich Ramsey) Date: Mon, 8 Feb 2016 09:30:50 -0800 Subject: [openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites In-Reply-To: References: <20160204171042.GA25291@roeckx.be> <2902654.TQ8Vo2iRU5@pintsize.usersys.redhat.com> <3b7219c7ecb7456b88a0c530a18ab4bd@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: I said I would be willing to help, but got no reply on how best to ramp up on developing a stable addition likely to be accepted by the dev team. I read the material online about contributing, and it refers ultimately back to this mailing list. Are there other online materials/resources I can read up on to get a better handle on contributing meaningful additions? I am aware that my work may still not be adopted by the core dev team, but would like to take on this project for my own edification. Thanks in advance for your consideration and help in this matter, Nich On Feb 8, 2016 6:49 AM, "Salz, Rich via RT" wrote: > > > over 40% of Alexa top 1 million TLS enabled servers enable Camellia > > That's different than actual use, as you know. > > > I don't see it mentioned anywhere in documentation, especially not in > > ciphers(1) man page. So, is it not so severe, or should the Camellia be > > removed from DEFAULT? > > It probably will be. > > I think the bottom line is that nobody on the team is enthusiastic, or > even willing, to put into the work to add and support it. And nobody is > wiling to put it into the codebase these days without an internal > commitment to support it. > > -- > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4075 > Please log in as guest with password guest if prompted > > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Mon Feb 8 17:30:52 2016 From: rt at openssl.org (Nich Ramsey via RT) Date: Mon, 08 Feb 2016 17:30:52 +0000 Subject: [openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites In-Reply-To: References: <20160204171042.GA25291@roeckx.be> <2902654.TQ8Vo2iRU5@pintsize.usersys.redhat.com> <3b7219c7ecb7456b88a0c530a18ab4bd@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: I said I would be willing to help, but got no reply on how best to ramp up on developing a stable addition likely to be accepted by the dev team. I read the material online about contributing, and it refers ultimately back to this mailing list. Are there other online materials/resources I can read up on to get a better handle on contributing meaningful additions? I am aware that my work may still not be adopted by the core dev team, but would like to take on this project for my own edification. Thanks in advance for your consideration and help in this matter, Nich On Feb 8, 2016 6:49 AM, "Salz, Rich via RT" wrote: > > > over 40% of Alexa top 1 million TLS enabled servers enable Camellia > > That's different than actual use, as you know. > > > I don't see it mentioned anywhere in documentation, especially not in > > ciphers(1) man page. So, is it not so severe, or should the Camellia be > > removed from DEFAULT? > > It probably will be. > > I think the bottom line is that nobody on the team is enthusiastic, or > even willing, to put into the work to add and support it. And nobody is > wiling to put it into the codebase these days without an internal > commitment to support it. > > -- > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4075 > Please log in as guest with password guest if prompted > > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4075 Please log in as guest with password guest if prompted From rt at openssl.org Mon Feb 8 17:37:52 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Mon, 08 Feb 2016 17:37:52 +0000 Subject: [openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites In-Reply-To: References: <20160204171042.GA25291@roeckx.be> <2902654.TQ8Vo2iRU5@pintsize.usersys.redhat.com> <3b7219c7ecb7456b88a0c530a18ab4bd@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: > I said I would be willing to help, but got no reply on how best to ramp up on > developing a stable addition likely to be accepted by the dev team. There's no hard-and-fast rules. We recently added some text: https://openssl.org/community/getting-started.html But again, for the specific request here, someone from the dev team has to be willing to do it. If it's really important, well, someone can always start a fork. Or work on making it an external ENGINE, like GOST. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4075 Please log in as guest with password guest if prompted From onicrypt at gmail.com Mon Feb 8 17:48:00 2016 From: onicrypt at gmail.com (Nich Ramsey) Date: Mon, 8 Feb 2016 09:48:00 -0800 Subject: [openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites In-Reply-To: References: <20160204171042.GA25291@roeckx.be> <2902654.TQ8Vo2iRU5@pintsize.usersys.redhat.com> <3b7219c7ecb7456b88a0c530a18ab4bd@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: Ok thanks for clarifying. What does it take to become a member of the dev team? I'm still years away from having enough crypto/C programming experience, what in particular should I be working on? Basically, what kind of skills would you like to see? Thanks again for the quick reply, I'll check out the link you sent. Stay awesome, Nich On Feb 8, 2016 9:38 AM, "Salz, Rich via RT" wrote: > > > I said I would be willing to help, but got no reply on how best to ramp > up on > > developing a stable addition likely to be accepted by the dev team. > > There's no hard-and-fast rules. We recently added some text: > https://openssl.org/community/getting-started.html > > But again, for the specific request here, someone from the dev team has to > be willing to do it. > > If it's really important, well, someone can always start a fork. Or work > on making it an external ENGINE, like GOST. > > > > -- > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4075 > Please log in as guest with password guest if prompted > > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Mon Feb 8 17:48:08 2016 From: rt at openssl.org (Nich Ramsey via RT) Date: Mon, 08 Feb 2016 17:48:08 +0000 Subject: [openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites In-Reply-To: References: <20160204171042.GA25291@roeckx.be> <2902654.TQ8Vo2iRU5@pintsize.usersys.redhat.com> Message-ID: Ok thanks for clarifying. What does it take to become a member of the dev team? I'm still years away from having enough crypto/C programming experience, what in particular should I be working on? Basically, what kind of skills would you like to see? Thanks again for the quick reply, I'll check out the link you sent. Stay awesome, Nich On Feb 8, 2016 9:38 AM, "Salz, Rich via RT" wrote: > > > I said I would be willing to help, but got no reply on how best to ramp > up on > > developing a stable addition likely to be accepted by the dev team. > > There's no hard-and-fast rules. We recently added some text: > https://openssl.org/community/getting-started.html > > But again, for the specific request here, someone from the dev team has to > be willing to do it. > > If it's really important, well, someone can always start a fork. Or work > on making it an external ENGINE, like GOST. > > > > -- > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4075 > Please log in as guest with password guest if prompted > > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4075 Please log in as guest with password guest if prompted From rsalz at akamai.com Mon Feb 8 17:50:01 2016 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 8 Feb 2016 17:50:01 +0000 Subject: [openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites In-Reply-To: References: <20160204171042.GA25291@roeckx.be> <2902654.TQ8Vo2iRU5@pintsize.usersys.redhat.com> Message-ID: <5fbafc558ef4488eb7094c32e9501a30@usma1ex-dag1mb1.msg.corp.akamai.com> > I'm still years away from having enough crypto/C programming experience, > what in particular should I be working on? Read the link. From rt at openssl.org Mon Feb 8 17:50:07 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Mon, 08 Feb 2016 17:50:07 +0000 Subject: [openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites In-Reply-To: <5fbafc558ef4488eb7094c32e9501a30@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20160204171042.GA25291@roeckx.be> <2902654.TQ8Vo2iRU5@pintsize.usersys.redhat.com> <5fbafc558ef4488eb7094c32e9501a30@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: > I'm still years away from having enough crypto/C programming experience, > what in particular should I be working on? Read the link. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4075 Please log in as guest with password guest if prompted From rsalz at akamai.com Mon Feb 8 18:37:31 2016 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 8 Feb 2016 18:37:31 +0000 Subject: [openssl-dev] Do you use the JPAKE feature? Message-ID: It's currently "experimental" and we're thinking of dropping it completely from the next release. If you use it, please reply here soon. -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz -------------- next part -------------- An HTML attachment was scrubbed... URL: From uri at ll.mit.edu Mon Feb 8 18:43:31 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Mon, 8 Feb 2016 18:43:31 +0000 Subject: [openssl-dev] Do you use the JPAKE feature? Message-ID: It?s currently ?experimental? and we?re thinking of dropping it completely from the next release. If you use it, please reply here soon. All of my openssl builds have JPAKE enabled. But I cannot call myself a user of it. I?d rather not see it dropped, but I can?t claim operational impact if you do. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Mon Feb 8 18:51:15 2016 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 8 Feb 2016 18:51:15 +0000 Subject: [openssl-dev] [openssl.org #2021] sni bug In-Reply-To: References: <4A942BF3.90905@edelweb.fr> <56B66223.90209@on-x.com> Message-ID: <98e93229acd14b5fb4e66d78439aca18@usma1ex-dag1mb1.msg.corp.akamai.com> > A correct logic is one single function(the code of check and parse combined) > that collects the values of extensions and then treat them calls callbacks in a > defined order. Yes, but right now we've got what we've got :) > Actually it seems that you could influence the server behavoiur if you change > the order of extensions in the clienthello. Probably. > sni first or last for example. > That makes server application code difficult. Yes. It would be great to have a single function that got all parsed extensions. Sadly, I don't know if we'll get it fixed before the final API-change deadline. :( From rt at openssl.org Mon Feb 8 18:51:27 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Mon, 08 Feb 2016 18:51:27 +0000 Subject: [openssl-dev] [openssl.org #2021] sni bug In-Reply-To: <98e93229acd14b5fb4e66d78439aca18@usma1ex-dag1mb1.msg.corp.akamai.com> References: <4A942BF3.90905@edelweb.fr> <56B66223.90209@on-x.com> <98e93229acd14b5fb4e66d78439aca18@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: > A correct logic is one single function(the code of check and parse combined) > that collects the values of extensions and then treat them calls callbacks in a > defined order. Yes, but right now we've got what we've got :) > Actually it seems that you could influence the server behavoiur if you change > the order of extensions in the clienthello. Probably. > sni first or last for example. > That makes server application code difficult. Yes. It would be great to have a single function that got all parsed extensions. Sadly, I don't know if we'll get it fixed before the final API-change deadline. :( -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2021 Please log in as guest with password guest if prompted From kurt at roeckx.be Mon Feb 8 19:38:45 2016 From: kurt at roeckx.be (Kurt Roeckx) Date: Mon, 8 Feb 2016 20:38:45 +0100 Subject: [openssl-dev] version script In-Reply-To: References: Message-ID: <20160208193844.GA14421@roeckx.be> On Mon, Feb 08, 2016 at 01:41:10PM +0000, Catalin Vasile wrote: > I'm trying to compile a custom OpenSSL library to work with nginx. > nginx requires that the SSL library have version data included in the .so files, so I'm using?this patch[1] for this. > The problem is that if I set the library versiont to 1.0.1 into that script, when I start nginx or trigger ldd on nginx I get: > /usr/lib/libssl.so.1.0.0: version `OPENSSL_1.0.0' not found > If I set that version to 1.0.0 I get: > /usr/lib/libssl.so.1.0.0: version `OPENSSL_1.0.1' not found > Can someone help me out to understand what is going on? You should use the same version script as the versions you're trying to replace. Kurt From openssl-users at dukhovni.org Mon Feb 8 20:02:51 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 8 Feb 2016 20:02:51 +0000 Subject: [openssl-dev] Duplicate APIs? In-Reply-To: <6274621B-FF90-4A73-92E4-9455CE31DC7C@dukhovni.org> References: <07821AB6-987F-480E-ADBF-9313EADA7FBD@akamai.com> <6274621B-FF90-4A73-92E4-9455CE31DC7C@dukhovni.org> Message-ID: <20160208200251.GY19242@mournblade.imrryr.org> On Mon, Feb 08, 2016 at 10:17:37AM -0500, Viktor Dukhovni wrote: > What'll likely happen is that SSL_session_reused() will be the > new name of the SSL_cache_hit() function, and SSL_cache_hit will > become a macro referencing that function: > > int SSL_session_reused(const SSL *ssl); > #if OPENSSL_API_COMPAT < 0x10100000L > # define SSL_cache_hit(ssl) SSL_session_reused(ssl) > #endif > > The control variant will be removed. And this is now done, with the only difference being that no "const" was added to the function prototype, that might happen in a future commit, or it be good enough as-is. -- Viktor. From rainer.jung at kippdata.de Mon Feb 8 20:49:21 2016 From: rainer.jung at kippdata.de (Rainer Jung) Date: Mon, 8 Feb 2016 21:49:21 +0100 Subject: [openssl-dev] SSL_R_HTTP_REQUEST no longer supported in 1.1.0 Message-ID: <56B8FF51.1050507@kippdata.de> The constant SSL_R_HTTP_REQUEST is still defined, but I can't find code that sets it and practical experiments indicate it is no longer set. In Apache land we use it to detect "HTTP spoken on HTTPS port". OpenSSL 1.0.2 has code in ssl23_get_client_hello() that checks read bytes against "HEAD", "GET", "POST" etc. to detect this situation. Was this feature removed intentionally or will it come back until the final 1.1.0 release? Regards, Rainer From openssl at roumenpetrov.info Mon Feb 8 21:36:53 2016 From: openssl at roumenpetrov.info (Roumen Petrov) Date: Mon, 08 Feb 2016 23:36:53 +0200 Subject: [openssl-dev] BIO_new_connect after refactoring In-Reply-To: <20160208.154810.1850336826127140760.levitte@openssl.org> References: <56B718F3.9070500@roumenpetrov.info> <20160208.154810.1850336826127140760.levitte@openssl.org> Message-ID: <56B90A75.8030408@roumenpetrov.info> Richard Levitte wrote: > That patch just got merged into master, commit > 80926502986a97eed53afe1d85fc074e40829547 10x It seems to me #4296 is second report. > Cheers, > Richard > > In message <56B718F3.9070500 at roumenpetrov.info> on Sun, 07 Feb 2016 12:14:11 +0200, Roumen Petrov said: > > openssl> Hello, > openssl> > openssl> With master branch my ssh ocsp tests start to fail again. > openssl> The program code call BIO_new_connect("127.0.01") and then parsing of > openssl> 'name' crash. > openssl> Please find attached proposed patch. Roumen From levitte at openssl.org Mon Feb 8 21:39:45 2016 From: levitte at openssl.org (Richard Levitte) Date: Mon, 08 Feb 2016 22:39:45 +0100 (CET) Subject: [openssl-dev] BIO_new_connect after refactoring In-Reply-To: <56B90A75.8030408@roumenpetrov.info> References: <56B718F3.9070500@roumenpetrov.info> <20160208.154810.1850336826127140760.levitte@openssl.org> <56B90A75.8030408@roumenpetrov.info> Message-ID: <20160208.223945.2096361615582283597.levitte@openssl.org> In message <56B90A75.8030408 at roumenpetrov.info> on Mon, 08 Feb 2016 23:36:53 +0200, Roumen Petrov said: openssl> Richard Levitte wrote: openssl> > That patch just got merged into master, commit openssl> > 80926502986a97eed53afe1d85fc074e40829547 openssl> 10x openssl> It seems to me #4296 is second report. Yes, thanks for reminding me, I've now closed that ticket. The reporter has aready been notified via his pull request. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From matt at openssl.org Mon Feb 8 22:07:46 2016 From: matt at openssl.org (Matt Caswell) Date: Mon, 8 Feb 2016 22:07:46 +0000 Subject: [openssl-dev] SSL_R_HTTP_REQUEST no longer supported in 1.1.0 In-Reply-To: <56B8FF51.1050507@kippdata.de> References: <56B8FF51.1050507@kippdata.de> Message-ID: <56B911B2.9020604@openssl.org> On 08/02/16 20:49, Rainer Jung wrote: > The constant SSL_R_HTTP_REQUEST is still defined, but I can't find code > that sets it and practical experiments indicate it is no longer set. > > In Apache land we use it to detect "HTTP spoken on HTTPS port". OpenSSL > 1.0.2 has code in ssl23_get_client_hello() that checks read bytes > against "HEAD", "GET", "POST" etc. to detect this situation. > > Was this feature removed intentionally Well, kinda sorta. The whole version negotiation approach has been completely rewritten. This made all of the ssl23* files redundant and so they were deleted. > or will it come back until the > final 1.1.0 release? Realistically I am unlikely to have time before feature freeze to add this myself. I'd be happy to look at patches though. Matt From rt at openssl.org Mon Feb 8 23:31:27 2016 From: rt at openssl.org (Alessandro Ghedini via RT) Date: Mon, 08 Feb 2016 23:31:27 +0000 Subject: [openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites In-Reply-To: <20160208233114.GA10927@kronk.local> References: <20160204171042.GA25291@roeckx.be> <2902654.TQ8Vo2iRU5@pintsize.usersys.redhat.com> <3b7219c7ecb7456b88a0c530a18ab4bd@usma1ex-dag1mb1.msg.corp.akamai.com> <20160208233114.GA10927@kronk.local> Message-ID: On Mon, Feb 08, 2016 at 05:30:52pm +0000, Nich Ramsey via RT wrote: > I said I would be willing to help, but got no reply on how best to ramp up > on developing a stable addition likely to be accepted by the dev team. FWIW, the necessary code has already been written (by me) for this particular feature [0]... the problem isn't lack of code here. Cheers [0] https://github.com/openssl/openssl/pull/374 -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4075 Please log in as guest with password guest if prompted -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From rt at openssl.org Mon Feb 8 23:48:25 2016 From: rt at openssl.org (Alessandro Ghedini via RT) Date: Mon, 08 Feb 2016 23:48:25 +0000 Subject: [openssl-dev] [openssl.org #4271] Enhancement Request: Support TCP Fast Open In-Reply-To: <20160208234815.GB10927@kronk.local> References: <20160208234815.GB10927@kronk.local> Message-ID: On Mon, Jan 25, 2016 at 06:24:55pm +0000, Sara Dickinson via RT wrote: > Hi, > > I would like to request that support be added to OpenSSL to enable client applications to make use use of TCP Fast Open (https://tools.ietf.org/html/rfc7413 ) when initiating the TLS handshake on Linux (TCP Fast Open is available in Linux kernel > 4.1). > > This was discussed in detail on the OpenSSL Users list: > https://mta.openssl.org/pipermail/openssl-users/2016-January/002835.html I took a stab at implementing TFO support for OpenSSL on Linux and OS X at: https://github.com/ghedo/openssl/commits/fast_open This only works for the BIO_s_socket() BIO, but could probably be adapted to BIO_s_connect() as well if needed. However I'm not particularly happy with the implementation (it's fairly ugly), and it would probably be easier to implement this on the application side by overriding the "write" method of whatever BIO is used, instead of trying to make OpenSSL do it directly. Cheers -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4271 Please log in as guest with password guest if prompted -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From rt at openssl.org Tue Feb 9 03:44:43 2016 From: rt at openssl.org (J Mohan Rao Arisankala via RT) Date: Tue, 09 Feb 2016 03:44:43 +0000 Subject: [openssl-dev] [openssl.org #4299] s_server cmd In-Reply-To: References: Message-ID: Hi, - added missing help option messages - ecdh_single option is removed as it is a no-op and not an option supported in earlier versions - ssl_ctx_security_debug() was invoked before ctx check for NULL - trusted_first option can be removed, as it is always enabled in 1.1. But not removed the option, require confirmation. I have made these changes in the below pull request, please have a look. https://github.com/openssl/openssl/pull/646 Thanks, Mohan -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4299 Please log in as guest with password guest if prompted From sms at antinode.info Tue Feb 9 06:20:58 2016 From: sms at antinode.info (Steven M. Schweda) Date: Tue, 9 Feb 2016 00:20:58 -0600 (CST) Subject: [openssl-dev] Upcoming build system change Message-ID: <16020900205830_2020AB3E@antinode.info> > - Perl! Reports tell me that version 5.10.1 works fine [...] Perhaps, but around here, the current version fails pretty badly: ALP $ perl --version This is perl 5, version 22, subversion 1 (v5.22.1) built for VMS_AXP The generated descrip.mms is defective. It starts out reasonable, with stuff like: SRCDIR=DISK$UTIL5ALPX:[UTILITY.SOURCE.OPENSSL.openssl-refactor-build] BUILDDIR=DISK$UTIL5ALPX:[UTILITY.SOURCE.OPENSSL.openssl-refactor-build] but many (supposedly relative) derived paths are bad. For example: DEFINE SRCTOP [-.DISK$UTIL5ALPX.UTILITY.SOURCE.OPENSSL.openssl-refactor-build] DEFINE BLDTOP [-.DISK$UTIL5ALPX.UTILITY.SOURCE.OPENSSL.openssl-refactor-build] $(PERL) [-.DISK$UTIL5ALPX.UTILITY.SOURCE.OPENSSL.openssl-refactor-build.test]run_tests.pl $(TESTS) copy-certs : @ IF F$SEARCH("[.DISK$UTIL5ALPX.UTILITY.SOURCE.OPENSSL.openssl-refactor-build]certs.dir") .EQS. "" THEN - CREATE/DIR [.DISK$UTIL5ALPX.UTILITY.SOURCE.OPENSSL.openssl-refactor-build.certs] and so on. With all this device-directory confusion ("DISK$UTIL5ALPX:" v. "[.DISK$UTIL5ALPX]"), failures come thick and fast. Apparently, all the realpath() and abs2rel() stuff does horrible things on VMS in some circumstances (like mine). My default device:[directory] spec does not include the DISK$volume_label device name: ALP $ show default UTILITY5_DEV:[UTILITY.source.openssl.openssl-refactor-build] ALP $ show logical UTILITY5_DEV "UTILITY5_DEV" = "ALP$DKC100:" (LNM$SYSTEM_TABLE) ALP $ show logical DISK$UTIL5ALPX "DISK$UTIL5ALPX" = "ALP$DKC100:" (LNM$SYSTEM_TABLE) If there's a requirement to use the DISK$volume_label device name, then there needs to be some (seriously restrictive and/or confusing) documentation, or else some improved automation to set it as required. If Perl can't do this work reliably on VMS, then it might make more sense to derive such directories/paths using DCL, and let Perl do the stuff which can be done more portably. Knowing approximately nothing about Perl, I'm ill-equipped to contribute much more to this discussion than complaints about how badly it works, but I'm open to requests for details or more testing. For a little recent, related Perl-on-VMS discussion, there's a thread on comp.os.vms: https://groups.google.com/forum/#!topic/comp.os.vms/npJUbALe9Lo I still don't know why the CPAN stuff failed here, but it did. I don't object to Perl being required to build OpenSSL, but if the OpenSSL builders are sensitive to Perl versions, or to fine details in how the user specifies his default dev:[dir], then I predict abundant complaints from a large fraction of VMS users who try to build this stuff. (Which may not be a large number, of course.) I fetched my openssl-refactor-build.zip kit around 14-JAN-2016, so if significantly changes were made since then, then I don't know about them. > ! There is no install target yet. > ! As a matter of fact, I'd like to talk about exactly where it > ! should install. Let's talk! Because VMS lacks a popular default localtion (like /usr/local), I suggest asking the victim where he'd like it. > Feedback welcome! I'm almost always willing to complain. ------------------------------------------------------------------------ Steven M. Schweda sms at antinode-info 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 From levitte at openssl.org Tue Feb 9 07:41:37 2016 From: levitte at openssl.org (Richard Levitte) Date: Tue, 09 Feb 2016 08:41:37 +0100 (CET) Subject: [openssl-dev] Upcoming build system change In-Reply-To: <16020900205830_2020AB3E@antinode.info> References: <16020900205830_2020AB3E@antinode.info> Message-ID: <20160209.084137.1237311317473114554.levitte@openssl.org> In message <16020900205830_2020AB3E at antinode.info> on Tue, 9 Feb 2016 00:20:58 -0600 (CST), "Steven M. Schweda" said: sms> > - Perl! Reports tell me that version 5.10.1 works fine [...] sms> sms> Perhaps, but around here, the current version fails pretty badly: sms> sms> ALP $ perl --version sms> sms> This is perl 5, version 22, subversion 1 (v5.22.1) built for sms> VMS_AXP In my case: $ perl --version This is perl 5, version 20, subversion 1 (v5.20.1) built for VMS_AXP I sure hope things haven't gone for the worse... sms> The generated descrip.mms is defective. It starts out reasonable, sms> with stuff like: sms> sms> SRCDIR=DISK$UTIL5ALPX:[UTILITY.SOURCE.OPENSSL.openssl-refactor-build] sms> BUILDDIR=DISK$UTIL5ALPX:[UTILITY.SOURCE.OPENSSL.openssl-refactor-build] sms> sms> but many (supposedly relative) derived paths are bad. For example: sms> sms> DEFINE SRCTOP [-.DISK$UTIL5ALPX.UTILITY.SOURCE.OPENSSL.openssl-refactor-build] sms> DEFINE BLDTOP [-.DISK$UTIL5ALPX.UTILITY.SOURCE.OPENSSL.openssl-refactor-build] sms> $(PERL) [-.DISK$UTIL5ALPX.UTILITY.SOURCE.OPENSSL.openssl-refactor-build.test]run_tests.pl $(TESTS) That's... bad. I would like three things from you: 1. The configuration command line you used. 2. configdata.pm (it's produced by Configure) 3. descrip.mms ("We are the Spanish Inquisition...") sms> copy-certs : sms> @ IF F$SEARCH("[.DISK$UTIL5ALPX.UTILITY.SOURCE.OPENSSL.openssl-refactor-build]certs.dir") .EQS. "" THEN - sms> CREATE/DIR [.DISK$UTIL5ALPX.UTILITY.SOURCE.OPENSSL.openssl-refactor-build.certs] sms> sms> and so on. With all this device-directory confusion ("DISK$UTIL5ALPX:" sms> v. "[.DISK$UTIL5ALPX]"), failures come thick and fast. sms> sms> Apparently, all the realpath() and abs2rel() stuff does horrible sms> things on VMS in some circumstances (like mine). It seems there are circumstances I haven't tested (yet). Although, I recall having some (unrelated) trouble with realpath(), that might be something for me to look into. sms> My default device:[directory] spec does not include the DISK$volume_label device sms> name: sms> sms> ALP $ show default sms> UTILITY5_DEV:[UTILITY.source.openssl.openssl-refactor-build] Was this the directory you configured and built in as well? (I'm asking, because Configure now supports building outside of the source directory) sms> ALP $ show logical UTILITY5_DEV sms> "UTILITY5_DEV" = "ALP$DKC100:" (LNM$SYSTEM_TABLE) sms> sms> ALP $ show logical DISK$UTIL5ALPX sms> "DISK$UTIL5ALPX" = "ALP$DKC100:" (LNM$SYSTEM_TABLE) sms> sms> If there's a requirement to use the DISK$volume_label device name, sms> then there needs to be some (seriously restrictive and/or confusing) sms> documentation, or else some improved automation to set it as required. No such requirement. Configure is supposed to figure things out from your default directory and other given data. sms> Knowing approximately nothing about Perl, I'm ill-equipped to sms> contribute much more to this discussion than complaints about how badly sms> it works, but I'm open to requests for details or more testing. Thanks. sms> For a little recent, related Perl-on-VMS discussion, there's a thread on sms> comp.os.vms: sms> sms> https://groups.google.com/forum/#!topic/comp.os.vms/npJUbALe9Lo (Oh my, I haven't approached Usenet or whatever it has become in ages) sms> I fetched my openssl-refactor-build.zip kit around 14-JAN-2016, so if sms> significantly changes were made since then, then I don't know about sms> them. Things have changed a bit, it might be that a newer fetch clears things up. Not going to guarantee it, though, so let me check through the stuff I hope you'll send me first. sms> > ! There is no install target yet. sms> > ! As a matter of fact, I'd like to talk about exactly where it sms> > ! should install. Let's talk! sms> sms> Because VMS lacks a popular default localtion (like /usr/local), I sms> suggest asking the victim where he'd like it. Actually, from looking at what the vms-ports folks do, it seems that SYS$COMMON:['name'...] is a popular location sms> > Feedback welcome! sms> sms> I'm almost always willing to complain. Heh ;-) -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From levitte at openssl.org Tue Feb 9 08:33:28 2016 From: levitte at openssl.org (Richard Levitte) Date: Tue, 09 Feb 2016 09:33:28 +0100 (CET) Subject: [openssl-dev] Upcoming build system change In-Reply-To: <20160209.084137.1237311317473114554.levitte@openssl.org> References: <16020900205830_2020AB3E@antinode.info> <20160209.084137.1237311317473114554.levitte@openssl.org> Message-ID: <20160209.093328.60502183161855889.levitte@openssl.org> In message <20160209.084137.1237311317473114554.levitte at openssl.org> on Tue, 09 Feb 2016 08:41:37 +0100 (CET), Richard Levitte said: levitte> In message <16020900205830_2020AB3E at antinode.info> on Tue, 9 Feb 2016 00:20:58 -0600 (CST), "Steven M. Schweda" said: levitte> sms> For a little recent, related Perl-on-VMS discussion, there's a thread on levitte> sms> comp.os.vms: levitte> sms> levitte> sms> https://groups.google.com/forum/#!topic/comp.os.vms/npJUbALe9Lo That discussion explained quite a lot! I was lucky (*) in my tests, the device of the directory I tested in was the volume label. I'm not sure I need your configdata.pm or descrip.mms at this point... Cheers, Richard (*) or not so lucky, I didn't get to have your wonderful experience ;-) -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From sreekanth_sk at yahoo.com Tue Feb 9 10:54:06 2016 From: sreekanth_sk at yahoo.com (Sreekanth M) Date: Tue, 9 Feb 2016 10:54:06 +0000 (UTC) Subject: [openssl-dev] ssl external session caching References: <1746257148.1446372.1455015246275.JavaMail.yahoo.ref@mail.yahoo.com> Message-ID: <1746257148.1446372.1455015246275.JavaMail.yahoo@mail.yahoo.com> Hi, I was doing load testing using openssl external session caching?feature and was facing some issues. Details are as below: Test setup I used nginx-1.0.10 and tested it for shared memory cache. ?Client sends around 200 Requests/sec ?and 50% of requests reuses ssl session. OpenSSL version used is?OpenSSL 1.0.1e-fips 11 Feb 2013. The operational mode used for session caching is as below: SSL_CTX_set_session_cache_ mode(ssl->ctx,?SSL_SESS_CACHE_ SERVER |?SSL_SESS_CACHE_NO_INTERNAL); SSL_SESS_CACHE_NO_INTERNAL is to ensure that OpenSSL does not store sessions internally and do any internal lookups . Results:I am seeing increase in response times and it looks like an issue with OpenSSL. ?As you can see, the connect time increases over time from 30 ms (t = 100 s) to 120 ms (at t = 500 s). ?Requests per sec remains the same over this time .? I suspect the issue is with OpenSSL framework which does some operations over large lists.? Please find attached the connect and request time graph for reference. Any feed back would be appreciated. Thanks,Sreekanth -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: connect_request_time.png Type: image/png Size: 3234 bytes Desc: not available URL: From hkario at redhat.com Tue Feb 9 15:09:35 2016 From: hkario at redhat.com (Hubert Kario) Date: Tue, 09 Feb 2016 16:09:35 +0100 Subject: [openssl-dev] [openssl.org #2021] sni bug In-Reply-To: References: <56B66223.90209@on-x.com> Message-ID: <3783509.0IET1vlGcC@pintsize.usersys.redhat.com> On Saturday 06 February 2016 21:24:26 Peter Sylvester via RT wrote: > On 06/02/2016 15:50, Rich Salz via RT wrote: > > Is this still a bug? > > -- > > Rich Salz, OpenSSL dev team; rsalz at openssl.org > > I don't know, there have been many changes to the extension treatment. > I have not followed the stuff since 5 years. > > The extension handling is not what I had in the original design and > seems to be broken. > > There was no split into two functions two functions that communicate > through the session.; > > Some callbacks are done in the check loop (as far as I remember) . > Unfortunately this split occured almost in parallel to our > contribution in 2006 when some EC stuff was added. > > A correct logic is one single function(the code of check and parse > combined) that collects the values of extensions > and then treat them calls callbacks in a defined order. > > Actually it seems that you could influence the server behavoiur if you > change the order of extensions in the clienthello. > sni first or last for example. > That makes server application code difficult. I'm not sure if I understand. Is the problem in OpenSSL internal handling of extensions or is it in the treatment that callbacks get? And which exact extensions interact badly with each other? Is it server_name[1] and any other extension (e.g supported_groups)? Can I trigger it with just s_server? I'm asking, as that's one of the test scenarios I want to cover in the tlsfuzzer - verification that server behaviour stays the same no matter the order of extensions in Client Hello. 1 - https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From rt at openssl.org Tue Feb 9 15:22:36 2016 From: rt at openssl.org (Matt Caswell via RT) Date: Tue, 09 Feb 2016 15:22:36 +0000 Subject: [openssl-dev] [openssl.org #3824] FEATURE: Please provide a function to unintialize the library In-Reply-To: References: Message-ID: On Wed Apr 29 05:10:28 2015, noloader at gmail.com wrote: > This question crops up on occasion: How do you shutdown the OpenSSL > library. See, for example: > > * "How to properly uninitialize OpenSSL", > http://stackoverflow.com/questions/29845527/how-to-properly- > uninitialize-openssl. > * "Order of Cleanup to avoid memory leaks?", > http://comments.gmane.org/gmane.comp.encryption.openssl.user/50784 > > If you look at an answer like questions and answers > http://comments.gmane.org/gmane.comp.encryption.openssl.user/50784, > its non-trivial to get right. There were at least ***8*** cleanup > calls, and 1 was still missed. > > In addition, there are some things that cannot be cleaned up because > they are not accessible outside the library. For example: > > * ssl_comp_methods > * > https://rt.openssl.org/Ticket/Display.html?id=2561&user=guest&pass=guest > * > http://rt.openssl.org/Ticket/Display.html?id=2439&user=guest&pass=guest > * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=584968. > > Please provide a function to unintialize the library. I imagine it > would be similar to SSL_library_init(). But rather than having it > create things, it would cleanup things. Done. In fact master now auto-initialises and deinitialises so no explicit init or cleanup is required at all in most cases. There are some exceptions - see the OPENSSL_INIT_crypto_library_start() and OPENSSL_INIT_ssl_library_start() man pages in the latest master. Where explicit init and deinit is required there is now a single function for each. Closing this ticket. Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3824 Please log in as guest with password guest if prompted From rt at openssl.org Tue Feb 9 15:26:11 2016 From: rt at openssl.org (Hubert Kario via RT) Date: Tue, 09 Feb 2016 15:26:11 +0000 Subject: [openssl-dev] [openssl.org #4299] s_server cmd In-Reply-To: <3958099.A03drGeT1T@pintsize.usersys.redhat.com> References: <3958099.A03drGeT1T@pintsize.usersys.redhat.com> Message-ID: On Tuesday 09 February 2016 03:44:43 J Mohan Rao Arisankala via RT wrote: > - trusted_first option can be removed, as it is always enabled in > 1.1. > But not removed the option, require confirmation. -trusted_first and the alternative chains (-no_alt_chains) work a bit differently so you can't say it is always enabled in edge cases you will get different chains or validation failures depending on options set -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4299 Please log in as guest with password guest if prompted -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From rt at openssl.org Tue Feb 9 22:25:47 2016 From: rt at openssl.org (Engstrom, John via RT) Date: Tue, 09 Feb 2016 22:25:47 +0000 Subject: [openssl-dev] [openssl.org #4300] BUG: Solaris FIPS container does not redefine bn_mul_mont_fpu in fipssyms.h In-Reply-To: <029563C6-6402-4668-A405-60C3BDAE4432@tditechnologies.com> References: <029563C6-6402-4668-A405-60C3BDAE4432@tditechnologies.com> Message-ID: When building an OpenSSL shared library on Solaris with FIPS support you get a multiply defined symbol error: ld: fatal: symbol 'bn_mul_mont_fpu' is multiply-defined: (file /usr/local/ssl/fips-2.0/lib//fipscanister.o type=FUNC; file libcrypto.a(sparcv9a-mont.o) type=FUNC); ld: fatal: file processing errors. No output written to libcrypto.so.1.0.0 make[4]: *** [link_a.solaris] Error 1 This traces back to the fipssyms.h header file NOT defining bn_mul_mont_fpu when building the fipscanister. NOTE: the bn_mul_mont_fpu function in the SPARC assembly file (sparcv9a-mont.s) would also need to get redefined as fips_bn_mul_mont. Thanks, John Engstrom john.engstrom at tditechnologies.com -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4300 Please log in as guest with password guest if prompted From rt at openssl.org Wed Feb 10 01:14:20 2016 From: rt at openssl.org (Rich Salz via RT) Date: Wed, 10 Feb 2016 01:14:20 +0000 Subject: [openssl-dev] [openssl.org #4123] Query regarding dummy variable inside crypto In-Reply-To: References: Message-ID: fixed with commit effaf4d. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4123 Please log in as guest with password guest if prompted From rt at openssl.org Wed Feb 10 01:15:37 2016 From: rt at openssl.org (Rich Salz via RT) Date: Wed, 10 Feb 2016 01:15:37 +0000 Subject: [openssl-dev] [openssl.org #4295] help cleanup in dgst, pkeyutl cmds In-Reply-To: References: Message-ID: commit a173a7e thanks. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4295 Please log in as guest with password guest if prompted From rt at openssl.org Wed Feb 10 01:18:07 2016 From: rt at openssl.org (Rich Salz via RT) Date: Wed, 10 Feb 2016 01:18:07 +0000 Subject: [openssl-dev] [openssl.org #4294] [bug] failed to install in Ubuntu In-Reply-To: References: Message-ID: believed fixed. open new ticket if not. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4294 Please log in as guest with password guest if prompted From rt at openssl.org Wed Feb 10 01:31:44 2016 From: rt at openssl.org (Rich Salz via RT) Date: Wed, 10 Feb 2016 01:31:44 +0000 Subject: [openssl-dev] [openssl.org #4286] Debug in OpenSSL In-Reply-To: References: Message-ID: there is not enough information for us to reproduce the error, if there is one, and it looks like a build configuration issue on your platform. please discuss this on the openssl-users list. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4286 Please log in as guest with password guest if prompted From bkaduk at akamai.com Wed Feb 10 03:05:18 2016 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Tue, 9 Feb 2016 21:05:18 -0600 Subject: [openssl-dev] When the ocsp client is not really a client, to verify or not to verify Message-ID: <56BAA8EE.7060401@akamai.com> The ocsp utility is something of a jack-of-all-trades; in addition to being able to function as an ocsp client or server (as the manual page categorizes its behavior), it can do a few things that are not really client or server behavior: generating a request but not sending it, parsing a response from file, and mucking around in the revocation database to get the status of a certificate by bypassing the protocol. The middle case has something of a mismatch between the documentation and the code, though -- the example in the manual page seems to indicate that "openssl ocsp -respin resp.der -text" will just do a conversion of the response from DER to text form, but in actuality, the utility will also attempt to perform validation on the response, which is likely to fail since no -CApath or -CAfile argument is given. (It is possible that the default trust stores could suffice to verify the input response, but that seems unlikely in most cases.) The other two cases I mentioned above do not suffer from this ambiguity, since if a request is just generated but not sent, there is no response to attempt to validate (so the utility returns success), and if the utility is just checking the server-side database, the check "[i]f running as responder don't verify our own response" triggers an early (success) return. I see arguments on both sides (that "openssl ocsp -respin resp.der -text" should or should not attempt validation), but am currently leaning towards the status quo that the "client side" always attempts validation, for consistency and simplicity of code -- the risk of having another code path that skips validation and might be overzealous is bigger than the burden of just adding -noverify to the documented example. I've filed https://github.com/openssl/openssl/pull/650 with a commit that implements that behavior (as well as several other fixups to the ocsp utility and manual page), but am happy to modify it if an alternate resolution is preferred. -Ben From bkaduk at akamai.com Wed Feb 10 03:05:24 2016 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Tue, 9 Feb 2016 21:05:24 -0600 Subject: [openssl-dev] When the ocsp client is not really a client, to verify or not to verify Message-ID: <56BAA8F4.3060009@akamai.com> The ocsp utility is something of a jack-of-all-trades; in addition to being able to function as an ocsp client or server (as the manual page categorizes its behavior), it can do a few things that are not really client or server behavior: generating a request but not sending it, parsing a response from file, and mucking around in the revocation database to get the status of a certificate by bypassing the protocol. The middle case has something of a mismatch between the documentation and the code, though -- the example in the manual page seems to indicate that "openssl ocsp -respin resp.der -text" will just do a conversion of the response from DER to text form, but in actuality, the utility will also attempt to perform validation on the response, which is likely to fail since no -CApath or -CAfile argument is given. (It is possible that the default trust stores could suffice to verify the input response, but that seems unlikely in most cases.) The other two cases I mentioned above do not suffer from this ambiguity, since if a request is just generated but not sent, there is no response to attempt to validate (so the utility returns success), and if the utility is just checking the server-side database, the check "[i]f running as responder don't verify our own response" triggers an early (success) return. I see arguments on both sides (that "openssl ocsp -respin resp.der -text" should or should not attempt validation), but am currently leaning towards the status quo that the "client side" always attempts validation, for consistency and simplicity of code -- the risk of having another code path that skips validation and might be overzealous is bigger than the burden of just adding -noverify to the documented example. I've filed https://github.com/openssl/openssl/pull/650 with a commit that implements that behavior (as well as several other fixups to the ocsp utility and manual page), but am happy to modify it if an alternate resolution is preferred. -Ben From levitte at openssl.org Wed Feb 10 13:54:28 2016 From: levitte at openssl.org (Richard Levitte) Date: Wed, 10 Feb 2016 14:54:28 +0100 (CET) Subject: [openssl-dev] refactor-build branch now in master Message-ID: <20160210.145428.1416324177801513356.levitte@openssl.org> Hi, this is just a quick message to tell you guys that the refactor-build branch has now been merged into master. The branch on github will therefore be removed. Thanks to all that helped so far. I'm sure it's not entirely bug free yet, so please help out checking it further. On the unix platforms, you will notice that Configure tries to nudge you to try --unified if you haven't already. Please do try it, the more it's tested, the better it will be. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From uri at ll.mit.edu Wed Feb 10 16:46:53 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Wed, 10 Feb 2016 16:46:53 +0000 Subject: [openssl-dev] Current master branch doesn't compile - fails "make depend" Message-ID: The complete report is at https://github.com/openssl/openssl/issues/651 Configuration: $ ./Configure darwin64-x86_64-cc enable-rfc3779 enable-rc5 enable-md2 enable-deprecated experimental-jpake threads zlib enable-ec_nistp_64_gcc_128 shared --prefix=/Users/ur20980/src/openssl-1.1 --openssldir=/Users/ur20980/src/engines-1.1 The symptom: making depend in crypto... In file included from init.c:62: ../include/internal/conf.h:40:9: error: 'HEADER_INTERNAL_CONF_H' is used as a header guard here, followed by #define of a different macro [-Werror,-Wheader-guard] #ifndef HEADER_INTERNAL_CONF_H ^~~~~~~~~~~~~~~~~~~~~~ ../include/internal/conf.h:41:10: note: 'INTERNAL_CONF_H' is defined here; did you mean 'HEADER_INTERNAL_CONF_H'? # define INTERNAL_CONF_H ^~~~~~~~~~~~~~~ HEADER_INTERNAL_CONF_H 1 error generated. make[1]: *** [depend] Error 1 make: *** [depend] Error 1 $ -- Regards, Uri Blumenthal -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4324 bytes Desc: not available URL: From matt at openssl.org Wed Feb 10 17:29:44 2016 From: matt at openssl.org (Matt Caswell) Date: Wed, 10 Feb 2016 17:29:44 +0000 Subject: [openssl-dev] Current master branch doesn't compile - fails "make depend" In-Reply-To: References: Message-ID: <56BB7388.40105@openssl.org> On 10/02/16 16:46, Blumenthal, Uri - 0553 - MITLL wrote: > The complete report is at https://github.com/openssl/openssl/issues/651 > > Configuration: > > |$ ./Configure darwin64-x86_64-cc enable-rfc3779 enable-rc5 enable-md2 > enable-deprecated experimental-jpake threads zlib > enable-ec_nistp_64_gcc_128 shared > --prefix=/Users/ur20980/src/openssl-1.1 > --openssldir=/Users/ur20980/src/engines-1.1| > > > The symptom: > > |making depend in crypto... In file included from init.c:62: > ../include/internal/conf.h:40:9: error: 'HEADER_INTERNAL_CONF_H' is used > as a header guard here, followed by #define of a different macro > [-Werror,-Wheader-guard] #ifndef HEADER_INTERNAL_CONF_H > ^~~~~~~~~~~~~~~~~~~~~~ ../include/internal/conf.h:41:10: note: > 'INTERNAL_CONF_H' is defined here; did you mean > 'HEADER_INTERNAL_CONF_H'? # define INTERNAL_CONF_H ^~~~~~~~~~~~~~~ > HEADER_INTERNAL_CONF_H 1 error generated. make[1]: *** [depend] Error 1 > make: *** [depend] Error 1 $| Richard just fixed this. Matt From openssl-users at dukhovni.org Wed Feb 10 17:31:45 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 10 Feb 2016 12:31:45 -0500 Subject: [openssl-dev] Current master branch doesn't compile - fails "make depend" In-Reply-To: <56BB7388.40105@openssl.org> References: <56BB7388.40105@openssl.org> Message-ID: <21B900A2-98F5-4270-84DC-38FDF2D45C9E@dukhovni.org> > On Feb 10, 2016, at 12:29 PM, Matt Caswell wrote: > > Richard just fixed this. But for now, you'll also need to: $ git revert 5d1f03f29e2794f6d1642dfedf10fc3e334937d0 There's a problem with the assembly symbol names for ChaChaPoly1305. -- Viktor. From michel.sales at free.fr Wed Feb 10 20:52:21 2016 From: michel.sales at free.fr (Michel) Date: Wed, 10 Feb 2016 21:52:21 +0100 Subject: [openssl-dev] Configure error, 'head' not a Windows internal command Message-ID: <004801d16444$eff50120$cfdf0360$@sales@free.fr> Hi, Just to let you know that the configure perl script output the following error : 'head' is not recognized as an internal command under Windows 7. Regards, Michel. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Wed Feb 10 20:54:25 2016 From: rt at openssl.org (Andy Polyakov via RT) Date: Wed, 10 Feb 2016 20:54:25 +0000 Subject: [openssl-dev] [openssl.org #4300] BUG: Solaris FIPS container does not redefine bn_mul_mont_fpu in fipssyms.h In-Reply-To: <56BBA379.7070309@openssl.org> References: <029563C6-6402-4668-A405-60C3BDAE4432@tditechnologies.com> <56BBA379.7070309@openssl.org> Message-ID: Hi, > When building an OpenSSL shared library on Solaris with FIPS support you get a multiply defined symbol error: > > ld: fatal: symbol 'bn_mul_mont_fpu' is multiply-defined: > (file /usr/local/ssl/fips-2.0/lib//fipscanister.o type=FUNC; file > libcrypto.a(sparcv9a-mont.o) type=FUNC); > ld: fatal: file processing errors. No output written to libcrypto.so.1.0.0 > make[4]: *** [link_a.solaris] Error 1 > > > This traces back to the fipssyms.h header file NOT defining bn_mul_mont_fpu when building the fipscanister. NOTE: the bn_mul_mont_fpu function in the SPARC assembly file (sparcv9a-mont.s) would also need to get redefined as fips_bn_mul_mont. Quoting RT#3713: "The reason for why the problem in question (and similar) slip through is that FIPS module validation procedure, exhausting as it is, does not involve linking with "big" OpenSSL. As result one risks to remain oblivious of them on rare platforms such as one in question till it becomes too late. But luckily enough one can modify "big" OpenSSL to accommodate such mishaps. Renaming symbols as general method or case-specific workarounds ... is the way to go." Once again, "renaming symbols" refers to renaming in "big" OpenSSL, not in FIPS source, which can't be modified at will. As for case-specific workarounds in this case adding '.weak $fname' right after '.global $fname' in sparcv9a-mont.pl in "big" OpenSSL should do the trick. Could you verify and report back? -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4300 Please log in as guest with password guest if prompted From rt at openssl.org Wed Feb 10 21:59:12 2016 From: rt at openssl.org (Cristian Berneanu via RT) Date: Wed, 10 Feb 2016 21:59:12 +0000 Subject: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format In-Reply-To: References: Message-ID: Version: "OpenSSL 1.1.0-pre2 (alpha) 14 Jan 2016" Command: "openssl x509 -inform der -in sample_ekcert.der" Result: "unable to load certificate 140618483803816:error:0D0E20DD:asn1 encoding routines:c2i_ibuf:illegal padding:a_int.c:223: 140618483803816:error:0D08303A:asn1 encoding routines:asn1_template_noexp_d2i:nested asn1 error:tasn_dec.c:648:Field=serialNumber, Type=X509_CINF 140618483803816:error:0D08303A:asn1 encoding routines:asn1_template_noexp_d2i:nested asn1 error:tasn_dec.c:648:Field=cert_info, Type=X509" Input file: see attachment. Stable version works fine. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4301 Please log in as guest with password guest if prompted -------------- next part -------------- A non-text attachment was scrubbed... Name: sample_ekcert.der Type: application/x-x509-ca-cert Size: 1122 bytes Desc: not available URL: From michel.sales at free.fr Wed Feb 10 22:14:04 2016 From: michel.sales at free.fr (Michel) Date: Wed, 10 Feb 2016 23:14:04 +0100 Subject: [openssl-dev] Build 1.1 failed depending on configure options Message-ID: <007101d16450$5ab15f30$10141d90$@sales@free.fr> Hi, Just to let you know that today's 1.1 version fails to build when configured as follow : PERL Configure no-deprecated VC-WIN32 --debug --prefix=c:\OpenSSL_11_dbg link /nologo /subsystem:console /opt:ref /debug /out:out32.dbg\openssl.exe @C:\Users\...\Temp\nm5423.tmp libeay32.lib(eng_all.obj) : error LNK2019: unresolved external symbol _ENGINE_load_rdrand referenced in function _ENGINE_load_builtin_engines libeay32.lib(eng_all.obj) : error LNK2019: unresolved external symbol _ENGINE_load_dynamic referenced in function _ENGINE_load_builtin_engines libeay32.lib(eng_all.obj) : error LNK2019: unresolved external symbol _ENGINE_load_capi referenced in function _ENGINE_load_builtin_engines out32.dbg\openssl.exe : fatal error LNK1120: 3 unresolved externals NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\BIN\link.EXE"' : return code '0x460' Stop. With : PERL Configure no-engine VC-WIN32 --debug --prefix=c:\OpenSSL_11_dbg it fails with : E:\openssl-1.1.git\include\openssl/engine.h(70) : fatal error C1189: #error : ENGINE is disabled. With just : "VC-WIN32 --debug --prefix=. " options, build succeeds. Regards, Michel. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Wed Feb 10 22:47:40 2016 From: rt at openssl.org (Stephen Henson via RT) Date: Wed, 10 Feb 2016 22:47:40 +0000 Subject: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format In-Reply-To: References: Message-ID: On Wed Feb 10 21:59:12 2016, bcristi at gmail.com wrote: > Version: "OpenSSL 1.1.0-pre2 (alpha) 14 Jan 2016" > > Command: "openssl x509 -inform der -in sample_ekcert.der" > > Result: > "unable to load certificate > 140618483803816:error:0D0E20DD:asn1 encoding routines:c2i_ibuf:illegal > padding:a_int.c:223: > 140618483803816:error:0D08303A:asn1 encoding > routines:asn1_template_noexp_d2i:nested asn1 > error:tasn_dec.c:648:Field=serialNumber, Type=X509_CINF > 140618483803816:error:0D08303A:asn1 encoding > routines:asn1_template_noexp_d2i:nested asn1 > error:tasn_dec.c:648:Field=cert_info, Type=X509" > As the error is suggesting it doesn't like the serialNumber in the certificate. If you check it with asn1parse it says "BAD INTEGER". Using dumpasn1 you get: 13 20: INTEGER 00 59 DF E1 E2 94 81 88 77 C5 3E E2 D3 2F 2B A2 BB 5F EB DA : Error: Integer '00 59 ...' has non-DER encoding. The problem is that is an invalid encoding. An ASN.1 INTEGER cannot contain leading zeroes. OpenSSL 1.0.2 and earlier tolerated this but 1.1.0 is stricter. What was the certificate generated with? Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4301 Please log in as guest with password guest if prompted From rt at openssl.org Thu Feb 11 07:11:17 2016 From: rt at openssl.org (Cristian Berneanu via RT) Date: Thu, 11 Feb 2016 07:11:17 +0000 Subject: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format In-Reply-To: References: Message-ID: This is the Endorsement Key certificate extracted from a TPM device. On Thu, Feb 11, 2016 at 12:47 AM, Stephen Henson via RT wrote: > On Wed Feb 10 21:59:12 2016, bcristi at gmail.com wrote: > > Version: "OpenSSL 1.1.0-pre2 (alpha) 14 Jan 2016" > > > > Command: "openssl x509 -inform der -in sample_ekcert.der" > > > > Result: > > "unable to load certificate > > 140618483803816:error:0D0E20DD:asn1 encoding routines:c2i_ibuf:illegal > > padding:a_int.c:223: > > 140618483803816:error:0D08303A:asn1 encoding > > routines:asn1_template_noexp_d2i:nested asn1 > > error:tasn_dec.c:648:Field=serialNumber, Type=X509_CINF > > 140618483803816:error:0D08303A:asn1 encoding > > routines:asn1_template_noexp_d2i:nested asn1 > > error:tasn_dec.c:648:Field=cert_info, Type=X509" > > > > As the error is suggesting it doesn't like the serialNumber in the > certificate. > If you check it with asn1parse it says "BAD INTEGER". Using dumpasn1 you > get: > > 13 20: INTEGER 00 59 DF E1 E2 94 81 88 77 C5 3E E2 D3 2F 2B A2 BB 5F EB DA > : Error: Integer '00 59 ...' has non-DER encoding. > > > The problem is that is an invalid encoding. An ASN.1 INTEGER cannot contain > leading zeroes. OpenSSL 1.0.2 and earlier tolerated this but 1.1.0 is > stricter. > > What was the certificate generated with? > > Steve. > -- > Dr Stephen N. Henson. OpenSSL project core developer. > Commercial tech support now available see: http://www.openssl.org > > -- > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4301 > Please log in as guest with password guest if prompted > > -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4301 Please log in as guest with password guest if prompted From rt at openssl.org Thu Feb 11 08:01:07 2016 From: rt at openssl.org (Dannhauer Torben via RT) Date: Thu, 11 Feb 2016 08:01:07 +0000 Subject: [openssl-dev] [openssl.org #4289] OpenSSL 1.0.2f serious bug in Win32 makefiles, easy to fix, solution provided In-Reply-To: References: <6437c65f043f4f66b4b01a7930000a29@pmuex06.pmu.local> <56B227BC.2020909@dancingdragon.be> <56B257F6.7060101@dancingdragon.be> <2fff15c8a72742c88f15bced48195faa@usma1ex-dag1mb1.msg.corp.akamai.com> <56B27599.6090509@openssl.org> Message-ID: What is the status of this bug? Will it be fixed in the next release (1.0.2f /1.1.0) ? Thanks, Torben -----Urspr?ngliche Nachricht----- Von: Matt Caswell via RT [mailto:rt at openssl.org] Gesendet: Mittwoch, 3. Februar 2016 22:48 An: Dannhauer Torben Cc: openssl-dev at openssl.org Betreff: Re: [openssl-dev] [openssl.org #4289] OpenSSL 1.0.2f serious bug in Win32 makefiles, easy to fix, solution provided On 03/02/16 19:43, Salz, Rich via RT wrote: >> The diff works perfectly on master, but exposed a new bug (bare snprintf). >> The following patch fixes it. I can make a PR (or add it to my >> existing PR #512) if you'd like. > > Please do as a separate PR. Thanks. I think Richard is already on the case, so no need for a PR. Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4289 Please log in as guest with password guest if prompted From rt at openssl.org Thu Feb 11 08:32:57 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Thu, 11 Feb 2016 08:32:57 +0000 Subject: [openssl-dev] [openssl.org #4289] OpenSSL 1.0.2f serious bug in Win32 makefiles, easy to fix, solution provided In-Reply-To: References: <6437c65f043f4f66b4b01a7930000a29@pmuex06.pmu.local> <56B227BC.2020909@dancingdragon.be> <56B27599.6090509@openssl.org> Message-ID: > What is the status of this bug? Will it be fixed in the next release (1.0.2f > /1.1.0) ? yes -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4289 Please log in as guest with password guest if prompted From rt at openssl.org Thu Feb 11 08:33:58 2016 From: rt at openssl.org (Dannhauer Torben via RT) Date: Thu, 11 Feb 2016 08:33:58 +0000 Subject: [openssl-dev] [openssl.org #4289] OpenSSL 1.0.2f serious bug in Win32 makefiles, easy to fix, solution provided In-Reply-To: References: <6437c65f043f4f66b4b01a7930000a29@pmuex06.pmu.local> <56B227BC.2020909@dancingdragon.be> Message-ID: Thanks! -----Urspr?ngliche Nachricht----- Von: Salz, Rich via RT [mailto:rt at openssl.org] Gesendet: Donnerstag, 11. Februar 2016 09:33 An: Dannhauer Torben Cc: openssl-dev at openssl.org Betreff: RE: [openssl-dev] [openssl.org #4289] OpenSSL 1.0.2f serious bug in Win32 makefiles, easy to fix, solution provided > What is the status of this bug? Will it be fixed in the next release (1.0.2f > /1.1.0) ? yes -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4289 Please log in as guest with password guest if prompted -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4289 Please log in as guest with password guest if prompted From deengert at gmail.com Thu Feb 11 13:52:26 2016 From: deengert at gmail.com (Douglas E Engert) Date: Thu, 11 Feb 2016 07:52:26 -0600 Subject: [openssl-dev] [openssl.org #4266] OpenSSL-1.1-pre2 cms can not use engine with parameters to sign cms msg In-Reply-To: References: <56A2D596.8020805@gmail.com> Message-ID: <56BC921A.30000@gmail.com> Any chance these changes to req.c and cms.c will make into 1.1-pre3? They fix a regression in functionality. req and cms worked in previous versions. req and cms are not usable in 1.1 with an engine for a smart card. The "See 4226" should be #4246 On 1/22/2016 7:29 PM, deengert at gmail.com via RT wrote: > The inkey parameter of the cms command does not does not accept parameters for an engine to sign the message. > > P.S. Also attached are the changes for req.c. to use the key to hold engine parameters. See #4226 > > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -- Douglas E. Engert From rt at openssl.org Thu Feb 11 13:52:40 2016 From: rt at openssl.org (deengert@gmail.com via RT) Date: Thu, 11 Feb 2016 13:52:40 +0000 Subject: [openssl-dev] [openssl.org #4266] OpenSSL-1.1-pre2 cms can not use engine with parameters to sign cms msg In-Reply-To: <56BC921A.30000@gmail.com> References: <56A2D596.8020805@gmail.com> <56BC921A.30000@gmail.com> Message-ID: Any chance these changes to req.c and cms.c will make into 1.1-pre3? They fix a regression in functionality. req and cms worked in previous versions. req and cms are not usable in 1.1 with an engine for a smart card. The "See 4226" should be #4246 On 1/22/2016 7:29 PM, deengert at gmail.com via RT wrote: > The inkey parameter of the cms command does not does not accept parameters for an engine to sign the message. > > P.S. Also attached are the changes for req.c. to use the key to hold engine parameters. See #4226 > > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -- Douglas E. Engert -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4266 Please log in as guest with password guest if prompted From ca+ssl-dev at esmtp.org Thu Feb 11 13:54:07 2016 From: ca+ssl-dev at esmtp.org (Claus Assmann) Date: Thu, 11 Feb 2016 05:54:07 -0800 Subject: [openssl-dev] OPENSSL_INIT_new(): malloc() Message-ID: <20160211135407.GA4043@x2.esmtp.org> commit 7253fd550c768979ecd3df8f4dbbedd6e9dd76b0 diff --git a/crypto/conf/conf_lib.c b/crypto/conf/conf_lib.c +/* + * These routines call the C malloc/free, to avoid intermixing with + * OpenSSL function pointers before the library is initialized. + */ +OPENSSL_INIT_SETTINGS *OPENSSL_INIT_new(void) +{ + OPENSSL_INIT_SETTINGS *ret = malloc(sizeof(*ret)); + + memset(ret, 0, sizeof(*ret)); If that's a "normal" malloc(), couldn't it return NULL? Should that be checked? From rt at openssl.org Thu Feb 11 14:36:00 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 11 Feb 2016 14:36:00 +0000 Subject: [openssl-dev] [openssl.org #2275] CVS HEAD: BIO b_sock: ioctl(FIONBIO) is not available everywhere; completed BIO_socket_nbio() so the #ifdef clutter in apps/* and other spots can be discarded after this In-Reply-To: References: Message-ID: Great, thanks for doing this Joey! Commit 27f172d -- Rich Salz, OpenSSL dev team; rsalz at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2275 Please log in as guest with password guest if prompted From rt at openssl.org Thu Feb 11 14:39:45 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Thu, 11 Feb 2016 14:39:45 +0000 Subject: [openssl-dev] [openssl.org #2275] CVS HEAD: BIO b_sock: ioctl(FIONBIO) is not available everywhere; completed BIO_socket_nbio() so the #ifdef clutter in apps/* and other spots can be discarded after this In-Reply-To: <516f3ccf95544a0f93dbc9ef3bfb7a58@ustx2ex-dag1mb1.msg.corp.akamai.com> References: <516f3ccf95544a0f93dbc9ef3bfb7a58@ustx2ex-dag1mb1.msg.corp.akamai.com> Message-ID: So now you want to open a PR to fix apps/s_client,server? :) -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2275 Please log in as guest with password guest if prompted From rt at openssl.org Thu Feb 11 16:08:58 2016 From: rt at openssl.org (Stephen Henson via RT) Date: Thu, 11 Feb 2016 16:08:58 +0000 Subject: [openssl-dev] [openssl.org #4266] OpenSSL-1.1-pre2 cms can not use engine with parameters to sign cms msg In-Reply-To: <56A2D596.8020805@gmail.com> References: <56A2D596.8020805@gmail.com> Message-ID: Now applied as commit 43db7aa2de68e0 Thanks for the report, Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4266 Please log in as guest with password guest if prompted From rt at openssl.org Thu Feb 11 17:21:06 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 11 Feb 2016 17:21:06 +0000 Subject: [openssl-dev] [openssl.org #3495] Enhance SSL_load_client_CA_file In-Reply-To: <53F59F1D.6030800@cybozu.co.jp> References: <53F59F1D.6030800@cybozu.co.jp> Message-ID: Thanks for your patience :) This is checked into master, for part of the next release. Commit 7823d792d0cad3b44ad5389a8d3381becefe7f44 -- Rich Salz, OpenSSL dev team; rsalz at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3495 Please log in as guest with password guest if prompted From beldmit at gmail.com Thu Feb 11 17:28:31 2016 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Thu, 11 Feb 2016 20:28:31 +0300 Subject: [openssl-dev] Commit 17a723885e8a875fc19d5140f580f80a113ba78f Message-ID: Hello all, Does the code added by the commit 17a723885e8a875fc19d5140f580f80a113ba78f + switch (EVP_PKEY_id(pk)) { + default: + return -1; + case EVP_PKEY_RSA: + return SSL_PKEY_RSA_ENC; + case EVP_PKEY_DSA: + return SSL_PKEY_DSA_SIGN; with leading 'default' label work correctly? Thank you! -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Thu Feb 11 17:30:08 2016 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 11 Feb 2016 17:30:08 +0000 Subject: [openssl-dev] Commit 17a723885e8a875fc19d5140f580f80a113ba78f In-Reply-To: References: Message-ID: <09b92a31d4034dcaa3352b04acb45a17@ustx2ex-dag1mb1.msg.corp.akamai.com> > with leading 'default' label work correctly? Yes, the order of case labels doesn't matter. (In fact, it used to be the case that compilers -- back in the stone age, when they generated code on stone tablets -- used to be a little more efficient when you did that.) From beldmit at gmail.com Thu Feb 11 17:37:05 2016 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Thu, 11 Feb 2016 20:37:05 +0300 Subject: [openssl-dev] Endianess info Message-ID: Hello OpenSSL Team, Is the endianess information available in any of installed by the 1.1.0 version *.h files? All the other necessary for building an algorithms-providing engine outside of the openssl source tree can be found in the opensslconf.h file. Thank you! -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From beldmit at gmail.com Thu Feb 11 17:37:58 2016 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Thu, 11 Feb 2016 20:37:58 +0300 Subject: [openssl-dev] Commit 17a723885e8a875fc19d5140f580f80a113ba78f In-Reply-To: <09b92a31d4034dcaa3352b04acb45a17@ustx2ex-dag1mb1.msg.corp.akamai.com> References: <09b92a31d4034dcaa3352b04acb45a17@ustx2ex-dag1mb1.msg.corp.akamai.com> Message-ID: Dear Rich, On Thu, Feb 11, 2016 at 8:30 PM, Salz, Rich wrote: > > with leading 'default' label work correctly? > > Yes, the order of case labels doesn't matter. (In fact, it used to be the > case that compilers -- back in the stone age, when they generated code on > stone tablets -- used to be a little more efficient when you did that.) > Thank you! I was sure from the ancient times that the 'default' label should be the last one... -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Thu Feb 11 17:39:24 2016 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 11 Feb 2016 17:39:24 +0000 Subject: [openssl-dev] Endianess info In-Reply-To: References: Message-ID: <916a024a242a4fcb934411b4051965cc@ustx2ex-dag1mb1.msg.corp.akamai.com> > Is the endianess information available in any of installed by the 1.1.0 version *.h files? > All the other necessary for building an algorithms-providing engine outside of the openssl source tree can be found in the opensslconf.h file. No, but that's an excellent idea. Which #define do you need "moved" from an existing header file? From rt at openssl.org Thu Feb 11 17:41:59 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 11 Feb 2016 17:41:59 +0000 Subject: [openssl-dev] [openssl.org #4181] Error building openssl with REF_PRINT In-Reply-To: References: Message-ID: fixed in master at commit f3f1cf8444f439c0be9de04bf3821a20d00fd956 thanks! -- Rich Salz, OpenSSL dev team; rsalz at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4181 Please log in as guest with password guest if prompted From beldmit at gmail.com Thu Feb 11 17:44:31 2016 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Thu, 11 Feb 2016 20:44:31 +0300 Subject: [openssl-dev] Endianess info In-Reply-To: <916a024a242a4fcb934411b4051965cc@ustx2ex-dag1mb1.msg.corp.akamai.com> References: <916a024a242a4fcb934411b4051965cc@ustx2ex-dag1mb1.msg.corp.akamai.com> Message-ID: Hello Rich, On Thu, Feb 11, 2016 at 8:39 PM, Salz, Rich wrote: > > Is the endianess information available in any of installed by the 1.1.0 > version *.h files? > > All the other necessary for building an algorithms-providing engine > outside of the openssl source tree can be found in the opensslconf.h file. > > No, but that's an excellent idea. Which #define do you need "moved" from > an existing header file? > I need the L_ENDIAN #define. Thank you! -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Thu Feb 11 17:58:05 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 11 Feb 2016 17:58:05 +0000 Subject: [openssl-dev] [openssl.org #3647] Remove Heartbeat Extension entirely In-Reply-To: <54AF17BA.9030902@azet.org> References: <54AF17BA.9030902@azet.org> Message-ID: fixed with 22e3dcb7808bb06cd18c3231e34a5930e796cc48 in master. thanks. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3647 Please log in as guest with password guest if prompted From openssl-users at dukhovni.org Thu Feb 11 18:29:45 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 11 Feb 2016 13:29:45 -0500 Subject: [openssl-dev] Commit 17a723885e8a875fc19d5140f580f80a113ba78f In-Reply-To: <09b92a31d4034dcaa3352b04acb45a17@ustx2ex-dag1mb1.msg.corp.akamai.com> References: <09b92a31d4034dcaa3352b04acb45a17@ustx2ex-dag1mb1.msg.corp.akamai.com> Message-ID: <8D5E8E14-68EA-431E-BD97-AF71E1DB1BBF@dukhovni.org> > On Feb 11, 2016, at 12:30 PM, Salz, Rich wrote: > > Yes, the order of case labels doesn't matter. (In fact, it used to be the case that compilers -- back in the stone age, when they generated code on stone tablets -- used to be a little more efficient when you did that.) I find "default:" first easier to read in some cases, you immediately know that the default case is handled and how, without having to read all the other cases and hunt for it further down, especially in large switches with lots of cases. I don't always put "default:" first, and never for any reasons of possible efficiency, but I do it when it seems more clear and I remember that I find it more clear. :-) -- Viktor. From openssl-users at dukhovni.org Thu Feb 11 18:34:23 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 11 Feb 2016 13:34:23 -0500 Subject: [openssl-dev] Endianess info In-Reply-To: References: Message-ID: <01211512-9FD0-46D1-AC66-262D0DE8C5F7@dukhovni.org> > On Feb 11, 2016, at 12:37 PM, Dmitry Belyavsky wrote: > > Is the endianess information available in any of installed by the 1.1.0 version *.h files? > All the other necessary for building an algorithms-providing engine outside of the openssl source tree can be found in the opensslconf.h file. Are there any exotic platforms where the same header files might be used to build executables with either endianness? If so, the public header files should not "pin" the endianness, just like they should not "pin" the machine ABI (32-bit vs. 64-bit, ...). I don't recall whether any such platforms still exist and are supported. -- Viktor. From rsalz at akamai.com Thu Feb 11 18:35:01 2016 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 11 Feb 2016 18:35:01 +0000 Subject: [openssl-dev] Endianess info In-Reply-To: References: <916a024a242a4fcb934411b4051965cc@ustx2ex-dag1mb1.msg.corp.akamai.com> Message-ID: <99afdfcb258649e7b4a8fb61c1f7543d@ustx2ex-dag1mb1.msg.corp.akamai.com> Does this patch work for you? ; git diff diff --git a/Configure b/Configure index 3dc6a42..b36bc32 100755 --- a/Configure +++ b/Configure @@ -1553,6 +1553,8 @@ foreach (grep /_asm_src$/, keys %target) { ($target{$obj} = $target{$src}) =~ s/\.[csS]\b/.o/g; } +$config{lendian} = $config{cflags} =~ /-DL_ENDIAN/ ? 'define' : 'undef'; + # Write down our configuration where it fits ######################### open(OUT,">configdata.pm") || die "unable to create configdata.pm: $!\n"; diff --git a/include/openssl/opensslconf.h.in b/include/openssl/opensslconf.h.in index d9f6429..9dc547f 100644 --- a/include/openssl/opensslconf.h.in +++ b/include/openssl/opensslconf.h.in @@ -122,6 +122,8 @@ EOF /* Generate 80386 code? */ {- $config{processor} eq "386" ? "#define" : "#undef" -} I386_ONLY +/* Big or little endian? */ +{- $config{lendian} eq "define" ? "#define" : "#undef" -} OPENSSL_LITTLE_ENDIAN #undef OPENSSL_UNISTD #define OPENSSL_UNISTD {- $target{unistd} -} -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz From: Dmitry Belyavsky [mailto:beldmit at gmail.com] Sent: Thursday, February 11, 2016 12:45 PM To: openssl-dev at openssl.org Subject: Re: [openssl-dev] Endianess info Hello Rich, On Thu, Feb 11, 2016 at 8:39 PM, Salz, Rich > wrote: > Is the endianess information available in any of installed by the 1.1.0 version *.h files? > All the other necessary for building an algorithms-providing engine outside of the openssl source tree can be found in the opensslconf.h file. No, but that's an excellent idea. Which #define do you need "moved" from an existing header file? I need the L_ENDIAN #define. Thank you! -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From beldmit at gmail.com Thu Feb 11 19:12:33 2016 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Thu, 11 Feb 2016 22:12:33 +0300 Subject: [openssl-dev] Endianess info In-Reply-To: <99afdfcb258649e7b4a8fb61c1f7543d@ustx2ex-dag1mb1.msg.corp.akamai.com> References: <916a024a242a4fcb934411b4051965cc@ustx2ex-dag1mb1.msg.corp.akamai.com> <99afdfcb258649e7b4a8fb61c1f7543d@ustx2ex-dag1mb1.msg.corp.akamai.com> Message-ID: Dear Rich, Thank you! I'll test it during the weekend. On Thu, Feb 11, 2016 at 9:35 PM, Salz, Rich wrote: > Does this patch work for you? > > ; git diff > > diff --git a/Configure b/Configure > > index 3dc6a42..b36bc32 100755 > > --- a/Configure > > +++ b/Configure > > @@ -1553,6 +1553,8 @@ foreach (grep /_asm_src$/, keys %target) { > > ($target{$obj} = $target{$src}) =~ s/\.[csS]\b/.o/g; > > } > > > > +$config{lendian} = $config{cflags} =~ /-DL_ENDIAN/ ? 'define' : 'undef'; > > + > > # Write down our configuration where it fits ######################### > > > > open(OUT,">configdata.pm") || die "unable to create configdata.pm: $!\n"; > > diff --git a/include/openssl/opensslconf.h.in b/include/openssl/ > opensslconf.h.in > > index d9f6429..9dc547f 100644 > > --- a/include/openssl/opensslconf.h.in > > +++ b/include/openssl/opensslconf.h.in > > @@ -122,6 +122,8 @@ EOF > > > > /* Generate 80386 code? */ > > {- $config{processor} eq "386" ? "#define" : "#undef" -} I386_ONLY > > +/* Big or little endian? */ > > +{- $config{lendian} eq "define" ? "#define" : "#undef" -} > OPENSSL_LITTLE_ENDIAN > > > > #undef OPENSSL_UNISTD > > #define OPENSSL_UNISTD {- $target{unistd} -} > > > > -- > > Senior Architect, Akamai Technologies > > IM: richsalz at jabber.at Twitter: RichSalz > > > > *From:* Dmitry Belyavsky [mailto:beldmit at gmail.com] > *Sent:* Thursday, February 11, 2016 12:45 PM > *To:* openssl-dev at openssl.org > *Subject:* Re: [openssl-dev] Endianess info > > > > Hello Rich, > > > > > > > > On Thu, Feb 11, 2016 at 8:39 PM, Salz, Rich wrote: > > > Is the endianess information available in any of installed by the 1.1.0 > version *.h files? > > All the other necessary for building an algorithms-providing engine > outside of the openssl source tree can be found in the opensslconf.h file. > > No, but that's an excellent idea. Which #define do you need "moved" from > an existing header file? > > > > I need the L_ENDIAN #define. > > > > Thank you! > > > > -- > > 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 uri at ll.mit.edu Thu Feb 11 19:25:54 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Thu, 11 Feb 2016 19:25:54 +0000 Subject: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format Message-ID: >On Thu, Feb 11, 2016 at 12:47 AM, Stephen Henson via RT >wrote: >>On Wed Feb 10 21:59:12 2016, bcristi at gmail.com wrote: >>As the error is suggesting it doesn't like the serialNumber in the >>certificate. >> If you check it with asn1parse it says "BAD INTEGER". Using dumpasn1 you >> get: >> >> 13 20: INTEGER 00 59 DF E1 E2 94 81 88 77 C5 3E E2 D3 2F 2B A2 BB 5F EB >>DA >> : Error: Integer '00 59 ...' has non-DER encoding. ^^^^^ Probably correct IN THIS ONE CASE, because Most Significant Bit is zero even without the leading zero byte. See below. >>The problem is that is an invalid encoding. An ASN.1 INTEGER cannot >>contain >> leading zeroes. I?m pretty sure this is not correct. It?s been a while since I touched ASN.1, but I had quite a bit of experience with it back when. SO first of all, could you please cite your (authoritative) sources stating that an ASN.1 DER_encoded INTEGER cannot have leading zero. Here?s what others had to say about this: The private key values are encoded as ASN.1 INTEGERs, which are signed values in two's complement format. The leading zero byte is necessary when the MSB of the (unsigned) RSA key value is set. Having the MSB set without a leading zero byte would mean a negative value. The ASN.1 specs are free and are linked from Wikipedia . The relevant section here is in X.690, "8.3 Encoding of an integer value?. In short, the problem is that without that leading zero there is no way to tell a negative integer from a positive integer. Here?s how the *current* OSS Nokalva ASN.1 compiler DER-encodes integers. First, the ASN.1 spec (had to wrap in a sequence to avoid jostling with the compiler, as I don?t remember how to write definitions of single primitive types) World-Schema DEFINITIONS AUTOMATIC TAGS ::= BEGIN Tst ::= SEQUENCE { value INTEGER (-256..257) } END And playing with different integer values in the given range: my-tst Tst ::= { value 127 } Encodes to 3003 02017F (relevant parts: tag 02, len 01, value 7f) However this: my-tst Tst ::= { value 128 } Encodes to 3004 02020080 (integer tag 02, len *02*, and value 00 80) and for a VERY good reason! If you try to decode the following 3003020180 (what you seem to suggest - the number without the leading zero) you get: ASN1STEP: Decoding PDU #1 : Tst SEQUENCE: tag = [UNIVERSAL 16] constructed; length = 3 value INTEGER: tag = [UNIVERSAL 2] primitive; length = 1 -128 Successfully decoded 5 bytes. rec1value Tst ::= { value -128 } Notice that minus. >>OpenSSL 1.0.2 and earlier tolerated this but 1.1.0 is stricter. I say OpenSSL-1.1 got this wrong, and needs to be fixed. P.S. Sticking the value of the integer provided provided by Cristian into OSS ASN.1 DER decoder gave: OSS ASN-1Step Version 7.1 Copyright (C) 2014 OSS Nokalva, Inc. All rights reserved. This product is licensed for use by "OSS Nokalva, Inc." C0043I: 0 error messages, 0 warning messages and 0 informatory messages issued. ASN1STEP: Decoding PDU #1 : Tst SEQUENCE: tag = [UNIVERSAL 16] constructed; length = 22 D0022E: Integer or enumerated value needlessly long; check field 'value' (type: INTEGER) of PDU #1 'Tst'. D0023E: Integer or enumerated value too long: 19; check field 'value' (type: INTEGER) of PDU #1 'Tst'. value INTEGER: tag = [UNIVERSAL 2] primitive; length = 20 2147483647 S0012E: Decoding of PDU #1 failed with the return code '5'. Trimming the leading zero from the value (as for *this* particular integer value that zero is not needed to disambiguate between + and -): OSS ASN-1Step Version 7.1 Copyright (C) 2014 OSS Nokalva, Inc. All rights reserved. This product is licensed for use by "OSS Nokalva, Inc." C0043I: 0 error messages, 0 warning messages and 0 informatory messages issued. ASN1STEP: Decoding PDU #1 : Tst SEQUENCE: tag = [UNIVERSAL 16] constructed; length = 21 D0023E: Integer or enumerated value too long: 19; check field 'value' (type: INTEGER) of PDU #1 'Tst'. value INTEGER: tag = [UNIVERSAL 2] primitive; length = 19 2147483647 S0012E: Decoding of PDU #1 failed with the return code '10'. The following might also be useful (attempting to encode/decode integer value 128). Schema World-Schema DEFINITIONS AUTOMATIC TAGS ::= BEGIN Human ::= INTEGER (0..257) END Data: 020180 Decoding: OSS ASN-1Step Version 7.1 Copyright (C) 2014 OSS Nokalva, Inc. All rights reserved. This product is licensed for use by "OSS Nokalva, Inc." C0043I: 0 error messages, 0 warning messages and 0 informatory messages issued. ASN1STEP: Decoding PDU #1 : D0076S: A negative unsigned integer encountered; check PDU #1 'Human'. S0012E: Decoding of PDU #1 failed with the return code '2'. The error is correct: decoded value by the rules of decoding is negative, but the type restriction said it had to be unsigned, aka non-negative. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4324 bytes Desc: not available URL: From rsalz at akamai.com Thu Feb 11 19:29:37 2016 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 11 Feb 2016 19:29:37 +0000 Subject: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format In-Reply-To: References: Message-ID: <6acb60f986d34dee8282c902fac6d3b0@ustx2ex-dag1mb1.msg.corp.akamai.com> If arbitrary leading zero's were allowed in DER, then the encoding wouldn't be *distinguished*, i.e., unique. In BER, almost anything goes :) From uri at ll.mit.edu Thu Feb 11 19:37:18 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Thu, 11 Feb 2016 19:37:18 +0000 Subject: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format In-Reply-To: <6acb60f986d34dee8282c902fac6d3b0@ustx2ex-dag1mb1.msg.corp.akamai.com> References: <6acb60f986d34dee8282c902fac6d3b0@ustx2ex-dag1mb1.msg.corp.akamai.com> Message-ID: On 2/11/16, 14:29 , "openssl-dev on behalf of Salz, Rich" wrote: >If arbitrary leading zero's were allowed in DER, then the encoding >wouldn't be *distinguished*, i.e., unique. I am NOT talking about ?arbitrary? leading zeros. I explicitly state (and cite the sources, might add the ASN.1 standard itself, and ?ASN.1 Complete? by John Larmouth) that a leading zero *is* necessary and required for a positive integer when its MSB is one (e.g., 0x80). In other cases it indeed does not belong. >In BER, almost anything goes :) We are *explicitly* and *exclusively* discussing DER. Anything goes for Bear. :-) P.S. In the integer value provided by Cristian, indeed the MSB was 0 (the first ?valuable? byte was 0x59), so the leading zero byte did not belong. But I hope OpenSSL-1.1 would properly process 0x02020080. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4324 bytes Desc: not available URL: From valerie.fenwick at oracle.com Thu Feb 11 19:43:22 2016 From: valerie.fenwick at oracle.com (Valerie Anne Fenwick) Date: Thu, 11 Feb 2016 11:43:22 -0800 Subject: [openssl-dev] [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <3CB9005A-76B1-4F42-BA72-DE46AB82C27D@akamai.com> References: <1770293.ATZhSyddb0@pintsize.usersys.redhat.com> <564CB19B.6050605@akamai.com> <3CB9005A-76B1-4F42-BA72-DE46AB82C27D@akamai.com> Message-ID: <56BCE45A.4000904@oracle.com> Sorry to revive this old thread, I did not see any recent updates. If there are - please point me that way, and apologies in advance. I saw a reference to SunOS libc compatibility issues, implying we never remove functionality. I want to be clear - we do. We do it by giving our customers advanced notice, and typically only do so in a "minor" release (using SunOS version numbering, 5.9, 5.10 and 5.11 were "minor" releases. 5.10.1 (or S10U1) was an update/patch release). We give the customers advance notice, and typically continue to support the feature on the currently released OS and it's updates, and remove it from the next minor. For example, all S10 updates may still support the feature, and it disappeared in S11. As others have noted, it is impossible to maintain all code forever. It will create bugs. I removed the "crypt(1)" command from Solaris 11, and "vi -x / -C" options as well, because they were based on the ENIGMA rotor. VERY insecure. We gave notice, told customers they should switch to our new encrypt(1) command (which had AES available) and made the move. I like Todd's suggestion (someone else made a similar one, too), but would take it a step further and prehaps only allow decryption/ verification with these old algorithms when enabled. (if possible) You can see some crypto related EOF announcements for Solaris here: http://www.oracle.com/technetwork/systems/end-of-notices/eonsolaris11-392732.html Thanks Valerie On 11/20/15 02:26 PM, Short, Todd wrote: > While I am all for simplicity, I also think that removing functionality is a ?bad idea?. > > To reduce the support burden, deprecate the ciphers: > 1. Under support, indicate that these ciphers will no longer receive fixes. > 2. Remove any assembly implementations > 3. Disable them by default. > > I suggest following the 80/20 rule (sometimes the 95/5 rule): > > Those ?who care? (the minority) about the ciphers can re-enable them and rebuild the > library. > Those ?who don?t care? (the majority) about the ciphers, should get the functionality > that most people care about, basically SSL/TLS connectivity. > > -- > -Todd Short > // tshort at akamai.com > // "One if by land, two if by sea, three if by the Internet." > > -- > -Todd Short > // tshort at akamai.com > // "One if by land, two if by sea, three if by the Internet." > >> On Nov 18, 2015, at 1:52 PM, Blumenthal, Uri - 0553 - MITLL > > wrote: >> >> On 11/18/15, 12:12 , "openssl-dev on behalf of Benjamin Kaduk" >> on behalf of >> bkaduk at akamai.com > wrote: >> >>> On 11/18/2015 07:05 AM, Hubert Kario wrote: >>>> So, a full CAdES-A, XAdES-A or PAdES-A implementation _needs_ to >>>> support >>>> both relatively modern TLS with user certificates, preferably the >>>> newest >>>> cryptosystems and hashes as well as the oldest ones that were >>>> standardised and used. >>>> >>>> That means that old algorithms MUST remain in OpenSSL as supported >>>> functionality. It may require linking to a specific library to make the >>>> EVP* with old ciphers, MACs, etc. work, but they MUST NOT be removed >>>> from it completely, definitely not before at least 50 years _after_ >>>> they >>>> became obsolete and broken. >>> >>> There seems to be a logical leap between these two paragraphs. Why is >>> it necessary that OpenSSL be the only cryptographic library used by >>> CAdES-A/etc. implementations? >> >> Because it used to be the only real game in town, and *people learned to >> rely upon it*. >> >>> Is it in fact even necessary that only a >>> single version of a single cryptographic library be used for such >>> software? >> >> No, of course not. But after letting people depend on this ?single >> cryptographic library? for many years, telling them ?too bad? isn?t very >> nice. >> >>> While OpenSSL may try to be a general-purpose crypto library, >>> when a software has stringent or unusual crypto requirements, it seems >>> reasonable that such a software may need to involve unusual >>> implementations. >> >> The requirements did not change. What changed was the maintainers >> expressing their desire to stop supporting some of them. >> >>> I do not believe that OpenSSL has promised anywhere that it will support >>> this sort of use case. >> >> Implicitly, by providing that kind of service for so long. And explicitly, >> as pointed out by Hubert: >> >> From the main web page of project: >> >> The OpenSSL Project is a collaborative effort to develop a robust, >> commercial-grade, *full-featured*, and Open Source toolkit >> implementing the Transport Layer Security (TLS) and Secure Sockets >> Layer (SSL) protocols as well as a full-strength *general purpose* >> *cryptography library* . >> >> _______________________________________________ >> openssl-dev mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > Valerie -- Valerie Fenwick, http://bubbva.blogspot.com/ @bubbva Solaris Cryptographic & Key Management Technologies, Manager Oracle Corporation: 4180 Network Circle, Santa Clara, CA, 95054. From uri at ll.mit.edu Thu Feb 11 19:46:36 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Thu, 11 Feb 2016 19:46:36 +0000 Subject: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format In-Reply-To: <6acb60f986d34dee8282c902fac6d3b0@ustx2ex-dag1mb1.msg.corp.akamai.com> References: <6acb60f986d34dee8282c902fac6d3b0@ustx2ex-dag1mb1.msg.corp.akamai.com> Message-ID: Testing the previous Github version of OpenSSL-1.1 produced encouraging results (notice the leading zero, right where it belongs): $ x=128; DYLD_LIBRARY_PATH=/Users/ur20980/src/openssl-1.1/lib ~/src/openssl-1.1/bin/openssl asn1parse -genstr "INTEGER:$x" -out d.der && hexdump -C d.der 0:d=0 hl=2 l= 2 prim: INTEGER :80 00000000 02 02 00 80 |....| 00000004 $ dumpasn1 d.der 0 2: INTEGER 128 0 warnings, 0 errors. $ P.S. dumpasn1.c doesn?t seem to parse negative integers correctly: $ x=-128; DYLD_LIBRARY_PATH=/Users/ur20980/src/openssl-1.1/lib ~/src/openssl-1.1/bin/openssl asn1parse -genstr "INTEGER:$x" -out d.der && hexdump -C d.der 0:d=0 hl=2 l= 1 prim: INTEGER :-80 00000000 02 01 80 |...| 00000003 $ dumpasn1 d.der 0 1: INTEGER 128 : Error: Integer has a negative value. 0 warnings, 1 error. $ -- Regards, Uri Blumenthal On 2/11/16, 14:29 , "openssl-dev on behalf of Salz, Rich" wrote: >If arbitrary leading zero's were allowed in DER, then the encoding >wouldn't be *distinguished*, i.e., unique. > >In BER, almost anything goes :) > >-- >openssl-dev mailing list >To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4324 bytes Desc: not available URL: From openssl-users at dukhovni.org Thu Feb 11 19:59:20 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 11 Feb 2016 14:59:20 -0500 Subject: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format In-Reply-To: References: <6acb60f986d34dee8282c902fac6d3b0@ustx2ex-dag1mb1.msg.corp.akamai.com> Message-ID: <725C911E-8CBD-43CC-9C97-A61B3DDA7A01@dukhovni.org> > On Feb 11, 2016, at 2:46 PM, Blumenthal, Uri - 0553 - MITLL wrote: > > Testing the previous Github version of OpenSSL-1.1 produced encouraging > results (notice the leading zero, right where it belongs): > > $ x=128; DYLD_LIBRARY_PATH=/Users/ur20980/src/openssl-1.1/lib > ~/src/openssl-1.1/bin/openssl asn1parse -genstr "INTEGER:$x" -out d.der && > hexdump -C d.der > 0:d=0 hl=2 l= 2 prim: INTEGER :80 > 00000000 02 02 00 80 |....| > 00000004 There's no leading zero in this example. Don't confuse zero nibbles with zero octets. -- Viktor. From rsalz at akamai.com Thu Feb 11 20:00:34 2016 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 11 Feb 2016 20:00:34 +0000 Subject: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format In-Reply-To: References: <6acb60f986d34dee8282c902fac6d3b0@ustx2ex-dag1mb1.msg.corp.akamai.com> Message-ID: > Larmouth) that a leading zero *is* necessary and required for a positive > integer when its MSB is one (e.g., 0x80). In other cases it indeed does not > belong. Agreed. Perhaps I mis-read your note. Sorry. From levitte at openssl.org Thu Feb 11 20:00:59 2016 From: levitte at openssl.org (Richard Levitte) Date: Thu, 11 Feb 2016 21:00:59 +0100 (CET) Subject: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format In-Reply-To: References: <6acb60f986d34dee8282c902fac6d3b0@ustx2ex-dag1mb1.msg.corp.akamai.com> Message-ID: <20160211.210059.1419712448595077275.levitte@openssl.org> Let's put this to rest, shall we? : ; cat > checkasn1int.sh #! /bin/sh CMD="$@" for x in "3003 02011F" \ "3003 020180" \ "3004 0202001F" \ "3004 02020080"; do echo Trying sequence $x echo $x | xxd -r -ps | $CMD done : ; sh checkasn1int.sh openssl asn1parse -inform d -i Trying sequence 3003 02011F 0:d=0 hl=2 l= 3 cons: SEQUENCE 2:d=1 hl=2 l= 1 prim: INTEGER :1F Trying sequence 3003 020180 0:d=0 hl=2 l= 3 cons: SEQUENCE 2:d=1 hl=2 l= 1 prim: INTEGER :-80 Trying sequence 3004 0202001F 0:d=0 hl=2 l= 4 cons: SEQUENCE 2:d=1 hl=2 l= 2 prim: INTEGER :1F Trying sequence 3004 02020080 0:d=0 hl=2 l= 4 cons: SEQUENCE 2:d=1 hl=2 l= 2 prim: INTEGER :80 : ; openssl version OpenSSL 1.0.2f 28 Jan 2016 : ; sh checkasn1int.sh util/shlib_wrap.sh apps/openssl asn1parse -inform d -i Trying sequence 3003 02011F 0:d=0 hl=2 l= 3 cons: SEQUENCE 2:d=1 hl=2 l= 1 prim: INTEGER :1F Trying sequence 3003 020180 0:d=0 hl=2 l= 3 cons: SEQUENCE 2:d=1 hl=2 l= 1 prim: INTEGER :-80 Trying sequence 3004 0202001F 0:d=0 hl=2 l= 4 cons: SEQUENCE 2:d=1 hl=2 l= 2 prim: INTEGER :BAD INTEGER:[001F] Trying sequence 3004 02020080 0:d=0 hl=2 l= 4 cons: SEQUENCE 2:d=1 hl=2 l= 2 prim: INTEGER :80 : ; util/shlib_wrap.sh apps/openssl version OpenSSL 1.1.0-pre3-dev xx XXX xxxx : ; Cheers, Richard In message on Thu, 11 Feb 2016 19:37:18 +0000, "Blumenthal, Uri - 0553 - MITLL" said: uri> On 2/11/16, 14:29 , "openssl-dev on behalf of Salz, Rich" uri> wrote: uri> uri> >If arbitrary leading zero's were allowed in DER, then the encoding uri> >wouldn't be *distinguished*, i.e., unique. uri> uri> I am NOT talking about ?arbitrary? leading zeros. I explicitly state (and uri> cite the sources, might add the ASN.1 standard itself, and ?ASN.1 uri> Complete? by John Larmouth) that a leading zero *is* necessary and uri> required for a positive integer when its MSB is one (e.g., 0x80). In other uri> cases it indeed does not belong. uri> uri> >In BER, almost anything goes :) uri> uri> We are *explicitly* and *exclusively* discussing DER. Anything goes for uri> Bear. :-) uri> uri> P.S. In the integer value provided by Cristian, indeed the MSB was 0 (the uri> first ?valuable? byte was 0x59), so the leading zero byte did not belong. uri> But I hope OpenSSL-1.1 would properly process 0x02020080. From uri at ll.mit.edu Thu Feb 11 20:09:29 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Thu, 11 Feb 2016 20:09:29 +0000 Subject: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format In-Reply-To: <725C911E-8CBD-43CC-9C97-A61B3DDA7A01@dukhovni.org> References: <6acb60f986d34dee8282c902fac6d3b0@ustx2ex-dag1mb1.msg.corp.akamai.com> <725C911E-8CBD-43CC-9C97-A61B3DDA7A01@dukhovni.org> Message-ID: >>On Feb 11, 2016, at 2:46 PM, Blumenthal, Uri - 0553 - MITLL >> wrote: >> >> Testing the previous Github version of OpenSSL-1.1 produced encouraging >> results (notice the leading zero, right where it belongs): >> >> $ x=128; DYLD_LIBRARY_PATH=/Users/ur20980/src/openssl-1.1/lib >> ~/src/openssl-1.1/bin/openssl asn1parse -genstr "INTEGER:$x" -out d.der >>&& >> hexdump -C d.der >> 0:d=0 hl=2 l= 2 prim: INTEGER :80 >> 00000000 02 02 00 80 |....| ^^ this is the leading zero >There's no leading zero in this example. But there is - ?00 80? rather than ?80?. >Don't confuse zero nibbles with zero octets. Thank you, I don?t. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4324 bytes Desc: not available URL: From rt at openssl.org Thu Feb 11 20:15:59 2016 From: rt at openssl.org (Andy Polyakov via RT) Date: Thu, 11 Feb 2016 20:15:59 +0000 Subject: [openssl-dev] [openssl.org #4279] Re: [openssl.org #3885] [BUGFIX] OpenSSL fails to cross-compile on 32-bit->64-bit In-Reply-To: <56BCEBFB.9000301@openssl.org> References: <78EEA715-EF95-4B66-A71F-85D1808F3593@akamai.com> <56BCEBFB.9000301@openssl.org> Message-ID: > I have an available fix: > > https://github.com/openssl/openssl/pull/597 As per http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=fd7dc201d3b9d43972de6a0e659f7ef6421c99cc problem is addressed in a little bit alternative way. Closing ticket[s]. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4279 Please log in as guest with password guest if prompted From Erwann.Abalea at docusign.com Thu Feb 11 19:52:52 2016 From: Erwann.Abalea at docusign.com (Erwann Abalea) Date: Thu, 11 Feb 2016 19:52:52 +0000 Subject: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format In-Reply-To: References: Message-ID: <8AE49D68-F483-44A9-A92A-F480FC614325@docusign.com> Bonjour, Le 11 f?vr. 2016 ? 20:25, Blumenthal, Uri - 0553 - MITLL > a ?crit : On Thu, Feb 11, 2016 at 12:47 AM, Stephen Henson via RT > wrote: On Wed Feb 10 21:59:12 2016, bcristi at gmail.com wrote: As the error is suggesting it doesn't like the serialNumber in the certificate. If you check it with asn1parse it says "BAD INTEGER". Using dumpasn1 you get: 13 20: INTEGER 00 59 DF E1 E2 94 81 88 77 C5 3E E2 D3 2F 2B A2 BB 5F EB DA : Error: Integer '00 59 ...' has non-DER encoding. ^^^^^ Probably correct IN THIS ONE CASE, because Most Significant Bit is zero even without the leading zero byte. See below. The problem is that is an invalid encoding. An ASN.1 INTEGER cannot contain leading zeroes. I?m pretty sure this is not correct. It?s been a while since I touched ASN.1, but I had quite a bit of experience with it back when. SO first of all, could you please cite your (authoritative) sources stating that an ASN.1 DER_encoded INTEGER cannot have leading zero. Here?s what others From rt at openssl.org Thu Feb 11 20:35:00 2016 From: rt at openssl.org (Andy Polyakov via RT) Date: Thu, 11 Feb 2016 20:35:00 +0000 Subject: [openssl-dev] [openssl.org #4289] OpenSSL 1.0.2f serious bug in Win32 makefiles, easy to fix, solution provided In-Reply-To: <56BCF073.30701@openssl.org> References: <6437c65f043f4f66b4b01a7930000a29@pmuex06.pmu.local> <56B227BC.2020909@dancingdragon.be> <20160203201617.Horde.EoMOVndd8H4N65C2EUikDDP@www.dannhauer.de> <56B2561D.1080803@dancingdragon.be> <56BCF073.30701@openssl.org> Message-ID: > I verified the problem on both 1.0.2f and master: > > set LINK=/DEBUG > perl Configure VC-WIN64A > ms\do_win64a.bat > nmake -f ms\nt.make > > link /nologo /subsystem:console /opt:ref /debug > /out:out32\openssl.exe @C:\Users\oscar\AppData\Local\Temp\nm45EB.tmp > LINK : fatal error LNK1181: cannot open input file 'link.obj' > NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual > Studio 12.0\VC\BIN\amd64\link.EXE"' : return code '0x49d' Patch is applied. Closing ticket. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4289 Please log in as guest with password guest if prompted From kurt at roeckx.be Thu Feb 11 20:45:50 2016 From: kurt at roeckx.be (Kurt Roeckx) Date: Thu, 11 Feb 2016 21:45:50 +0100 Subject: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format In-Reply-To: References: Message-ID: <20160211204550.GA12903@roeckx.be> See X.690, 8.3.2: If the contents octets of an integer value encoding consist of more than one octet, then the bits of the first octet and bit 8 of the second octet: a) shall not all be ones; and b) shall not all be zero. NOTE - These rules ensure that an integer value is always encoded in the smallest possible number of octets. Kurt From rt at openssl.org Thu Feb 11 20:46:34 2016 From: rt at openssl.org (Andy Polyakov via RT) Date: Thu, 11 Feb 2016 20:46:34 +0000 Subject: [openssl-dev] [openssl.org #4237] Failed self-tests on AARCH64 (ARM64) In-Reply-To: <56BCF32A.6000603@openssl.org> References: <56BCF32A.6000603@openssl.org> Message-ID: Hi, > $ uname -a > Linux hikey 3.18.0-linaro-hikey #1 SMP PREEMPT Mon Nov 30 00:11:03 UTC > 2015 aarch64 GNU/Linux > > $ make test > ... > ../test/recipes/80-test_dane.t ............ ok > ../test/recipes/80-test_ocsp.t ............ ok > ../test/recipes/80-test_ssl.t ............. 1/43 > # Failed test 'test sslv3 with client authentication via BIO pair' > # at ../test/recipes/80-test_ssl.t line 345. > # Looks like you failed 1 test of 27. Double-check attached patch and report back, please. Cheers. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4237 Please log in as guest with password guest if prompted -------------- next part -------------- diff --git a/crypto/ec/asm/ecp_nistz256-armv8.pl b/crypto/ec/asm/ecp_nistz256-armv8.pl index 9d1bce1..ce6b69e 100644 --- a/crypto/ec/asm/ecp_nistz256-armv8.pl +++ b/crypto/ec/asm/ecp_nistz256-armv8.pl @@ -1289,6 +1289,9 @@ $code.=<<___; stp $acc0,$acc1,[$rp_real,#$i] stp $acc2,$acc3,[$rp_real,#$i+16] ___ +$code.=<<___ if ($i == 0); + adr $bp_real,.Lone_mont-64 +___ } $code.=<<___; ldp $acc0,$acc1,[$ap_real,#$i] // in1 From steve at openssl.org Thu Feb 11 21:09:58 2016 From: steve at openssl.org (Dr. Stephen Henson) Date: Thu, 11 Feb 2016 21:09:58 +0000 Subject: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format In-Reply-To: References: Message-ID: <20160211210958.GA16282@openssl.org> On Thu, Feb 11, 2016, Blumenthal, Uri - 0553 - MITLL wrote: > ^^^^^ > Probably correct IN THIS ONE CASE, because Most Significant Bit is zero > even without the leading zero byte. See below. > > >>The problem is that is an invalid encoding. An ASN.1 INTEGER cannot > >>contain > >> leading zeroes. > > I???m pretty sure this is not correct. It???s been a while since I touched > ASN.1, but I had quite a bit of experience with it back when. > I should've been a bit clearer. I should have said additional or superfluous leading zeroes which is the cases here because there is a leading zero and the MSB of the second octet is also zero. Others have referenced the relevant sections of the standards that require that. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From uri at ll.mit.edu Thu Feb 11 21:15:24 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Thu, 11 Feb 2016 21:15:24 +0000 Subject: [openssl-dev] Current Github master fails to compile/link Message-ID: ./Configure darwin64-x86_64-cc enable-rfc3779 enable-rc5 enable-md2 enable-deprecated experimental-jpake threads zlib enable-ec_nistp_64_gcc_128 shared --prefix=/Users/ur20980/src/openssl-1.1 --openssldir=/Users/ur20980/src/engines-1.1 ? LD_LIBRARY_PATH=.: clang -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_EXPERIMENTAL_JPAKE -DOPENSSL_THREADS -DZLIB -DZLIB_SHARED -DOPENSSL_PIC -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DOPENSSLDIR="/Users/ur20980/src/engines-1.1" -DENGINESDIR="/Users/ur20980/src/openssl-1.1/lib/engines" -fPIC -fno-common -D_REENTRANT -arch x86_64 -DL_ENDIAN -Wall -O3 -arch x86_64 -dynamiclib -current_version 1.1 -compatibility_version 1.1 -install_name /Users/ur20980/src/openssl-1.1/lib/libcrypto.1.1.dylib -o ./libcrypto.1.1.dylib -all_load ./libcrypto.a -L. Undefined symbols for architecture x86_64: "poly1305_blocks", referenced from: _poly1305_init in libcrypto.a(poly1305-x86_64.o) (maybe you meant: _poly1305_blocks) "poly1305_emit", referenced from: _poly1305_init in libcrypto.a(poly1305-x86_64.o) (maybe you meant: _poly1305_emit) ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make[4]: *** [link_a.darwin] Error 1 make[3]: *** [do_darwin-shared] Error 2 make[2]: *** [libcrypto.1.1.dylib] Error 2 make[1]: *** [shared] Error 2 make: *** [build_crypto] Error 1 $ -- Regards, Uri Blumenthal -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4324 bytes Desc: not available URL: From rsalz at akamai.com Thu Feb 11 21:16:25 2016 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 11 Feb 2016 21:16:25 +0000 Subject: [openssl-dev] Current Github master fails to compile/link In-Reply-To: References: Message-ID: <06c0efedc03c4e87a4ec406d48b44747@ustx2ex-dag1mb1.msg.corp.akamai.com> Yes, fixed now. From rt at openssl.org Thu Feb 11 21:16:48 2016 From: rt at openssl.org (Stephen Henson via RT) Date: Thu, 11 Feb 2016 21:16:48 +0000 Subject: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format In-Reply-To: References: Message-ID: On Thu Feb 11 07:11:17 2016, bcristi at gmail.com wrote: > This is the Endorsement Key certificate extracted from a TPM device. > Does it always do that or is this just an oddity? Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4301 Please log in as guest with password guest if prompted From uri at ll.mit.edu Thu Feb 11 21:22:54 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Thu, 11 Feb 2016 21:22:54 +0000 Subject: [openssl-dev] Current Github master fails to compile/link Message-ID: On 2/11/16, 16:16 , "openssl-dev on behalf of Salz, Rich" wrote: >Yes, fixed now. I confirm the fix. Thanks! -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4324 bytes Desc: not available URL: From rt at openssl.org Thu Feb 11 21:38:18 2016 From: rt at openssl.org (Cristian Berneanu via RT) Date: Thu, 11 Feb 2016 21:38:18 +0000 Subject: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format In-Reply-To: References: Message-ID: The EK certificate is generated and burned into the TPM during manufacturing. The extraction operation always returns the same certificate. On Thu, Feb 11, 2016 at 11:16 PM, Stephen Henson via RT wrote: > On Thu Feb 11 07:11:17 2016, bcristi at gmail.com wrote: > > This is the Endorsement Key certificate extracted from a TPM device. > > > > Does it always do that or is this just an oddity? > > Steve. > -- > Dr Stephen N. Henson. OpenSSL project core developer. > Commercial tech support now available see: http://www.openssl.org > > -- > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4301 > Please log in as guest with password guest if prompted > > -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4301 Please log in as guest with password guest if prompted From michel.sales at free.fr Thu Feb 11 22:07:25 2016 From: michel.sales at free.fr (Michel) Date: Thu, 11 Feb 2016 23:07:25 +0100 Subject: [openssl-dev] PKCS12_Parse() no longer extract certificate Message-ID: <008d01d16518$976341a0$c629c4e0$@sales@free.fr> Hi, I have a test program which is failing using version 1.1 because PKCS12_Parse() doesn't return the certificate, just the key. No error is signaled. I supposed it is not intended. Is it work in progress ? I looks the same with the command line : with 1.0.2 : openssl pkcs12 -in Certificate.p12 -clcerts Enter Import Password: MAC verified OK Bag Attributes localKeyID: 6E D1 . subject=/CN=PubKeySign Test/C=FR issuer=/CN=PubKeySign Test/C=FR -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- Bag Attributes localKeyID: 6E D1 . Key Attributes: Enter PEM pass phrase: Verifying - Enter PEM pass phrase: -----BEGIN ENCRYPTED PRIVATE KEY----- ... -----END ENCRYPTED PRIVATE KEY----- 1.1 : c:\OpenSSL_11_dbg\bin\openssl pkcs12 -in Certificate.p12 Enter Import Password: Bag Attributes localKeyID: 6E D1 . Bag Attributes localKeyID: 6E D1 . Key Attributes: Enter PEM pass phrase: Verifying - Enter PEM pass phrase: -----BEGIN ENCRYPTED PRIVATE KEY----- ... -----END ENCRYPTED PRIVATE KEY----- Regards, Michel -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Thu Feb 11 22:26:15 2016 From: rt at openssl.org (Stephen Henson via RT) Date: Thu, 11 Feb 2016 22:26:15 +0000 Subject: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format In-Reply-To: References: Message-ID: On Thu Feb 11 21:38:18 2016, bcristi at gmail.com wrote: > The EK certificate is generated and burned into the TPM during > manufacturing. The extraction operation always returns the same certificate. > I meant do you have any other examples of this anomalous encoding or is it some rare glitch in the serial number generation? Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4301 Please log in as guest with password guest if prompted From rt at openssl.org Thu Feb 11 22:36:30 2016 From: rt at openssl.org (Andy Polyakov via RT) Date: Thu, 11 Feb 2016 22:36:30 +0000 Subject: [openssl-dev] [openssl.org #4229] Bug - OpenSSL 1.0.2e on AIX has sha256p8-ppc.s assembler build issue... In-Reply-To: <56BD0CEC.8030203@openssl.org> References: <0282ac07112643ff8f6275bab024a048@USRIPVDMAIL3.gtk.gtech.com> <56BD0CEC.8030203@openssl.org> Message-ID: Hi, > I am attempting to build OpenSSL 1.0.2e on AIX and I'm seeing an issue with the "stvx" assembler instruction in the sha256p8-ppc.s module. I have built prior version OpenSSL packages on AIX without issue until now (prior was 1.0.1c), and I haven't varied the steps I typically use. Specifics are: > > AIX: 5200-08 I'm not quite familiar with AIX lingo. What does 5200-08 mean? Is it 5.2? > ./Configure threads aix64-cc -no-mdc2 -no-idea -no-rc5 > > make depend (works ok) > > make (gets the following errors): > > cc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include -DOPENSSL_THREADS -qthreaded -D_THREAD_SAFE -DDSO_DLFCN -DHAVE_DLFCN_H -q64 -O -DB_ENDIAN -qmaxmem=16384 -qro -qroconst -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DVPAES_ASM -c -o sha256p8-ppc.o sha256p8-ppc.s > Assembler: > sha256p8-ppc.s: line 11: invalid opcode or pseudo-op > > . . . similar diagnostics . . . > > sha256p8-ppc.s: line 767: invalid opcode or pseudo-op > make: The error code from the last command is 1. There is ambiguity in the report. First you assert that there is an issue with stvx instruction, then list lines that refer even to lvx. Is it possible that your tool-chain can't tolerate *any* vector instruction, not just stvx and lvx? In such case you probably out of luck in sense that disabling assembly altogether would be the only advice from our side. Well, formally speaking one can put an effort into option to disable vector code in PPC builds, but we are presumably talking about unsupported platform, unsupported by IBM that is. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4229 Please log in as guest with password guest if prompted From uri at ll.mit.edu Thu Feb 11 22:53:25 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Thu, 11 Feb 2016 22:53:25 +0000 Subject: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format Message-ID: <20160211225332.18296914.43705.51031@ll.mit.edu> Might I suggest that the right thing in this case would be to keep generation strict, but relax the rules on parsing? "Be conservative in what you send, and liberal with what you receive"? Clearly the device manufacturer is at fault here, but the punished party is the user - probably not what we should want? Sent?from?my?BlackBerry?10?smartphone?on?the Verizon?Wireless?4G?LTE?network. ? Original Message ? From: Stephen Henson via RT Sent: Thursday, February 11, 2016 17:27 To: bcristi at gmail.com Reply To: rt at openssl.org Cc: openssl-dev at openssl.org Subject: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format On Thu Feb 11 21:38:18 2016, bcristi at gmail.com wrote: > The EK certificate is generated and burned into the TPM during > manufacturing. The extraction operation always returns the same certificate. > I meant do you have any other examples of this anomalous encoding or is it some rare glitch in the serial number generation? Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4301 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4350 bytes Desc: not available URL: From rt at openssl.org Thu Feb 11 23:00:41 2016 From: rt at openssl.org (Blumenthal, Uri - 0553 - MITLL via RT) Date: Thu, 11 Feb 2016 23:00:41 +0000 Subject: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format In-Reply-To: <20160211225332.18296914.43705.51031@ll.mit.edu> References: <20160211225332.18296914.43705.51031@ll.mit.edu> Message-ID: Might I suggest that the right thing in this case would be to keep generation strict, but relax the rules on parsing? "Be conservative in what you send, and liberal with what you receive"? Clearly the device manufacturer is at fault here, but the punished party is the user - probably not what we should want? Sent?from?my?BlackBerry?10?smartphone?on?the Verizon?Wireless?4G?LTE?network. ? Original Message ? From: Stephen Henson via RT Sent: Thursday, February 11, 2016 17:27 To: bcristi at gmail.com Reply To: rt at openssl.org Cc: openssl-dev at openssl.org Subject: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format On Thu Feb 11 21:38:18 2016, bcristi at gmail.com wrote: > The EK certificate is generated and burned into the TPM during > manufacturing. The extraction operation always returns the same certificate. > I meant do you have any other examples of this anomalous encoding or is it some rare glitch in the serial number generation? Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4301 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4301 Please log in as guest with password guest if prompted -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4350 bytes Desc: not available URL: From kurt at roeckx.be Thu Feb 11 23:02:48 2016 From: kurt at roeckx.be (Kurt Roeckx) Date: Fri, 12 Feb 2016 00:02:48 +0100 Subject: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format In-Reply-To: <20160211225332.18296914.43705.51031@ll.mit.edu> References: <20160211225332.18296914.43705.51031@ll.mit.edu> Message-ID: <20160211230248.GA21694@roeckx.be> On Thu, Feb 11, 2016 at 10:53:25PM +0000, Blumenthal, Uri - 0553 - MITLL wrote: > Might I suggest that the right thing in this case would be to keep generation strict, but relax the rules on parsing? "Be conservative in what you send, and liberal with what you receive"? This might be good advice for some things, but ussually not when it comes to crypto. Kurt From rt at openssl.org Thu Feb 11 23:02:51 2016 From: rt at openssl.org (Kurt Roeckx via RT) Date: Thu, 11 Feb 2016 23:02:51 +0000 Subject: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format In-Reply-To: <20160211230248.GA21694@roeckx.be> References: <20160211225332.18296914.43705.51031@ll.mit.edu> <20160211230248.GA21694@roeckx.be> Message-ID: On Thu, Feb 11, 2016 at 10:53:25PM +0000, Blumenthal, Uri - 0553 - MITLL wrote: > Might I suggest that the right thing in this case would be to keep generation strict, but relax the rules on parsing? "Be conservative in what you send, and liberal with what you receive"? This might be good advice for some things, but ussually not when it comes to crypto. Kurt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4301 Please log in as guest with password guest if prompted From rt at openssl.org Thu Feb 11 23:05:14 2016 From: rt at openssl.org (Andy Polyakov via RT) Date: Thu, 11 Feb 2016 23:05:14 +0000 Subject: [openssl-dev] [openssl.org #4218] Invalid typecasting in CRYPTO_ctr128_encrypt In-Reply-To: <56BD13AA.5060706@openssl.org> References: <20160105224225.GA9097@roeckx.be> <56BD13AA.5060706@openssl.org> Message-ID: Hi, >> OpenSSL 1.0.2e >> >> At line 156 of crypto/modes/ctr128.c >> >> const unsigned char *in, >> unsigned char *out, >> unsigned char ivec[16], >> unsigned char ecount_buf[16] >> >> *(size_t *)(out + n) = >> *(size_t *)(in + n) ^ *(size_t *)(ecount_buf + n); >> >> If the buffers are not aligned, the application crashes due to the invalid >> type casting of unsigned char (1 byte) to size_t (4 to 8 bytes for most >> CPU:s). > > You should not run into that issue if STRICT_ALIGNMENT is defined. Well, yes, except that it doesn't check for alignment of ecount_buf. I mean there is 'if' clause for STRICT_ALIGNMENT that ensures that in, out and ivec are aligned, but not ecount_buf. And judging from crash report, it is ecount_buf that is not properly aligned (see last displayed argument). So that original analysis is sane. It should be noted that it looks like subroutine in question is called from application directly. While if called from EVP, i.e. the usual way, the problem never occurs, because that buffer is properly aligned within EVP_CIPHER_CTX structure. Resolution will follow later... -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4218 Please log in as guest with password guest if prompted From steve at openssl.org Thu Feb 11 23:29:45 2016 From: steve at openssl.org (Dr. Stephen Henson) Date: Thu, 11 Feb 2016 23:29:45 +0000 Subject: [openssl-dev] PKCS12_Parse() no longer extract certificate In-Reply-To: <008d01d16518$976341a0$c629c4e0$@sales@free.fr> References: <008d01d16518$976341a0$c629c4e0$@sales@free.fr> Message-ID: <20160211232945.GA21307@openssl.org> On Thu, Feb 11, 2016, Michel wrote: > Hi, > > > > I have a test program which is failing using version 1.1 because > PKCS12_Parse() doesn't return the certificate, just the key. No error is > signaled. > > I supposed it is not intended. Is it work in progress ? > That's a bug which should be fixed by commit b3ca51559b1a6cd80d Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From michel.sales at free.fr Thu Feb 11 23:39:20 2016 From: michel.sales at free.fr (Michel) Date: Fri, 12 Feb 2016 00:39:20 +0100 Subject: [openssl-dev] PKCS12_Parse() no longer extract certificate In-Reply-To: <20160211232945.GA21307@openssl.org> References: <008d01d16518$976341a0$c629c4e0$@sales@free.fr> <20160211232945.GA21307@openssl.org> Message-ID: <00b501d16525$6e582200$4b086600$@sales@free.fr> Thank you Steve. -----Message d'origine----- De?: openssl-dev [mailto:openssl-dev-bounces at openssl.org] De la part de Dr. Stephen Henson Envoy??: vendredi 12 f?vrier 2016 00:30 ??: openssl-dev at openssl.org Objet?: Re: [openssl-dev] PKCS12_Parse() no longer extract certificate On Thu, Feb 11, 2016, Michel wrote: > Hi, > > > > I have a test program which is failing using version 1.1 because > PKCS12_Parse() doesn't return the certificate, just the key. No error > is signaled. > > I supposed it is not intended. Is it work in progress ? > That's a bug which should be fixed by commit b3ca51559b1a6cd80d Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From uri at ll.mit.edu Fri Feb 12 00:11:39 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Fri, 12 Feb 2016 00:11:39 +0000 Subject: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format Message-ID: <20160212001147.18296914.17675.51048@ll.mit.edu> Again, you are right, but what's the lesser evil? - being unable to use the new OpenSSL because it refuses to deal with the cert that some dim-witten TPM maker screwed up, or accept a certificate with a (minor) violation of DER (but not of BER)? What bad in your opinion could happen if OpenSSL allowed parsing an integer with a leading zero byte (when it shouldn't be there by DER)? Even in crypto (and that's the area I've been working in for quite a while) there are some shades of gray, not only black and white. P.S. My platform of choice is Mac, and Apple does not put TPM there - so I won't gain from this decision, whichever way it turns. ;-)? Sent?from?my?BlackBerry?10?smartphone?on?the Verizon?Wireless?4G?LTE?network. ? Original Message ? From: Kurt Roeckx Sent: Thursday, February 11, 2016 18:03? To: openssl-dev at openssl.org? Reply To: openssl-dev at openssl.org Cc: Stephen Henson via RT; bcristi at gmail.com Subject: Re: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format? On Thu, Feb 11, 2016 at 10:53:25PM +0000, Blumenthal, Uri - 0553 - MITLL wrote: > Might I suggest that the right thing in this case would be to keep generation strict, but relax the rules on parsing? "Be conservative in what you send, and liberal with what you receive"? This might be good advice for some things, but ussually not when it? comes to crypto. Kurt -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4350 bytes Desc: not available URL: From rt at openssl.org Fri Feb 12 00:11:45 2016 From: rt at openssl.org (Blumenthal, Uri - 0553 - MITLL via RT) Date: Fri, 12 Feb 2016 00:11:45 +0000 Subject: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format In-Reply-To: <20160212001147.18296914.17675.51048@ll.mit.edu> References: <20160212001147.18296914.17675.51048@ll.mit.edu> Message-ID: Again, you are right, but what's the lesser evil? - being unable to use the new OpenSSL because it refuses to deal with the cert that some dim-witten TPM maker screwed up, or accept a certificate with a (minor) violation of DER (but not of BER)? What bad in your opinion could happen if OpenSSL allowed parsing an integer with a leading zero byte (when it shouldn't be there by DER)? Even in crypto (and that's the area I've been working in for quite a while) there are some shades of gray, not only black and white. P.S. My platform of choice is Mac, and Apple does not put TPM there - so I won't gain from this decision, whichever way it turns. ;-)? Sent?from?my?BlackBerry?10?smartphone?on?the Verizon?Wireless?4G?LTE?network. ? Original Message ? From: Kurt Roeckx Sent: Thursday, February 11, 2016 18:03? To: openssl-dev at openssl.org? Reply To: openssl-dev at openssl.org Cc: Stephen Henson via RT; bcristi at gmail.com Subject: Re: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format? On Thu, Feb 11, 2016 at 10:53:25PM +0000, Blumenthal, Uri - 0553 - MITLL wrote: > Might I suggest that the right thing in this case would be to keep generation strict, but relax the rules on parsing? "Be conservative in what you send, and liberal with what you receive"? This might be good advice for some things, but ussually not when it? comes to crypto. Kurt -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4301 Please log in as guest with password guest if prompted -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4350 bytes Desc: not available URL: From pwalten at au1.ibm.com Fri Feb 12 00:22:57 2016 From: pwalten at au1.ibm.com (Peter Waltenberg) Date: Fri, 12 Feb 2016 10:22:57 +1000 Subject: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format In-Reply-To: References: <20160212001147.18296914.17675.51048@ll.mit.edu> Message-ID: <201602120024.u1C0ODnh025660@d23av06.au.ibm.com> The problem with making those little "Oh we'll allow it for interoperability' choices is that they may end up as security vulnerabilities elsewhere. Particularly when there are multiple of them made. So - it is quite reasonable to reject a change like that because it's near impossible to check all the little corner cases that it might expose. Peter From: "Blumenthal, Uri - 0553 - MITLL via RT" To: bcristi at gmail.com Cc: openssl-dev at openssl.org Date: 12/02/2016 10:13 Subject: Re: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format Sent by: "openssl-dev" Again, you are right, but what's the lesser evil? - being unable to use the new OpenSSL because it refuses to deal with the cert that some dim-witten TPM maker screwed up, or accept a certificate with a (minor) violation of DER (but not of BER)? What bad in your opinion could happen if OpenSSL allowed parsing an integer with a leading zero byte (when it shouldn't be there by DER)? Even in crypto (and that's the area I've been working in for quite a while) there are some shades of gray, not only black and white. P.S. My platform of choice is Mac, and Apple does not put TPM there - so I won't gain from this decision, whichever way it turns. ;-) Sent?from?my?BlackBerry?10?smartphone?on?the Verizon?Wireless?4G?LTE?network. ? Original Message From: Kurt Roeckx Sent: Thursday, February 11, 2016 18:03? To: openssl-dev at openssl.org? Reply To: openssl-dev at openssl.org Cc: Stephen Henson via RT; bcristi at gmail.com Subject: Re: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format? On Thu, Feb 11, 2016 at 10:53:25PM +0000, Blumenthal, Uri - 0553 - MITLL wrote: > Might I suggest that the right thing in this case would be to keep generation strict, but relax the rules on parsing? "Be conservative in what you send, and liberal with what you receive"? This might be good advice for some things, but ussually not when it? comes to crypto. Kurt -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4301 Please log in as guest with password guest if prompted [attachment "smime.p7s" deleted by Peter Waltenberg/Australia/IBM] -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: From rt at openssl.org Fri Feb 12 00:25:07 2016 From: rt at openssl.org (Peter Waltenberg via RT) Date: Fri, 12 Feb 2016 00:25:07 +0000 Subject: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format In-Reply-To: <201602120024.u1C0ODB1025665@d23av06.au.ibm.com> References: <20160212001147.18296914.17675.51048@ll.mit.edu> <201602120024.u1C0ODB1025665@d23av06.au.ibm.com> Message-ID: The problem with making those little "Oh we'll allow it for interoperability' choices is that they may end up as security vulnerabilities elsewhere. Particularly when there are multiple of them made. So - it is quite reasonable to reject a change like that because it's near impossible to check all the little corner cases that it might expose. Peter From: "Blumenthal, Uri - 0553 - MITLL via RT" To: bcristi at gmail.com Cc: openssl-dev at openssl.org Date: 12/02/2016 10:13 Subject: Re: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format Sent by: "openssl-dev" Again, you are right, but what's the lesser evil? - being unable to use the new OpenSSL because it refuses to deal with the cert that some dim-witten TPM maker screwed up, or accept a certificate with a (minor) violation of DER (but not of BER)? What bad in your opinion could happen if OpenSSL allowed parsing an integer with a leading zero byte (when it shouldn't be there by DER)? Even in crypto (and that's the area I've been working in for quite a while) there are some shades of gray, not only black and white. P.S. My platform of choice is Mac, and Apple does not put TPM there - so I won't gain from this decision, whichever way it turns. ;-) Sent?from?my?BlackBerry?10?smartphone?on?the Verizon?Wireless?4G?LTE?network. ? Original Message From: Kurt Roeckx Sent: Thursday, February 11, 2016 18:03? To: openssl-dev at openssl.org? Reply To: openssl-dev at openssl.org Cc: Stephen Henson via RT; bcristi at gmail.com Subject: Re: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format? On Thu, Feb 11, 2016 at 10:53:25PM +0000, Blumenthal, Uri - 0553 - MITLL wrote: > Might I suggest that the right thing in this case would be to keep generation strict, but relax the rules on parsing? "Be conservative in what you send, and liberal with what you receive"? This might be good advice for some things, but ussually not when it? comes to crypto. Kurt -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4301 Please log in as guest with password guest if prompted [attachment "smime.p7s" deleted by Peter Waltenberg/Australia/IBM] -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4301 Please log in as guest with password guest if prompted -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: From noloader at gmail.com Fri Feb 12 01:37:35 2016 From: noloader at gmail.com (Jeffrey Walton) Date: Thu, 11 Feb 2016 20:37:35 -0500 Subject: [openssl-dev] [openssl.org #4237] Failed self-tests on AARCH64 (ARM64) In-Reply-To: References: <56BCF32A.6000603@openssl.org> Message-ID: On Thu, Feb 11, 2016 at 3:46 PM, Andy Polyakov via RT wrote: > Hi, > >> $ uname -a >> Linux hikey 3.18.0-linaro-hikey #1 SMP PREEMPT Mon Nov 30 00:11:03 UTC >> 2015 aarch64 GNU/Linux >> >> $ make test >> ... >> ../test/recipes/80-test_dane.t ............ ok >> ../test/recipes/80-test_ocsp.t ............ ok >> ../test/recipes/80-test_ssl.t ............. 1/43 >> # Failed test 'test sslv3 with client authentication via BIO pair' >> # at ../test/recipes/80-test_ssl.t line 345. >> # Looks like you failed 1 test of 27. > > Double-check attached patch and report back, please. Cheers. I believe that cleared the issue. Thank you very much. ----- ... $ make test ... TOP=.. PERL=/usr/bin/perl /usr/bin/perl run_tests.pl alltests ../test/recipes/00-check_testexes.t ....... ok ../test/recipes/01-test_ordinals.t ........ ok ../test/recipes/05-test_bf.t .............. ok ../test/recipes/05-test_cast.t ............ ok ../test/recipes/05-test_des.t ............. ok ../test/recipes/05-test_hmac.t ............ ok ../test/recipes/05-test_idea.t ............ ok ../test/recipes/05-test_md2.t ............. skipped: md2 is not supported by this OpenSSL build ../test/recipes/05-test_md4.t ............. ok ../test/recipes/05-test_md5.t ............. ok ../test/recipes/05-test_mdc2.t ............ ok ../test/recipes/05-test_rand.t ............ ok ../test/recipes/05-test_rc2.t ............. ok ../test/recipes/05-test_rc4.t ............. ok ../test/recipes/05-test_rc5.t ............. skipped: rc5 is not supported by this OpenSSL build ../test/recipes/05-test_rmd.t ............. ok ../test/recipes/05-test_sha1.t ............ ok ../test/recipes/05-test_sha256.t .......... ok ../test/recipes/05-test_sha512.t .......... ok ../test/recipes/05-test_wp.t .............. ok ../test/recipes/10-test_bn.t .............. ok ../test/recipes/10-test_exp.t ............. ok ../test/recipes/15-test_dh.t .............. ok ../test/recipes/15-test_dsa.t ............. ok ../test/recipes/15-test_ec.t .............. ok ../test/recipes/15-test_ecdh.t ............ ok ../test/recipes/15-test_ecdsa.t ........... ok ../test/recipes/15-test_rsa.t ............. ok ../test/recipes/20-test_enc.t ............. ok ../test/recipes/25-test_crl.t ............. ok ../test/recipes/25-test_gen.t ............. ok ../test/recipes/25-test_pkcs7.t ........... ok ../test/recipes/25-test_req.t ............. ok ../test/recipes/25-test_sid.t ............. ok ../test/recipes/25-test_verify.t .......... ok ../test/recipes/25-test_x509.t ............ ok ../test/recipes/30-test_engine.t .......... ok ../test/recipes/30-test_evp.t ............. ok ../test/recipes/30-test_evp_extra.t ....... ok ../test/recipes/30-test_pbelu.t ........... ok ../test/recipes/40-test_rehash.t .......... ok ../test/recipes/70-test_clienthello.t ..... ok ../test/recipes/70-test_packet.t .......... ok ../test/recipes/70-test_sslcertstatus.t ... skipped: test_sslcertstatus can only be performed with OpenSSL configured shared ../test/recipes/70-test_sslextension.t .... skipped: test_sslextension can only be performed with OpenSSL configured shared ../test/recipes/70-test_sslsessiontick.t .. skipped: test_sslsessiontick can only be performed with OpenSSL configured shared ../test/recipes/70-test_sslskewith0p.t .... skipped: test_sslskewith0p can only be performed with OpenSSL configured shared ../test/recipes/70-test_sslvertol.t ....... skipped: test_sslextension can only be performed with OpenSSL configured shared ../test/recipes/70-test_tlsextms.t ........ skipped: test_tlsextms can only be performed with OpenSSL configured shared ../test/recipes/70-test_verify_extra.t .... ok ../test/recipes/80-test_ca.t .............. ok ../test/recipes/80-test_cms.t ............. ok ../test/recipes/80-test_dane.t ............ ok ../test/recipes/80-test_dtlsv1listen.t .... ok ../test/recipes/80-test_ocsp.t ............ ok ../test/recipes/80-test_ssl.t ............. ok ../test/recipes/80-test_tsa.t ............. ok ../test/recipes/90-test_async.t ........... ok ../test/recipes/90-test_constant_time.t ... ok ../test/recipes/90-test_gmdiff.t .......... ok ../test/recipes/90-test_heartbeat.t ....... skipped: heartbeats is not supported by this OpenSSL build ../test/recipes/90-test_ige.t ............. ok ../test/recipes/90-test_jpake.t ........... skipped: jpake is not supported by this OpenSSL build ../test/recipes/90-test_memleak.t ......... ok ../test/recipes/90-test_networking.t ...... skipped: test_networking can only be performed with OpenSSL configured shared ../test/recipes/90-test_np.t .............. ok ../test/recipes/90-test_p5_crpt2.t ........ ok ../test/recipes/90-test_secmem.t .......... ok ../test/recipes/90-test_srp.t ............. ok ../test/recipes/90-test_v3name.t .......... ok All tests successful. Files=70, Tests=409, 153 wallclock secs ( 3.54 usr 0.34 sys + 112.32 cusr 9.31 csys = 125.51 CPU) Result: PASS make[1]: Leaving directory '/home/jwalton/openssl/test' OpenSSL 1.1.0-pre3-dev xx XXX xxxx built on: reproducible build, date unspecified platform: linux-aarch64 compiler: gcc OPENSSLDIR: "/usr/local/ssl" From rt at openssl.org Fri Feb 12 01:37:48 2016 From: rt at openssl.org (noloader@gmail.com via RT) Date: Fri, 12 Feb 2016 01:37:48 +0000 Subject: [openssl-dev] [openssl.org #4237] Failed self-tests on AARCH64 (ARM64) In-Reply-To: References: <56BCF32A.6000603@openssl.org> Message-ID: On Thu, Feb 11, 2016 at 3:46 PM, Andy Polyakov via RT wrote: > Hi, > >> $ uname -a >> Linux hikey 3.18.0-linaro-hikey #1 SMP PREEMPT Mon Nov 30 00:11:03 UTC >> 2015 aarch64 GNU/Linux >> >> $ make test >> ... >> ../test/recipes/80-test_dane.t ............ ok >> ../test/recipes/80-test_ocsp.t ............ ok >> ../test/recipes/80-test_ssl.t ............. 1/43 >> # Failed test 'test sslv3 with client authentication via BIO pair' >> # at ../test/recipes/80-test_ssl.t line 345. >> # Looks like you failed 1 test of 27. > > Double-check attached patch and report back, please. Cheers. I believe that cleared the issue. Thank you very much. ----- ... $ make test ... TOP=.. PERL=/usr/bin/perl /usr/bin/perl run_tests.pl alltests ../test/recipes/00-check_testexes.t ....... ok ../test/recipes/01-test_ordinals.t ........ ok ../test/recipes/05-test_bf.t .............. ok ../test/recipes/05-test_cast.t ............ ok ../test/recipes/05-test_des.t ............. ok ../test/recipes/05-test_hmac.t ............ ok ../test/recipes/05-test_idea.t ............ ok ../test/recipes/05-test_md2.t ............. skipped: md2 is not supported by this OpenSSL build ../test/recipes/05-test_md4.t ............. ok ../test/recipes/05-test_md5.t ............. ok ../test/recipes/05-test_mdc2.t ............ ok ../test/recipes/05-test_rand.t ............ ok ../test/recipes/05-test_rc2.t ............. ok ../test/recipes/05-test_rc4.t ............. ok ../test/recipes/05-test_rc5.t ............. skipped: rc5 is not supported by this OpenSSL build ../test/recipes/05-test_rmd.t ............. ok ../test/recipes/05-test_sha1.t ............ ok ../test/recipes/05-test_sha256.t .......... ok ../test/recipes/05-test_sha512.t .......... ok ../test/recipes/05-test_wp.t .............. ok ../test/recipes/10-test_bn.t .............. ok ../test/recipes/10-test_exp.t ............. ok ../test/recipes/15-test_dh.t .............. ok ../test/recipes/15-test_dsa.t ............. ok ../test/recipes/15-test_ec.t .............. ok ../test/recipes/15-test_ecdh.t ............ ok ../test/recipes/15-test_ecdsa.t ........... ok ../test/recipes/15-test_rsa.t ............. ok ../test/recipes/20-test_enc.t ............. ok ../test/recipes/25-test_crl.t ............. ok ../test/recipes/25-test_gen.t ............. ok ../test/recipes/25-test_pkcs7.t ........... ok ../test/recipes/25-test_req.t ............. ok ../test/recipes/25-test_sid.t ............. ok ../test/recipes/25-test_verify.t .......... ok ../test/recipes/25-test_x509.t ............ ok ../test/recipes/30-test_engine.t .......... ok ../test/recipes/30-test_evp.t ............. ok ../test/recipes/30-test_evp_extra.t ....... ok ../test/recipes/30-test_pbelu.t ........... ok ../test/recipes/40-test_rehash.t .......... ok ../test/recipes/70-test_clienthello.t ..... ok ../test/recipes/70-test_packet.t .......... ok ../test/recipes/70-test_sslcertstatus.t ... skipped: test_sslcertstatus can only be performed with OpenSSL configured shared ../test/recipes/70-test_sslextension.t .... skipped: test_sslextension can only be performed with OpenSSL configured shared ../test/recipes/70-test_sslsessiontick.t .. skipped: test_sslsessiontick can only be performed with OpenSSL configured shared ../test/recipes/70-test_sslskewith0p.t .... skipped: test_sslskewith0p can only be performed with OpenSSL configured shared ../test/recipes/70-test_sslvertol.t ....... skipped: test_sslextension can only be performed with OpenSSL configured shared ../test/recipes/70-test_tlsextms.t ........ skipped: test_tlsextms can only be performed with OpenSSL configured shared ../test/recipes/70-test_verify_extra.t .... ok ../test/recipes/80-test_ca.t .............. ok ../test/recipes/80-test_cms.t ............. ok ../test/recipes/80-test_dane.t ............ ok ../test/recipes/80-test_dtlsv1listen.t .... ok ../test/recipes/80-test_ocsp.t ............ ok ../test/recipes/80-test_ssl.t ............. ok ../test/recipes/80-test_tsa.t ............. ok ../test/recipes/90-test_async.t ........... ok ../test/recipes/90-test_constant_time.t ... ok ../test/recipes/90-test_gmdiff.t .......... ok ../test/recipes/90-test_heartbeat.t ....... skipped: heartbeats is not supported by this OpenSSL build ../test/recipes/90-test_ige.t ............. ok ../test/recipes/90-test_jpake.t ........... skipped: jpake is not supported by this OpenSSL build ../test/recipes/90-test_memleak.t ......... ok ../test/recipes/90-test_networking.t ...... skipped: test_networking can only be performed with OpenSSL configured shared ../test/recipes/90-test_np.t .............. ok ../test/recipes/90-test_p5_crpt2.t ........ ok ../test/recipes/90-test_secmem.t .......... ok ../test/recipes/90-test_srp.t ............. ok ../test/recipes/90-test_v3name.t .......... ok All tests successful. Files=70, Tests=409, 153 wallclock secs ( 3.54 usr 0.34 sys + 112.32 cusr 9.31 csys = 125.51 CPU) Result: PASS make[1]: Leaving directory '/home/jwalton/openssl/test' OpenSSL 1.1.0-pre3-dev xx XXX xxxx built on: reproducible build, date unspecified platform: linux-aarch64 compiler: gcc OPENSSLDIR: "/usr/local/ssl" -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4237 Please log in as guest with password guest if prompted From Erwann.Abalea at docusign.com Fri Feb 12 09:38:31 2016 From: Erwann.Abalea at docusign.com (Erwann Abalea) Date: Fri, 12 Feb 2016 09:38:31 +0000 Subject: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format In-Reply-To: <20160212001147.18296914.17675.51048@ll.mit.edu> References: <20160212001147.18296914.17675.51048@ll.mit.edu> Message-ID: <7BB76887-80F7-4DB6-9436-7933ECB3FE85@docusign.com> Bonjour, Le 12 f?vr. 2016 ? 01:11, Blumenthal, Uri - 0553 - MITLL > a ?crit : Again, you are right, but what's the lesser evil? - being unable to use the new OpenSSL because it refuses to deal with the cert that some dim-witten TPM maker screwed up, or accept a certificate with a (minor) violation of DER (but not of BER)? What bad in your opinion could happen if OpenSSL allowed parsing an integer with a leading zero byte (when it shouldn't be there by DER)? As shown yesterday, this INTEGER encoding isn?t even valid BER. Being liberal in what you accept, when dealing with crypto, gives you stuff like this: https://www.mozilla.org/en-US/security/advisories/mfsa2014-73/ Cordialement, Erwann Abalea -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Fri Feb 12 10:16:20 2016 From: rt at openssl.org (Andy Polyakov via RT) Date: Fri, 12 Feb 2016 10:16:20 +0000 Subject: [openssl-dev] [openssl.org #4171] Compile failure on OS X 10.7 clang with OpenSSL 1.0.2e In-Reply-To: <56BDB0EE.8070706@openssl.org> References: <56BDB0EE.8070706@openssl.org> Message-ID: Hi, > https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=301a6dcd4590fb2f69d08259577e215b4cc3caa3#patch5 added a check to see if it should use the ADDX instructions based on the clang version. Unfortunately, on older versions of clang on OS X this check incorrectly returns true and compilation then fails due to not knowing the instructions: > > x86_64-mont.s:966:2 error: invalid instruction mnemonic 'adcxq' > adcxq %rax,%r12 > ^~~~~ > > The version of the compiler in question is: `Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)` (On an ancient OS X 10.7 VM) > > This issue was also filed in Github (https://github.com/openssl/openssl/issues/494) This was addressed in http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=b9749432346f69b29d82070041e71b237d718ce7 by giving "based on LLVM" higher priority. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4171 Please log in as guest with password guest if prompted From rt at openssl.org Fri Feb 12 10:46:22 2016 From: rt at openssl.org (Cristian Berneanu via RT) Date: Fri, 12 Feb 2016 10:46:22 +0000 Subject: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format In-Reply-To: References: <20160212001147.18296914.17675.51048@ll.mit.edu> <7BB76887-80F7-4DB6-9436-7933ECB3FE85@docusign.com> Message-ID: FYI, I checked other machines that have a TPM device manufactured by STM, but I could not find another with a serial number less than 20 bytes (I guess they do padding in that case). I also have a certificate from an Atmel device where I get a notice that the serial number is negative. For me personally, it would be perfectly fine if I could have a "relaxed parsing" option that I could pass when I expect these kinds of broken encodings. On Fri, Feb 12, 2016 at 11:38 AM, Erwann Abalea wrote: > Bonjour, > > Le 12 f?vr. 2016 ? 01:11, Blumenthal, Uri - 0553 - MITLL > a ?crit : > > Again, you are right, but what's the lesser evil? - being unable to use > the new OpenSSL because it refuses to deal with the cert that some > dim-witten TPM maker screwed up, or accept a certificate with a (minor) > violation of DER (but not of BER)? What bad in your opinion could happen if > OpenSSL allowed parsing an integer with a leading zero byte (when it > shouldn't be there by DER)? > > > As shown yesterday, this INTEGER encoding isn?t even valid BER. > > Being liberal in what you accept, when dealing with crypto, gives you > stuff like this: > https://www.mozilla.org/en-US/security/advisories/mfsa2014-73/ > > Cordialement, > Erwann Abalea > > -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4301 Please log in as guest with password guest if prompted From rt at openssl.org Fri Feb 12 11:11:08 2016 From: rt at openssl.org (Erwann Abalea via RT) Date: Fri, 12 Feb 2016 11:11:08 +0000 Subject: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format In-Reply-To: <7BB76887-80F7-4DB6-9436-7933ECB3FE85@docusign.com> References: <20160212001147.18296914.17675.51048@ll.mit.edu> <7BB76887-80F7-4DB6-9436-7933ECB3FE85@docusign.com> Message-ID: Bonjour, Le 12 f?vr. 2016 ? 01:11, Blumenthal, Uri - 0553 - MITLL > a ?crit : Again, you are right, but what's the lesser evil? - being unable to use the new OpenSSL because it refuses to deal with the cert that some dim-witten TPM maker screwed up, or accept a certificate with a (minor) violation of DER (but not of BER)? What bad in your opinion could happen if OpenSSL allowed parsing an integer with a leading zero byte (when it shouldn't be there by DER)? As shown yesterday, this INTEGER encoding isn?t even valid BER. Being liberal in what you accept, when dealing with crypto, gives you stuff like this: https://www.mozilla.org/en-US/security/advisories/mfsa2014-73/ Cordialement, Erwann Abalea -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4301 Please log in as guest with password guest if prompted From rt at openssl.org Fri Feb 12 13:23:23 2016 From: rt at openssl.org (=?UTF-8?B?RW1pbGlhIEvDpHNwZXI=?= via RT) Date: Fri, 12 Feb 2016 13:23:23 +0000 Subject: [openssl-dev] [openssl.org #3854] openssl.cnf in openssl-1.0.1m still uses default_bits=1024 In-Reply-To: <2533734.QspX2uaRnp@gaston.colazone> References: <2533734.QspX2uaRnp@gaston.colazone> Message-ID: We cleaned this up a little: - crypto/conf/ssleay.cnf was obsolete and is gone from the master branch. - the req app now uses 2048 bits as a default if no other defaults are given. ssleay.txt is already gone from the master branch, and the test/ ones are used in tests. Cheers, Emilia -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3854 Please log in as guest with password guest if prompted From rt at openssl.org Fri Feb 12 14:22:50 2016 From: rt at openssl.org (Andy Polyakov via RT) Date: Fri, 12 Feb 2016 14:22:50 +0000 Subject: [openssl-dev] [openssl.org #3759] [PATCH] crypto: use bigint in x86-64 perl In-Reply-To: <56BDEAB4.8080306@openssl.org> References: <1426935725-11133-1-git-send-email-vapier@gentoo.org> <56BDEAB4.8080306@openssl.org> Message-ID: > When building on x32 systems where the default type is 32bit, make sure > we can transparently represent 64bit integers. Otherwise we end up with > build errors like: > /usr/bin/perl asm/ghash-x86_64.pl elf > ghash-x86_64.s > Integer overflow in hexadecimal number at asm/../../perlasm/x86_64-xlate.pl line 201, <> line 890. > ... > ghash-x86_64.s: Assembler messages: > ghash-x86_64.s:890: Error: junk '.15473355479995e+19' after expression > > We don't enable this globally as there are some cases where we'd get > 32bit values interpreted as unsigned when we need them as signed. This was recently addressed in another manner. Closing the ticket. Thanks. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3759 Please log in as guest with password guest if prompted From doctor at doctor.nl2k.ab.ca Fri Feb 12 14:31:34 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Fri, 12 Feb 2016 07:31:34 -0700 Subject: [openssl-dev] openssl-SNAP-20160212 issue Message-ID: <20160212143134.GB23393@doctor.nl2k.ab.ca> Here is another fix needed: making all in ssl... gcc -I.. -I../include -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_EXPERIMENTAL_JPAKE -DOPENSSL_THREADS -DOPENSSL_PIC -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/contrib\"" -DENGINESDIR="\"/usr/contrib/lib/engines\"" -fPIC -pthread -D_THREAD_SAFE -D_REENTRANT -DPERL5 -DL_ENDIAN -DTERMIOS -fomit-frame-pointer -O2 -march=i486 -Wall -g -c t1_trce.c -o t1_trce.o t1_trce.c: In function `ssl_get_keyex': t1_trce.c:923: `SSL_kECDHr' undeclared (first use in this function) t1_trce.c:923: (Each undeclared identifier is reported only once t1_trce.c:923: for each function it appears in.) t1_trce.c:927: `SSL_kECDHe' undeclared (first use in this function) t1_trce.c: In function `ssl_print_client_keyex': t1_trce.c:993: `SSL_kECDHr' undeclared (first use in this function) t1_trce.c:994: `SSL_kECDHe' undeclared (first use in this function) t1_trce.c: In function `ssl_print_server_keyex': t1_trce.c:1026: `SSL_kECDHr' undeclared (first use in this function) t1_trce.c:1027: `SSL_kECDHe' undeclared (first use in this function) *** Error code 1 Stop. *** Error code 1 Please repair. -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Broadcasting the truth for 25 years From matt at openssl.org Fri Feb 12 14:44:29 2016 From: matt at openssl.org (Matt Caswell) Date: Fri, 12 Feb 2016 14:44:29 +0000 Subject: [openssl-dev] openssl-SNAP-20160212 issue In-Reply-To: <20160212143134.GB23393@doctor.nl2k.ab.ca> References: <20160212143134.GB23393@doctor.nl2k.ab.ca> Message-ID: <56BDEFCD.6070403@openssl.org> On 12/02/16 14:31, The Doctor wrote: > Here is another fix needed: > > making all in ssl... > gcc -I.. -I../include -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_EXPERIMENTAL_JPAKE -DOPENSSL_THREADS -DOPENSSL_PIC -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/contrib\"" -DENGINESDIR="\"/usr/contrib/lib/engines\"" -fPIC -pthread -D_THREAD_SAFE -D_REENTRANT -DPERL5 -DL_ENDIAN -DTERMIOS -fomit-frame-pointer -O2 -march=i486 -Wall -g -c t1_trce.c -o t1_trce.o > t1_trce.c: In function `ssl_get_keyex': > t1_trce.c:923: `SSL_kECDHr' undeclared (first use in this function) > t1_trce.c:923: (Each undeclared identifier is reported only once > t1_trce.c:923: for each function it appears in.) > t1_trce.c:927: `SSL_kECDHe' undeclared (first use in this function) > t1_trce.c: In function `ssl_print_client_keyex': > t1_trce.c:993: `SSL_kECDHr' undeclared (first use in this function) > t1_trce.c:994: `SSL_kECDHe' undeclared (first use in this function) > t1_trce.c: In function `ssl_print_server_keyex': > t1_trce.c:1026: `SSL_kECDHr' undeclared (first use in this function) > t1_trce.c:1027: `SSL_kECDHe' undeclared (first use in this function) > *** Error code 1 > > Stop. > *** Error code 1 > > Please repair. > This only happens if you use the enable-ssl-trace config option. It's already fixed in current master. Matt From doctor at doctor.nl2k.ab.ca Fri Feb 12 15:12:28 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Fri, 12 Feb 2016 08:12:28 -0700 Subject: [openssl-dev] openssl-SNAP-20160212 issue In-Reply-To: <56BDEFCD.6070403@openssl.org> References: <20160212143134.GB23393@doctor.nl2k.ab.ca> <56BDEFCD.6070403@openssl.org> Message-ID: <20160212151228.GA4709@doctor.nl2k.ab.ca> On Fri, Feb 12, 2016 at 02:44:29PM +0000, Matt Caswell wrote: > > > On 12/02/16 14:31, The Doctor wrote: > > Here is another fix needed: > > > > making all in ssl... > > gcc -I.. -I../include -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_EXPERIMENTAL_JPAKE -DOPENSSL_THREADS -DOPENSSL_PIC -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/contrib\"" -DENGINESDIR="\"/usr/contrib/lib/engines\"" -fPIC -pthread -D_THREAD_SAFE -D_REENTRANT -DPERL5 -DL_ENDIAN -DTERMIOS -fomit-frame-pointer -O2 -march=i486 -Wall -g -c t1_trce.c -o t1_trce.o > > t1_trce.c: In function `ssl_get_keyex': > > t1_trce.c:923: `SSL_kECDHr' undeclared (first use in this function) > > t1_trce.c:923: (Each undeclared identifier is reported only once > > t1_trce.c:923: for each function it appears in.) > > t1_trce.c:927: `SSL_kECDHe' undeclared (first use in this function) > > t1_trce.c: In function `ssl_print_client_keyex': > > t1_trce.c:993: `SSL_kECDHr' undeclared (first use in this function) > > t1_trce.c:994: `SSL_kECDHe' undeclared (first use in this function) > > t1_trce.c: In function `ssl_print_server_keyex': > > t1_trce.c:1026: `SSL_kECDHr' undeclared (first use in this function) > > t1_trce.c:1027: `SSL_kECDHe' undeclared (first use in this function) > > *** Error code 1 > > > > Stop. > > *** Error code 1 > > > > Please repair. > > > > This only happens if you use the enable-ssl-trace config option. It's > already fixed in current master. > > Matt > Will check in tomorrow. > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Broadcasting the truth for 25 years From rt at openssl.org Fri Feb 12 16:41:02 2016 From: rt at openssl.org (Richard.Koenning@ts.fujitsu.com via RT) Date: Fri, 12 Feb 2016 16:41:02 +0000 Subject: [openssl-dev] [openssl.org #4302] Documentation error in apps/x509.html: -[digest] option In-Reply-To: <56BDFD76.8060706@ts.fujitsu.com> References: <56BDFD76.8060706@ts.fujitsu.com> Message-ID: https://www.openssl.org/docs/manmaster/apps/x509.html says: > -[digest] > > the digest to use. This affects any signing or display option that uses a message digest, such as the -fingerprint, > -signkey and -CA options. Any digest supported by the OpenSSL dgst command can be used. If not specified then SHA1 is used. That SHA1 is used when the digest is not specified is true for the -fingerprint option, but it is at least not true for the -CA option. In the latter case (and very probably also for the -signkey option) the default digest method is selected via rsa_pkey_ctrl() in crypto/rsa/rsa_ameth.c with op = ASN1_PKEY_CTRL_DEFAULT_MD_NID and here is NID_sha256 returned since OpenSSL 1.0.2 instead NID_sha1 in older OpenSSL versions. Best regards, Richard K?nning -- Dr. Richard W. K?nning Fujitsu Technology Solutions GmbH -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4302 Please log in as guest with password guest if prompted From rt at openssl.org Fri Feb 12 17:44:44 2016 From: rt at openssl.org (Jeremy Farrell via RT) Date: Fri, 12 Feb 2016 17:44:44 +0000 Subject: [openssl-dev] [openssl.org #4229] Bug - OpenSSL 1.0.2e on AIX has sha256p8-ppc.s assembler build issue... In-Reply-To: <56BE19FC.20709@oracle.com> References: <0282ac07112643ff8f6275bab024a048@USRIPVDMAIL3.gtk.gtech.com> <56BD0CEC.8030203@openssl.org> <56BE19FC.20709@oracle.com> Message-ID: On 11/02/2016 22:36, Andy Polyakov via RT wrote: >> I am attempting to build OpenSSL 1.0.2e on AIX and I'm seeing an issue with the "stvx" assembler instruction in the sha256p8-ppc.s module. I have built prior version OpenSSL packages on AIX without issue until now (prior was 1.0.1c), and I haven't varied the steps I typically use. Specifics are: >> >> AIX: 5200-08 > I'm not quite familiar with AIX lingo. What does 5200-08 mean? Is it 5.2? Yes, AIX 5.2 TL 8. I believe that IBM stopped providing fixes for that particular technology level in February 2007, stopped standard support for AIX 5.2 final technology level (TL 10) in April 2009, stopped admitting to ever having heard of 5.2 sometime in 2012. no-asm seems to be the appropriate way to deal with this. -- J. J. Farrell -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4229 Please log in as guest with password guest if prompted From rt at openssl.org Fri Feb 12 18:41:41 2016 From: rt at openssl.org (Rainer Jung via RT) Date: Fri, 12 Feb 2016 18:41:41 +0000 Subject: [openssl-dev] [openssl.org #4303] OpenSSL 1.1.0 renegotiation problem (s_server/s_client) In-Reply-To: <56BE2238.6060606@kippdata.de> References: <56BE2238.6060606@kippdata.de> Message-ID: Using OpenSSL 1.1.0pre2 I see renegotiation problems between s_client and s_server (but also in Apache mod_ssl). First starting: s_server -cert server.crt -key server.pem -accept 8443 -debug -state Using default temp DH parameters ACCEPT Now starting s_client -connect localhost:8443 -debug -state I see on the server side: SSL_accept:before SSL initialization ... SSL_accept:SSLv3/TLS write finished -----BEGIN SSL SESSION PARAMETERS----- MFoCAQECAgMDBALAMAQABDBWP93rPtTOpEyh6rNq87IB7+8JHLQ3Kgg3dDxFrxhH 6gdH1LM33nePKWE8je2ezmKhBgIEVr4d6aIEAgIcIKQGBAQAAAABrQMCAQE= -----END SSL SESSION PARAMETERS----- Shared ciphers:ECDHE-ECDSA-AES256-CCM8:ECDHE-ECDSA-AES256-CCM:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES256-CCM8:DHE-RSA-AES256-CCM:DHE-DSS-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA256:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-CAMELLIA256-SHA384:ECDHE-ECDSA-CAMELLIA256-SHA384:DHE-RSA-CHACHA20-POLY1305:DHE-RSA-CAMELLIA256-SHA256:DHE-DSS-CAMELLIA256-SHA256:DHE-RSA-CAMELLIA256-SHA:DHE-DSS-CAMELLIA256-SHA:ECDH-RSA-AES256-GCM-SHA384:ECDH-ECDSA-AES256-GCM-SHA384:ECDH-RSA-AES256-SHA384:ECDH-ECDSA-AES256-SHA384:ECDH-RSA-AES256-SHA:ECDH-ECDSA-AES256-SHA:ECDH-RSA-CAMELLIA256-SHA384:ECDH-ECDSA-CAMELLIA256-SHA384:AES256-CCM8:AES256-CCM:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA:CAMELLIA256-SHA256:CAMELLIA256-SHA:ECDHE-ECDSA-AES128-CCM8:ECDHE-ECDSA-AES128-CCM:ECDHE-RSA-A! ES128-GC M-SHA256 Signature Algorithms: RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+SHA1:DSA+SHA1:ECDSA+SHA1 Shared Signature Algorithms: RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+SHA1:DSA+SHA1:ECDSA+SHA1 Supported Elliptic Curve Point Formats: uncompressed:ansiX962_compressed_prime:ansiX962_compressed_char2 Supported Elliptic Curves: P-256:P-521:brainpoolP512r1:brainpoolP384r1:P-384:brainpoolP256r1:secp256k1:B-571:K-571:K-409:B-409:K-283:B-283 Shared Elliptic curves: P-256:P-521:brainpoolP512r1:brainpoolP384r1:P-384:brainpoolP256r1:secp256k1:B-571:K-571:K-409:B-409:K-283:B-283 CIPHER is ECDHE-RSA-AES256-GCM-SHA384 Secure Renegotiation IS supported and on the client side: CONNECTED(00000003) SSL_connect:before SSL initialization ... -----END CERTIFICATE----- subject=/C=US/ST=California/L=San Francisco/O=ASF/OU=httpd-test/rsa-test/CN=localhost/emailAddress=test-dev at httpd.apache.org issuer=/C=US/ST=California/L=San Francisco/O=ASF/OU=httpd-test/CN=ca/emailAddress=test-dev at httpd.apache.org --- No client certificate CA names sent Peer signing digest: SHA512 Server Temp Key: ECDH, P-256, 256 bits --- SSL handshake has read 1672 bytes and written 447 bytes --- New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-GCM-SHA384 Session-ID: B57844A325DB8E6781073CD615128A88342E850B5A11B9966A2B7C2F475B1727 Session-ID-ctx: Master-Key: 563FDDEB3ED4CEA44CA1EAB36AF3B201EFEF091CB4372A0837743C45AF1847EA0747D4B337DE778F29613C8DED9ECE62 PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 7200 (seconds) TLS session ticket: ... Start Time: 1455300073 Timeout : 7200 (sec) Verify return code: 21 (unable to verify the first certificate) Extended master secret: yes --- Now pressing R and return on the client side results on the server side in: read from 0x2c9978 [0x2d7abb] (5 bytes => 5 (0x5)) 0000 - 16 03 03 01 63 ....c read from 0x2c9978 [0x2d7ac0] (355 bytes => 355 (0x163)) SSL_accept:before SSL initialization SSL_accept:before SSL initialization SSL_accept:SSLv3/TLS read client hello SSL_accept:SSLv3/TLS write server hello SSL_accept:SSLv3/TLS write certificate SSL_accept:error in error ERROR 4280523828:error:14179044:SSL routines:tls_construct_server_key_exchange:internal error:statem/statem_srvr.c:1778: shutting down SSL CONNECTION CLOSED ACCEPT and on the client side R RENEGOTIATING SSL_connect:SSL negotiation finished successfully write to 0x2cf680 [0x2dbc13] (360 bytes => 360 (0x168)) ... SSL_connect:SSLv3/TLS write client hello read from 0x2cf680 [0x2d76c3] (5 bytes => 0 (0x0)) SSL_connect:error in SSLv3/TLS write client hello write:errno=0 error in s_client I ran into the same problem when trying to use OpenSSL 1.1.0pre2 in Apache for mod_ssl. The code in question is in tls_construct_server_key_exchange(). The following conditions triggers the jump to err: 1773 if (type & (SSL_kECDHE | SSL_kECDHEPSK)) { 1774 int nid; 1775 1776 if (s->s3->tmp.pkey != NULL) { 1777 SSLerr(SSL_F_TLS_CONSTRUCT_SERVER_KEY_EXCHANGE, 1778 ERR_R_INTERNAL_ERROR); 1779 goto err; 1780 } Using an AES reneg works, with ECDHE as above not. Regards, Rainer -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4303 Please log in as guest with password guest if prompted From tshort at akamai.com Fri Feb 12 18:59:39 2016 From: tshort at akamai.com (Short, Todd) Date: Fri, 12 Feb 2016 18:59:39 +0000 Subject: [openssl-dev] 3DES is a HIGH-strength cipher? Message-ID: <79B8A535-27A0-461F-A796-08FEB2B117AB@akamai.com> Hi, In OpenSSL 1.0.2, and 1.0.1i, 3DES-CBC?s bit-strength was changed from 168 to 112, which makes sense. However, it is still considered a HIGH-strength cipher. RC4 is listed as having a bit strength of MEDIUM, and is a 128-bit strength cipher (kinda). This is a bit contradictory. According to the OpenSSL cipher documentation, HIGH refers to 128-bit, or stronger, ciphers. Should 3DES ciphers be moved to the MEDIUM category? -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." -------------- next part -------------- An HTML attachment was scrubbed... URL: From richmoore44 at gmail.com Fri Feb 12 20:05:17 2016 From: richmoore44 at gmail.com (Richard Moore) Date: Fri, 12 Feb 2016 20:05:17 +0000 Subject: [openssl-dev] 3DES is a HIGH-strength cipher? In-Reply-To: <79B8A535-27A0-461F-A796-08FEB2B117AB@akamai.com> References: <79B8A535-27A0-461F-A796-08FEB2B117AB@akamai.com> Message-ID: On 12 February 2016 at 18:59, Short, Todd wrote: > Hi, > > In OpenSSL 1.0.2, and 1.0.1i, 3DES-CBC?s bit-strength was changed from 168 > to 112, which makes sense. However, it is still considered a HIGH-strength > cipher. > > RC4 is listed as having a bit strength of MEDIUM, and is a 128-bit > strength cipher (kinda). > > This is a bit contradictory. According to the OpenSSL cipher > documentation, HIGH refers to 128-bit, or stronger, ciphers. > > Should 3DES ciphers be moved to the MEDIUM category? > > ?I tend to agree with moving it to the medium category, but not with the reasoning. eg. We could have XOR with a 256 bit key and I still wouldn't want it to be considered as High. Rich. ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Fri Feb 12 20:06:27 2016 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 12 Feb 2016 20:06:27 +0000 Subject: [openssl-dev] 3DES is a HIGH-strength cipher? In-Reply-To: References: <79B8A535-27A0-461F-A796-08FEB2B117AB@akamai.com> Message-ID: <789e99e7c40a4d8b9b7a45f5bc9fc4bd@ustx2ex-dag1mb1.msg.corp.akamai.com> My personal opinion is that things like HIGH MEDIUM LOW are bad things ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Fri Feb 12 20:13:29 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 12 Feb 2016 15:13:29 -0500 Subject: [openssl-dev] 3DES is a HIGH-strength cipher? In-Reply-To: <79B8A535-27A0-461F-A796-08FEB2B117AB@akamai.com> References: <79B8A535-27A0-461F-A796-08FEB2B117AB@akamai.com> Message-ID: <86FA6564-7062-4359-A076-02EA1AA8FAD0@dukhovni.org> > On Feb 12, 2016, at 1:59 PM, Short, Todd wrote: > > This is a bit contradictory. According to the OpenSSL cipher documentation, HIGH refers to 128-bit, or stronger, ciphers. > > Should 3DES ciphers be moved to the MEDIUM category? 3DES is an MTI ciphersuite for TLS, so it must stay HIGH for now. -- Viktor. From rsalz at akamai.com Fri Feb 12 20:15:12 2016 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 12 Feb 2016 20:15:12 +0000 Subject: [openssl-dev] 3DES is a HIGH-strength cipher? In-Reply-To: <86FA6564-7062-4359-A076-02EA1AA8FAD0@dukhovni.org> References: <79B8A535-27A0-461F-A796-08FEB2B117AB@akamai.com> <86FA6564-7062-4359-A076-02EA1AA8FAD0@dukhovni.org> Message-ID: <04d2c3e893ac466293971abe2e1bcdd2@ustx2ex-dag1mb1.msg.corp.akamai.com> > 3DES is an MTI ciphersuite for TLS, so it must stay HIGH for now. Say what? So is RC4 and we don't see that as HIGH. HIGH implies strength, not MTI-ness. From openssl-users at dukhovni.org Fri Feb 12 20:36:36 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 12 Feb 2016 15:36:36 -0500 Subject: [openssl-dev] 3DES is a HIGH-strength cipher? In-Reply-To: <04d2c3e893ac466293971abe2e1bcdd2@ustx2ex-dag1mb1.msg.corp.akamai.com> References: <79B8A535-27A0-461F-A796-08FEB2B117AB@akamai.com> <86FA6564-7062-4359-A076-02EA1AA8FAD0@dukhovni.org> <04d2c3e893ac466293971abe2e1bcdd2@ustx2ex-dag1mb1.msg.corp.akamai.com> Message-ID: <3C7783E1-9ED0-4B5D-A5BF-C95F01C1DD99@dukhovni.org> > On Feb 12, 2016, at 3:15 PM, Salz, Rich wrote: > > So is RC4 and we don't see that as HIGH. HIGH implies strength, not MTI-ness. Now let's not make stuff up: http://tools.ietf.org/html/rfc5246#section-9 9. Mandatory Cipher Suites In the absence of an application profile standard specifying otherwise, a TLS-compliant application MUST implement the cipher suite TLS_RSA_WITH_AES_128_CBC_SHA (see Appendix A.5 for the definition). http://tools.ietf.org/html/rfc4346#section-9 9. Mandatory Cipher Suites In the absence of an application profile standard specifying otherwise, a TLS compliant application MUST implement the cipher suite TLS_RSA_WITH_3DES_EDE_CBC_SHA. http://tools.ietf.org/html/rfc2246#section-9 9. Mandatory Cipher Suites In the absence of an application profile standard specifying otherwise, a TLS compliant application MUST implement the cipher suite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA. Since many users enable just HIGH ciphers, they must not exclude the MTI ciphers. -- -- Viktor. From rsalz at akamai.com Fri Feb 12 20:39:03 2016 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 12 Feb 2016 20:39:03 +0000 Subject: [openssl-dev] 3DES is a HIGH-strength cipher? In-Reply-To: <3C7783E1-9ED0-4B5D-A5BF-C95F01C1DD99@dukhovni.org> References: <79B8A535-27A0-461F-A796-08FEB2B117AB@akamai.com> <86FA6564-7062-4359-A076-02EA1AA8FAD0@dukhovni.org> <04d2c3e893ac466293971abe2e1bcdd2@ustx2ex-dag1mb1.msg.corp.akamai.com> <3C7783E1-9ED0-4B5D-A5BF-C95F01C1DD99@dukhovni.org> Message-ID: <1aef58087f8d442982325c699a88fe63@ustx2ex-dag1mb1.msg.corp.akamai.com> > Now let's not make stuff up: Caught me, I should have looked it up first. :) > Since many users enable just HIGH ciphers, they must not exclude the MTI > ciphers. Sob. "So let's lie because many users don't know what to do." From tshort at akamai.com Fri Feb 12 20:52:16 2016 From: tshort at akamai.com (Short, Todd) Date: Fri, 12 Feb 2016 20:52:16 +0000 Subject: [openssl-dev] 3DES is a HIGH-strength cipher? In-Reply-To: <3C7783E1-9ED0-4B5D-A5BF-C95F01C1DD99@dukhovni.org> References: <79B8A535-27A0-461F-A796-08FEB2B117AB@akamai.com> <86FA6564-7062-4359-A076-02EA1AA8FAD0@dukhovni.org> <04d2c3e893ac466293971abe2e1bcdd2@ustx2ex-dag1mb1.msg.corp.akamai.com> <3C7783E1-9ED0-4B5D-A5BF-C95F01C1DD99@dukhovni.org> Message-ID: So, if it?s ?mandatory?, then it should be in the default set of ciphers, not necessarily the ?HIGH? set. I?m selecting ?HIGH? because I want 128-bit+ ciphers, not a cipher that that has subsequently found to be weaker than previously thought. -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." On Feb 12, 2016, at 3:36 PM, Viktor Dukhovni > wrote: On Feb 12, 2016, at 3:15 PM, Salz, Rich > wrote: So is RC4 and we don't see that as HIGH. HIGH implies strength, not MTI-ness. Now let's not make stuff up: http://tools.ietf.org/html/rfc5246#section-9 9. Mandatory Cipher Suites In the absence of an application profile standard specifying otherwise, a TLS-compliant application MUST implement the cipher suite TLS_RSA_WITH_AES_128_CBC_SHA (see Appendix A.5 for the definition). http://tools.ietf.org/html/rfc4346#section-9 9. Mandatory Cipher Suites In the absence of an application profile standard specifying otherwise, a TLS compliant application MUST implement the cipher suite TLS_RSA_WITH_3DES_EDE_CBC_SHA. http://tools.ietf.org/html/rfc2246#section-9 9. Mandatory Cipher Suites In the absence of an application profile standard specifying otherwise, a TLS compliant application MUST implement the cipher suite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA. Since many users enable just HIGH ciphers, they must not exclude the MTI ciphers. -- -- Viktor. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Fri Feb 12 21:03:24 2016 From: rt at openssl.org (Andy Polyakov via RT) Date: Fri, 12 Feb 2016 21:03:24 +0000 Subject: [openssl-dev] [openssl.org #4218] Invalid typecasting in CRYPTO_ctr128_encrypt In-Reply-To: <56BE489B.2040809@openssl.org> References: <20160105224225.GA9097@roeckx.be> <56BD13AA.5060706@openssl.org> <56BE489B.2040809@openssl.org> Message-ID: >>> OpenSSL 1.0.2e >>> >>> At line 156 of crypto/modes/ctr128.c >>> >>> const unsigned char *in, >>> unsigned char *out, >>> unsigned char ivec[16], >>> unsigned char ecount_buf[16] >>> >>> *(size_t *)(out + n) = >>> *(size_t *)(in + n) ^ *(size_t *)(ecount_buf + n); >>> >>> If the buffers are not aligned, the application crashes due to the invalid >>> type casting of unsigned char (1 byte) to size_t (4 to 8 bytes for most >>> CPU:s). >> >> You should not run into that issue if STRICT_ALIGNMENT is defined. > > Well, yes, except that it doesn't check for alignment of ecount_buf. I > mean there is 'if' clause for STRICT_ALIGNMENT that ensures that in, out > and ivec are aligned, but not ecount_buf. And judging from crash report, > it is ecount_buf that is not properly aligned (see last displayed > argument). So that original analysis is sane. It should be noted that it > looks like subroutine in question is called from application directly. > While if called from EVP, i.e. the usual way, the problem never occurs, > because that buffer is properly aligned within EVP_CIPHER_CTX structure. > Resolution will follow later... http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=5e4bbeb49fb6522d858703201b5adee9611e7b7b. Closing ticket. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4218 Please log in as guest with password guest if prompted From uri at ll.mit.edu Fri Feb 12 21:04:28 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Fri, 12 Feb 2016 21:04:28 +0000 Subject: [openssl-dev] 3DES is a HIGH-strength cipher? In-Reply-To: References: <79B8A535-27A0-461F-A796-08FEB2B117AB@akamai.com> <86FA6564-7062-4359-A076-02EA1AA8FAD0@dukhovni.org> <04d2c3e893ac466293971abe2e1bcdd2@ustx2ex-dag1mb1.msg.corp.akamai.com> <3C7783E1-9ED0-4B5D-A5BF-C95F01C1DD99@dukhovni.org> Message-ID: > So, if it?s ?mandatory?, then it should be in the default set of ciphers, not > necessarily the ?HIGH? set. > > I?m selecting ?HIGH? because I want 128-bit+ ciphers, not a cipher that that > has subsequently found to be weaker than previously thought. I used to think that MTI doesn?t mean ?Mandatory To Offer?. My codebase must have it, but my server (and/or client) configuration may explicitly forbid it. Is there anything wrong with this view? > -- > -Todd Short > // tshort at akamai.com > // "One if by land, two if by sea, three if by the Internet." > >> On Feb 12, 2016, at 3:36 PM, Viktor Dukhovni >> wrote: >> >> >>> On Feb 12, 2016, at 3:15 PM, Salz, Rich wrote: >>> >>> So is RC4 and we don't see that as HIGH. HIGH implies strength, not >>> MTI-ness. >> >> Now let's not make stuff up: >> >> http://tools.ietf.org/html/rfc5246#section-9 >> >> 9. Mandatory Cipher Suites >> >> In the absence of an application profile standard specifying >> otherwise, a TLS-compliant application MUST implement the cipher >> suite TLS_RSA_WITH_AES_128_CBC_SHA (see Appendix A.5 for the >> definition). >> >> http://tools.ietf.org/html/rfc4346#section-9 >> >> 9. Mandatory Cipher Suites >> >> In the absence of an application profile standard specifying >> otherwise, a TLS compliant application MUST implement the cipher >> suite TLS_RSA_WITH_3DES_EDE_CBC_SHA. >> >> http://tools.ietf.org/html/rfc2246#section-9 >> >> 9. Mandatory Cipher Suites >> >> In the absence of an application profile standard specifying >> otherwise, a TLS compliant application MUST implement the cipher >> suite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA. >> >> Since many users enable just HIGH ciphers, they must not exclude the MTI >> ciphers. >> >> -- >> -- >> Viktor. >> >> -- >> openssl-dev mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4324 bytes Desc: not available URL: From rsalz at akamai.com Fri Feb 12 21:06:38 2016 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 12 Feb 2016 21:06:38 +0000 Subject: [openssl-dev] 3DES is a HIGH-strength cipher? In-Reply-To: References: <79B8A535-27A0-461F-A796-08FEB2B117AB@akamai.com> <86FA6564-7062-4359-A076-02EA1AA8FAD0@dukhovni.org> <04d2c3e893ac466293971abe2e1bcdd2@ustx2ex-dag1mb1.msg.corp.akamai.com> <3C7783E1-9ED0-4B5D-A5BF-C95F01C1DD99@dukhovni.org> Message-ID: <9b7bc4c8c1ab40e38afab84a0403939b@ustx2ex-dag1mb1.msg.corp.akamai.com> > I used to think that MTI doesn?t mean ?Mandatory To Offer?. My codebase must have it, but my server (and/or client) configuration may explicitly forbid it. Is there anything wrong with this view? No. At least within the TLS WG this has been brought up multiple times. :) From openssl-users at dukhovni.org Fri Feb 12 21:12:10 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 12 Feb 2016 16:12:10 -0500 Subject: [openssl-dev] 3DES is a HIGH-strength cipher? In-Reply-To: References: <79B8A535-27A0-461F-A796-08FEB2B117AB@akamai.com> <86FA6564-7062-4359-A076-02EA1AA8FAD0@dukhovni.org> <04d2c3e893ac466293971abe2e1bcdd2@ustx2ex-dag1mb1.msg.corp.akamai.com> <3C7783E1-9ED0-4B5D-A5BF-C95F01C1DD99@dukhovni.org> Message-ID: <73BA3441-D846-4E97-848D-A0CFB0FA4614@dukhovni.org> > On Feb 12, 2016, at 3:52 PM, Short, Todd wrote: > > So, if it?s ?mandatory?, then it should be in the default set of ciphers, not necessarily the ?HIGH? set. > > I?m selecting ?HIGH? because I want 128-bit+ ciphers, not a cipher that that has subsequently found to be weaker than previously thought. 3DES was not found weaker than previously thought. It is as-strong as it ever was, with 168-bit keys that are subject to a meet-in-the-middle attack (at 2^56 memory cost) that brings the brute force effort to a way unrealistic 112-bit attack. The issue with 3DES its performance (slower than AES especially AESNI) and the short block size (8 bytes vs. 16). It is a cipher that has stood the test of time quite well. If you don't want 3DES, set your cipherlist to 'DEFAULT:!EXPORT:!LOW:!MEDIUM:!3DES' -- Viktor. From rsalz at akamai.com Fri Feb 12 21:15:05 2016 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 12 Feb 2016 21:15:05 +0000 Subject: [openssl-dev] 3DES is a HIGH-strength cipher? In-Reply-To: <73BA3441-D846-4E97-848D-A0CFB0FA4614@dukhovni.org> References: <79B8A535-27A0-461F-A796-08FEB2B117AB@akamai.com> <86FA6564-7062-4359-A076-02EA1AA8FAD0@dukhovni.org> <04d2c3e893ac466293971abe2e1bcdd2@ustx2ex-dag1mb1.msg.corp.akamai.com> <3C7783E1-9ED0-4B5D-A5BF-C95F01C1DD99@dukhovni.org> <73BA3441-D846-4E97-848D-A0CFB0FA4614@dukhovni.org> Message-ID: <1949822c5bed4adaa55b6b2f2e2b8cd5@ustx2ex-dag1mb1.msg.corp.akamai.com> Conversely, if you do want 3DES set your cipherlist to DEFAULT:3DES Or someone fix the manpage. :( From ppearl at zimbra.com Fri Feb 12 21:06:04 2016 From: ppearl at zimbra.com (Phil Pearl) Date: Fri, 12 Feb 2016 15:06:04 -0600 (CST) Subject: [openssl-dev] 3DES is a HIGH-strength cipher? In-Reply-To: References: <79B8A535-27A0-461F-A796-08FEB2B117AB@akamai.com> <86FA6564-7062-4359-A076-02EA1AA8FAD0@dukhovni.org> <04d2c3e893ac466293971abe2e1bcdd2@ustx2ex-dag1mb1.msg.corp.akamai.com> <3C7783E1-9ED0-4B5D-A5BF-C95F01C1DD99@dukhovni.org> Message-ID: <2032696507.811441.1455311164601.JavaMail.zimbra@zimbra.com> Seconding Uri and Todd's views... On Feb 12, 2016, at 3:36 PM, Todd Short wrote: >So, if it?s ?mandatory?, then it should be in the default set of > ciphers, not necessarily the ?HIGH? set. > > I?m selecting ?HIGH? because I want 128-bit+ ciphers, not a cipher > that that has subsequently found to be weaker than previously > thought. I have to agree. The docs on 'cipher' in no way convey that HIGH has any correlation to MTI (http://tools.ietf.org/html/rfc5246#section-9). My interpretation of the I IN MTI to mean "Implement" (an implementation detail necessary to meet the spec), but per the docs "HIGH" seems to indicate a choice of strength desired when running the software and therefore these seem a bit orthogonal. Is there no hope in softening that stance? Phil From openssl-users at dukhovni.org Fri Feb 12 21:26:34 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 12 Feb 2016 16:26:34 -0500 Subject: [openssl-dev] 3DES is a HIGH-strength cipher? In-Reply-To: <2032696507.811441.1455311164601.JavaMail.zimbra@zimbra.com> References: <79B8A535-27A0-461F-A796-08FEB2B117AB@akamai.com> <86FA6564-7062-4359-A076-02EA1AA8FAD0@dukhovni.org> <04d2c3e893ac466293971abe2e1bcdd2@ustx2ex-dag1mb1.msg.corp.akamai.com> <3C7783E1-9ED0-4B5D-A5BF-C95F01C1DD99@dukhovni.org> <2032696507.811441.1455311164601.JavaMail.zimbra@zimbra.com> Message-ID: <1AE932F8-3022-4631-B81C-6C3DA4ADD10E@dukhovni.org> > On Feb 12, 2016, at 4:06 PM, Phil Pearl wrote: > > I have to agree. The docs on 'cipher' in no way convey that HIGH has > any correlation to MTI (http://tools.ietf.org/html/rfc5246#section-9). > My interpretation of the I IN MTI to mean "Implement" (an > implementation detail necessary to meet the spec), but per the docs > "HIGH" seems to indicate a choice of strength desired when running the > software and therefore these seem a bit orthogonal. > > Is there no hope in softening that stance? Well, it would be a major compatibility break for 1.0.2 and earlier, so no go there. As for 1.1.0, folks who think that 3DES is realistically the weakest link in the security of their TLS sessions are quite misguided. If you are willing to disable TLS < 1.2, then feel free to disable 3DES. Breaking compatibility for everyone else is not a win. With TLS 1.3 AEAD is required, and 3DES goes away naturally. -- Viktor. From rsalz at akamai.com Fri Feb 12 21:29:08 2016 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 12 Feb 2016 21:29:08 +0000 Subject: [openssl-dev] 3DES is a HIGH-strength cipher? In-Reply-To: <1AE932F8-3022-4631-B81C-6C3DA4ADD10E@dukhovni.org> References: <79B8A535-27A0-461F-A796-08FEB2B117AB@akamai.com> <86FA6564-7062-4359-A076-02EA1AA8FAD0@dukhovni.org> <04d2c3e893ac466293971abe2e1bcdd2@ustx2ex-dag1mb1.msg.corp.akamai.com> <3C7783E1-9ED0-4B5D-A5BF-C95F01C1DD99@dukhovni.org> <2032696507.811441.1455311164601.JavaMail.zimbra@zimbra.com> <1AE932F8-3022-4631-B81C-6C3DA4ADD10E@dukhovni.org> Message-ID: <0ca00184c9854a8893aaf3fb1fcc3981@ustx2ex-dag1mb1.msg.corp.akamai.com> > Well, it would be a major compatibility break for 1.0.2 and earlier, so no go > there. As for 1.1.0, folks Or those who trust us to say what HIGH means should, well, not be lied to. Something must be changed for 1.1 Either 3DES moves out of HIGH or the definition of HIGH as documented in the manpage must change. From kudzu at tenebras.com Fri Feb 12 21:38:32 2016 From: kudzu at tenebras.com (Michael Sierchio) Date: Fri, 12 Feb 2016 13:38:32 -0800 Subject: [openssl-dev] 3DES is a HIGH-strength cipher? In-Reply-To: <0ca00184c9854a8893aaf3fb1fcc3981@ustx2ex-dag1mb1.msg.corp.akamai.com> References: <79B8A535-27A0-461F-A796-08FEB2B117AB@akamai.com> <86FA6564-7062-4359-A076-02EA1AA8FAD0@dukhovni.org> <04d2c3e893ac466293971abe2e1bcdd2@ustx2ex-dag1mb1.msg.corp.akamai.com> <3C7783E1-9ED0-4B5D-A5BF-C95F01C1DD99@dukhovni.org> <2032696507.811441.1455311164601.JavaMail.zimbra@zimbra.com> <1AE932F8-3022-4631-B81C-6C3DA4ADD10E@dukhovni.org> <0ca00184c9854a8893aaf3fb1fcc3981@ustx2ex-dag1mb1.msg.corp.akamai.com> Message-ID: I think you should revert to your earlier comment - that High, Medium, Low are inherently awful. Maybe color codes? ;-) I consider 3DES-EDE to be adequately strong. The block size is a problem, speed in software is a problem, etc. but it has been remarkably resilient against differential cryptanalysis and other attacks. - M On Fri, Feb 12, 2016 at 1:29 PM, Salz, Rich wrote: > > > Well, it would be a major compatibility break for 1.0.2 and earlier, so > no go > > there. As for 1.1.0, folks > > Or those who trust us to say what HIGH means should, well, not be lied to. > > Something must be changed for 1.1 Either 3DES moves out of HIGH or the > definition of HIGH as documented in the manpage must change. > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Fri Feb 12 22:05:41 2016 From: rt at openssl.org (Gomes, Robert via RT) Date: Fri, 12 Feb 2016 22:05:41 +0000 Subject: [openssl-dev] [openssl.org #4229] Bug - OpenSSL 1.0.2e on AIX has sha256p8-ppc.s assembler build issue... In-Reply-To: References: <0282ac07112643ff8f6275bab024a048@USRIPVDMAIL3.gtk.gtech.com> <56BD0CEC.8030203@openssl.org> <56BE19FC.20709@oracle.com> Message-ID: Hi, Per Jeremy Farrell's suggestion, specifying the "-no-asm" option worked and I was able to get through the build. Regarding the "stvx" instruction, here is a bit clearer set of info to map to why that instruction seemed to be the issue: ./crypto/sha/sha256p8-ppc.s AES_ASM -c -o sha256p8-ppc.o sha256p8-ppc.s Assembler: sha256p8-ppc.s: line 11: invalid opcode or pseudo-op sha256p8-ppc.s: line 14: invalid opcode or pseudo-op sha256p8-ppc.s: line 16: invalid opcode or pseudo-op sha256p8-ppc.s: line 18: invalid opcode or pseudo-op sha256p8-ppc.s: line 20: invalid opcode or pseudo-op sha256p8-ppc.s: line 22: invalid opcode or pseudo-op sha256p8-ppc.s: line 24: invalid opcode or pseudo-op The diags correspond to the "stvx" instruction: 01 .machine "any" 02 .csect .text[PR],7 03 04 .globl .sha256_block_p8 05 .align 6 06 .sha256_block_p8: 07 stdu 1,-448(1) 08 mflr 8 09 li 10,207 10 li 11,223 11 stvx 20,10,1 12 addi 10,10,32 13 li 12,-1 14 stvx 21,11,1 15 addi 11,11,32 16 stvx 22,10,1 17 addi 10,10,32 18 stvx 23,11,1 19 addi 11,11,32 20 stvx 24,10,1 21 addi 10,10,32 22 stvx 25,11,1 23 addi 11,11,32 24 stvx 26,10,1 Note that I understand that AIX 5.2 is old, however the original inquiry was more driven by the unexpected build issue with OpenSSL 1.0.2e, since I was able to build 1.0.1c fine - however, perhaps it was just coincidence that AIX 5.2 builds happened to work before ;) Thanks. -----Original Message----- From: Jeremy Farrell via RT [mailto:rt at openssl.org] Sent: Friday, February 12, 2016 12:45 PM To: Gomes, Robert Cc: openssl-dev at openssl.org Subject: Re: [openssl-dev] [openssl.org #4229] Bug - OpenSSL 1.0.2e on AIX has sha256p8-ppc.s assembler build issue... On 11/02/2016 22:36, Andy Polyakov via RT wrote: >> I am attempting to build OpenSSL 1.0.2e on AIX and I'm seeing an issue with the "stvx" assembler instruction in the sha256p8-ppc.s module. I have built prior version OpenSSL packages on AIX without issue until now (prior was 1.0.1c), and I haven't varied the steps I typically use. Specifics are: >> >> AIX: 5200-08 > I'm not quite familiar with AIX lingo. What does 5200-08 mean? Is it 5.2? Yes, AIX 5.2 TL 8. I believe that IBM stopped providing fixes for that particular technology level in February 2007, stopped standard support for AIX 5.2 final technology level (TL 10) in April 2009, stopped admitting to ever having heard of 5.2 sometime in 2012. no-asm seems to be the appropriate way to deal with this. -- J. J. Farrell -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4229 Please log in as guest with password guest if prompted CONFIDENTIALITY NOTICE: This message is the property of International Game Technology PLC and/or its subsidiaries and may contain proprietary, confidential or trade secret information. This message is intended solely for the use of the addressee. If you are not the intended recipient and have received this message in error, please delete this message from your system. Any unauthorized reading, distribution, copying, or other use of this message or its attachments is strictly prohibited. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4229 Please log in as guest with password guest if prompted From richmoore44 at gmail.com Fri Feb 12 23:55:28 2016 From: richmoore44 at gmail.com (Richard Moore) Date: Fri, 12 Feb 2016 23:55:28 +0000 Subject: [openssl-dev] 3DES is a HIGH-strength cipher? In-Reply-To: <0ca00184c9854a8893aaf3fb1fcc3981@ustx2ex-dag1mb1.msg.corp.akamai.com> References: <79B8A535-27A0-461F-A796-08FEB2B117AB@akamai.com> <86FA6564-7062-4359-A076-02EA1AA8FAD0@dukhovni.org> <04d2c3e893ac466293971abe2e1bcdd2@ustx2ex-dag1mb1.msg.corp.akamai.com> <3C7783E1-9ED0-4B5D-A5BF-C95F01C1DD99@dukhovni.org> <2032696507.811441.1455311164601.JavaMail.zimbra@zimbra.com> <1AE932F8-3022-4631-B81C-6C3DA4ADD10E@dukhovni.org> <0ca00184c9854a8893aaf3fb1fcc3981@ustx2ex-dag1mb1.msg.corp.akamai.com> Message-ID: On 12 February 2016 at 21:29, Salz, Rich wrote: > > > Well, it would be a major compatibility break for 1.0.2 and earlier, so > no go > > there. As for 1.1.0, folks > > Or those who trust us to say what HIGH means should, well, not be lied to. > > Something must be changed for 1.1 Either 3DES moves out of HIGH or the > definition of HIGH as documented in the manpage must change. > > ?Personally I think the fact that HIGH includes ciphersuites that offer no MITM protection means that those who trust it have already been totally betrayed. Rich. ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Sat Feb 13 00:16:38 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 12 Feb 2016 19:16:38 -0500 Subject: [openssl-dev] 3DES is a HIGH-strength cipher? In-Reply-To: References: <79B8A535-27A0-461F-A796-08FEB2B117AB@akamai.com> <86FA6564-7062-4359-A076-02EA1AA8FAD0@dukhovni.org> <04d2c3e893ac466293971abe2e1bcdd2@ustx2ex-dag1mb1.msg.corp.akamai.com> <3C7783E1-9ED0-4B5D-A5BF-C95F01C1DD99@dukhovni.org> <2032696507.811441.1455311164601.JavaMail.zimbra@zimbra.com> <1AE932F8-3022-4631-B81C-6C3DA4ADD10E@dukhovni.org> <0ca00184c9854a8893aaf3fb1fcc3981@ustx2ex-dag1mb1.msg.corp.akamai.com> Message-ID: <088D237B-C24B-4934-93D6-C4C471914838@dukhovni.org> > On Feb 12, 2016, at 6:55 PM, Richard Moore wrote: > > ?Personally I think the fact that HIGH includes ciphersuites that offer no MITM protection means that those who trust it have already been totally betrayed. The correct way to use high-grade ciphers is. "DEFAULT:!EXPORT:!LOW:!MEDIUM" The various individual cipherlist building blocks are properly orthogonal, and HIGH/MEDIUM/LOW/EXPORT covers only the symmetric algorithm strength. One can also use it safely via constructs such as "HIGH:!aNULL:!aDSS:!kRSA" (if say one also wants to disable DSA and RSA key transport). -- -- Viktor. From richmoore44 at gmail.com Sat Feb 13 00:21:34 2016 From: richmoore44 at gmail.com (Richard Moore) Date: Sat, 13 Feb 2016 00:21:34 +0000 Subject: [openssl-dev] 3DES is a HIGH-strength cipher? In-Reply-To: <088D237B-C24B-4934-93D6-C4C471914838@dukhovni.org> References: <79B8A535-27A0-461F-A796-08FEB2B117AB@akamai.com> <86FA6564-7062-4359-A076-02EA1AA8FAD0@dukhovni.org> <04d2c3e893ac466293971abe2e1bcdd2@ustx2ex-dag1mb1.msg.corp.akamai.com> <3C7783E1-9ED0-4B5D-A5BF-C95F01C1DD99@dukhovni.org> <2032696507.811441.1455311164601.JavaMail.zimbra@zimbra.com> <1AE932F8-3022-4631-B81C-6C3DA4ADD10E@dukhovni.org> <0ca00184c9854a8893aaf3fb1fcc3981@ustx2ex-dag1mb1.msg.corp.akamai.com> <088D237B-C24B-4934-93D6-C4C471914838@dukhovni.org> Message-ID: On 13 February 2016 at 00:16, Viktor Dukhovni wrote: > > > On Feb 12, 2016, at 6:55 PM, Richard Moore > wrote: > > > > ?Personally I think the fact that HIGH includes ciphersuites that offer > no MITM protection means that those who trust it have already been totally > betrayed. > > The correct way to use high-grade ciphers is. > > "DEFAULT:!EXPORT:!LOW:!MEDIUM" > > The various individual cipherlist building blocks are properly orthogonal, > and HIGH/MEDIUM/LOW/EXPORT covers only the symmetric algorithm strength. > > One can also use it safely via constructs such as "HIGH:!aNULL:!aDSS:!kRSA" > (if say one also wants to disable DSA and RSA key transport). > ?Yeah, the apache docs didn't say this for /many/ years and it was rejected when I reported it as a security problem. The docs had been correct I believe with some older versions of openssl but the more general point is that users need a setting that doesn't require expertise, a decoder ring or a secret handshake. I think we need to reach a point where DEFAULT is the only sensible option for users without extensive expertise and means to ensure that they don't make things worse by mistake. HIGH currently is a dangerous option. Rich. ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Sat Feb 13 00:32:42 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 12 Feb 2016 19:32:42 -0500 Subject: [openssl-dev] 3DES is a HIGH-strength cipher? In-Reply-To: References: <79B8A535-27A0-461F-A796-08FEB2B117AB@akamai.com> <86FA6564-7062-4359-A076-02EA1AA8FAD0@dukhovni.org> <04d2c3e893ac466293971abe2e1bcdd2@ustx2ex-dag1mb1.msg.corp.akamai.com> <3C7783E1-9ED0-4B5D-A5BF-C95F01C1DD99@dukhovni.org> <2032696507.811441.1455311164601.JavaMail.zimbra@zimbra.com> <1AE932F8-3022-4631-B81C-6C3DA4ADD10E@dukhovni.org> <0ca00184c9854a8893aaf3fb1fcc3981@ustx2ex-dag1mb1.msg.corp.akamai.com> <088D237B-C24B-4934-93D6-C4C471914838@dukhovni.org> Message-ID: <4BEF5091-2AF4-48AB-A464-BC0C22D9501D@dukhovni.org> > On Feb 12, 2016, at 7:21 PM, Richard Moore wrote: > > Yeah, the apache docs didn't say this for /many/ years and it was rejected when I reported it as a security problem. The docs had been correct I believe with some older versions of openssl but the more general point is that users need a setting that doesn't require expertise, a decoder ring or a secret handshake. I think we need to reach a point where DEFAULT is the only sensible option for users without extensive expertise and means to ensure that they don't make things worse by mistake. HIGH currently is a dangerous option. The problem is too a good degree with Apache. They chose to expose a raw expert interface to users without exposing a safer alternative. Postfix uses the same OpenSSL libraries, but does not expect users to understand the details of OpenSSL cipherlists. Instead a safe interface is exposed to users, and the underlying cipherlists while also configurable are documented as "expert" configuration controls that most users should not touch. This does not mean that OpenSSL should not also provide additional safe "for dummies" controls, but in the mean-time applications are not absolved of the responsibility of providing appropriate interfaces for their users. -- Viktor. From rt at openssl.org Sat Feb 13 01:15:42 2016 From: rt at openssl.org (Rainer Jung via RT) Date: Sat, 13 Feb 2016 01:15:42 +0000 Subject: [openssl-dev] [openssl.org #4304] [Patch] Support HTTP-on-HTTPS-Error for OpenSSL 1.1.0 In-Reply-To: <56BE83AF.3050206@kippdata.de> References: <56BE83AF.3050206@kippdata.de> Message-ID: Hi there, please find attached a patch proposal to reintroduce the HTTP-on-HTTPS detection for OpenSSL 1.1.0. The feature is present until 1.0.2, but although the error codes are still in the 1.1.0 header files, the detection is gone. Comments welcome! Regards, Rainer -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4304 Please log in as guest with password guest if prompted -------------- next part -------------- A non-text attachment was scrubbed... Name: http-on-https.patch Type: text/x-diff Size: 1072 bytes Desc: not available URL: From pwalten at au1.ibm.com Sat Feb 13 01:51:45 2016 From: pwalten at au1.ibm.com (Peter Waltenberg) Date: Sat, 13 Feb 2016 01:51:45 +0000 Subject: [openssl-dev] [openssl.org #4229] Bug - OpenSSL 1.0.2e on AIX has sha256p8-ppc.s assembler build issue... In-Reply-To: References: , <0282ac07112643ff8f6275bab024a048@USRIPVDMAIL3.gtk.gtech.com> <56BD0CEC.8030203@openssl.org> <56BE19FC.20709@oracle.com> Message-ID: <201602130152.u1D1pxEA019490@d23av01.au.ibm.com> An HTML attachment was scrubbed... URL: From rt at openssl.org Sat Feb 13 01:53:00 2016 From: rt at openssl.org (Peter Waltenberg via RT) Date: Sat, 13 Feb 2016 01:53:00 +0000 Subject: [openssl-dev] [openssl.org #4229] Bug - OpenSSL 1.0.2e on AIX has sha256p8-ppc.s assembler build issue... In-Reply-To: <201602130152.u1D1pxVh002250@d23av03.au.ibm.com> References: , <0282ac07112643ff8f6275bab024a048@USRIPVDMAIL3.gtk.gtech.com> <56BD0CEC.8030203@openssl.org> <56BE19FC.20709@oracle.com> <201602130152.u1D1pxVh002250@d23av03.au.ibm.com> Message-ID: You can also add some more macros to the perlasm which already translates a LOT of opcodes into something older assemblers won't choke on. Pete -----"openssl-dev" wrote: -----To: Robert.Gomes at IGT.com From: Jeremy Farrell via RT Sent by: "openssl-dev" Date: 02/13/2016 03:46AM Cc: openssl-dev at openssl.org Subject: Re: [openssl-dev] [openssl.org #4229] Bug - OpenSSL 1.0.2e on AIX has sha256p8-ppc.s assembler build issue... On 11/02/2016 22:36, Andy Polyakov via RT wrote: >> I am attempting to build OpenSSL 1.0.2e on AIX and I'm seeing an issue with the "stvx" assembler instruction in the sha256p8-ppc.s module. I have built prior version OpenSSL packages on AIX without issue until now (prior was 1.0.1c), and I haven't varied the steps I typically use. Specifics are: >> >> AIX: 5200-08 > I'm not quite familiar with AIX lingo. What does 5200-08 mean? Is it 5.2? Yes, AIX 5.2 TL 8. I believe that IBM stopped providing fixes for that particular technology level in February 2007, stopped standard support for AIX 5.2 final technology level (TL 10) in April 2009, stopped admitting to ever having heard of 5.2 sometime in 2012. no-asm seems to be the appropriate way to deal with this. -- J. J. Farrell -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4229 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4229 Please log in as guest with password guest if prompted From rt at openssl.org Sat Feb 13 03:50:02 2016 From: rt at openssl.org (David Benjamin via RT) Date: Sat, 13 Feb 2016 03:50:02 +0000 Subject: [openssl-dev] [openssl.org #4305] ChaCha20 assembly bugs In-Reply-To: References: Message-ID: Hi folks, I've started playing with the ChaCha20 assembly that was recently checked in and found a few problems. Most of these do not affect OpenSSL as you only ever call ChaCha20_ctr32 on a whole number of blocks. But this isn't documented as a constraint in internal/chacha.h and the assembly has code for partial blocks, so it seems it was supposed to work. (If not, I'd recommend removing the codepaths and documenting the constraint.) 1. In chacha-x86_64.pl, .Ltail: https://git.openssl.org/gitweb/?p=openssl.git;a=blob;f=crypto/chacha/asm/chacha-x86_64.pl;h=41dbef51b26db07a78d8939c728a8da5c703d806;hb=HEAD#l345 the xor %rbx,%rbx line clobbers @x[1] right before it is read. (@x[1] is %rbx.) It should be moved one line down or a different register used. 2. In chacha-x86_64.pl, .Loop_tail_ssse3: https://git.openssl.org/gitweb/?p=openssl.git;a=blob;f=crypto/chacha/asm/chacha-x86_64.pl;h=41dbef51b26db07a78d8939c728a8da5c703d806;hb=HEAD#l522 The length decrement loop is wrong and instead counts up from 0 to 2^64. It also clobbers $len because $len is %rdx. This seems to work instead: .Loop_tail_ssse3: movzb ($inp,%rbx),%eax movzb (%rsp,%rbx),%ecx lea 1(%rbx),%rbx xor %ecx,%eax mov %al,-1($out,%rbx) dec $len jnz .Loop_tail_ssse3 3. In chacha-x86.pl, loop: https://git.openssl.org/gitweb/?p=openssl.git;a=blob;f=crypto/chacha/asm/chacha-x86.pl;h=60d604882f76c227798895da6fafd798834f467a;hb=HEAD#l207 The line: &mov ($b,&wparam(3)); # load len should say: &mov ($b,&wparam(2)); # load len wparam(3) is the pointer to the key. This works in OpenSSL's calls because pointers are typically larger than 64, and that's sufficient for the codepaths you exercise. 4. The assembly versions crash if you pass in an empty input/output. The generic C code handles this fine. (I'll defer to you whether this is a bug or a caller obligation to be documented.) I have not tested the AVX2 or XOP code yet. I'll let you know if I find problems. David -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4305 Please log in as guest with password guest if prompted From director at openca.org Sat Feb 13 09:37:13 2016 From: director at openca.org (Dr. Pala) Date: Sat, 13 Feb 2016 09:37:13 +0000 Subject: [openssl-dev] 3DES is a HIGH-strength cipher? In-Reply-To: <0ca00184c9854a8893aaf3fb1fcc3981@ustx2ex-dag1mb1.msg.corp.akamai.com> References: <79B8A535-27A0-461F-A796-08FEB2B117AB@akamai.com> <86FA6564-7062-4359-A076-02EA1AA8FAD0@dukhovni.org> <04d2c3e893ac466293971abe2e1bcdd2@ustx2ex-dag1mb1.msg.corp.akamai.com> <3C7783E1-9ED0-4B5D-A5BF-C95F01C1DD99@dukhovni.org> <2032696507.811441.1455311164601.JavaMail.zimbra@zimbra.com> <1AE932F8-3022-4631-B81C-6C3DA4ADD10E@dukhovni.org> <0ca00184c9854a8893aaf3fb1fcc3981@ustx2ex-dag1mb1.msg.corp.akamai.com> Message-ID: <297C6DCF-7B59-463B-8B75-F41571BF25E8@openca.org> +1 Also, I would like to add that companies and some "security" appliances vendors really fail to understand the different ciphers properties (especially outside the web world). Therefore, IMHO, providing a more fool-proof configuration (e.g. a strict definition of HIGH and disabling the rest by default) is something I would really welcome and recommend for future releases. Cheers, Max > On Feb 12, 2016, at 9:29 PM, Salz, Rich wrote: > > >> Well, it would be a major compatibility break for 1.0.2 and earlier, so no go >> there. As for 1.1.0, folks > > Or those who trust us to say what HIGH means should, well, not be lied to. > > Something must be changed for 1.1 Either 3DES moves out of HIGH or the definition of HIGH as documented in the manpage must change. > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2374 bytes Desc: not available URL: From rt at openssl.org Sat Feb 13 09:51:28 2016 From: rt at openssl.org (Andy Polyakov via RT) Date: Sat, 13 Feb 2016 09:51:28 +0000 Subject: [openssl-dev] [openssl.org #4210] Compiler warning for Sparc T4 DES opcodes In-Reply-To: <56BEFC9B.6060208@openssl.org> References: <56846513.5070605@kippdata.de> <56BEFC9B.6060208@openssl.org> Message-ID: > OpenSSL 1.1.0 Pre 1 > Platform: Sparc Solaris 10 > Compiler: GCC 4.9.3 > > Warnings: > > e_des.c: In function 'des_init_key': > e_des.c:239:29: warning: assignment from incompatible pointer type > dat->stream.cbc = enc ? des_t4_cbc_encrypt : > des_t4_cbc_decrypt; > ^ > e_des3.c: In function 'des_ede_init_key': > e_des3.c:266:29: warning: assignment from incompatible pointer type > dat->stream.cbc = enc ? des_t4_ede3_cbc_encrypt : > ^ > e_des3.c: In function 'des_ede3_init_key': > e_des3.c:293:29: warning: assignment from incompatible pointer type > dat->stream.cbc = enc ? des_t4_ede3_cbc_encrypt : Addressed in http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=7687f5255011a5a3ca75e8c5427683d58ae411c0 (and there is 1.0.2-specific too). Closing the ticket. Thanks. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4210 Please log in as guest with password guest if prompted From rt at openssl.org Sat Feb 13 10:20:20 2016 From: rt at openssl.org (Andy Polyakov via RT) Date: Sat, 13 Feb 2016 10:20:20 +0000 Subject: [openssl-dev] [openssl.org #4229] Bug - OpenSSL 1.0.2e on AIX has sha256p8-ppc.s assembler build issue... In-Reply-To: <56BF0363.6060405@openssl.org> References: <0282ac07112643ff8f6275bab024a048@USRIPVDMAIL3.gtk.gtech.com> <56BD0CEC.8030203@openssl.org> <56BE19FC.20709@oracle.com> <201602130152.u1D1pxVh002250@d23av03.au.ibm.com> <56BF0363.6060405@openssl.org> Message-ID: > You can also add some more macros to the perlasm which already translates a > LOT of opcodes into something older assemblers won't choke on. If it was a matter of few instructions, then absolutely. But if it's a question about *all* vector instructions, then it becomes counter-productive. As already mentioned, in situation like this it *would* be more appropriate to discuss *option* of disabling vector code altogether. Rather than implementing complete AltiVec support in perlasm that is. But as long as we are talking about one obsolete platform(*), any non-trivial effort becomes questionable. To draw a parallel, why doesn't IBM provide AIX 5.2 users with more capable assembler? What I'm trying to say is that whatever reason that is articulated, similar one can be formulated on OpenSSL behalf. (*) I'm not referring to AIX as obsolete platform, but to obsolete AIX *versions*. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4229 Please log in as guest with password guest if prompted From rt at openssl.org Sat Feb 13 10:33:18 2016 From: rt at openssl.org (Andy Polyakov via RT) Date: Sat, 13 Feb 2016 10:33:18 +0000 Subject: [openssl-dev] [openssl.org #4229] Bug - OpenSSL 1.0.2e on AIX has sha256p8-ppc.s assembler build issue... In-Reply-To: <56BF066D.4030202@openssl.org> References: <0282ac07112643ff8f6275bab024a048@USRIPVDMAIL3.gtk.gtech.com> <56BD0CEC.8030203@openssl.org> <56BE19FC.20709@oracle.com> <56BF066D.4030202@openssl.org> Message-ID: Hi, > Per Jeremy Farrell's suggestion, specifying the "-no-asm" option worked and I was able to get through the build. > > Regarding the "stvx" instruction, here is a bit clearer set of info to map to why that instruction seemed to be the issue: Original report listed even last lines in error output, and those were referring to lvx instructions. So that insisting on problem being limited to stvx by limiting error output doesn't make it clearer. Question still is if tool-chain in question supports vector instruction *at all*. If it doesn't, then no-asm is the only option that can be offered. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4229 Please log in as guest with password guest if prompted From rt at openssl.org Sat Feb 13 10:48:42 2016 From: rt at openssl.org (Andy Polyakov via RT) Date: Sat, 13 Feb 2016 10:48:42 +0000 Subject: [openssl-dev] [openssl.org #4230] apps/speed.c does not handle ghash in the no-SIGALRM case In-Reply-To: <56BF0A09.3030504@openssl.org> References: <56956629.50300@akamai.com> <56BF0A09.3030504@openssl.org> Message-ID: > It looks like in the #ifndef SIGALRM case, c[D_GHASH][0] is set, but not > c[D_GHASH][i] for larger i. Fixed in master. > (Where is the no-SIGALRM code used?) Nowhere 99.9999997% cares about. Originally it was used extensively on Windows (i.e. among those majority cared about), but then even that switched to equivalent of asynchronous alarm. Closing ticket. Thanks. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4230 Please log in as guest with password guest if prompted From rt at openssl.org Sat Feb 13 12:46:47 2016 From: rt at openssl.org (Andy Polyakov via RT) Date: Sat, 13 Feb 2016 12:46:47 +0000 Subject: [openssl-dev] [openssl.org #4305] ChaCha20 assembly bugs In-Reply-To: <56BF25B3.4060209@openssl.org> References: <56BF25B3.4060209@openssl.org> Message-ID: Hi, > I've started playing with the ChaCha20 assembly that was recently checked > in and found a few problems. Most of these do not affect OpenSSL as you > only ever call ChaCha20_ctr32 on a whole number of blocks. But this isn't > documented as a constraint in internal/chacha.h and the assembly has code > for partial blocks, so it seems it was supposed to work. (If not, I'd > recommend removing the codepaths and documenting the constraint.) Idea behind implementing partial blocks and not using them is to reserve for code reuse in contexts other than OpenSSL. > 1. In chacha-x86_64.pl, .Ltail: > > 2. In chacha-x86_64.pl, .Loop_tail_ssse3: > > 3. In chacha-x86.pl, loop: Fix is upcoming. Thanks! > 4. The assembly versions crash if you pass in an empty input/output. The > generic C code handles this fine. (I'll defer to you whether this is a bug > or a caller obligation to be documented.) This will be addressed separately by fixing all modules. I mean not all modules have this problem, but all modules will be double-checked and fixed as required. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4305 Please log in as guest with password guest if prompted From rt at openssl.org Sat Feb 13 13:20:11 2016 From: rt at openssl.org (Stephen Henson via RT) Date: Sat, 13 Feb 2016 13:20:11 +0000 Subject: [openssl-dev] [openssl.org #4303] OpenSSL 1.1.0 renegotiation problem (s_server/s_client) In-Reply-To: <56BE2238.6060606@kippdata.de> References: <56BE2238.6060606@kippdata.de> Message-ID: On Fri Feb 12 18:41:41 2016, rainer.jung at kippdata.de wrote: > Using OpenSSL 1.1.0pre2 I see renegotiation problems between s_client > and s_server (but also in Apache mod_ssl). > Fixed in commit 5b326dc529e19194 Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4303 Please log in as guest with password guest if prompted From andrewponomarenko at yandex.ru Sat Feb 13 16:06:11 2016 From: andrewponomarenko at yandex.ru (Ponomarenko Andrey) Date: Sat, 13 Feb 2016 19:06:11 +0300 Subject: [openssl-dev] Verification of ABI compatibility In-Reply-To: <56A8EBC1.5090803@cisco.com> References: <56A8EBC1.5090803@cisco.com> Message-ID: <6446851455379571@web20g.yandex.ru> Hello John, 1. Please update ABICC and ABI Dumper tools. You are currently using too old versions 1.99.9 and 0.99.7. The newer ones are 1.99.16 and 0.99.14. There are a lot of improvements: https://github.com/lvc The update is easy. Just unpack tarballs and type `sudo make install`. 2. Please follow instructions on the page https://wiki.openssl.org/index.php/Binary_Compatibility in order to: a) filter out private part of the ABI from dumps b) fix version numbers in the report Thank you. 27.01.2016, 19:19, "John Foley": > If anyone is interested, I've added a new build to the Jenkins workflow > to verify ABI compatibility on the 1.0.2-stable branch. This job will > run nightly and look for ABI differences between the current build and > the build from the previous night. If a commit goes into the branch > that changes ABI, this job should alert the openssl-commits alias. > > This results of this job can be viewed here: > > https://openssl-sanity.cisco.com:8443/view/1.0.2%20Stable/job/1_0_2_abi/ From rt at openssl.org Sat Feb 13 16:16:56 2016 From: rt at openssl.org (Felipe Sere via RT) Date: Sat, 13 Feb 2016 16:16:56 +0000 Subject: [openssl-dev] [openssl.org #4290] HMAC_Init_ex() return bug In-Reply-To: References: Message-ID: Hi, I am having the exact same problem, just that I use openssl through Rust. This is the error I am seeing: cargo run ? ? ?Running `target/debug/lantern` thread '
' panicked at 'assertion failed: `(left == right)` (left: `-1165085120`, right: `1`)', /Users/felipe/.multirust/toolchains/stable/cargo/registry/src/github.com-88ac128001ac3a9a/openssl-0.7.6/src/crypto/hmac.rs:100 Which points to the HMAC_Init_ex function. I am using OpenSSL 1.0.2f ?28 Jan 2016 on OSX 10.11.2 --? Felipe Sere Sent with Airmail -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4290 Please log in as guest with password guest if prompted From rt at openssl.org Sat Feb 13 16:36:42 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Sat, 13 Feb 2016 16:36:42 +0000 Subject: [openssl-dev] [openssl.org #4290] HMAC_Init_ex() return bug In-Reply-To: <0067fd9364e046a9be901c3d84b983b8@ustx2ex-dag1mb1.msg.corp.akamai.com> References: <0067fd9364e046a9be901c3d84b983b8@ustx2ex-dag1mb1.msg.corp.akamai.com> Message-ID: Is anyone non a non-Mac seeing this? I'm beginning to think compiler bug. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4290 Please log in as guest with password guest if prompted From rt at openssl.org Sat Feb 13 17:53:49 2016 From: rt at openssl.org (Felipe Sere via RT) Date: Sat, 13 Feb 2016 17:53:49 +0000 Subject: [openssl-dev] [openssl.org #4290] HMAC_Init_ex() return bu In-Reply-To: References: Message-ID: If it makes any difference, I build OpenSSL using hombrew which in turn used clang: $ clang --version Apple LLVM version 7.0.2 (clang-700.1.81) Target: x86_64-apple-darwin15.2.0 Thread model: posix --? Felipe Sere Sent with Airmail -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4290 Please log in as guest with password guest if prompted From rt at openssl.org Sat Feb 13 19:30:09 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sat, 13 Feb 2016 19:30:09 +0000 Subject: [openssl-dev] [openssl.org #4304] [Patch] Support HTTP-on-HTTPS-Error for OpenSSL 1.1.0 In-Reply-To: <56BE83AF.3050206@kippdata.de> References: <56BE83AF.3050206@kippdata.de> Message-ID: fixed with commie t124f6ff thanks! -- Rich Salz, OpenSSL dev team; rsalz at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4304 Please log in as guest with password guest if prompted From michel.sales at free.fr Sat Feb 13 22:19:20 2016 From: michel.sales at free.fr (Michel) Date: Sat, 13 Feb 2016 23:19:20 +0100 Subject: [openssl-dev] memory leaks detected using libSSL 1.1 Message-ID: <000001d166ac$9660f640$c322e2c0$@sales@free.fr> Hi, I have multithreaded test programs (client and server) that I use to test some functionalities build with OpenSSL. They started to warn about memory leaks when I linked them with version 1.1. As I had to do some code changes to adapt the new version, I first thought I forget some [new] init/free code. I finally used OPENSSL_cleanup() and alikes instead of the previous litany calls ;-), but still encounters leaks. As it was hard to track them down, I write a simple server test program that wait for a client and then return without even receiving data. No certificate are loaded. Leaks are detected only when a client handshake with the server. I might be wrong, but I do not think this is a false positive. Could you please have a look at the informations below and share your feelings ? Regards, Michel. Windows _CrtDumpMemoryLeaks() output : Detected memory leaks! Dumping objects -> {4697} normal block at 0x00822660, 140 bytes long. Data: < > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 {4696} normal block at 0x00822608, 24 bytes long. Data: < > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 {4695} normal block at 0x008225B0, 24 bytes long. Data: < > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 {4694} normal block at 0x00822558, 24 bytes long. Data: < > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 {4693} normal block at 0x00822488, 148 bytes long. Data: < & X% % > 00 00 00 00 08 26 82 00 58 25 82 00 B0 25 82 00 Object dump complete. WARNING: Visual Leak Detector detected memory leaks! ---------- Block 4677 at 0x00822488: 148 bytes ---------- Leak Hash: 0x76FECFA5, Count: 1, Total 148 bytes Call Stack (TID 2904): ntdll.dll!RtlAllocateHeap() f:\dd\vctools\crt\crtw32\misc\dbgmalloc.c (56): TestsTLS-11.exe!malloc() + 0x15 bytes e:\openssl-1.1.git\crypto\mem.c (138): TestsTLS-11.exe!CRYPTO_malloc() + 0x9 bytes e:\openssl-1.1.git\crypto\mem.c (158): TestsTLS-11.exe!CRYPTO_zalloc() + 0x11 bytes e:\openssl-1.1.git\crypto\hmac\hmac.c (174): TestsTLS-11.exe!HMAC_CTX_new() + 0xE bytes e:\openssl-1.1.git\ssl\t1_lib.c (3060): TestsTLS-11.exe!tls_decrypt_ticket() + 0x5 bytes e:\openssl-1.1.git\ssl\t1_lib.c (2994): TestsTLS-11.exe!tls_check_serverhello_tlsext_early() + 0x2F bytes e:\openssl-1.1.git\ssl\ssl_sess.c (536): TestsTLS-11.exe!ssl_get_prev_session() + 0x18 bytes e:\openssl-1.1.git\ssl\statem\statem_srvr.c (1181): TestsTLS-11.exe!tls_process_client_hello() + 0x11 bytes e:\openssl-1.1.git\ssl\statem\statem_srvr.c (804): TestsTLS-11.exe!ossl_statem_server_process_message() + 0xD bytes e:\openssl-1.1.git\ssl\statem\statem.c (609): TestsTLS-11.exe!read_state_machine() + 0xB bytes e:\openssl-1.1.git\ssl\statem\statem.c (429): TestsTLS-11.exe!state_machine() + 0x9 bytes e:\openssl-1.1.git\ssl\statem\statem.c (222): TestsTLS-11.exe!ossl_statem_accept() + 0xB bytes e:\openssl-1.1.git\ssl\ssl_lib.c (2908): TestsTLS-11.exe!SSL_do_handshake() + 0xC bytes p:\mes programmes\shared\ocrypto-11\tls.cpp (1017): TestsTLS-11.exe!OTLS::TLSSss::DoHandshake() + 0xC bytes p:\mes programmes\tests\_testsshared\teststls-11-leak - copie\testtls.cpp (202): TestsTLS-11.exe!main() + 0xB bytes f:\dd\vctools\crt\crtw32\startup\crt0.c (165): TestsTLS-11.exe!mainCRTStartup() ---------- Block 4678 at 0x00822558: 24 bytes ---------- Leak Hash: 0xEBA79111, Count: 1, Total 24 bytes Call Stack (TID 2904): ntdll.dll!RtlAllocateHeap() f:\dd\vctools\crt\crtw32\misc\dbgmalloc.c (56): TestsTLS-11.exe!malloc() + 0x15 bytes e:\openssl-1.1.git\crypto\mem.c (138): TestsTLS-11.exe!CRYPTO_malloc() + 0x9 bytes e:\openssl-1.1.git\crypto\mem.c (158): TestsTLS-11.exe!CRYPTO_zalloc() + 0x11 bytes e:\openssl-1.1.git\crypto\evp\digest.c (154): TestsTLS-11.exe!EVP_MD_CTX_new() + 0xB bytes e:\openssl-1.1.git\crypto\hmac\hmac.c (210): TestsTLS-11.exe!HMAC_CTX_reset() + 0x5 bytes e:\openssl-1.1.git\crypto\hmac\hmac.c (177): TestsTLS-11.exe!HMAC_CTX_new() + 0x9 bytes e:\openssl-1.1.git\ssl\t1_lib.c (3060): TestsTLS-11.exe!tls_decrypt_ticket() + 0x5 bytes e:\openssl-1.1.git\ssl\t1_lib.c (2994): TestsTLS-11.exe!tls_check_serverhello_tlsext_early() + 0x2F bytes e:\openssl-1.1.git\ssl\ssl_sess.c (536): TestsTLS-11.exe!ssl_get_prev_session() + 0x18 bytes e:\openssl-1.1.git\ssl\statem\statem_srvr.c (1181): TestsTLS-11.exe!tls_process_client_hello() + 0x11 bytes e:\openssl-1.1.git\ssl\statem\statem_srvr.c (804): TestsTLS-11.exe!ossl_statem_server_process_message() + 0xD bytes e:\openssl-1.1.git\ssl\statem\statem.c (609): TestsTLS-11.exe!read_state_machine() + 0xB bytes e:\openssl-1.1.git\ssl\statem\statem.c (429): TestsTLS-11.exe!state_machine() + 0x9 bytes e:\openssl-1.1.git\ssl\statem\statem.c (222): TestsTLS-11.exe!ossl_statem_accept() + 0xB bytes e:\openssl-1.1.git\ssl\ssl_lib.c (2908): TestsTLS-11.exe!SSL_do_handshake() + 0xC bytes p:\mes programmes\shared\ocrypto-11\tls.cpp (1017): TestsTLS-11.exe!OTLS::TLSSss::DoHandshake() + 0xC bytes p:\mes programmes\tests\_testsshared\teststls-11-leak - copie\testtls.cpp (202): TestsTLS-11.exe!main() + 0xB bytes f:\dd\vctools\crt\crtw32\startup\crt0.c (165): TestsTLS-11.exe!mainCRTStartup() ---------- Block 4679 at 0x008225B0: 24 bytes ---------- Leak Hash: 0x6479AA48, Count: 1, Total 24 bytes Call Stack (TID 2904): ntdll.dll!RtlAllocateHeap() f:\dd\vctools\crt\crtw32\misc\dbgmalloc.c (56): TestsTLS-11.exe!malloc() + 0x15 bytes e:\openssl-1.1.git\crypto\mem.c (138): TestsTLS-11.exe!CRYPTO_malloc() + 0x9 bytes e:\openssl-1.1.git\crypto\mem.c (158): TestsTLS-11.exe!CRYPTO_zalloc() + 0x11 bytes e:\openssl-1.1.git\crypto\evp\digest.c (154): TestsTLS-11.exe!EVP_MD_CTX_new() + 0xB bytes e:\openssl-1.1.git\crypto\hmac\hmac.c (214): TestsTLS-11.exe!HMAC_CTX_reset() + 0x5 bytes e:\openssl-1.1.git\crypto\hmac\hmac.c (177): TestsTLS-11.exe!HMAC_CTX_new() + 0x9 bytes e:\openssl-1.1.git\ssl\t1_lib.c (3060): TestsTLS-11.exe!tls_decrypt_ticket() + 0x5 bytes e:\openssl-1.1.git\ssl\t1_lib.c (2994): TestsTLS-11.exe!tls_check_serverhello_tlsext_early() + 0x2F bytes e:\openssl-1.1.git\ssl\ssl_sess.c (536): TestsTLS-11.exe!ssl_get_prev_session() + 0x18 bytes e:\openssl-1.1.git\ssl\statem\statem_srvr.c (1181): TestsTLS-11.exe!tls_process_client_hello() + 0x11 bytes e:\openssl-1.1.git\ssl\statem\statem_srvr.c (804): TestsTLS-11.exe!ossl_statem_server_process_message() + 0xD bytes e:\openssl-1.1.git\ssl\statem\statem.c (609): TestsTLS-11.exe!read_state_machine() + 0xB bytes e:\openssl-1.1.git\ssl\statem\statem.c (429): TestsTLS-11.exe!state_machine() + 0x9 bytes e:\openssl-1.1.git\ssl\statem\statem.c (222): TestsTLS-11.exe!ossl_statem_accept() + 0xB bytes e:\openssl-1.1.git\ssl\ssl_lib.c (2908): TestsTLS-11.exe!SSL_do_handshake() + 0xC bytes p:\mes programmes\shared\ocrypto-11\tls.cpp (1017): TestsTLS-11.exe!OTLS::TLSSss::DoHandshake() + 0xC bytes p:\mes programmes\tests\_testsshared\teststls-11-leak - copie\testtls.cpp (202): TestsTLS-11.exe!main() + 0xB bytes f:\dd\vctools\crt\crtw32\startup\crt0.c (165): TestsTLS-11.exe!mainCRTStartup() ---------- Block 4680 at 0x00822608: 24 bytes ---------- Leak Hash: 0x7CF76213, Count: 1, Total 24 bytes Call Stack (TID 2904): ntdll.dll!RtlAllocateHeap() f:\dd\vctools\crt\crtw32\misc\dbgmalloc.c (56): TestsTLS-11.exe!malloc() + 0x15 bytes e:\openssl-1.1.git\crypto\mem.c (138): TestsTLS-11.exe!CRYPTO_malloc() + 0x9 bytes e:\openssl-1.1.git\crypto\mem.c (158): TestsTLS-11.exe!CRYPTO_zalloc() + 0x11 bytes e:\openssl-1.1.git\crypto\evp\digest.c (154): TestsTLS-11.exe!EVP_MD_CTX_new() + 0xB bytes e:\openssl-1.1.git\crypto\hmac\hmac.c (218): TestsTLS-11.exe!HMAC_CTX_reset() + 0x5 bytes e:\openssl-1.1.git\crypto\hmac\hmac.c (177): TestsTLS-11.exe!HMAC_CTX_new() + 0x9 bytes e:\openssl-1.1.git\ssl\t1_lib.c (3060): TestsTLS-11.exe!tls_decrypt_ticket() + 0x5 bytes e:\openssl-1.1.git\ssl\t1_lib.c (2994): TestsTLS-11.exe!tls_check_serverhello_tlsext_early() + 0x2F bytes e:\openssl-1.1.git\ssl\ssl_sess.c (536): TestsTLS-11.exe!ssl_get_prev_session() + 0x18 bytes e:\openssl-1.1.git\ssl\statem\statem_srvr.c (1181): TestsTLS-11.exe!tls_process_client_hello() + 0x11 bytes e:\openssl-1.1.git\ssl\statem\statem_srvr.c (804): TestsTLS-11.exe!ossl_statem_server_process_message() + 0xD bytes e:\openssl-1.1.git\ssl\statem\statem.c (609): TestsTLS-11.exe!read_state_machine() + 0xB bytes e:\openssl-1.1.git\ssl\statem\statem.c (429): TestsTLS-11.exe!state_machine() + 0x9 bytes e:\openssl-1.1.git\ssl\statem\statem.c (222): TestsTLS-11.exe!ossl_statem_accept() + 0xB bytes e:\openssl-1.1.git\ssl\ssl_lib.c (2908): TestsTLS-11.exe!SSL_do_handshake() + 0xC bytes p:\mes programmes\shared\ocrypto-11\tls.cpp (1017): TestsTLS-11.exe!OTLS::TLSSss::DoHandshake() + 0xC bytes p:\mes programmes\tests\_testsshared\teststls-11-leak - copie\testtls.cpp (202): TestsTLS-11.exe!main() + 0xB bytes f:\dd\vctools\crt\crtw32\startup\crt0.c (165): TestsTLS-11.exe!mainCRTStartup() ---------- Block 4681 at 0x00822660: 140 bytes ---------- Leak Hash: 0x86320408, Count: 1, Total 140 bytes Call Stack (TID 2904): ntdll.dll!RtlAllocateHeap() f:\dd\vctools\crt\crtw32\misc\dbgmalloc.c (56): TestsTLS-11.exe!malloc() + 0x15 bytes e:\openssl-1.1.git\crypto\mem.c (138): TestsTLS-11.exe!CRYPTO_malloc() + 0x9 bytes e:\openssl-1.1.git\crypto\mem.c (158): TestsTLS-11.exe!CRYPTO_zalloc() + 0x11 bytes e:\openssl-1.1.git\crypto\evp\evp_enc.c (95): TestsTLS-11.exe!EVP_CIPHER_CTX_new() + 0xE bytes e:\openssl-1.1.git\ssl\t1_lib.c (3063): TestsTLS-11.exe!tls_decrypt_ticket() + 0x5 bytes e:\openssl-1.1.git\ssl\t1_lib.c (2994): TestsTLS-11.exe!tls_check_serverhello_tlsext_early() + 0x2F bytes e:\openssl-1.1.git\ssl\ssl_sess.c (536): TestsTLS-11.exe!ssl_get_prev_session() + 0x18 bytes e:\openssl-1.1.git\ssl\statem\statem_srvr.c (1181): TestsTLS-11.exe!tls_process_client_hello() + 0x11 bytes e:\openssl-1.1.git\ssl\statem\statem_srvr.c (804): TestsTLS-11.exe!ossl_statem_server_process_message() + 0xD bytes e:\openssl-1.1.git\ssl\statem\statem.c (609): TestsTLS-11.exe!read_state_machine() + 0xB bytes e:\openssl-1.1.git\ssl\statem\statem.c (429): TestsTLS-11.exe!state_machine() + 0x9 bytes e:\openssl-1.1.git\ssl\statem\statem.c (222): TestsTLS-11.exe!ossl_statem_accept() + 0xB bytes e:\openssl-1.1.git\ssl\ssl_lib.c (2908): TestsTLS-11.exe!SSL_do_handshake() + 0xC bytes p:\mes programmes\shared\ocrypto-11\tls.cpp (1017): TestsTLS-11.exe!OTLS::TLSSss::DoHandshake() + 0xC bytes p:\mes programmes\tests\_testsshared\teststls-11-leak - copie\testtls.cpp (202): TestsTLS-11.exe!main() + 0xB bytes f:\dd\vctools\crt\crtw32\startup\crt0.c (165): TestsTLS-11.exe!mainCRTStartup() Visual Leak Detector detected 5 memory leaks (10545 bytes). Largest number used: 138152 bytes. Total allocations: 611193 bytes. Visual Leak Detector is now exiting. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Sat Feb 13 23:30:16 2016 From: matt at openssl.org (Matt Caswell) Date: Sat, 13 Feb 2016 23:30:16 +0000 Subject: [openssl-dev] memory leaks detected using libSSL 1.1 In-Reply-To: <000001d166ac$9660f640$c322e2c0$@sales@free.fr> References: <000001d166ac$9660f640$c322e2c0$@sales@free.fr> Message-ID: <56BFBC88.1010901@openssl.org> On 13/02/16 22:19, Michel wrote: > Hi, > > > > I have multithreaded test programs (client and server) that I use to > test some functionalities build with OpenSSL. > > They started to warn about memory leaks when I linked them with version 1.1. > > As I had to do some code changes to adapt the new version, I first > thought I forget some [new] init/free code. > > I finally used OPENSSL_cleanup() and alikes instead of the previous > litany calls ;-), but still encounters leaks. > > As it was hard to track them down, I write a simple server test program > that wait for a client and then return without even receiving data. > > No certificate are loaded. > > Leaks are detected only when a client handshake with the server. > > > > I might be wrong, but I do not think this is a false positive. > > Could you please have a look at the informations below and share your > feelings ? Hmmm. It does look to me like there could be a memory leak here. What's not clear to me is to why you are only seeing this in 1.1 and not previous versions, as it looks like the same could happen in 1.0.2 as well! Anyway, please try the attached patch to see if that helps. Let me know how you get on. Thanks Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: tls_decrypt_ticket.patch Type: text/x-patch Size: 2281 bytes Desc: not available URL: From michel.sales at free.fr Sun Feb 14 00:11:01 2016 From: michel.sales at free.fr (Michel) Date: Sun, 14 Feb 2016 01:11:01 +0100 Subject: [openssl-dev] memory leaks detected using libSSL 1.1 In-Reply-To: <56BFBC88.1010901@openssl.org> References: <000001d166ac$9660f640$c322e2c0$@sales@free.fr> <56BFBC88.1010901@openssl.org> Message-ID: <000001d166bc$308f5680$91ae0380$@sales@free.fr> Hi Matt, Thanks for your quick answer. I applied your patch and it fixes the leaks found in the simple test program. However, a more complex one, still report [other] leaks. Below is a new log if you can have a look at them. I will investigate deeper tomorrow concering 1.0.2. Thanks again, Michel. Detected memory leaks! Dumping objects -> {4383} normal block at 0x006472C8, 8 bytes long. Data: < > 00 00 00 00 01 00 00 00 {4381} normal block at 0x00646B48, 12 bytes long. Data: < od } > D8 6F 64 00 00 00 00 00 20 7D 00 00 {4379} normal block at 0x00647248, 64 bytes long. Data: 48 6B 64 00 00 00 00 00 00 00 00 00 00 00 00 00 {4377} normal block at 0x006471A8, 96 bytes long. Data: 48 72 64 00 10 03 A5 00 30 03 A5 00 08 00 00 00 {4375} normal block at 0x00646FD8, 400 bytes long. Data: < > 00 00 00 00 A0 09 00 00 00 00 00 00 00 00 00 00 Object dump complete. WARNING: Visual Leak Detector detected memory leaks! ---------- Block 4363 at 0x00646B48: 12 bytes ---------- Leak Hash: 0xF7E93E2A, Count: 1, Total 12 bytes Call Stack (TID 2464): ntdll.dll!RtlAllocateHeap() f:\dd\vctools\crt\crtw32\misc\dbgmalloc.c (56): TestsTLS-11.exe!malloc() + 0x15 bytes e:\openssl-1.1.git\crypto\mem.c (138): TestsTLS-11.exe!CRYPTO_malloc() + 0x9 bytes e:\openssl-1.1.git\crypto\lhash\lhash.c (168): TestsTLS-11.exe!lh_insert() + 0xB bytes e:\openssl-1.1.git\crypto\err\err_lcl.h (2): TestsTLS-11.exe!lh_ERR_STATE_insert() + 0x10 bytes e:\openssl-1.1.git\crypto\err\err.c (371): TestsTLS-11.exe!int_thread_set_item() + 0xD bytes e:\openssl-1.1.git\crypto\err\err.c (884): TestsTLS-11.exe!ERR_get_state() + 0xC bytes e:\openssl-1.1.git\crypto\err\err.c (598): TestsTLS-11.exe!ERR_clear_error() + 0x5 bytes e:\openssl-1.1.git\ssl\statem\statem.c (279): TestsTLS-11.exe!state_machine() e:\openssl-1.1.git\ssl\statem\statem.c (217): TestsTLS-11.exe!ossl_statem_connect() + 0xB bytes e:\openssl-1.1.git\ssl\ssl_lib.c (2908): TestsTLS-11.exe!SSL_do_handshake() + 0xC bytes p:\mes programmes\shared\ocrypto-11\tls.cpp (1017): TestsTLS-11.exe!OTLS::TLSSss::DoHandshake() + 0xC bytes p:\mes programmes\tests\_testsshared\teststls-11-leak\clttasks.cpp (63): TestsTLS-11.exe!CltThread::Main() + 0xB bytes p:\mes programmes\shared\sthread.cpp (17): TestsTLS-11.exe!SThread::Run() + 0xE bytes f:\dd\vctools\crt\crtw32\startup\threadex.c (359): TestsTLS-11.exe!_threadstartex() ---------- Block 4357 at 0x00646FD8: 400 bytes ---------- Leak Hash: 0xC22F7275, Count: 1, Total 400 bytes Call Stack (TID 2464): ntdll.dll!RtlAllocateHeap() f:\dd\vctools\crt\crtw32\misc\dbgmalloc.c (56): TestsTLS-11.exe!malloc() + 0x15 bytes e:\openssl-1.1.git\crypto\mem.c (138): TestsTLS-11.exe!CRYPTO_malloc() + 0x9 bytes e:\openssl-1.1.git\crypto\err\err.c (874): TestsTLS-11.exe!ERR_get_state() + 0xE bytes e:\openssl-1.1.git\crypto\err\err.c (598): TestsTLS-11.exe!ERR_clear_error() + 0x5 bytes e:\openssl-1.1.git\ssl\statem\statem.c (279): TestsTLS-11.exe!state_machine() e:\openssl-1.1.git\ssl\statem\statem.c (217): TestsTLS-11.exe!ossl_statem_connect() + 0xB bytes e:\openssl-1.1.git\ssl\ssl_lib.c (2908): TestsTLS-11.exe!SSL_do_handshake() + 0xC bytes p:\mes programmes\shared\ocrypto-11\tls.cpp (1017): TestsTLS-11.exe!OTLS::TLSSss::DoHandshake() + 0xC bytes p:\mes programmes\tests\_testsshared\teststls-11-leak\clttasks.cpp (63): TestsTLS-11.exe!CltThread::Main() + 0xB bytes p:\mes programmes\shared\sthread.cpp (17): TestsTLS-11.exe!SThread::Run() + 0xE bytes f:\dd\vctools\crt\crtw32\startup\threadex.c (359): TestsTLS-11.exe!_threadstartex() ---------- Block 4359 at 0x006471A8: 96 bytes ---------- Leak Hash: 0x1DBDD4B0, Count: 1, Total 96 bytes Call Stack (TID 2464): ntdll.dll!RtlAllocateHeap() f:\dd\vctools\crt\crtw32\misc\dbgmalloc.c (56): TestsTLS-11.exe!malloc() + 0x15 bytes e:\openssl-1.1.git\crypto\mem.c (138): TestsTLS-11.exe!CRYPTO_malloc() + 0x9 bytes e:\openssl-1.1.git\crypto\mem.c (158): TestsTLS-11.exe!CRYPTO_zalloc() + 0x11 bytes e:\openssl-1.1.git\crypto\lhash\lhash.c (116): TestsTLS-11.exe!lh_new() + 0xB bytes e:\openssl-1.1.git\crypto\err\err_lcl.h (2): TestsTLS-11.exe!lh_ERR_STATE_new() + 0x10 bytes e:\openssl-1.1.git\crypto\err\err.c (321): TestsTLS-11.exe!int_thread_get() + 0xF bytes e:\openssl-1.1.git\crypto\err\err.c (369): TestsTLS-11.exe!int_thread_set_item() + 0x9 bytes e:\openssl-1.1.git\crypto\err\err.c (884): TestsTLS-11.exe!ERR_get_state() + 0xC bytes e:\openssl-1.1.git\crypto\err\err.c (598): TestsTLS-11.exe!ERR_clear_error() + 0x5 bytes e:\openssl-1.1.git\ssl\statem\statem.c (279): TestsTLS-11.exe!state_machine() e:\openssl-1.1.git\ssl\statem\statem.c (217): TestsTLS-11.exe!ossl_statem_connect() + 0xB bytes e:\openssl-1.1.git\ssl\ssl_lib.c (2908): TestsTLS-11.exe!SSL_do_handshake() + 0xC bytes p:\mes programmes\shared\ocrypto-11\tls.cpp (1017): TestsTLS-11.exe!OTLS::TLSSss::DoHandshake() + 0xC bytes p:\mes programmes\tests\_testsshared\teststls-11-leak\clttasks.cpp (63): TestsTLS-11.exe!CltThread::Main() + 0xB bytes p:\mes programmes\shared\sthread.cpp (17): TestsTLS-11.exe!SThread::Run() + 0xE bytes f:\dd\vctools\crt\crtw32\startup\threadex.c (359): TestsTLS-11.exe!_threadstartex() ---------- Block 4361 at 0x00647248: 64 bytes ---------- Leak Hash: 0x713FD291, Count: 1, Total 64 bytes Call Stack (TID 2464): ntdll.dll!RtlAllocateHeap() f:\dd\vctools\crt\crtw32\misc\dbgmalloc.c (56): TestsTLS-11.exe!malloc() + 0x15 bytes e:\openssl-1.1.git\crypto\mem.c (138): TestsTLS-11.exe!CRYPTO_malloc() + 0x9 bytes e:\openssl-1.1.git\crypto\mem.c (158): TestsTLS-11.exe!CRYPTO_zalloc() + 0x11 bytes e:\openssl-1.1.git\crypto\lhash\lhash.c (118): TestsTLS-11.exe!lh_new() + 0xB bytes e:\openssl-1.1.git\crypto\err\err_lcl.h (2): TestsTLS-11.exe!lh_ERR_STATE_new() + 0x10 bytes e:\openssl-1.1.git\crypto\err\err.c (321): TestsTLS-11.exe!int_thread_get() + 0xF bytes e:\openssl-1.1.git\crypto\err\err.c (369): TestsTLS-11.exe!int_thread_set_item() + 0x9 bytes e:\openssl-1.1.git\crypto\err\err.c (884): TestsTLS-11.exe!ERR_get_state() + 0xC bytes e:\openssl-1.1.git\crypto\err\err.c (598): TestsTLS-11.exe!ERR_clear_error() + 0x5 bytes e:\openssl-1.1.git\ssl\statem\statem.c (279): TestsTLS-11.exe!state_machine() e:\openssl-1.1.git\ssl\statem\statem.c (217): TestsTLS-11.exe!ossl_statem_connect() + 0xB bytes e:\openssl-1.1.git\ssl\ssl_lib.c (2908): TestsTLS-11.exe!SSL_do_handshake() + 0xC bytes p:\mes programmes\shared\ocrypto-11\tls.cpp (1017): TestsTLS-11.exe!OTLS::TLSSss::DoHandshake() + 0xC bytes p:\mes programmes\tests\_testsshared\teststls-11-leak\clttasks.cpp (63): TestsTLS-11.exe!CltThread::Main() + 0xB bytes p:\mes programmes\shared\sthread.cpp (17): TestsTLS-11.exe!SThread::Run() + 0xE bytes f:\dd\vctools\crt\crtw32\startup\threadex.c (359): TestsTLS-11.exe!_threadstartex() ---------- Block 4365 at 0x006472C8: 8 bytes ---------- Leak Hash: 0xFBE574AD, Count: 1, Total 8 bytes Call Stack (TID 2464): ntdll.dll!RtlAllocateHeap() f:\dd\vctools\crt\crtw32\misc\dbgmalloc.c (56): TestsTLS-11.exe!malloc() + 0x15 bytes e:\openssl-1.1.git\crypto\mem.c (138): TestsTLS-11.exe!CRYPTO_malloc() + 0x9 bytes e:\openssl-1.1.git\crypto\mem.c (158): TestsTLS-11.exe!CRYPTO_zalloc() + 0x11 bytes e:\openssl-1.1.git\crypto\init.c (197): TestsTLS-11.exe!ossl_init_get_thread_local() + 0xB bytes e:\openssl-1.1.git\crypto\init.c (511): TestsTLS-11.exe!ossl_init_thread_start() + 0x7 bytes e:\openssl-1.1.git\crypto\err\err.c (898): TestsTLS-11.exe!ERR_get_state() + 0x9 bytes e:\openssl-1.1.git\crypto\err\err.c (598): TestsTLS-11.exe!ERR_clear_error() + 0x5 bytes e:\openssl-1.1.git\ssl\statem\statem.c (279): TestsTLS-11.exe!state_machine() e:\openssl-1.1.git\ssl\statem\statem.c (217): TestsTLS-11.exe!ossl_statem_connect() + 0xB bytes e:\openssl-1.1.git\ssl\ssl_lib.c (2908): TestsTLS-11.exe!SSL_do_handshake() + 0xC bytes p:\mes programmes\shared\ocrypto-11\tls.cpp (1017): TestsTLS-11.exe!OTLS::TLSSss::DoHandshake() + 0xC bytes p:\mes programmes\tests\_testsshared\teststls-11-leak\clttasks.cpp (63): TestsTLS-11.exe!CltThread::Main() + 0xB bytes p:\mes programmes\shared\sthread.cpp (17): TestsTLS-11.exe!SThread::Run() + 0xE bytes f:\dd\vctools\crt\crtw32\startup\threadex.c (359): TestsTLS-11.exe!_threadstartex() Visual Leak Detector detected 5 memory leaks (10757 bytes). Largest number used: 213916 bytes. Total allocations: 902180 bytes. Visual Leak Detector is now exiting. -----Message d'origine----- De?: openssl-dev [mailto:openssl-dev-bounces at openssl.org] De la part de Matt Caswell Envoy??: dimanche 14 f?vrier 2016 00:30 ??: openssl-dev at openssl.org Objet?: Re: [openssl-dev] memory leaks detected using libSSL 1.1 Hmmm. It does look to me like there could be a memory leak here. What's not clear to me is to why you are only seeing this in 1.1 and not previous versions, as it looks like the same could happen in 1.0.2 as well! Anyway, please try the attached patch to see if that helps. Let me know how you get on. Thanks Matt From jeevhi at gmail.com Sun Feb 14 06:21:40 2016 From: jeevhi at gmail.com (JM) Date: Sun, 14 Feb 2016 11:51:40 +0530 Subject: [openssl-dev] Random Crash in X509_NAME_cmp Message-ID: Hello All, We are facing this issue for quite sometime, a random crash in SSL3_accept. We yet to figure out the exact cause as it's quite random and does not happen frequently - but it does happen once in a few hundred thousand connections and crashing the server. We are using openssl 1.0.1e on CentOS 7.2. I hope to get some help here, will be happy to provide additional information if requires. Program terminated with signal 11, Segmentation fault. #0 0x00007f0956bd394a in X509_NAME_cmp () from /lib64/libcrypto.so.10 Missing separate debuginfos, use: debuginfo-install cyrus-sasl-lib-2.1.26-19.2.el7.x86_64 glibc-2.17-106.el7_2.1.x86_64 gmp-6.0.0-12.el7_1.x86_64 gnutls-3.3.8-14.el7_2.x86_64 keyutils-libs-1.5.8-3.el7.x86_64 krb5-libs-1.13.2-10.el7.x86_64 libcom_err-1.42.9-7.el7.x86_64 libcurl-7.29.0-25.el7.centos.x86_64 libffi-3.0.13-16.el7.x86_64 libgcc-4.8.5-4.el7.x86_64 libidn-1.28-4.el7.x86_64 libselinux-2.2.2-6.el7.x86_64 libssh2-1.4.3-10.el7.x86_64 libstdc++-4.8.5-4.el7.x86_64 libtasn1-3.8-2.el7.x86_64 mariadb-libs-5.5.44-2.el7.centos.x86_64 nettle-2.7.1-4.el7.x86_64 nspr-4.10.8-2.el7_1.x86_64 nss-3.19.1-19.el7_2.x86_64 nss-softokn-freebl-3.16.2.3-13.el7_1.x86_64 nss-util-3.19.1-4.el7_1.x86_64 openldap-2.4.40-8.el7.x86_64 openssl-libs-1.0.1e-51.el7_2.2.x86_64 p11-kit-0.20.7-3.el7.x86_64 pcre-8.32-15.el7.x86_64 trousers-0.3.13-1.el7.x86_64 xz-libs-5.1.2-12alpha.el7.x86_64 zlib-1.2.7-15.el7.x86_64 (gdb) b Breakpoint 1 at 0x7f0956bd394a (gdb) bt #0 0x00007f0956bd394a in X509_NAME_cmp () from /lib64/libcrypto.so.10 #1 0x00007f0956b26b54 in OBJ_bsearch_ex_ () from /lib64/libcrypto.so.10 #2 0x00007f0956b9c005 in internal_find () from /lib64/libcrypto.so.10 #3 0x00007f0956bd9a3f in x509_object_idx_cnt () from /lib64/libcrypto.so.10 #4 0x00007f0956bd9fb9 in X509_OBJECT_retrieve_by_subject () from /lib64/libcrypto.so.10 #5 0x00007f0956bda03b in X509_STORE_get_by_subject () from /lib64/libcrypto.so.10 #6 0x00007f0956bda8ea in X509_STORE_CTX_get1_issuer () from /lib64/libcrypto.so.10 #7 0x00007f0956bd64f5 in X509_verify_cert () from /lib64/libcrypto.so.10 #8 0x00007f0956ecec98 in ssl3_output_cert_chain () from /lib64/libssl.so.10 #9 0x00007f0956ec23d5 in ssl3_send_server_certificate () from /lib64/libssl.so.10 #10 0x00007f0956ec384d in ssl3_accept () from /lib64/libssl.so.10 #11 0x00007f0956ed1088 in ssl23_accept () from /lib64/libssl.so.10 Thanks Jim -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Sun Feb 14 07:04:21 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sun, 14 Feb 2016 07:04:21 +0000 Subject: [openssl-dev] Random Crash in X509_NAME_cmp In-Reply-To: References: Message-ID: <20160214070421.GT19242@mournblade.imrryr.org> On Sun, Feb 14, 2016 at 11:51:40AM +0530, JM wrote: > Hello All, > > We are facing this issue for quite sometime, a random crash in SSL3_accept. > We yet to figure out the exact cause as it's quite random and does not > happen frequently - but it does happen once in a few hundred thousand > connections and crashing the server. We are using openssl 1.0.1e on CentOS > 7.2. I hope to get some help here, will be happy to provide additional > information if requires. > > (gdb) bt > #0 0x00007f0956bd394a in X509_NAME_cmp () from /lib64/libcrypto.so.10 > #1 0x00007f0956b26b54 in OBJ_bsearch_ex_ () from /lib64/libcrypto.so.10 > #2 0x00007f0956b9c005 in internal_find () from /lib64/libcrypto.so.10 > #3 0x00007f0956bd9a3f in x509_object_idx_cnt () from /lib64/libcrypto.so.10 > #4 0x00007f0956bd9fb9 in X509_OBJECT_retrieve_by_subject () from > /lib64/libcrypto.so.10 > #5 0x00007f0956bda03b in X509_STORE_get_by_subject () from > /lib64/libcrypto.so.10 > #6 0x00007f0956bda8ea in X509_STORE_CTX_get1_issuer () from > /lib64/libcrypto.so.10 > #7 0x00007f0956bd64f5 in X509_verify_cert () from /lib64/libcrypto.so.10 > #8 0x00007f0956ecec98 in ssl3_output_cert_chain () from /lib64/libssl.so.10 > #9 0x00007f0956ec23d5 in ssl3_send_server_certificate () from > /lib64/libssl.so.10 > #10 0x00007f0956ec384d in ssl3_accept () from /lib64/libssl.so.10 > #11 0x00007f0956ed1088 in ssl23_accept () from /lib64/libssl.so.10 This sequence of calls corresponds to the server building its own certificate chain, by finding issuers for its own certificate recursively in the trust store. If this fails intermittently, that suggests memory corruption somewhere else. Is this server multi-threaded? Is it using the requisite locking callbacks? ... In the mean-time a work-around might be to configure the server with an explicit certificate chain (load a chain file, not just a leaf certificate), and just in case also set the SSL mode flags to include SSL_MODE_NO_AUTO_CHAIN: SSL_CTX_set_mode(ctx, SSL_MODE_NO_AUTO_CHAIN); or SSL_set_mode(ssl, SSL_MODE_NO_AUTO_CHAIN); Then the above call sequence will go no deeper than ssl3_output_cert_chain(), and your server will do less work for each client connection. It it still crashes, we'll learn that the crash in the cert store code is just a canary for a problem elsewhere. The only other thing that comes to mind is potential races against code is rehashing the CApath directory, but that seems unlikely. -- Viktor. From beldmit at gmail.com Sun Feb 14 09:58:23 2016 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Sun, 14 Feb 2016 12:58:23 +0300 Subject: [openssl-dev] Endianess info In-Reply-To: <99afdfcb258649e7b4a8fb61c1f7543d@ustx2ex-dag1mb1.msg.corp.akamai.com> References: <916a024a242a4fcb934411b4051965cc@ustx2ex-dag1mb1.msg.corp.akamai.com> <99afdfcb258649e7b4a8fb61c1f7543d@ustx2ex-dag1mb1.msg.corp.akamai.com> Message-ID: Dear Rich, Thank you, this patch works for me. On Thu, Feb 11, 2016 at 9:35 PM, Salz, Rich wrote: > Does this patch work for you? > > ; git diff > > diff --git a/Configure b/Configure > > index 3dc6a42..b36bc32 100755 > > --- a/Configure > > +++ b/Configure > > @@ -1553,6 +1553,8 @@ foreach (grep /_asm_src$/, keys %target) { > > ($target{$obj} = $target{$src}) =~ s/\.[csS]\b/.o/g; > > } > > > > +$config{lendian} = $config{cflags} =~ /-DL_ENDIAN/ ? 'define' : 'undef'; > > + > > # Write down our configuration where it fits ######################### > > > > open(OUT,">configdata.pm") || die "unable to create configdata.pm: $!\n"; > > diff --git a/include/openssl/opensslconf.h.in b/include/openssl/ > opensslconf.h.in > > index d9f6429..9dc547f 100644 > > --- a/include/openssl/opensslconf.h.in > > +++ b/include/openssl/opensslconf.h.in > > @@ -122,6 +122,8 @@ EOF > > > > /* Generate 80386 code? */ > > {- $config{processor} eq "386" ? "#define" : "#undef" -} I386_ONLY > > +/* Big or little endian? */ > > +{- $config{lendian} eq "define" ? "#define" : "#undef" -} > OPENSSL_LITTLE_ENDIAN > > > > #undef OPENSSL_UNISTD > > #define OPENSSL_UNISTD {- $target{unistd} -} > > > > -- > > Senior Architect, Akamai Technologies > > IM: richsalz at jabber.at Twitter: RichSalz > > > > *From:* Dmitry Belyavsky [mailto:beldmit at gmail.com] > *Sent:* Thursday, February 11, 2016 12:45 PM > *To:* openssl-dev at openssl.org > *Subject:* Re: [openssl-dev] Endianess info > > > > Hello Rich, > > > > > > > > On Thu, Feb 11, 2016 at 8:39 PM, Salz, Rich wrote: > > > Is the endianess information available in any of installed by the 1.1.0 > version *.h files? > > All the other necessary for building an algorithms-providing engine > outside of the openssl source tree can be found in the opensslconf.h file. > > No, but that's an excellent idea. Which #define do you need "moved" from > an existing header file? > > > > I need the L_ENDIAN #define. > > > > Thank you! > > > > -- > > 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 appro at openssl.org Sun Feb 14 10:27:08 2016 From: appro at openssl.org (Andy Polyakov) Date: Sun, 14 Feb 2016 11:27:08 +0100 Subject: [openssl-dev] Endianess info In-Reply-To: <99afdfcb258649e7b4a8fb61c1f7543d@ustx2ex-dag1mb1.msg.corp.akamai.com> References: <916a024a242a4fcb934411b4051965cc@ustx2ex-dag1mb1.msg.corp.akamai.com> <99afdfcb258649e7b4a8fb61c1f7543d@ustx2ex-dag1mb1.msg.corp.akamai.com> Message-ID: <56C0567C.4060002@openssl.org> > Does this patch work for you? I'd vote against [catering this information in public header]. As it stands now -D[BL]_ENDIAN in OpenSSL config lines is actually just an optimization flag, and not as significant one. "Optimization flag" means that you can actually omit it, and it will still work, and "not as significant" means that not very much slower. Real endian dependencies are handled either by adhering to endian-neutral coding practices or so called constant conditions, such as if (endian.little). Advantage of constant condition is that both paths are parsed by compilers, so that at least code handling "less popular" endianness doesn't end up in majority's blind spot. There is no reason for why either of these techniques can't be exercised in off-tree code. From rsalz at akamai.com Sun Feb 14 15:37:28 2016 From: rsalz at akamai.com (Salz, Rich) Date: Sun, 14 Feb 2016 15:37:28 +0000 Subject: [openssl-dev] Endianess info In-Reply-To: <56C0567C.4060002@openssl.org> References: <916a024a242a4fcb934411b4051965cc@ustx2ex-dag1mb1.msg.corp.akamai.com> <99afdfcb258649e7b4a8fb61c1f7543d@ustx2ex-dag1mb1.msg.corp.akamai.com> <56C0567C.4060002@openssl.org> Message-ID: > I'd vote against [catering this information in public header]. As it stands now - > D[BL]_ENDIAN in OpenSSL config lines is actually just an optimization flag, Okay, you know more about this stuff than I do. I'll leave it to you to help Dmitry if he needs it :) From rainer.jung at kippdata.de Sun Feb 14 16:24:13 2016 From: rainer.jung at kippdata.de (Rainer Jung) Date: Sun, 14 Feb 2016 17:24:13 +0100 Subject: [openssl-dev] How to do reneg with client certs in 1.1.0 API In-Reply-To: <56B8A57F.2070509@openssl.org> References: <56B885DF.4090606@kippdata.de> <56B88B5C.8010303@openssl.org> <1454939157.21154.6.camel@redhat.com> <56B8A57F.2070509@openssl.org> Message-ID: <56C0AA2D.8030909@kippdata.de> Am 08.02.2016 um 15:26 schrieb Matt Caswell: > On 08/02/16 13:45, Tomas Mraz wrote: >> On Po, 2016-02-08 at 12:34 +0000, Matt Caswell wrote: >>> >>> On 08/02/16 12:11, Rainer Jung wrote: >>>> >>> Renegotiation isn't entirely within the control of the server. A >>> server >>> can request that a renegotiation takes place. It is up to the client >>> whether it honours that request immediately; or perhaps its finishes >>> off >>> sending some application data before it gets around to honouring it; >>> or >>> perhaps it doesn't honour it at all. >>> >>>> SSL_renegotiate(ssl); >>>> SSL_do_handshake(ssl); >>> >>> This sequence makes the server send the HelloVerifyRequest. It is >>> then >>> back in a state where it can continue to receive application data >>> from >>> the client. At some later point the client may or may not initiate a >>> reneg. >>> >>>> SSL_set_state(ssl, SSL_ST_ACCEPT); >>>> SSL_do_handshake(ssl); >>> >>> This is really not a good idea, and I suspect is a hack that was >>> originally copied from s_server :-). Doing this will make the >>> connection >>> fail if the client sends application data next (which it is allowed >>> to do). >>> >>> We don't know what we're going to get next from the client it could >>> be >>> more application data. It could be an immediate start of a new >>> handshake. The correct thing for the server to do is to attempt to >>> read >>> application data. If we happen to get a handshake instead then it >>> will >>> be automatically handled. >> >> What if the server wants to discard all the application data that was >> sent before the renegotiation completed? Or how the server can >> recognize which part of data was received before renegotiation >> completed and which after it? >> > > You never get app data from two different epochs returned in a single > API call. In certain situations you can get a handshake finish occur > followed by a read of application data all within a single API call. > It's also valid that the attempt to read application data handled the > handshake but doesn't actually return any app data because the client > didn't send any yet (it *just* did the reneg). > > So if you want to discard all application data until the client has > initiated a reneg and supplied a certificate then you'll want to do > something like: > > SSL_renegotiate(ssl); > SSL_do_handshake(ssl); > do { > read_some_app_data(); > if(no_client_cert_yet()) { > discard_app_data(); > } > } while(no_client_cert_yet()); After doing some experiments I ended up calling SSL_peek() with a length of 0 bytes. That seems to reliably trigger the renegotiation handshake. Using this approach was easier, since we (Apache) have to handle various reneg scenarios: - waiting for client certs - doing a reneg because cipher requirements changed but no client certs involved - sometimes no application data is expected after the renegotiation I hope that effect of SSL_peek(ssl, buf, 0) is not just an implementation artefact and we can actually rely on it. Regards, Rainer From beldmit at gmail.com Sun Feb 14 16:28:06 2016 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Sun, 14 Feb 2016 19:28:06 +0300 Subject: [openssl-dev] Endianess info In-Reply-To: <56C0567C.4060002@openssl.org> References: <916a024a242a4fcb934411b4051965cc@ustx2ex-dag1mb1.msg.corp.akamai.com> <99afdfcb258649e7b4a8fb61c1f7543d@ustx2ex-dag1mb1.msg.corp.akamai.com> <56C0567C.4060002@openssl.org> Message-ID: Dear Andy, On Sun, Feb 14, 2016 at 1:27 PM, Andy Polyakov wrote: > > Does this patch work for you? > > I'd vote against [catering this information in public header]. As it > stands now -D[BL]_ENDIAN in OpenSSL config lines is actually just an > optimization flag, and not as significant one. "Optimization flag" means > that you can actually omit it, and it will still work, and "not as > significant" means that not very much slower. Real endian dependencies > are handled either by adhering to endian-neutral coding practices or so > called constant conditions, such as if (endian.little). Advantage of > constant condition is that both paths are parsed by compilers, so that > at least code handling "less popular" endianness doesn't end up in > majority's blind spot. There is no reason for why either of these > techniques can't be exercised in off-tree code. > The endianess information could be used in case of cross-compilation. -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From appro at openssl.org Sun Feb 14 16:58:13 2016 From: appro at openssl.org (Andy Polyakov) Date: Sun, 14 Feb 2016 17:58:13 +0100 Subject: [openssl-dev] Endianess info In-Reply-To: References: <916a024a242a4fcb934411b4051965cc@ustx2ex-dag1mb1.msg.corp.akamai.com> <99afdfcb258649e7b4a8fb61c1f7543d@ustx2ex-dag1mb1.msg.corp.akamai.com> <56C0567C.4060002@openssl.org> Message-ID: <56C0B225.8070708@openssl.org> > > Does this patch work for you? > > I'd vote against [catering this information in public header]. As it > stands now -D[BL]_ENDIAN in OpenSSL config lines is actually just an > optimization flag, and not as significant one. "Optimization flag" means > that you can actually omit it, and it will still work, and "not as > significant" means that not very much slower. Real endian dependencies > are handled either by adhering to endian-neutral coding practices or so > called constant conditions, such as if (endian.little). Advantage of > constant condition is that both paths are parsed by compilers, so that > at least code handling "less popular" endianness doesn't end up in > majority's blind spot. There is no reason for why either of these > techniques can't be exercised in off-tree code. > > > The endianess information could be used in case of cross-compilation. Endian-neutral coding and constant conditions work in cross-compilation cases. From rt at openssl.org Sun Feb 14 20:28:11 2016 From: rt at openssl.org (Andy Polyakov via RT) Date: Sun, 14 Feb 2016 20:28:11 +0000 Subject: [openssl-dev] [openssl.org #4305] ChaCha20 assembly bugs In-Reply-To: <56C0E351.7090101@openssl.org> References: <56BF25B3.4060209@openssl.org> <56C0E351.7090101@openssl.org> Message-ID: >> 1. In chacha-x86_64.pl, .Ltail: >> >> 2. In chacha-x86_64.pl, .Loop_tail_ssse3: >> >> 3. In chacha-x86.pl, loop: > > Fix is upcoming. Thanks! > >> 4. The assembly versions crash if you pass in an empty input/output. The >> generic C code handles this fine. (I'll defer to you whether this is a bug >> or a caller obligation to be documented.) > > This will be addressed separately by fixing all modules. I mean not all > modules have this problem, but all modules will be double-checked and > fixed as required. Fixes are committed. Thanks again. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4305 Please log in as guest with password guest if prompted From doctor at doctor.nl2k.ab.ca Sun Feb 14 20:22:28 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Sun, 14 Feb 2016 13:22:28 -0700 Subject: [openssl-dev] Openssl-SNAP-20160214 issues Message-ID: <20160214202228.GA14241@doctor.nl2k.ab.ca> Please explain why making all in ssl... gcc -I.. -I../include -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_EXPERIMENTAL_JPAKE -DOPENSSL_THREADS -DOPENSSL_PIC -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/contrib\"" -DENGINESDIR="\"/usr/contrib/lib/engines\"" -fPIC -pthread -D_THREAD_SAFE -D_REENTRANT -DPERL5 -DL_ENDIAN -DTERMIOS -fomit-frame-pointer -O2 -march=i486 -Wall -g -c ssl_utst.c -o ssl_utst.o ssl_utst.c:63: `dtls1_process_heartbeat' undeclared here (not in a function) ssl_utst.c:63: initializer element is not constant ssl_utst.c:63: (near initialization for `ssl_test_functions.p_dtls1_process_heartbeat') *** Error code 1 Stop. *** Error code 1 Stop. is happening . -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Broadcasting the truth for 25 years From rsalz at akamai.com Sun Feb 14 20:36:43 2016 From: rsalz at akamai.com (Salz, Rich) Date: Sun, 14 Feb 2016 20:36:43 +0000 Subject: [openssl-dev] Openssl-SNAP-20160214 issues In-Reply-To: <20160214202228.GA14241@doctor.nl2k.ab.ca> References: <20160214202228.GA14241@doctor.nl2k.ab.ca> Message-ID: <211382577880483383237e36948e4ec8@ustx2ex-dag1mb1.msg.corp.akamai.com> > Please explain why My guess would be a bug. :) For these kinds of things, it helps to give the config line you used. AT any rate, see if this fixes it. Add this line to ssl_utst.c: static const struct openssl_ssl_test_functions ssl_test_functions = { ssl_init_wbio_buffer, ssl3_setup_buffers, # ifndef OPENSSL_NO_HEARTBEATS #undef dtls1_process_heartbeat <<<< NEW LINE dtls1_process_heartbeat # endif }; From doctor at doctor.nl2k.ab.ca Sun Feb 14 21:19:13 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Sun, 14 Feb 2016 14:19:13 -0700 Subject: [openssl-dev] Openssl-SNAP-20160214 issues In-Reply-To: <211382577880483383237e36948e4ec8@ustx2ex-dag1mb1.msg.corp.akamai.com> References: <20160214202228.GA14241@doctor.nl2k.ab.ca> <211382577880483383237e36948e4ec8@ustx2ex-dag1mb1.msg.corp.akamai.com> Message-ID: <20160214211913.GA24745@doctor.nl2k.ab.ca> On Sun, Feb 14, 2016 at 08:36:43PM +0000, Salz, Rich wrote: > > > Please explain why > > My guess would be a bug. :) > > For these kinds of things, it helps to give the config line you used. > > AT any rate, see if this fixes it. Add this line to ssl_utst.c: > static const struct openssl_ssl_test_functions ssl_test_functions = { > ssl_init_wbio_buffer, > ssl3_setup_buffers, > # ifndef OPENSSL_NO_HEARTBEATS > #undef dtls1_process_heartbeat <<<< NEW LINE > dtls1_process_heartbeat > # endif > }; > That is your fix right there! Please commit. > > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Broadcasting the truth for 25 years From doctor at doctor.nl2k.ab.ca Sun Feb 14 21:28:19 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Sun, 14 Feb 2016 14:28:19 -0700 Subject: [openssl-dev] Openssl-SNAP-20160214 issues In-Reply-To: <20160214211913.GA24745@doctor.nl2k.ab.ca> References: <20160214202228.GA14241@doctor.nl2k.ab.ca> <211382577880483383237e36948e4ec8@ustx2ex-dag1mb1.msg.corp.akamai.com> <20160214211913.GA24745@doctor.nl2k.ab.ca> Message-ID: <20160214212819.GB24745@doctor.nl2k.ab.ca> On Sun, Feb 14, 2016 at 02:19:13PM -0700, The Doctor wrote: > On Sun, Feb 14, 2016 at 08:36:43PM +0000, Salz, Rich wrote: > > > > > Please explain why > > > > My guess would be a bug. :) > > > > For these kinds of things, it helps to give the config line you used. > > > > AT any rate, see if this fixes it. Add this line to ssl_utst.c: > > static const struct openssl_ssl_test_functions ssl_test_functions = { > > ssl_init_wbio_buffer, > > ssl3_setup_buffers, > > # ifndef OPENSSL_NO_HEARTBEATS > > #undef dtls1_process_heartbeat <<<< NEW LINE > > dtls1_process_heartbeat > > # endif > > }; > > > > That is your fix right there! > Please commit. > Still getting hung up at ../test/recipes/70-test_sslcertstatus.t ... The last time this worked was 20120203 > > > > -- > > openssl-dev mailing list > > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > > -- > Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca > God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! > http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism > Broadcasting the truth for 25 years > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Broadcasting the truth for 25 years From levitte at openssl.org Mon Feb 15 00:11:53 2016 From: levitte at openssl.org (Richard Levitte) Date: Mon, 15 Feb 2016 01:11:53 +0100 (CET) Subject: [openssl-dev] Question about dynamically loadable engines on Cygwin / Mingw Message-ID: <20160215.011153.260736821613988186.levitte@openssl.org> Hi, I've got a question to the Cygwin / Mingw community, regarding the naming of dynamic engines. >From looking at Makefile.shared et al, the engines get the same kind of prefixes as a standard shared library (but without the accompanying import library, of course). So the capi engine gets named like this: Cygwin: cygcapi.dll Mingw: capieay32.dll Does that mean that using engines with the openssl commands looks strangely different depending on the platform you happen to be on? Like, would a run of openssl s_server with the capi engine like something like this? Cygwin: openssl s_server -engine cygcapi.dll ... Mingw: openssl s_server -engine capieay32.dll ... Unix: openssl s_server -engine capi ... (note that on Unix, it's assumed that the engine *may* be prefixed with "lib", which might be a reason for discussion as well, as it's not really meant to be used as a shared library) Apart from the fact that the current ENGINE framework has no support for the ".dll" suffix internally (that's an easy fix), is there any reason to name the dynamic engines anything but, in this example, capi.dll or libcapi.dll? This is assuming, btw, that no one mixes the different Windows POSIX layers on top of each other. If such mixes are commonplace, it's worth considering, of course... Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From pwalten at au1.ibm.com Mon Feb 15 08:41:08 2016 From: pwalten at au1.ibm.com (Peter Waltenberg) Date: Mon, 15 Feb 2016 08:41:08 +0000 Subject: [openssl-dev] Question about dynamically loadable engines on Cygwin / Mingw In-Reply-To: <20160215.011153.260736821613988186.levitte@openssl.org> References: <20160215.011153.260736821613988186.levitte@openssl.org> Message-ID: <201602150841.u1F8fN3q019887@d23av02.au.ibm.com> An HTML attachment was scrubbed... URL: From vinschen at redhat.com Mon Feb 15 10:50:45 2016 From: vinschen at redhat.com (Corinna Vinschen) Date: Mon, 15 Feb 2016 11:50:45 +0100 Subject: [openssl-dev] Question about dynamically loadable engines on Cygwin / Mingw In-Reply-To: <20160215.011153.260736821613988186.levitte@openssl.org> References: <20160215.011153.260736821613988186.levitte@openssl.org> Message-ID: <20160215105045.GA7601@calimero.vinschen.de> Hi Richard, On Feb 15 01:11, Richard Levitte wrote: > Hi, > > I've got a question to the Cygwin / Mingw community, regarding the > naming of dynamic engines. > > >From looking at Makefile.shared et al, the engines get the same kind > of prefixes as a standard shared library (but without the accompanying > import library, of course). So the capi engine gets named like this: > > Cygwin: cygcapi.dll I can't speak for Mingw, but on Cygwin the modules are called libFOO.so, e.g. /usr/lib/openssl-1.0.2/engines/libcapi.so I hope the changes to the build system will keep this intact. > This is assuming, btw, that no one mixes the different Windows POSIX > layers on top of each other. If such mixes are commonplace, it's > worth considering, of course... No such mixing is possible due to dependency issues, nor is it supported. You can try but it will not work as desired. Ideally just handle Cygwin as a POSIX system with a few quirks (like having the DLLs in /usr/bin instead of /usr/lib), but otherwise disjunct from native Windows environments. POSIX, not Windows. Thanks, Corinna -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From levitte at openssl.org Mon Feb 15 11:11:26 2016 From: levitte at openssl.org (Richard Levitte) Date: Mon, 15 Feb 2016 12:11:26 +0100 (CET) Subject: [openssl-dev] Question about dynamically loadable engines on Cygwin / Mingw In-Reply-To: <20160215105045.GA7601@calimero.vinschen.de> References: <20160215.011153.260736821613988186.levitte@openssl.org> <20160215105045.GA7601@calimero.vinschen.de> Message-ID: <20160215.121126.852135915726474180.levitte@openssl.org> Hi Corinna, In message <20160215105045.GA7601 at calimero.vinschen.de> on Mon, 15 Feb 2016 11:50:45 +0100, Corinna Vinschen said: vinschen> > Cygwin: cygcapi.dll vinschen> vinschen> I can't speak for Mingw, but on Cygwin the modules are called libFOO.so, vinschen> e.g. vinschen> vinschen> /usr/lib/openssl-1.0.2/engines/libcapi.so Really? I don't understand how that can be. The link_o.cygwin target in Makefile.shared tells me a very different story, with these lines: SHLIB=cyg$(LIBNAME); \ ... SHLIB_SUFFIX=.dll; \ vinschen> I hope the changes to the build system will keep this intact. May I ask why? The only thing I can see that would depend on the name of engines in practice is the DSO module (and that one has no support for .dll files in a POSIX context). I plan on fixing that one to match changes I make. (and, should it come to that, I can see the possibility of making backward compatibility copies if someone needs it) vinschen> > This is assuming, btw, that no one mixes the different Windows POSIX vinschen> > layers on top of each other. If such mixes are commonplace, it's vinschen> > worth considering, of course... vinschen> vinschen> No such mixing is possible due to dependency issues, nor is it vinschen> supported. You can try but it will not work as desired. Ideally just vinschen> handle Cygwin as a POSIX system with a few quirks (like having the DLLs vinschen> in /usr/bin instead of /usr/lib), but otherwise disjunct from native vinschen> Windows environments. POSIX, not Windows. Good. Someone else told me "It would take a brave man to mix Cygwin plugins (engines) with non-Cygwin host or vice versa"... message received, I don't need to worry about that. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From rt at openssl.org Mon Feb 15 11:19:02 2016 From: rt at openssl.org (J Mohan Rao Arisankala via RT) Date: Mon, 15 Feb 2016 11:19:02 +0000 Subject: [openssl-dev] [openssl.org #4306] few cmds help cleanup In-Reply-To: References: Message-ID: Hi, enc: - typo in -base64 option - missing help opt text ocsp/req/rsautl/s_client: - missing help opt text Created the following pull request with the changes. https://github.com/openssl/openssl/pull/681 Thanks, Mohan -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4306 Please log in as guest with password guest if prompted From vinschen at redhat.com Mon Feb 15 11:39:36 2016 From: vinschen at redhat.com (Corinna Vinschen) Date: Mon, 15 Feb 2016 12:39:36 +0100 Subject: [openssl-dev] Question about dynamically loadable engines on Cygwin / Mingw In-Reply-To: <20160215.121126.852135915726474180.levitte@openssl.org> References: <20160215.011153.260736821613988186.levitte@openssl.org> <20160215105045.GA7601@calimero.vinschen.de> <20160215.121126.852135915726474180.levitte@openssl.org> Message-ID: <20160215113936.GA9749@calimero.vinschen.de> On Feb 15 12:11, Richard Levitte wrote: > Hi Corinna, > > In message <20160215105045.GA7601 at calimero.vinschen.de> on Mon, 15 Feb 2016 11:50:45 +0100, Corinna Vinschen said: > > vinschen> > Cygwin: cygcapi.dll > vinschen> > vinschen> I can't speak for Mingw, but on Cygwin the modules are called libFOO.so, > vinschen> e.g. > vinschen> > vinschen> /usr/lib/openssl-1.0.2/engines/libcapi.so > > Really? I don't understand how that can be. The link_o.cygwin target > in Makefile.shared tells me a very different story, with these lines: > > SHLIB=cyg$(LIBNAME); \ > ... > SHLIB_SUFFIX=.dll; \ Well, I fear it's something we could call a "bad hack" in engines/Makefile. Look at the install target: for l in $(LIBNAMES); do \ ( echo installing $$l; \ pfx=lib; \ if expr "$(PLATFORM)" : "Cygwin" >/dev/null; then \ sfx=".so"; \ cp cyg$$l.dll $(INSTALL_PREFIX)$(INSTALLTOP)/$(LIBDIR)/engines/$$pfx$$l$$sfx.new; \ else \ [...] \ fi; \ chmod 755 $(INSTALL_PREFIX)$(INSTALLTOP)/$(LIBDIR)/engines/$$pfx$$l$$sfx.new; \ mv -f $(INSTALL_PREFIX)$(INSTALLTOP)/$(LIBDIR)/engines/$$pfx$$l$$sfx.new $(INSTALL_PREFIX)$(INSTALLTOP)/$(LIBDIR)/engines/$$pfx$$l$$sfx ); \ done; \ So the build creates the file as cygFOO.dll and then renames it to libFOO.so at install time. However, on second thought, we *could* install the files as cygFOO.dll into the engines dir, too, because Cygwin's dlopen call is capable to handle a dlopen call using the usual libFOO.so: dlopen ("/usr/lib/openssl-1.0.2/engines/libcapi.so", ...) Internally it tries to find /usr/lib/openssl-1.0.2/engines/libcapi.so /usr/lib/openssl-1.0.2/engines/libcapi.dll /usr/lib/openssl-1.0.2/engines/cygcapi.dll in that order, and if any of them exist, it will load it. This Cygwin tweak wasn't available back when the above Makefile hack has been introduced. OTOH, just keeping it at libFOO.so shouldn't hurt. First of all it reduxes confusion when checking for file existence at some other point in the code. And second it saves time since trying to find out if the file exists under another name is extra work we can avoid. > vinschen> I hope the changes to the build system will keep this intact. > > May I ask why? The only thing I can see that would depend on the name > of engines in practice is the DSO module (and that one has no support > for .dll files in a POSIX context). I plan on fixing that one to > match changes I make. Well, keeping the libFOO.so names for the modules is more POSIXy and avoids having to change the DSO module. Corinna -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From levitte at openssl.org Mon Feb 15 12:03:50 2016 From: levitte at openssl.org (Richard Levitte) Date: Mon, 15 Feb 2016 13:03:50 +0100 (CET) Subject: [openssl-dev] Question about dynamically loadable engines on Cygwin / Mingw In-Reply-To: <20160215113936.GA9749@calimero.vinschen.de> References: <20160215105045.GA7601@calimero.vinschen.de> <20160215.121126.852135915726474180.levitte@openssl.org> <20160215113936.GA9749@calimero.vinschen.de> Message-ID: <20160215.130350.1478048874642246205.levitte@openssl.org> In message <20160215113936.GA9749 at calimero.vinschen.de> on Mon, 15 Feb 2016 12:39:36 +0100, Corinna Vinschen said: vinschen> On Feb 15 12:11, Richard Levitte wrote: vinschen> > Hi Corinna, vinschen> > vinschen> > In message <20160215105045.GA7601 at calimero.vinschen.de> on Mon, 15 Feb 2016 11:50:45 +0100, Corinna Vinschen said: vinschen> > vinschen> > vinschen> > Cygwin: cygcapi.dll vinschen> > vinschen> vinschen> > vinschen> I can't speak for Mingw, but on Cygwin the modules are called libFOO.so, vinschen> > vinschen> e.g. vinschen> > vinschen> vinschen> > vinschen> /usr/lib/openssl-1.0.2/engines/libcapi.so vinschen> > vinschen> > Really? I don't understand how that can be. The link_o.cygwin target vinschen> > in Makefile.shared tells me a very different story, with these lines: vinschen> > vinschen> > SHLIB=cyg$(LIBNAME); \ vinschen> > ... vinschen> > SHLIB_SUFFIX=.dll; \ vinschen> vinschen> Well, I fear it's something we could call a "bad hack" in engines/Makefile. vinschen> Look at the install target: vinschen> vinschen> for l in $(LIBNAMES); do \ vinschen> ( echo installing $$l; \ vinschen> pfx=lib; \ vinschen> if expr "$(PLATFORM)" : "Cygwin" >/dev/null; then \ vinschen> sfx=".so"; \ vinschen> cp cyg$$l.dll $(INSTALL_PREFIX)$(INSTALLTOP)/$(LIBDIR)/engines/$$pfx$$l$$sfx.new; \ vinschen> else \ vinschen> [...] \ vinschen> fi; \ vinschen> chmod 755 $(INSTALL_PREFIX)$(INSTALLTOP)/$(LIBDIR)/engines/$$pfx$$l$$sfx.new; \ vinschen> mv -f $(INSTALL_PREFIX)$(INSTALLTOP)/$(LIBDIR)/engines/$$pfx$$l$$sfx.new $(INSTALL_PREFIX)$(INSTALLTOP)/$(LIBDIR)/engines/$$pfx$$l$$sfx ); \ vinschen> done; \ vinschen> vinschen> So the build creates the file as cygFOO.dll and then renames it to vinschen> libFOO.so at install time. Ew, hadn't noticed that. But ok, an install time thing, and supposedly because there was no support whatsoever for the ".dll" suffix or "cyg" prefix in crypto/dso/dso_dlfcn.c (still isn't) vinschen> However, on second thought, we *could* install the files as cygFOO.dll vinschen> into the engines dir, too, because Cygwin's dlopen call is capable to vinschen> handle a dlopen call using the usual libFOO.so: vinschen> vinschen> dlopen ("/usr/lib/openssl-1.0.2/engines/libcapi.so", ...) vinschen> vinschen> Internally it tries to find vinschen> vinschen> /usr/lib/openssl-1.0.2/engines/libcapi.so vinschen> /usr/lib/openssl-1.0.2/engines/libcapi.dll vinschen> /usr/lib/openssl-1.0.2/engines/cygcapi.dll Interesting hack. vinschen> > May I ask why? The only thing I can see that would depend on the name vinschen> > of engines in practice is the DSO module (and that one has no support vinschen> > for .dll files in a POSIX context). I plan on fixing that one to vinschen> > match changes I make. vinschen> vinschen> Well, keeping the libFOO.so names for the modules is more POSIXy and vinschen> avoids having to change the DSO module. Mmm, libFOO.so is POSIXy... for shared libraries that are intended to be linked against using cc / ld -l option. However, the trend is that DSOs that are meant to be loaded dynamically by a program (in other words, plugins) need not be named in that way, and I'd argue further that they *shouldn't*, so as not to be confused with shared libraries. So here is what I'm thinking... - engines in 1.1 should be named FOO.{suffix} (for an engine FOO and whatever suffix is conventional on the platform at hand, be it .so, .dll, .sl, .dylib...) - the OpenSSL DSO module should be changed to have the DSO suffix configured instead of having it hardcoded as it is right now (the template framework we use makes that real easy, see how crypto/include/internal/bn_conf.h is generated as an example). - the OpenSSL ENGINE module should be changed to tell the DSO module not to prefix the received file name with "lib" (which I suspect is the primary reason for the install hack you mentioned above). That way, we would have engines that look like DSOs and not like shared libraries. On cygwin, that would be something like "capi.dll", on MacOS it would be "capi.dylib", on most other Unixen it would be "capi.so". My intention is to have this work smoothly and consistently, without having to resort to all kinds of weird install hacks or whatnot. Does that sounds like an acceptable change to you? (also, I'm thinking that engines should never be expected to exist along LD_LIBRARY_PATH. That environment variable is for shared libraries, not for DSOs... it's not a hard opinion, though) Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From vinschen at redhat.com Mon Feb 15 12:25:09 2016 From: vinschen at redhat.com (Corinna Vinschen) Date: Mon, 15 Feb 2016 13:25:09 +0100 Subject: [openssl-dev] Question about dynamically loadable engines on Cygwin / Mingw In-Reply-To: <20160215.130350.1478048874642246205.levitte@openssl.org> References: <20160215105045.GA7601@calimero.vinschen.de> <20160215.121126.852135915726474180.levitte@openssl.org> <20160215113936.GA9749@calimero.vinschen.de> <20160215.130350.1478048874642246205.levitte@openssl.org> Message-ID: <20160215122509.GA15067@calimero.vinschen.de> On Feb 15 13:03, Richard Levitte wrote: > So here is what I'm thinking... > > - engines in 1.1 should be named FOO.{suffix} (for an engine FOO and > whatever suffix is conventional on the platform at hand, be it .so, > .dll, .sl, .dylib...) > - the OpenSSL DSO module should be changed to have the DSO suffix > configured instead of having it hardcoded as it is right now (the > template framework we use makes that real easy, see how > crypto/include/internal/bn_conf.h is generated as an example). > - the OpenSSL ENGINE module should be changed to tell the DSO module > not to prefix the received file name with "lib" (which I suspect is > the primary reason for the install hack you mentioned above). > > That way, we would have engines that look like DSOs and not like > shared libraries. On cygwin, that would be something like "capi.dll", > on MacOS it would be "capi.dylib", on most other Unixen it would be > "capi.so". My intention is to have this work smoothly and > consistently, without having to resort to all kinds of weird install > hacks or whatnot. > > Does that sounds like an acceptable change to you? Any method being platform independent because implementation details are hidden under the hood sounds perfect to me. Thanks, Corinna -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From levitte at openssl.org Mon Feb 15 12:29:03 2016 From: levitte at openssl.org (Richard Levitte) Date: Mon, 15 Feb 2016 13:29:03 +0100 (CET) Subject: [openssl-dev] Question about dynamically loadable engines on Cygwin / Mingw In-Reply-To: <20160215122509.GA15067@calimero.vinschen.de> References: <20160215113936.GA9749@calimero.vinschen.de> <20160215.130350.1478048874642246205.levitte@openssl.org> <20160215122509.GA15067@calimero.vinschen.de> Message-ID: <20160215.132903.588105753089173385.levitte@openssl.org> In message <20160215122509.GA15067 at calimero.vinschen.de> on Mon, 15 Feb 2016 13:25:09 +0100, Corinna Vinschen said: vinschen> On Feb 15 13:03, Richard Levitte wrote: vinschen> > So here is what I'm thinking... vinschen> > vinschen> > - engines in 1.1 should be named FOO.{suffix} (for an engine FOO and vinschen> > whatever suffix is conventional on the platform at hand, be it .so, vinschen> > .dll, .sl, .dylib...) vinschen> > - the OpenSSL DSO module should be changed to have the DSO suffix vinschen> > configured instead of having it hardcoded as it is right now (the vinschen> > template framework we use makes that real easy, see how vinschen> > crypto/include/internal/bn_conf.h is generated as an example). vinschen> > - the OpenSSL ENGINE module should be changed to tell the DSO module vinschen> > not to prefix the received file name with "lib" (which I suspect is vinschen> > the primary reason for the install hack you mentioned above). vinschen> > vinschen> > That way, we would have engines that look like DSOs and not like vinschen> > shared libraries. On cygwin, that would be something like "capi.dll", vinschen> > on MacOS it would be "capi.dylib", on most other Unixen it would be vinschen> > "capi.so". My intention is to have this work smoothly and vinschen> > consistently, without having to resort to all kinds of weird install vinschen> > hacks or whatnot. vinschen> > vinschen> > Does that sounds like an acceptable change to you? vinschen> vinschen> Any method being platform independent because implementation details are vinschen> hidden under the hood sounds perfect to me. Then it's a go, I'll work on that. Thanks for your feedback! -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From matt at openssl.org Mon Feb 15 13:42:56 2016 From: matt at openssl.org (Matt Caswell) Date: Mon, 15 Feb 2016 13:42:56 +0000 Subject: [openssl-dev] Pipelining Message-ID: <56C1D5E0.2000103@openssl.org> I have just pushed to github some code that I have been working on to implement a feature I have called "pipelining". This is still WIP, although is fairly well advanced. I am keen to hear any feedback. You can see the PR here: https://github.com/openssl/openssl/pull/682 The idea is that some engines may be able to process multiple simultaneous crypto operations. This capability could be utilised to parallelise the processing of a single connection. For example a single write could be split into multiple records and each one encrypted independently and in parallel (this can only work in TLS1.1+ where we get a new IV per record). This initial version only provides pipelining for TLS (no DTLS at this stage). Documentation still needs to be added (hence WIP). It works similarly to how the existing MULTIBLOCK code works now. The primary differences are that MULTIBLOCK only ever deals with batches of 4 or 8 records in one go and the engine is responsible for writing the entire set of records including all the record headers. This means the engine ciphers are TLS protocol specific. They couldn't ever be used for DTLS and it doesn't make any sense to call them directly (i.e. not in the context of a TLS connection). The pipelining support is protocol agnostic and hence can be used for TLS or directly via EVP. It is also much more flexible about the number of pipelines that are used at any one time. Two new SSL/SSL_CTX parameters can be used to control how this works in the "write pipelining": max_pipelines and split_send_fragment. max_pipelines defines the maximum number of pipelines that can ever be used in one go for a single connection. It must always be less than or equal to SSL_MAX_PIPELINES (currently defined to be 32). By default only one pipeline will be used (i.e. normal non-parallel operation). split_send_fragment defines how data is split up into pipelines. The number of pipelines used will be determined by the amount of data provided to the SSL_write call divided by split_send_fragment. For example if split_send_fragment is set to 2000 and max_pipelines is 4 then: SSL_write called with 0-2000 bytes == 1 pipeline used SSL_write called with 2001-4000 bytes == 2 pipelines used SSL_write called with 4001-6000 bytes == 3 pipelines used SSL_write called with 6001+ bytes == 4 pipelines used split_send_fragment must always be less than or equal to max_send_fragment. By default it is set to be equal to max_send_fragment. This will mean that the same number of records will always be created as would have been created in the non-parallel case, although the data will be apportioned differently. In the parallel case data will be spread equally between the pipelines. Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that read_ahead must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. You need to have an engine that provides ciphers that support this. I have updated the dasync engine to provide some suitable ciphers. I've also added some arguments to s_client and s_server to support setting of the split_send_fragment and max_pipelines variables for write pipelining, and the size of the read buffer for read pipelining. Matt From rt at openssl.org Mon Feb 15 15:36:52 2016 From: rt at openssl.org (Valentin Vidic via RT) Date: Mon, 15 Feb 2016 15:36:52 +0000 Subject: [openssl-dev] [openssl.org #4308] Add Postgres support to -starttls In-Reply-To: <20160215144247.GW2566@gavran.carpriv.carnet.hr> References: <20160215144247.GW2566@gavran.carpriv.carnet.hr> Message-ID: The patch sends a SSLRequest packet and checks for a S in response. Useful for checking certificate validity of a PostgreSQL server. https://github.com/openssl/openssl/pull/683 -- Valentin -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4308 Please log in as guest with password guest if prompted From hkario at redhat.com Mon Feb 15 15:38:57 2016 From: hkario at redhat.com (Hubert Kario) Date: Mon, 15 Feb 2016 16:38:57 +0100 Subject: [openssl-dev] 3DES is a HIGH-strength cipher? In-Reply-To: <3C7783E1-9ED0-4B5D-A5BF-C95F01C1DD99@dukhovni.org> References: <79B8A535-27A0-461F-A796-08FEB2B117AB@akamai.com> <04d2c3e893ac466293971abe2e1bcdd2@ustx2ex-dag1mb1.msg.corp.akamai.com> <3C7783E1-9ED0-4B5D-A5BF-C95F01C1DD99@dukhovni.org> Message-ID: <12552162.HQEVECdyeI@pintsize.usersys.redhat.com> On Friday 12 February 2016 15:36:36 Viktor Dukhovni wrote: > > On Feb 12, 2016, at 3:15 PM, Salz, Rich wrote: > > > > So is RC4 and we don't see that as HIGH. HIGH implies strength, not > > MTI-ness. > Now let's not make stuff up: > > http://tools.ietf.org/html/rfc5246#section-9 > > 9. Mandatory Cipher Suites > > In the absence of an application profile standard specifying > otherwise, a TLS-compliant application MUST implement the cipher > suite TLS_RSA_WITH_AES_128_CBC_SHA (see Appendix A.5 for the > definition). > > http://tools.ietf.org/html/rfc4346#section-9 > > 9. Mandatory Cipher Suites > > In the absence of an application profile standard specifying > otherwise, a TLS compliant application MUST implement the cipher > suite TLS_RSA_WITH_3DES_EDE_CBC_SHA. > > http://tools.ietf.org/html/rfc2246#section-9 > > 9. Mandatory Cipher Suites > > In the absence of an application profile standard specifying > otherwise, a TLS compliant application MUST implement the cipher > suite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA. > > Since many users enable just HIGH ciphers, they must not exclude the > MTI ciphers. MTI means Mandatory To Implement, not Mandatory To Deploy or Mandatory To Enable and definitely does not mean Mandatory To Force User Applications To Advertise Support For Nobody on the Internet uses TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA, does that mean that the TLS1.0 deployment is 0%? -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From jeremy.farrell at oracle.com Mon Feb 15 17:54:47 2016 From: jeremy.farrell at oracle.com (Jeremy Farrell) Date: Mon, 15 Feb 2016 17:54:47 +0000 Subject: [openssl-dev] Question about dynamically loadable engines on Cygwin / Mingw In-Reply-To: <20160215.132903.588105753089173385.levitte@openssl.org> References: <20160215113936.GA9749@calimero.vinschen.de> <20160215.130350.1478048874642246205.levitte@openssl.org> <20160215122509.GA15067@calimero.vinschen.de> <20160215.132903.588105753089173385.levitte@openssl.org> Message-ID: <56C210E7.5080804@oracle.com> On 15/02/2016 12:29, Richard Levitte wrote: > In message <20160215122509.GA15067 at calimero.vinschen.de> on Mon, 15 Feb 2016 13:25:09 +0100, Corinna Vinschen said: > > vinschen> On Feb 15 13:03, Richard Levitte wrote: > vinschen> > So here is what I'm thinking... > vinschen> > > vinschen> > - engines in 1.1 should be named FOO.{suffix} (for an engine FOO and > vinschen> > whatever suffix is conventional on the platform at hand, be it .so, > vinschen> > .dll, .sl, .dylib...) > vinschen> > - the OpenSSL DSO module should be changed to have the DSO suffix > vinschen> > configured instead of having it hardcoded as it is right now (the > vinschen> > template framework we use makes that real easy, see how > vinschen> > crypto/include/internal/bn_conf.h is generated as an example). > vinschen> > - the OpenSSL ENGINE module should be changed to tell the DSO module > vinschen> > not to prefix the received file name with "lib" (which I suspect is > vinschen> > the primary reason for the install hack you mentioned above). > vinschen> > > vinschen> > That way, we would have engines that look like DSOs and not like > vinschen> > shared libraries. On cygwin, that would be something like "capi.dll", > vinschen> > on MacOS it would be "capi.dylib", on most other Unixen it would be > vinschen> > "capi.so". My intention is to have this work smoothly and > vinschen> > consistently, without having to resort to all kinds of weird install > vinschen> > hacks or whatnot. > vinschen> > > vinschen> > Does that sounds like an acceptable change to you? > vinschen> > vinschen> Any method being platform independent because implementation details are > vinschen> hidden under the hood sounds perfect to me. > > Then it's a go, I'll work on that. Thanks for your feedback! It sounds good, except shouldn't it be "capi.so" for cygwin, like the other mainstream POSIXy implementations? The point of cygwin is that it's POSIX not Windows, and it generally follows common practices of POSIXy OSes for things which aren't specified by POSIX. It seems that it would be simpler all round (for users as well as development) to treat it the same as "normal" UNIX-like OSes except when it absolutely has to be treated differently. -- J. J. Farrell - not speaking for Oracle. -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Mon Feb 15 17:59:53 2016 From: levitte at openssl.org (Richard Levitte) Date: Mon, 15 Feb 2016 18:59:53 +0100 (CET) Subject: [openssl-dev] Question about dynamically loadable engines on Cygwin / Mingw In-Reply-To: <56C210E7.5080804@oracle.com> References: <20160215122509.GA15067@calimero.vinschen.de> <20160215.132903.588105753089173385.levitte@openssl.org> <56C210E7.5080804@oracle.com> Message-ID: <20160215.185953.117619649162395329.levitte@openssl.org> In message <56C210E7.5080804 at oracle.com> on Mon, 15 Feb 2016 17:54:47 +0000, Jeremy Farrell said: jeremy.farrell> jeremy.farrell> jeremy.farrell> On 15/02/2016 12:29, Richard Levitte wrote: jeremy.farrell> > In message <20160215122509.GA15067 at calimero.vinschen.de> on Mon, 15 jeremy.farrell> > Feb 2016 13:25:09 +0100, Corinna Vinschen said: jeremy.farrell> > jeremy.farrell> > vinschen> On Feb 15 13:03, Richard Levitte wrote: jeremy.farrell> > vinschen> > So here is what I'm thinking... jeremy.farrell> > vinschen> > jeremy.farrell> > vinschen> > - engines in 1.1 should be named FOO.{suffix} (for an engine FOO and jeremy.farrell> > vinschen> > whatever suffix is conventional on the platform at hand, be it .so, jeremy.farrell> > vinschen> > .dll, .sl, .dylib...) jeremy.farrell> > vinschen> > - the OpenSSL DSO module should be changed to have the DSO suffix jeremy.farrell> > vinschen> > configured instead of having it hardcoded as it is right now (the jeremy.farrell> > vinschen> > template framework we use makes that real easy, see how jeremy.farrell> > vinschen> > crypto/include/internal/bn_conf.h is generated as an example). jeremy.farrell> > vinschen> > - the OpenSSL ENGINE module should be changed to tell the DSO module jeremy.farrell> > vinschen> > not to prefix the received file name with "lib" (which I suspect is jeremy.farrell> > vinschen> > the primary reason for the install hack you mentioned above). jeremy.farrell> > vinschen> > jeremy.farrell> > vinschen> > That way, we would have engines that look like DSOs and not like jeremy.farrell> > vinschen> > shared libraries. On cygwin, that would be something like "capi.dll", jeremy.farrell> > vinschen> > on MacOS it would be "capi.dylib", on most other Unixen it would be jeremy.farrell> > vinschen> > "capi.so". My intention is to have this work smoothly and jeremy.farrell> > vinschen> > consistently, without having to resort to all kinds of weird install jeremy.farrell> > vinschen> > hacks or whatnot. jeremy.farrell> > vinschen> > jeremy.farrell> > vinschen> > Does that sounds like an acceptable change to you? jeremy.farrell> > vinschen> jeremy.farrell> > vinschen> Any method being platform independent because implementation details are jeremy.farrell> > vinschen> hidden under the hood sounds perfect to me. jeremy.farrell> > jeremy.farrell> > Then it's a go, I'll work on that. Thanks for your feedback! jeremy.farrell> jeremy.farrell> It sounds good, except shouldn't it be "capi.so" for jeremy.farrell> cygwin, like the other mainstream POSIXy jeremy.farrell> implementations? The point of cygwin is that it's jeremy.farrell> POSIX not Windows, and it generally follows common jeremy.farrell> practices of POSIXy OSes for things which aren't jeremy.farrell> specified by POSIX. It seems that it would be simpler jeremy.farrell> all round (for users as well as development) to treat jeremy.farrell> it the same as "normal" UNIX-like OSes except when it jeremy.farrell> absolutely has to be treated differently. In practice, it really doesn't matter, it all comes down what the DSO module supports, and the way I'm coding this, Configure will decide. So it's a preference and nothing else. Me, I don't particularly care, but if it disturbs the Cygwin community to see one .dll too many, I'm ready to make the necessary changes (it's literally one line of code to change). Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From doctor at doctor.nl2k.ab.ca Mon Feb 15 18:45:27 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Mon, 15 Feb 2016 11:45:27 -0700 Subject: [openssl-dev] Call for testing: OpenSSH 7.2 In-Reply-To: References: Message-ID: <20160215184527.GB11163@doctor.nl2k.ab.ca> Just tested this on the old BSD/OS machine works with openssl 1.0.2X Openssl 1.1.X issues cipher.h in openssl 1.1 needs to read struct sshcipher; struct sshcipher_ctx { int plaintext; int encrypt; struct evp_cipher_ctx_st *evp; struct chachapoly_ctx cp_ctx; /* XXX union with evp? */ struct aesctr_ctx ac_ctx; /* XXX union with evp? */ const struct sshcipher *cipher; }; I am running into issues with sshkey.c gcc -g -O2 -Wall -Wpointer-arith -Wuninitialized -Wsign-compare -Wformat-security -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -ftrapv -fno-builtin-memset -I. -I. -I/usr/contrib//include -DSSHDIR=\"/etc\" -D_PATH_SSH_PROGRAM=\"/usr/contrib/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/contrib/libexec/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/usr/contrib/libexec/sftp-server\" -D_PATH_SSH_KEY_SIGN=\"/usr/contrib/libexec/ssh-keysign\" -D_PATH_SSH_PKCS11_HELPER=\"/usr/contrib/libexec/ssh-pkcs11-helper\" -D_PATH_SSH_PIDDIR=\"/var/run\" -D_PATH_PRIVSEP_CHROOT_DIR=\"/var/empty\" -DHAVE_CONFIG_H -c sshkey.c -o sshkey.o sshkey.c: In function `fingerprint_b64': sshkey.c:936: warning: implicit declaration of function `strlcpy' sshkey.c:937: warning: implicit declaration of function `strlcat' sshkey.c: In function `sshkey_ecdsa_key_to_nid': sshkey.c:1574: warning: `eg' might be used uninitialized in this function sshkey.c: In function `sshkey_private_to_blob2': sshkey.c:3026: warning: `keylen' might be used uninitialized in this function sshkey.c:3026: warning: `ivlen' might be used uninitialized in this function sshkey.c: In function `sshkey_parse_private_pem_fileblob': sshkey.c:3787: dereferencing pointer to incomplete type sshkey.c:3802: dereferencing pointer to incomplete type sshkey.c:3814: dereferencing pointer to incomplete type line 3787 if (pk->type == EVP_PKEY_RSA && line 3802 } else if (pk->type == EVP_PKEY_DSA && line 3814 } else if (pk->type == EVP_PKEY_EC && Now EVP_PKEY *pk = NULL; and /usr/contrib/include/openssl/ossl_typ.h:typedef struct evp_pkey_st EVP_PKEY; Any issue? -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Broadcasting the truth for 25 years From openssl at openssl.org Mon Feb 15 19:04:20 2016 From: openssl at openssl.org (OpenSSL) Date: Mon, 15 Feb 2016 19:04:20 +0000 Subject: [openssl-dev] OpenSSL version 1.1.0 pre release 3 published Message-ID: <20160215190420.GA12045@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenSSL version 1.1.0 pre release 3 (alpha) =========================================== OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ OpenSSL 1.1.0 is currently in alpha. OpenSSL 1.1.0 pre release 3 has now been made available. For details of changes and known issues see the release notes at: http://www.openssl.org/news/openssl-1.1.0-notes.html Note: This OpenSSL pre-release has been provided for testing ONLY. It should NOT be used for security critical purposes. The alpha release is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under http://www.openssl.org/source/mirror.html): * http://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.1.0-pre3.tar.gz Size: 5024305 SHA1 checksum: 5b2257c1d7d8db6400c9951865bd7ef58dc758b3 SHA256 checksum: bb0ead36155dcf6122bfb0555205ba562ad5a82bb6067f2bfc9111ca4a4e6442 The checksums were calculated using the following commands: openssl sha1 openssl-1.1.0-pre3.tar.gz openssl sha256 openssl-1.1.0-pre3.tar.gz Please download and check this alpha release as soon as possible. Bug reports should go to rt at openssl.org. Please check the release notes and mailing lists to avoid duplicate reports of known issues. Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJWwhryAAoJENXp5D99+e6MnDwP/juSt7tF3GZRWnR9qVtJOOna BI8xqEt18S0c396m51+kNJrZ6CMyPOLjA16Jwl+6YRdB634TlrVjxfbyTeMRKCjr kXWloh/ntOSKEWUql7auJyMZYFnvHg+fwLWRBsmrqnoXmV6044tDIF168qW1i/Sm 9g0aCx2KIKyXkWZ6e6VXOzSIckCCQbzvxhgUAIAVRLTivOwQmCSVSnqI5XzNXhQR Jm0j16ViMuHd1si/DsQDXtqFzygw6Gnh7IcLsC0S4DHcUKnli9mhcUk+AsiIqtAN s5tYfZPzyoRbAgqrN4PDBaDMhSK6TFW7b5GmxJMjbEp1UFUxPO7XhyMg3OOL9kx3 MXpCvp7J+azvppXqFgcbRq097jRVv/eS45SA92y64ucZt0Wk6mdGIpD9UJQ6njxd EiexAf3WwceLo8kxsBcIDayIzjb/HjqzUjHF2qcgfD0qQH19IYACVr2Mu4HyqDCx GIx0IUg2oltjtynVkJeaTnoApgaUF5dPTgRLKyjir1gIYdquP0mEe35+3ubTNVci n4X5FPog3U5lDHKMsHWywes8Gm8gynza6KxvaeIUTmQyWOIZwTMpvjKGuMMdyaH8 rEGJ8Xxv4WKmlJRKLrnU0KkICgEPT8sSNGQFABB4xLwxYGrHVOXVaZQ7FXvkEkZT so0emsh4V0fnfx5rNuOX =zaOF -----END PGP SIGNATURE----- From rt at openssl.org Mon Feb 15 20:09:53 2016 From: rt at openssl.org (Engstrom, John via RT) Date: Mon, 15 Feb 2016 20:09:53 +0000 Subject: [openssl-dev] [openssl.org #4300] BUG: Solaris FIPS container does not redefine bn_mul_mont_fpu in fipssyms.h In-Reply-To: <93E88AE4-1E84-4DEB-BBD5-DA8210BAADB7@tditechnologies.com> References: <029563C6-6402-4668-A405-60C3BDAE4432@tditechnologies.com> <56BBA379.7070309@openssl.org> <93E88AE4-1E84-4DEB-BBD5-DA8210BAADB7@tditechnologies.com> Message-ID: Sorry this has taken me so long to respond to. Just as you suspected adding .weak makes the build of ?big? OpenSSL work just fine. I assume that bn_mul_mont_fpu is something that in all likelihood won?t change since .weak will tell the linker to use the first definition of bn_mul_mont_fpu which I assume is the one defined in fipscanister.o? Thanks, John Engstrom > On Feb 10, 2016, at 2:54 PM, Andy Polyakov via RT wrote: > > Hi, > >> When building an OpenSSL shared library on Solaris with FIPS support you get a multiply defined symbol error: >> >> ld: fatal: symbol 'bn_mul_mont_fpu' is multiply-defined: >> (file /usr/local/ssl/fips-2.0/lib//fipscanister.o type=FUNC; file >> libcrypto.a(sparcv9a-mont.o) type=FUNC); >> ld: fatal: file processing errors. No output written to libcrypto.so.1.0.0 >> make[4]: *** [link_a.solaris] Error 1 >> >> >> This traces back to the fipssyms.h header file NOT defining bn_mul_mont_fpu when building the fipscanister. NOTE: the bn_mul_mont_fpu function in the SPARC assembly file (sparcv9a-mont.s) would also need to get redefined as fips_bn_mul_mont. > > Quoting RT#3713: > > "The > reason for why the problem in question (and similar) slip through is > that FIPS module validation procedure, exhausting as it is, does not > involve linking with "big" OpenSSL. As result one risks to remain > oblivious of them on rare platforms such as one in question till it > becomes too late. But luckily enough one can modify "big" OpenSSL to > accommodate such mishaps. Renaming symbols as general method or > case-specific workarounds ... is the way to go." > > Once again, "renaming symbols" refers to renaming in "big" OpenSSL, not > in FIPS source, which can't be modified at will. As for case-specific > workarounds in this case adding '.weak $fname' right after '.global > $fname' in sparcv9a-mont.pl in "big" OpenSSL should do the trick. Could > you verify and report back? > > > -- > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4300 > Please log in as guest with password guest if prompted > -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4300 Please log in as guest with password guest if prompted From j at w1.fi Mon Feb 15 20:52:27 2016 From: j at w1.fi (Jouni Malinen) Date: Mon, 15 Feb 2016 22:52:27 +0200 Subject: [openssl-dev] OpenSSL version 1.1.0 pre release 3 published In-Reply-To: <20160215190420.GA12045@openssl.org> References: <20160215190420.GA12045@openssl.org> Message-ID: <20160215205227.GA18770@w1.fi> On Mon, Feb 15, 2016 at 07:04:20PM +0000, OpenSSL wrote: > OpenSSL version 1.1.0 pre release 3 (alpha) > > OpenSSL 1.1.0 is currently in alpha. OpenSSL 1.1.0 pre release 3 has now > been made available. For details of changes and known issues see the > release notes at: > > http://www.openssl.org/news/openssl-1.1.0-notes.html It looks like something in pre release 3 has changed behavior in a way that results in SSL_CTX_new(SSLv23_method()) failing in some cases. I've never seen this with earlier releases. It looks like the error within SSL_CTX_new() is in EVP_get_digestbyname("ssl3-md5") returning NULL suddenly after a process has called SSL_CTX_new() and SSL_CTX_free() multiple times. Based on a git bisect between OpenSSL_1_1_0-pre2 and OpenSSL_1_1_0-pre3 tags, it looks like the different behavior was triggered by commit 7fa792d14d06cdaca18f225b1d2d8daf8ed24fd7 ('Auto init/de-init libssl'). That does add a call to OPENSSL_INIT_ssl_library_start(OPENSSL_INIT_LOAD_SSL_STRINGS, NULL) within SSL_CTX_new(), so I guess this is somehow messing up the registered digests. The program in question (wpa_supplicant) calls SSL_load_error_strings(), SSL_library_init(), EVP_add_digest(EVP_sha256()), EVP_add_cipher(EVP_rc2_40_cbc()), and PKCS12_PBE_add(), but commenting these out did not change anything for the issue. I could not find anything related to this in the release notes either. Is this a bug somewhere in pre release 3 or is there supposed to be some changes needed in applications using OpenSSL to work with this auto init/de-init libssl change? -- Jouni Malinen PGP id EFC895FA From matt at openssl.org Mon Feb 15 21:20:27 2016 From: matt at openssl.org (Matt Caswell) Date: Mon, 15 Feb 2016 21:20:27 +0000 Subject: [openssl-dev] OpenSSL version 1.1.0 pre release 3 published In-Reply-To: <20160215205227.GA18770@w1.fi> References: <20160215190420.GA12045@openssl.org> <20160215205227.GA18770@w1.fi> Message-ID: <56C2411B.2040408@openssl.org> On 15/02/16 20:52, Jouni Malinen wrote: > On Mon, Feb 15, 2016 at 07:04:20PM +0000, OpenSSL wrote: >> OpenSSL version 1.1.0 pre release 3 (alpha) >> >> OpenSSL 1.1.0 is currently in alpha. OpenSSL 1.1.0 pre release 3 has now >> been made available. For details of changes and known issues see the >> release notes at: >> >> http://www.openssl.org/news/openssl-1.1.0-notes.html > > It looks like something in pre release 3 has changed behavior in a way > that results in SSL_CTX_new(SSLv23_method()) failing in some cases. I've > never seen this with earlier releases. It looks like the error within > SSL_CTX_new() is in EVP_get_digestbyname("ssl3-md5") returning NULL > suddenly after a process has called SSL_CTX_new() and SSL_CTX_free() > multiple times. > > Based on a git bisect between OpenSSL_1_1_0-pre2 and OpenSSL_1_1_0-pre3 > tags, it looks like the different behavior was triggered by commit > 7fa792d14d06cdaca18f225b1d2d8daf8ed24fd7 ('Auto init/de-init libssl'). > That does add a call to > OPENSSL_INIT_ssl_library_start(OPENSSL_INIT_LOAD_SSL_STRINGS, NULL) > within SSL_CTX_new(), so I guess this is somehow messing up the > registered digests. > > The program in question (wpa_supplicant) calls SSL_load_error_strings(), > SSL_library_init(), EVP_add_digest(EVP_sha256()), > EVP_add_cipher(EVP_rc2_40_cbc()), and PKCS12_PBE_add(), but commenting > these out did not change anything for the issue. > > I could not find anything related to this in the release notes either. > > Is this a bug somewhere in pre release 3 or is there supposed to be some > changes needed in applications using OpenSSL to work with this auto > init/de-init libssl change? > > Do you call EVP_cleanup() at any point between creating the SSL_CTX objects? Matt From j at w1.fi Mon Feb 15 21:25:30 2016 From: j at w1.fi (Jouni Malinen) Date: Mon, 15 Feb 2016 23:25:30 +0200 Subject: [openssl-dev] OpenSSL version 1.1.0 pre release 3 published In-Reply-To: <20160215205227.GA18770@w1.fi> References: <20160215190420.GA12045@openssl.org> <20160215205227.GA18770@w1.fi> Message-ID: <20160215212530.GA13775@w1.fi> On Mon, Feb 15, 2016 at 10:52:27PM +0200, Jouni Malinen wrote: > On Mon, Feb 15, 2016 at 07:04:20PM +0000, OpenSSL wrote: > > OpenSSL version 1.1.0 pre release 3 (alpha) > It looks like something in pre release 3 has changed behavior in a way > that results in SSL_CTX_new(SSLv23_method()) failing in some cases. I've > never seen this with earlier releases. It looks like the error within > SSL_CTX_new() is in EVP_get_digestbyname("ssl3-md5") returning NULL > suddenly after a process has called SSL_CTX_new() and SSL_CTX_free() > multiple times. Found the trigger.. When adding and removing a network interface, wpa_supplicant ends up going through OpenSSL library init and deinit. One part of that deinit is a call to EVP_cleanup(). Init on the other hand is calling SSL_library_init(). The difference between pre release 2 and 3 is in the SSL_library_init() call after EVP_cleanup() call not adding back the needed digest registration. Is this change in OpenSSL behavior expected? Is it not allowed to call EVP_cleanup() and then re-initialize OpenSSL digests with SSL_library_init()? I can "fix" this by removing the EVP_cleanup() call in wpa_supplicant, but that does not sound like the best thing to do here since it was needed to avoid leaving allocated memory behind during process deinit (i.e., getting memory leak reports from valgrind). The way the ossl_init_ssl_base() function is "hidden" within ssl_init.c, the application cannot even call it again, so other than duplicating the contents of that function after that EVP_cleanup() call, I don't see how this could be fixed cleanly without an OpenSSL change. -- Jouni Malinen PGP id EFC895FA From matt at openssl.org Mon Feb 15 21:34:33 2016 From: matt at openssl.org (Matt Caswell) Date: Mon, 15 Feb 2016 21:34:33 +0000 Subject: [openssl-dev] OpenSSL version 1.1.0 pre release 3 published In-Reply-To: <20160215212530.GA13775@w1.fi> References: <20160215190420.GA12045@openssl.org> <20160215205227.GA18770@w1.fi> <20160215212530.GA13775@w1.fi> Message-ID: <56C24469.2050605@openssl.org> On 15/02/16 21:25, Jouni Malinen wrote: > On Mon, Feb 15, 2016 at 10:52:27PM +0200, Jouni Malinen wrote: >> On Mon, Feb 15, 2016 at 07:04:20PM +0000, OpenSSL wrote: >>> OpenSSL version 1.1.0 pre release 3 (alpha) > >> It looks like something in pre release 3 has changed behavior in a way >> that results in SSL_CTX_new(SSLv23_method()) failing in some cases. I've >> never seen this with earlier releases. It looks like the error within >> SSL_CTX_new() is in EVP_get_digestbyname("ssl3-md5") returning NULL >> suddenly after a process has called SSL_CTX_new() and SSL_CTX_free() >> multiple times. > > Found the trigger.. When adding and removing a network interface, > wpa_supplicant ends up going through OpenSSL library init and deinit. > One part of that deinit is a call to EVP_cleanup(). Init on the other > hand is calling SSL_library_init(). The difference between pre release 2 > and 3 is in the SSL_library_init() call after EVP_cleanup() call not > adding back the needed digest registration. > > Is this change in OpenSSL behavior expected? Is it not allowed to call > EVP_cleanup() and then re-initialize OpenSSL digests with > SSL_library_init()? Correct, you cannot reinit once you have deinit. > > I can "fix" this by removing the EVP_cleanup() call in wpa_supplicant, > but that does not sound like the best thing to do here since it was > needed to avoid leaving allocated memory behind during process deinit > (i.e., getting memory leak reports from valgrind). > > The way the ossl_init_ssl_base() function is "hidden" within > ssl_init.c, the application cannot even call it again, so other than > duplicating the contents of that function after that EVP_cleanup() call, > I don't see how this could be fixed cleanly without an OpenSSL change. > You should not need to explicitly init or deinit at all. Try removing all such calls. If you are getting memory leaks not caused by your application then that is a bug in OpenSSL. Matt From j at w1.fi Mon Feb 15 21:50:40 2016 From: j at w1.fi (Jouni Malinen) Date: Mon, 15 Feb 2016 23:50:40 +0200 Subject: [openssl-dev] OpenSSL version 1.1.0 pre release 3 published In-Reply-To: <56C24469.2050605@openssl.org> References: <20160215190420.GA12045@openssl.org> <20160215205227.GA18770@w1.fi> <20160215212530.GA13775@w1.fi> <56C24469.2050605@openssl.org> Message-ID: <20160215215040.GA23301@w1.fi> On Mon, Feb 15, 2016 at 09:34:33PM +0000, Matt Caswell wrote: > On 15/02/16 21:25, Jouni Malinen wrote: > > Is this change in OpenSSL behavior expected? Is it not allowed to call > > EVP_cleanup() and then re-initialize OpenSSL digests with > > SSL_library_init()? > > Correct, you cannot reinit once you have deinit. OK.. That used to work, though, so it would be good to mention this clearly in the release notes since this can cause a difficult to find issues for existing programs. Luckily I happened to have automated test cases that found this now with wpa_supplicant. > You should not need to explicitly init or deinit at all. Try removing > all such calls. If you are getting memory leaks not caused by your > application then that is a bug in OpenSSL. I agree with the "should not need" part, but there is a reason why I added those calls in the first place, i.e., these were needed with older OpenSSL releases (well, all releases so far since 1.1.0 has not been released). I guess I can remove these calls with #ifdef OPENSSL_VERSION_NUMBER < 0x10100000L to maintain support for older versions. I'd also recommend updating EVP_cleanup man page to be clearer about EVP_cleanup() being something that must not be called if there is going to be any future calls to OpenSSL before the process exits. -- Jouni Malinen PGP id EFC895FA From matt at openssl.org Mon Feb 15 22:17:15 2016 From: matt at openssl.org (Matt Caswell) Date: Mon, 15 Feb 2016 22:17:15 +0000 Subject: [openssl-dev] OpenSSL version 1.1.0 pre release 3 published In-Reply-To: <20160215215040.GA23301@w1.fi> References: <20160215190420.GA12045@openssl.org> <20160215205227.GA18770@w1.fi> <20160215212530.GA13775@w1.fi> <56C24469.2050605@openssl.org> <20160215215040.GA23301@w1.fi> Message-ID: <56C24E6B.5090808@openssl.org> On 15/02/16 21:50, Jouni Malinen wrote: > On Mon, Feb 15, 2016 at 09:34:33PM +0000, Matt Caswell wrote: >> On 15/02/16 21:25, Jouni Malinen wrote: >>> Is this change in OpenSSL behavior expected? Is it not allowed to call >>> EVP_cleanup() and then re-initialize OpenSSL digests with >>> SSL_library_init()? >> >> Correct, you cannot reinit once you have deinit. > > OK.. That used to work, though, so it would be good to mention this > clearly in the release notes since this can cause a difficult to find > issues for existing programs. Luckily I happened to have automated test > cases that found this now with wpa_supplicant. > >> You should not need to explicitly init or deinit at all. Try removing >> all such calls. If you are getting memory leaks not caused by your >> application then that is a bug in OpenSSL. > > I agree with the "should not need" part, but there is a reason why I > added those calls in the first place, i.e., these were needed with older > OpenSSL releases (well, all releases so far since 1.1.0 has not been > released). I guess I can remove these calls with #ifdef > OPENSSL_VERSION_NUMBER < 0x10100000L to maintain support for older > versions. > > I'd also recommend updating EVP_cleanup man page to be clearer about > EVP_cleanup() being something that must not be called if there is going > to be any future calls to OpenSSL before the process exits. Maybe EVP_cleanup() and other similar explicit deinit functions should be deprecated, and do nothing in 1.1.0? The auto-deinit capability should handle it. That way you would not need to do anything "special" for 1.1.0 with "#ifdef" etc. What do you think? If applications *must* do explicit cleanup they can always use the new OPENSSL_cleanup() function (which is clear in the docs that you cannot reinit afterwards). Matt From erik at efca.com Mon Feb 15 22:30:48 2016 From: erik at efca.com (Erik Forsberg) Date: Mon, 15 Feb 2016 14:30:48 -0800 Subject: [openssl-dev] 1.1-pre3 configuration changes Message-ID: OK, now I'm confused, in pre2 I started using personal .conf files with my specific build configuration, that no longer works in pre3 If I do the same as before, I copied my conf file into Configurations subdirectory then ran make -f Makefile.in TABLE to generate a new TABLE file containing my configuration among all other configs. Then I ran a normal Configure Doing that with pre3, make TABLE bombs out because the Makefile.in file has stuff in it that must be processed by perl first (line 33 is first case) How should I update the TABLE file in pre3 ? From levitte at openssl.org Mon Feb 15 22:36:23 2016 From: levitte at openssl.org (Richard Levitte) Date: Mon, 15 Feb 2016 23:36:23 +0100 (CET) Subject: [openssl-dev] 1.1-pre3 configuration changes In-Reply-To: References: Message-ID: <20160215.233623.1870316931576077268.levitte@openssl.org> In message on Mon, 15 Feb 2016 14:30:48 -0800, "Erik Forsberg" said: erik> erik> OK, now I'm confused, in pre2 I started using personal .conf erik> files with my specific build configuration, that no longer works in pre3 erik> erik> If I do the same as before, I copied my conf file into Configurations erik> subdirectory then ran make -f Makefile.in TABLE to generate a new TABLE erik> file containing my configuration among all other configs. Then I ran erik> a normal Configure erik> erik> Doing that with pre3, make TABLE bombs out because the Makefile.in file erik> has stuff in it that must be processed by perl first (line 33 is first case) erik> erik> How should I update the TABLE file in pre3 ? Some changes have been made, it's true. Would you mind letting me have a look at your .conf file to see for myself? -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From erik at efca.com Mon Feb 15 23:02:52 2016 From: erik at efca.com (Erik Forsberg) Date: Mon, 15 Feb 2016 15:02:52 -0800 Subject: [openssl-dev] 1.1-pre3 configuration changes In-Reply-To: <20160215.233623.1870316931576077268.levitte@openssl.org> References: <20160215.233623.1870316931576077268.levitte@openssl.org> Message-ID: <6A2KG6vygF8027u@srv.efca.com> Sure, attached. However, dont think anything wrong with it, I did notice the changes and aligned. The question is more how do I incorporate my custom conf file into the build system. Copying this conf file into Configrations and running make -f Makefile.in TABLE results in this + cp ../20-efca.conf Configurations + make -f Makefile.in TABLE make: Fatal error in reader: Makefile.in, line 33: Badly formed macro assignment GNU make throws a differently worded error on same line. If I manually run perl Configure TABLE > TABLE it works OK, at least I can run Configure Another bug is that with pre3, assembler support is broken for solaris64-x86_64-cc configurations. First assembler file x86_64cpuid.pl gets tons of syntax errors. Havent looked too deep yet. Has been working fine for ever. My platform is Solaris 11 x64 using native SunStudio btw Will try gcc too. >-- Original Message -- > >In message on Mon, 15 Feb 2016 14:30:48 -0800, "Erik Forsberg" said: > >erik> >erik> OK, now I'm confused, in pre2 I started using personal .conf >erik> files with my specific build configuration, that no longer works in pre3 >erik> >erik> If I do the same as before, I copied my conf file into Configurations >erik> subdirectory then ran make -f Makefile.in TABLE to generate a new TABLE >erik> file containing my configuration among all other configs. Then I ran >erik> a normal Configure >erik> >erik> Doing that with pre3, make TABLE bombs out because the Makefile.in file >erik> has stuff in it that must be processed by perl first (line 33 is first case) >erik> >erik> How should I update the TABLE file in pre3 ? > >Some changes have been made, it's true. Would you mind letting me >have a look at your .conf file to see for myself? > >-- >Richard Levitte levitte at openssl.org >OpenSSL Project http://www.openssl.org/~levitte/ >-- >openssl-dev mailing list >To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: 20-efca.conf Type: application/octet-stream Size: 2749 bytes Desc: not available URL: From matt at openssl.org Mon Feb 15 23:15:09 2016 From: matt at openssl.org (Matt Caswell) Date: Mon, 15 Feb 2016 23:15:09 +0000 Subject: [openssl-dev] memory leaks detected using libSSL 1.1 In-Reply-To: <000001d166bc$308f5680$91ae0380$@sales@free.fr> References: <000001d166ac$9660f640$c322e2c0$@sales@free.fr> <56BFBC88.1010901@openssl.org> <000001d166bc$308f5680$91ae0380$@sales@free.fr> Message-ID: <56C25BFD.3060708@openssl.org> On 14/02/16 00:11, Michel wrote: > Hi Matt, > > Thanks for your quick answer. > I applied your patch and it fixes the leaks found in the simple test > program. > > However, a more complex one, still report [other] leaks. > > Below is a new log if you can have a look at them. > I will investigate deeper tomorrow concering 1.0.2. Are you linking to OpenSSL statically? Please see the "Notes" section on this page: https://www.openssl.org/docs/manmaster/crypto/OPENSSL_atexit.html Matt > > Thanks again, > > Michel. > > Detected memory leaks! > Dumping objects -> > {4383} normal block at 0x006472C8, 8 bytes long. > Data: < > 00 00 00 00 01 00 00 00 > {4381} normal block at 0x00646B48, 12 bytes long. > Data: < od } > D8 6F 64 00 00 00 00 00 20 7D 00 00 > {4379} normal block at 0x00647248, 64 bytes long. > Data: 48 6B 64 00 00 00 00 00 00 00 00 00 00 00 00 00 > {4377} normal block at 0x006471A8, 96 bytes long. > Data: 48 72 64 00 10 03 A5 00 30 03 A5 00 08 00 00 00 > {4375} normal block at 0x00646FD8, 400 bytes long. > Data: < > 00 00 00 00 A0 09 00 00 00 00 00 00 00 00 00 00 > Object dump complete. > > WARNING: Visual Leak Detector detected memory leaks! > ---------- Block 4363 at 0x00646B48: 12 bytes ---------- > Leak Hash: 0xF7E93E2A, Count: 1, Total 12 bytes > Call Stack (TID 2464): > ntdll.dll!RtlAllocateHeap() > f:\dd\vctools\crt\crtw32\misc\dbgmalloc.c (56): TestsTLS-11.exe!malloc() > + 0x15 bytes > e:\openssl-1.1.git\crypto\mem.c (138): TestsTLS-11.exe!CRYPTO_malloc() + > 0x9 bytes > e:\openssl-1.1.git\crypto\lhash\lhash.c (168): > TestsTLS-11.exe!lh_insert() + 0xB bytes > e:\openssl-1.1.git\crypto\err\err_lcl.h (2): > TestsTLS-11.exe!lh_ERR_STATE_insert() + 0x10 bytes > e:\openssl-1.1.git\crypto\err\err.c (371): > TestsTLS-11.exe!int_thread_set_item() + 0xD bytes > e:\openssl-1.1.git\crypto\err\err.c (884): > TestsTLS-11.exe!ERR_get_state() + 0xC bytes > e:\openssl-1.1.git\crypto\err\err.c (598): > TestsTLS-11.exe!ERR_clear_error() + 0x5 bytes > e:\openssl-1.1.git\ssl\statem\statem.c (279): > TestsTLS-11.exe!state_machine() > e:\openssl-1.1.git\ssl\statem\statem.c (217): > TestsTLS-11.exe!ossl_statem_connect() + 0xB bytes > e:\openssl-1.1.git\ssl\ssl_lib.c (2908): > TestsTLS-11.exe!SSL_do_handshake() + 0xC bytes > p:\mes programmes\shared\ocrypto-11\tls.cpp (1017): > TestsTLS-11.exe!OTLS::TLSSss::DoHandshake() + 0xC bytes > p:\mes programmes\tests\_testsshared\teststls-11-leak\clttasks.cpp (63): > TestsTLS-11.exe!CltThread::Main() + 0xB bytes > p:\mes programmes\shared\sthread.cpp (17): > TestsTLS-11.exe!SThread::Run() + 0xE bytes > f:\dd\vctools\crt\crtw32\startup\threadex.c (359): > TestsTLS-11.exe!_threadstartex() > > ---------- Block 4357 at 0x00646FD8: 400 bytes ---------- > Leak Hash: 0xC22F7275, Count: 1, Total 400 bytes > Call Stack (TID 2464): > ntdll.dll!RtlAllocateHeap() > f:\dd\vctools\crt\crtw32\misc\dbgmalloc.c (56): TestsTLS-11.exe!malloc() > + 0x15 bytes > e:\openssl-1.1.git\crypto\mem.c (138): TestsTLS-11.exe!CRYPTO_malloc() + > 0x9 bytes > e:\openssl-1.1.git\crypto\err\err.c (874): > TestsTLS-11.exe!ERR_get_state() + 0xE bytes > e:\openssl-1.1.git\crypto\err\err.c (598): > TestsTLS-11.exe!ERR_clear_error() + 0x5 bytes > e:\openssl-1.1.git\ssl\statem\statem.c (279): > TestsTLS-11.exe!state_machine() > e:\openssl-1.1.git\ssl\statem\statem.c (217): > TestsTLS-11.exe!ossl_statem_connect() + 0xB bytes > e:\openssl-1.1.git\ssl\ssl_lib.c (2908): > TestsTLS-11.exe!SSL_do_handshake() + 0xC bytes > p:\mes programmes\shared\ocrypto-11\tls.cpp (1017): > TestsTLS-11.exe!OTLS::TLSSss::DoHandshake() + 0xC bytes > p:\mes programmes\tests\_testsshared\teststls-11-leak\clttasks.cpp (63): > TestsTLS-11.exe!CltThread::Main() + 0xB bytes > p:\mes programmes\shared\sthread.cpp (17): > TestsTLS-11.exe!SThread::Run() + 0xE bytes > f:\dd\vctools\crt\crtw32\startup\threadex.c (359): > TestsTLS-11.exe!_threadstartex() > > ---------- Block 4359 at 0x006471A8: 96 bytes ---------- > Leak Hash: 0x1DBDD4B0, Count: 1, Total 96 bytes > Call Stack (TID 2464): > ntdll.dll!RtlAllocateHeap() > f:\dd\vctools\crt\crtw32\misc\dbgmalloc.c (56): TestsTLS-11.exe!malloc() > + 0x15 bytes > e:\openssl-1.1.git\crypto\mem.c (138): TestsTLS-11.exe!CRYPTO_malloc() + > 0x9 bytes > e:\openssl-1.1.git\crypto\mem.c (158): TestsTLS-11.exe!CRYPTO_zalloc() + > 0x11 bytes > e:\openssl-1.1.git\crypto\lhash\lhash.c (116): TestsTLS-11.exe!lh_new() > + 0xB bytes > e:\openssl-1.1.git\crypto\err\err_lcl.h (2): > TestsTLS-11.exe!lh_ERR_STATE_new() + 0x10 bytes > e:\openssl-1.1.git\crypto\err\err.c (321): > TestsTLS-11.exe!int_thread_get() + 0xF bytes > e:\openssl-1.1.git\crypto\err\err.c (369): > TestsTLS-11.exe!int_thread_set_item() + 0x9 bytes > e:\openssl-1.1.git\crypto\err\err.c (884): > TestsTLS-11.exe!ERR_get_state() + 0xC bytes > e:\openssl-1.1.git\crypto\err\err.c (598): > TestsTLS-11.exe!ERR_clear_error() + 0x5 bytes > e:\openssl-1.1.git\ssl\statem\statem.c (279): > TestsTLS-11.exe!state_machine() > e:\openssl-1.1.git\ssl\statem\statem.c (217): > TestsTLS-11.exe!ossl_statem_connect() + 0xB bytes > e:\openssl-1.1.git\ssl\ssl_lib.c (2908): > TestsTLS-11.exe!SSL_do_handshake() + 0xC bytes > p:\mes programmes\shared\ocrypto-11\tls.cpp (1017): > TestsTLS-11.exe!OTLS::TLSSss::DoHandshake() + 0xC bytes > p:\mes programmes\tests\_testsshared\teststls-11-leak\clttasks.cpp (63): > TestsTLS-11.exe!CltThread::Main() + 0xB bytes > p:\mes programmes\shared\sthread.cpp (17): > TestsTLS-11.exe!SThread::Run() + 0xE bytes > f:\dd\vctools\crt\crtw32\startup\threadex.c (359): > TestsTLS-11.exe!_threadstartex() > > ---------- Block 4361 at 0x00647248: 64 bytes ---------- > Leak Hash: 0x713FD291, Count: 1, Total 64 bytes > Call Stack (TID 2464): > ntdll.dll!RtlAllocateHeap() > f:\dd\vctools\crt\crtw32\misc\dbgmalloc.c (56): TestsTLS-11.exe!malloc() > + 0x15 bytes > e:\openssl-1.1.git\crypto\mem.c (138): TestsTLS-11.exe!CRYPTO_malloc() + > 0x9 bytes > e:\openssl-1.1.git\crypto\mem.c (158): TestsTLS-11.exe!CRYPTO_zalloc() + > 0x11 bytes > e:\openssl-1.1.git\crypto\lhash\lhash.c (118): TestsTLS-11.exe!lh_new() > + 0xB bytes > e:\openssl-1.1.git\crypto\err\err_lcl.h (2): > TestsTLS-11.exe!lh_ERR_STATE_new() + 0x10 bytes > e:\openssl-1.1.git\crypto\err\err.c (321): > TestsTLS-11.exe!int_thread_get() + 0xF bytes > e:\openssl-1.1.git\crypto\err\err.c (369): > TestsTLS-11.exe!int_thread_set_item() + 0x9 bytes > e:\openssl-1.1.git\crypto\err\err.c (884): > TestsTLS-11.exe!ERR_get_state() + 0xC bytes > e:\openssl-1.1.git\crypto\err\err.c (598): > TestsTLS-11.exe!ERR_clear_error() + 0x5 bytes > e:\openssl-1.1.git\ssl\statem\statem.c (279): > TestsTLS-11.exe!state_machine() > e:\openssl-1.1.git\ssl\statem\statem.c (217): > TestsTLS-11.exe!ossl_statem_connect() + 0xB bytes > e:\openssl-1.1.git\ssl\ssl_lib.c (2908): > TestsTLS-11.exe!SSL_do_handshake() + 0xC bytes > p:\mes programmes\shared\ocrypto-11\tls.cpp (1017): > TestsTLS-11.exe!OTLS::TLSSss::DoHandshake() + 0xC bytes > p:\mes programmes\tests\_testsshared\teststls-11-leak\clttasks.cpp (63): > TestsTLS-11.exe!CltThread::Main() + 0xB bytes > p:\mes programmes\shared\sthread.cpp (17): > TestsTLS-11.exe!SThread::Run() + 0xE bytes > f:\dd\vctools\crt\crtw32\startup\threadex.c (359): > TestsTLS-11.exe!_threadstartex() > > ---------- Block 4365 at 0x006472C8: 8 bytes ---------- > Leak Hash: 0xFBE574AD, Count: 1, Total 8 bytes > Call Stack (TID 2464): > ntdll.dll!RtlAllocateHeap() > f:\dd\vctools\crt\crtw32\misc\dbgmalloc.c (56): TestsTLS-11.exe!malloc() > + 0x15 bytes > e:\openssl-1.1.git\crypto\mem.c (138): TestsTLS-11.exe!CRYPTO_malloc() + > 0x9 bytes > e:\openssl-1.1.git\crypto\mem.c (158): TestsTLS-11.exe!CRYPTO_zalloc() + > 0x11 bytes > e:\openssl-1.1.git\crypto\init.c (197): > TestsTLS-11.exe!ossl_init_get_thread_local() + 0xB bytes > e:\openssl-1.1.git\crypto\init.c (511): > TestsTLS-11.exe!ossl_init_thread_start() + 0x7 bytes > e:\openssl-1.1.git\crypto\err\err.c (898): > TestsTLS-11.exe!ERR_get_state() + 0x9 bytes > e:\openssl-1.1.git\crypto\err\err.c (598): > TestsTLS-11.exe!ERR_clear_error() + 0x5 bytes > e:\openssl-1.1.git\ssl\statem\statem.c (279): > TestsTLS-11.exe!state_machine() > e:\openssl-1.1.git\ssl\statem\statem.c (217): > TestsTLS-11.exe!ossl_statem_connect() + 0xB bytes > e:\openssl-1.1.git\ssl\ssl_lib.c (2908): > TestsTLS-11.exe!SSL_do_handshake() + 0xC bytes > p:\mes programmes\shared\ocrypto-11\tls.cpp (1017): > TestsTLS-11.exe!OTLS::TLSSss::DoHandshake() + 0xC bytes > p:\mes programmes\tests\_testsshared\teststls-11-leak\clttasks.cpp (63): > TestsTLS-11.exe!CltThread::Main() + 0xB bytes > p:\mes programmes\shared\sthread.cpp (17): > TestsTLS-11.exe!SThread::Run() + 0xE bytes > f:\dd\vctools\crt\crtw32\startup\threadex.c (359): > TestsTLS-11.exe!_threadstartex() > > Visual Leak Detector detected 5 memory leaks (10757 bytes). > Largest number used: 213916 bytes. > Total allocations: 902180 bytes. > Visual Leak Detector is now exiting. > > -----Message d'origine----- > De : openssl-dev [mailto:openssl-dev-bounces at openssl.org] De la part de Matt > Caswell > Envoy? : dimanche 14 f?vrier 2016 00:30 > ? : openssl-dev at openssl.org > Objet : Re: [openssl-dev] memory leaks detected using libSSL 1.1 > > Hmmm. It does look to me like there could be a memory leak here. What's not > clear to me is to why you are only seeing this in 1.1 and not previous > versions, as it looks like the same could happen in 1.0.2 as well! > > Anyway, please try the attached patch to see if that helps. > > Let me know how you get on. > > Thanks > > Matt > > From erik at efca.com Mon Feb 15 23:15:28 2016 From: erik at efca.com (Erik Forsberg) Date: Mon, 15 Feb 2016 15:15:28 -0800 Subject: [openssl-dev] OpenSSL 1.1 pre-3 CRYPTO_set_mem_functions Message-ID: <0v59RC3DjidYWsO@srv.efca.com> just started do the 1.1 updates needed in my own software, in the past I had use the 1.0.2 memory allocation hooks to link into my own mem leak tester. 1.1 has reworked this, by what I read in the past, sounded like I could still get value out of if, but today when I looked at CRYPTO_set_mem_functions() I see they simply save function pointers into 3 static _wrapper variables. You can read them by calling CRYPTO_get_mem_functions but thats all. No other use of them at all in the file crypto/mem.c Are we supposed to be able to hook into OPENSSL_malloc() etc in 1.1 ? From levitte at openssl.org Mon Feb 15 23:16:56 2016 From: levitte at openssl.org (Richard Levitte) Date: Tue, 16 Feb 2016 00:16:56 +0100 (CET) Subject: [openssl-dev] Question about dynamically loadable engines on Cygwin / Mingw In-Reply-To: <20160215.185953.117619649162395329.levitte@openssl.org> References: <20160215.132903.588105753089173385.levitte@openssl.org> <56C210E7.5080804@oracle.com> <20160215.185953.117619649162395329.levitte@openssl.org> Message-ID: <20160216.001656.1322821529737613607.levitte@openssl.org> In message <20160215.185953.117619649162395329.levitte at openssl.org> on Mon, 15 Feb 2016 18:59:53 +0100 (CET), Richard Levitte said: levitte> In message <56C210E7.5080804 at oracle.com> on Mon, 15 Feb 2016 17:54:47 +0000, Jeremy Farrell said: levitte> levitte> jeremy.farrell> It sounds good, except shouldn't it be "capi.so" for levitte> jeremy.farrell> cygwin, like the other mainstream POSIXy levitte> jeremy.farrell> implementations? The point of cygwin is that it's levitte> jeremy.farrell> POSIX not Windows, and it generally follows common levitte> jeremy.farrell> practices of POSIXy OSes for things which aren't levitte> jeremy.farrell> specified by POSIX. It seems that it would be simpler levitte> jeremy.farrell> all round (for users as well as development) to treat levitte> jeremy.farrell> it the same as "normal" UNIX-like OSes except when it levitte> jeremy.farrell> absolutely has to be treated differently. levitte> levitte> In practice, it really doesn't matter, it all comes down what the DSO levitte> module supports, and the way I'm coding this, Configure will decide. levitte> So it's a preference and nothing else. Me, I don't particularly care, levitte> but if it disturbs the Cygwin community to see one .dll too many, I'm levitte> ready to make the necessary changes (it's literally one line of code levitte> to change). I had myself a look around in my little installation, and tried these two commands: find /usr/lib -name '*.so' find /usr/lib -name '*.dll' The first one didn't even return a screenfull (in my 25 line terminal screen), and the overwhelming majority was OpenSSL 1.0.2 engines ;-) The second one, on the other hand, gave a *lot* more output. All aspell, babl, gawk, gegl, perl(!) loadable modules are named with the FOO.dll naming convention (there are a few packages, a minority, that have named them cygFOO.dll)... and the list goes on. So looking at how things seem to be done normally, I feel confident that FOO.dll is a sane choice, even though not strictly POSIX in its file name extension. And like I said, it matters very little for any user, the goal is to allow this kind of command line: openssl s_server -engine FOO No extension, just a name for the user to worry about. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From levitte at openssl.org Mon Feb 15 23:30:54 2016 From: levitte at openssl.org (Richard Levitte) Date: Tue, 16 Feb 2016 00:30:54 +0100 (CET) Subject: [openssl-dev] 1.1-pre3 configuration changes In-Reply-To: <6A2KG6vygF8027u@srv.efca.com> References: <20160215.233623.1870316931576077268.levitte@openssl.org> <6A2KG6vygF8027u@srv.efca.com> Message-ID: <20160216.003054.1770538565803637346.levitte@openssl.org> In message <6A2KG6vygF8027u at srv.efca.com> on Mon, 15 Feb 2016 15:02:52 -0800, "Erik Forsberg" said: erik> Sure, attached. erik> However, dont think anything wrong with it, I did notice the changes erik> and aligned. The question is more how do I incorporate my custom conf file into erik> the build system. Copying this conf file into Configrations and running erik> make -f Makefile.in TABLE erik> results in this erik> erik> + cp ../20-efca.conf Configurations erik> + make -f Makefile.in TABLE erik> make: Fatal error in reader: Makefile.in, line 33: Badly formed macro assignment Ah-ha! Using Makefile.in directly like that is not possible any more. The reason is that we've templatised it. If you look, you'll see that there are perl fragments within {- and -} delimiters. Line 33 is right in the middle of one of those. The answer is that you MUST configure first. We could probably clarify that a bit louder (and when I'm looking in INSTALL right now, I'm noticing it's lagging behind on the changes. To be fixed!) erik> GNU make throws a differently worded error on same line. Yup. The answer will remain "don't do that, configure first!" erik> If I manually run erik> perl Configure TABLE > TABLE erik> it works OK, at least I can run Configure Yes. erik> Another bug is that with pre3, assembler support is broken for solaris64-x86_64-cc erik> configurations. First assembler file x86_64cpuid.pl gets tons of syntax errors. erik> Havent looked too deep yet. Has been working fine for ever. Ok, that's to look into. Mind giving us a log? erik> My platform is Solaris 11 x64 using native SunStudio btw erik> Will try gcc too. erik> erik> >-- Original Message -- erik> > erik> >In message on Mon, 15 Feb 2016 14:30:48 -0800, "Erik Forsberg" said: erik> > erik> >erik> erik> >erik> OK, now I'm confused, in pre2 I started using personal .conf erik> >erik> files with my specific build configuration, that no longer works in pre3 erik> >erik> erik> >erik> If I do the same as before, I copied my conf file into Configurations erik> >erik> subdirectory then ran make -f Makefile.in TABLE to generate a new TABLE erik> >erik> file containing my configuration among all other configs. Then I ran erik> >erik> a normal Configure erik> >erik> erik> >erik> Doing that with pre3, make TABLE bombs out because the Makefile.in file erik> >erik> has stuff in it that must be processed by perl first (line 33 is first case) erik> >erik> erik> >erik> How should I update the TABLE file in pre3 ? erik> > erik> >Some changes have been made, it's true. Would you mind letting me erik> >have a look at your .conf file to see for myself? erik> > erik> >-- erik> >Richard Levitte levitte at openssl.org erik> >OpenSSL Project http://www.openssl.org/~levitte/ erik> >-- erik> >openssl-dev mailing list erik> >To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev erik> From levitte at openssl.org Mon Feb 15 23:33:41 2016 From: levitte at openssl.org (Richard Levitte) Date: Tue, 16 Feb 2016 00:33:41 +0100 (CET) Subject: [openssl-dev] OpenSSL 1.1 pre-3 CRYPTO_set_mem_functions In-Reply-To: <0v59RC3DjidYWsO@srv.efca.com> References: <0v59RC3DjidYWsO@srv.efca.com> Message-ID: <20160216.003341.1330342472230157667.levitte@openssl.org> In message <0v59RC3DjidYWsO at srv.efca.com> on Mon, 15 Feb 2016 15:15:28 -0800, "Erik Forsberg" said: erik> erik> just started do the 1.1 updates needed in my own software, in the past I had erik> use the 1.0.2 memory allocation hooks to link into my own mem leak tester. erik> erik> 1.1 has reworked this, by what I read in the past, sounded like I could still erik> get value out of if, but today when I looked at CRYPTO_set_mem_functions() erik> I see they simply save function pointers into 3 static _wrapper variables. erik> You can read them by calling CRYPTO_get_mem_functions but thats all. erik> No other use of them at all in the file crypto/mem.c erik> erik> Are we supposed to be able to hook into OPENSSL_malloc() etc in 1.1 ? You may have missed it, but there's a CRYPTO_set_mem_functions() as well. Can't you use that? Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From erik at efca.com Mon Feb 15 23:40:40 2016 From: erik at efca.com (Erik Forsberg) Date: Mon, 15 Feb 2016 15:40:40 -0800 Subject: [openssl-dev] 1.1-pre3 configuration changes In-Reply-To: <20160216.003054.1770538565803637346.levitte@openssl.org> References: <20160216.003054.1770538565803637346.levitte@openssl.org> Message-ID: >-- Original Message -- > >In message <6A2KG6vygF8027u at srv.efca.com> on Mon, 15 Feb 2016 15:02:52 -0800, "Erik Forsberg" said: > >erik> Sure, attached. >erik> However, dont think anything wrong with it, I did notice the changes >erik> and aligned. The question is more how do I incorporate my custom conf file into >erik> the build system. Copying this conf file into Configrations and running >erik> make -f Makefile.in TABLE >erik> results in this >erik> >erik> + cp ../20-efca.conf Configurations >erik> + make -f Makefile.in TABLE >erik> make: Fatal error in reader: Makefile.in, line 33: Badly formed macro assignment > >Ah-ha! Using Makefile.in directly like that is not possible any >more. The reason is that we've templatised it. If you look, you'll >see that there are perl fragments within {- and -} delimiters. Line >33 is right in the middle of one of those. > >The answer is that you MUST configure first. We could probably >clarify that a bit louder (and when I'm looking in INSTALL right now, >I'm noticing it's lagging behind on the changes. To be fixed!) That creates the illusion of a chicken and an egg paradox. You cant configure your custom config until AFTER you have managed to update the TABLE file. I guess you can configure a standard target, then put in your custom conf file, then run make TABLE, then re-configure the custom target. Will that be the recommended process ? > >erik> GNU make throws a differently worded error on same line. > >Yup. The answer will remain "don't do that, configure first!" > >erik> If I manually run >erik> perl Configure TABLE > TABLE >erik> it works OK, at least I can run Configure > >Yes. > >erik> Another bug is that with pre3, assembler support is broken for solaris64-x86_64-cc >erik> configurations. First assembler file x86_64cpuid.pl gets tons of syntax errors. >erik> Havent looked too deep yet. Has been working fine for ever. > >Ok, that's to look into. Mind giving us a log? will start a new thread on that. > >erik> My platform is Solaris 11 x64 using native SunStudio btw >erik> Will try gcc too. >erik> >erik> >-- Original Message -- >erik> > >erik> >In message on Mon, 15 Feb 2016 14:30:48 -0800, "Erik Forsberg" said: >erik> > >erik> >erik> >erik> >erik> OK, now I'm confused, in pre2 I started using personal .conf >erik> >erik> files with my specific build configuration, that no longer works in pre3 >erik> >erik> >erik> >erik> If I do the same as before, I copied my conf file into Configurations >erik> >erik> subdirectory then ran make -f Makefile.in TABLE to generate a new TABLE >erik> >erik> file containing my configuration among all other configs. Then I ran >erik> >erik> a normal Configure >erik> >erik> >erik> >erik> Doing that with pre3, make TABLE bombs out because the Makefile.in file >erik> >erik> has stuff in it that must be processed by perl first (line 33 is first case) >erik> >erik> >erik> >erik> How should I update the TABLE file in pre3 ? >erik> > >erik> >Some changes have been made, it's true. Would you mind letting me >erik> >have a look at your .conf file to see for myself? >erik> > >erik> >-- >erik> >Richard Levitte levitte at openssl.org >erik> >OpenSSL Project http://www.openssl.org/~levitte/ >erik> >-- >erik> >openssl-dev mailing list >erik> >To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev >erik> >-- >openssl-dev mailing list >To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From erik at efca.com Mon Feb 15 23:43:28 2016 From: erik at efca.com (Erik Forsberg) Date: Mon, 15 Feb 2016 15:43:28 -0800 Subject: [openssl-dev] OpenSSL 1.1 pre-3 CRYPTO_set_mem_functions In-Reply-To: <20160216.003341.1330342472230157667.levitte@openssl.org> References: <0v59RC3DjidYWsO@srv.efca.com> <20160216.003341.1330342472230157667.levitte@openssl.org> Message-ID: I was talking about CRYPTO_set_mem_functions() It doesnt do anything, just saving some pointers that are never used for anything. So a big NO-OP, seems like a TODO implementation ? >-- Original Message -- > >In message <0v59RC3DjidYWsO at srv.efca.com> on Mon, 15 Feb 2016 15:15:28 -0800, "Erik Forsberg" said: > >erik> >erik> just started do the 1.1 updates needed in my own software, in the past I had >erik> use the 1.0.2 memory allocation hooks to link into my own mem leak tester. >erik> >erik> 1.1 has reworked this, by what I read in the past, sounded like I could still >erik> get value out of if, but today when I looked at CRYPTO_set_mem_functions() >erik> I see they simply save function pointers into 3 static _wrapper variables. >erik> You can read them by calling CRYPTO_get_mem_functions but thats all. >erik> No other use of them at all in the file crypto/mem.c >erik> >erik> Are we supposed to be able to hook into OPENSSL_malloc() etc in 1.1 ? > >You may have missed it, but there's a CRYPTO_set_mem_functions() as >well. Can't you use that? > >Cheers, >Richard > >-- >Richard Levitte levitte at openssl.org >OpenSSL Project http://www.openssl.org/~levitte/ > >-- >openssl-dev mailing list >To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From levitte at openssl.org Mon Feb 15 23:54:05 2016 From: levitte at openssl.org (Richard Levitte) Date: Tue, 16 Feb 2016 00:54:05 +0100 (CET) Subject: [openssl-dev] 1.1-pre3 configuration changes In-Reply-To: References: <20160216.003054.1770538565803637346.levitte@openssl.org> Message-ID: <20160216.005405.572975583490217601.levitte@openssl.org> In message on Mon, 15 Feb 2016 15:40:40 -0800, "Erik Forsberg" said: erik> erik> >-- Original Message -- erik> > erik> >In message <6A2KG6vygF8027u at srv.efca.com> on Mon, 15 Feb 2016 15:02:52 -0800, "Erik Forsberg" said: erik> > erik> >erik> Sure, attached. erik> >erik> However, dont think anything wrong with it, I did notice the changes erik> >erik> and aligned. The question is more how do I incorporate my custom conf file into erik> >erik> the build system. Copying this conf file into Configrations and running erik> >erik> make -f Makefile.in TABLE erik> >erik> results in this erik> >erik> erik> >erik> + cp ../20-efca.conf Configurations erik> >erik> + make -f Makefile.in TABLE erik> >erik> make: Fatal error in reader: Makefile.in, line 33: Badly formed macro assignment erik> > erik> >Ah-ha! Using Makefile.in directly like that is not possible any erik> >more. The reason is that we've templatised it. If you look, you'll erik> >see that there are perl fragments within {- and -} delimiters. Line erik> >33 is right in the middle of one of those. erik> > erik> >The answer is that you MUST configure first. We could probably erik> >clarify that a bit louder (and when I'm looking in INSTALL right now, erik> >I'm noticing it's lagging behind on the changes. To be fixed!) erik> erik> That creates the illusion of a chicken and an egg paradox. erik> You cant configure your custom config until AFTER you have erik> managed to update the TABLE file. That's not at all true. The TABLE file is for your convenience only, meant as a visual configuration debugging tool which has frankly lost its value by now. It was much more valuable in pre-1.1 OpenSSL versions, as those string configurations are quite hard to read. Setting up and building OpenSSL doesn't need the TABLE file at all. I can't remember that it ever has. All you have to do to configure your favorit configuration is this: perl Configure efca-x64-gcc [options] That's it. No TABLE file needed. erik> I guess you can configure a standard target, then put in your erik> custom conf file, then run make TABLE, then re-configure the erik> custom target. Will that be the recommended process ? Nope. Just put your custom 20-efca.conf in Configurations and fire off the Configure command demonstrated above. I'm afraid you're complicating things needlessly... erik> erik> > erik> >erik> GNU make throws a differently worded error on same line. erik> > erik> >Yup. The answer will remain "don't do that, configure first!" erik> > erik> >erik> If I manually run erik> >erik> perl Configure TABLE > TABLE erik> >erik> it works OK, at least I can run Configure erik> > erik> >Yes. erik> > erik> >erik> Another bug is that with pre3, assembler support is broken for solaris64-x86_64-cc erik> >erik> configurations. First assembler file x86_64cpuid.pl gets tons of syntax errors. erik> >erik> Havent looked too deep yet. Has been working fine for ever. erik> > erik> >Ok, that's to look into. Mind giving us a log? erik> erik> will start a new thread on that. erik> erik> > erik> >erik> My platform is Solaris 11 x64 using native SunStudio btw erik> >erik> Will try gcc too. erik> >erik> erik> >erik> >-- Original Message -- erik> >erik> > erik> >erik> >In message on Mon, 15 Feb 2016 14:30:48 -0800, "Erik Forsberg" said: erik> >erik> > erik> >erik> >erik> erik> >erik> >erik> OK, now I'm confused, in pre2 I started using personal .conf erik> >erik> >erik> files with my specific build configuration, that no longer works in pre3 erik> >erik> >erik> erik> >erik> >erik> If I do the same as before, I copied my conf file into Configurations erik> >erik> >erik> subdirectory then ran make -f Makefile.in TABLE to generate a new TABLE erik> >erik> >erik> file containing my configuration among all other configs. Then I ran erik> >erik> >erik> a normal Configure erik> >erik> >erik> erik> >erik> >erik> Doing that with pre3, make TABLE bombs out because the Makefile.in file erik> >erik> >erik> has stuff in it that must be processed by perl first (line 33 is first case) erik> >erik> >erik> erik> >erik> >erik> How should I update the TABLE file in pre3 ? erik> >erik> > erik> >erik> >Some changes have been made, it's true. Would you mind letting me erik> >erik> >have a look at your .conf file to see for myself? erik> >erik> > erik> >erik> >-- erik> >erik> >Richard Levitte levitte at openssl.org erik> >erik> >OpenSSL Project http://www.openssl.org/~levitte/ erik> >erik> >-- erik> >erik> >openssl-dev mailing list erik> >erik> >To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev erik> >erik> erik> >-- erik> >openssl-dev mailing list erik> >To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev erik> erik> -- erik> openssl-dev mailing list erik> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev erik> From levitte at openssl.org Mon Feb 15 23:56:09 2016 From: levitte at openssl.org (Richard Levitte) Date: Tue, 16 Feb 2016 00:56:09 +0100 (CET) Subject: [openssl-dev] OpenSSL 1.1 pre-3 CRYPTO_set_mem_functions In-Reply-To: References: <0v59RC3DjidYWsO@srv.efca.com> <20160216.003341.1330342472230157667.levitte@openssl.org> Message-ID: <20160216.005609.2264501703125197202.levitte@openssl.org> You know, you're entirely right. That's a flaw and needs correction. Thanks for the notification. Cheers, Richard In message on Mon, 15 Feb 2016 15:43:28 -0800, "Erik Forsberg" said: erik> I was talking about CRYPTO_set_mem_functions() erik> erik> It doesnt do anything, just saving some pointers that are never erik> used for anything. So a big NO-OP, seems like a TODO implementation ? erik> erik> >-- Original Message -- erik> > erik> >In message <0v59RC3DjidYWsO at srv.efca.com> on Mon, 15 Feb 2016 15:15:28 -0800, "Erik Forsberg" said: erik> > erik> >erik> erik> >erik> just started do the 1.1 updates needed in my own software, in the past I had erik> >erik> use the 1.0.2 memory allocation hooks to link into my own mem leak tester. erik> >erik> erik> >erik> 1.1 has reworked this, by what I read in the past, sounded like I could still erik> >erik> get value out of if, but today when I looked at CRYPTO_set_mem_functions() erik> >erik> I see they simply save function pointers into 3 static _wrapper variables. erik> >erik> You can read them by calling CRYPTO_get_mem_functions but thats all. erik> >erik> No other use of them at all in the file crypto/mem.c erik> >erik> erik> >erik> Are we supposed to be able to hook into OPENSSL_malloc() etc in 1.1 ? erik> > erik> >You may have missed it, but there's a CRYPTO_set_mem_functions() as erik> >well. Can't you use that? erik> > erik> >Cheers, erik> >Richard erik> > erik> >-- erik> >Richard Levitte levitte at openssl.org erik> >OpenSSL Project http://www.openssl.org/~levitte/ erik> > erik> >-- erik> >openssl-dev mailing list erik> >To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev erik> erik> -- erik> openssl-dev mailing list erik> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev erik> From erik at efca.com Tue Feb 16 00:06:20 2016 From: erik at efca.com (Erik Forsberg) Date: Mon, 15 Feb 2016 16:06:20 -0800 Subject: [openssl-dev] 1.1-pre3 configuration changes In-Reply-To: <20160216.005405.572975583490217601.levitte@openssl.org> References: <20160216.005405.572975583490217601.levitte@openssl.org> Message-ID: >-- Original Message -- > >In message on Mon, 15 Feb 2016 15:40:40 -0800, "Erik Forsberg" said: > >erik> >erik> >-- Original Message -- >erik> > >erik> >In message <6A2KG6vygF8027u at srv.efca.com> on Mon, 15 Feb 2016 15:02:52 -0800, "Erik Forsberg" said: >erik> > >erik> >erik> Sure, attached. >erik> >erik> However, dont think anything wrong with it, I did notice the changes >erik> >erik> and aligned. The question is more how do I incorporate my custom conf file into >erik> >erik> the build system. Copying this conf file into Configrations and running >erik> >erik> make -f Makefile.in TABLE >erik> >erik> results in this >erik> >erik> >erik> >erik> + cp ../20-efca.conf Configurations >erik> >erik> + make -f Makefile.in TABLE >erik> >erik> make: Fatal error in reader: Makefile.in, line 33: Badly formed macro assignment >erik> > >erik> >Ah-ha! Using Makefile.in directly like that is not possible any >erik> >more. The reason is that we've templatised it. If you look, you'll >erik> >see that there are perl fragments within {- and -} delimiters. Line >erik> >33 is right in the middle of one of those. >erik> > >erik> >The answer is that you MUST configure first. We could probably >erik> >clarify that a bit louder (and when I'm looking in INSTALL right now, >erik> >I'm noticing it's lagging behind on the changes. To be fixed!) >erik> >erik> That creates the illusion of a chicken and an egg paradox. >erik> You cant configure your custom config until AFTER you have >erik> managed to update the TABLE file. > >That's not at all true. The TABLE file is for your convenience only, >meant as a visual configuration debugging tool which has frankly lost >its value by now. It was much more valuable in pre-1.1 OpenSSL >versions, as those string configurations are quite hard to read. >Setting up and building OpenSSL doesn't need the TABLE file at all. I >can't remember that it ever has. I certainly was under the impression it was needed. Every .conf file had an admonition to update TABLE at the top -:) A quick test confirms that you dont need it anymore though. Which is fine with me. > >All you have to do to configure your favorit configuration is this: > > perl Configure efca-x64-gcc [options] > >That's it. No TABLE file needed. > >erik> I guess you can configure a standard target, then put in your >erik> custom conf file, then run make TABLE, then re-configure the >erik> custom target. Will that be the recommended process ? > >Nope. Just put your custom 20-efca.conf in Configurations and fire >off the Configure command demonstrated above. I'm afraid you're >complicating things needlessly... Indeed looks like it. This process of custom configs works perfectly fine by me. > >erik> >erik> > >erik> >erik> GNU make throws a differently worded error on same line. >erik> > >erik> >Yup. The answer will remain "don't do that, configure first!" >erik> > >erik> >erik> If I manually run >erik> >erik> perl Configure TABLE > TABLE >erik> >erik> it works OK, at least I can run Configure >erik> > >erik> >Yes. >erik> > >erik> >erik> Another bug is that with pre3, assembler support is broken for solaris64-x86_64-cc >erik> >erik> configurations. First assembler file x86_64cpuid.pl gets tons of syntax errors. >erik> >erik> Havent looked too deep yet. Has been working fine for ever. >erik> > >erik> >Ok, that's to look into. Mind giving us a log? >erik> >erik> will start a new thread on that. >erik> >erik> > >erik> >erik> My platform is Solaris 11 x64 using native SunStudio btw >erik> >erik> Will try gcc too. >erik> >erik> >erik> >erik> >-- Original Message -- >erik> >erik> > >erik> >erik> >In message on Mon, 15 Feb 2016 14:30:48 -0800, "Erik Forsberg" said: >erik> >erik> > >erik> >erik> >erik> >erik> >erik> >erik> OK, now I'm confused, in pre2 I started using personal .conf >erik> >erik> >erik> files with my specific build configuration, that no longer works in pre3 >erik> >erik> >erik> >erik> >erik> >erik> If I do the same as before, I copied my conf file into Configurations >erik> >erik> >erik> subdirectory then ran make -f Makefile.in TABLE to generate a new TABLE >erik> >erik> >erik> file containing my configuration among all other configs. Then I ran >erik> >erik> >erik> a normal Configure >erik> >erik> >erik> >erik> >erik> >erik> Doing that with pre3, make TABLE bombs out because the Makefile.in file >erik> >erik> >erik> has stuff in it that must be processed by perl first (line 33 is first case) >erik> >erik> >erik> >erik> >erik> >erik> How should I update the TABLE file in pre3 ? >erik> >erik> > >erik> >erik> >Some changes have been made, it's true. Would you mind letting me >erik> >erik> >have a look at your .conf file to see for myself? >erik> >erik> > >erik> >erik> >-- >erik> >erik> >Richard Levitte levitte at openssl.org >erik> >erik> >OpenSSL Project http://www.openssl.org/~levitte/ >erik> >erik> >-- >erik> >erik> >openssl-dev mailing list >erik> >erik> >To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev >erik> >erik> >erik> >-- >erik> >openssl-dev mailing list >erik> >To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev >erik> >erik> -- >erik> openssl-dev mailing list >erik> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev >erik> >-- >openssl-dev mailing list >To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From levitte at openssl.org Tue Feb 16 00:11:53 2016 From: levitte at openssl.org (Richard Levitte) Date: Tue, 16 Feb 2016 01:11:53 +0100 (CET) Subject: [openssl-dev] 1.1-pre3 configuration changes In-Reply-To: References: <20160216.005405.572975583490217601.levitte@openssl.org> Message-ID: <20160216.011153.1613401554448059821.levitte@openssl.org> In message on Mon, 15 Feb 2016 16:06:20 -0800, "Erik Forsberg" said: erik> I certainly was under the impression it was needed. erik> Every .conf file had an admonition to update TABLE at the top -:) erik> A quick test confirms that you dont need it anymore though. erik> Which is fine with me. Some of them still do... *ahem* a gross exageration, glad we could clear that up. erik> >Nope. Just put your custom 20-efca.conf in Configurations and fire erik> >off the Configure command demonstrated above. I'm afraid you're erik> >complicating things needlessly... erik> erik> Indeed looks like it. This process of custom configs works perfectly erik> fine by me. Yeah, we're a bit fond of them too. erik> erik> > erik> >erik> erik> >erik> > erik> >erik> >erik> GNU make throws a differently worded error on same line. erik> >erik> > erik> >erik> >Yup. The answer will remain "don't do that, configure first!" erik> >erik> > erik> >erik> >erik> If I manually run erik> >erik> >erik> perl Configure TABLE > TABLE erik> >erik> >erik> it works OK, at least I can run Configure erik> >erik> > erik> >erik> >Yes. erik> >erik> > erik> >erik> >erik> Another bug is that with pre3, assembler support is broken for solaris64-x86_64-cc erik> >erik> >erik> configurations. First assembler file x86_64cpuid.pl gets tons of syntax errors. erik> >erik> >erik> Havent looked too deep yet. Has been working fine for ever. erik> >erik> > erik> >erik> >Ok, that's to look into. Mind giving us a log? erik> >erik> erik> >erik> will start a new thread on that. erik> >erik> erik> >erik> > erik> >erik> >erik> My platform is Solaris 11 x64 using native SunStudio btw erik> >erik> >erik> Will try gcc too. erik> >erik> >erik> erik> >erik> >erik> >-- Original Message -- erik> >erik> >erik> > erik> >erik> >erik> >In message on Mon, 15 Feb 2016 14:30:48 -0800, "Erik Forsberg" said: erik> >erik> >erik> > erik> >erik> >erik> >erik> erik> >erik> >erik> >erik> OK, now I'm confused, in pre2 I started using personal .conf erik> >erik> >erik> >erik> files with my specific build configuration, that no longer works in pre3 erik> >erik> >erik> >erik> erik> >erik> >erik> >erik> If I do the same as before, I copied my conf file into Configurations erik> >erik> >erik> >erik> subdirectory then ran make -f Makefile.in TABLE to generate a new TABLE erik> >erik> >erik> >erik> file containing my configuration among all other configs. Then I ran erik> >erik> >erik> >erik> a normal Configure erik> >erik> >erik> >erik> erik> >erik> >erik> >erik> Doing that with pre3, make TABLE bombs out because the Makefile.in file erik> >erik> >erik> >erik> has stuff in it that must be processed by perl first (line 33 is first case) erik> >erik> >erik> >erik> erik> >erik> >erik> >erik> How should I update the TABLE file in pre3 ? erik> >erik> >erik> > erik> >erik> >erik> >Some changes have been made, it's true. Would you mind letting me erik> >erik> >erik> >have a look at your .conf file to see for myself? erik> >erik> >erik> > erik> >erik> >erik> >-- erik> >erik> >erik> >Richard Levitte levitte at openssl.org erik> >erik> >erik> >OpenSSL Project http://www.openssl.org/~levitte/ erik> >erik> >erik> >-- erik> >erik> >erik> >openssl-dev mailing list erik> >erik> >erik> >To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev erik> >erik> >erik> erik> >erik> >-- erik> >erik> >openssl-dev mailing list erik> >erik> >To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev erik> >erik> erik> >erik> -- erik> >erik> openssl-dev mailing list erik> >erik> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev erik> >erik> erik> >-- erik> >openssl-dev mailing list erik> >To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev erik> erik> -- erik> openssl-dev mailing list erik> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev erik> From djm at mindrot.org Tue Feb 16 00:06:42 2016 From: djm at mindrot.org (Damien Miller) Date: Tue, 16 Feb 2016 11:06:42 +1100 (AEDT) Subject: [openssl-dev] Call for testing: OpenSSH 7.2 In-Reply-To: <20160215184527.GB11163@doctor.nl2k.ab.ca> References: <20160215184527.GB11163@doctor.nl2k.ab.ca> Message-ID: On Mon, 15 Feb 2016, The Doctor wrote: > Just tested this on the old BSD/OS machine > > works with openssl 1.0.2X > > Openssl 1.1.X issues Thanks for testing. OpenSSH won't work with OpenSSL until someone ports it and writes compat shims to make it work with both OpenSSL 1.0.x and 1.1.x. The 1.1.x series breaks source compatibility by making a heap of structures opaque, including EVP_PKEY which is causing your compile problems in sshkey.c Porting is a fair bit of work, since at least some of the the newly- opaque structs have not previously had accessor functions available, so I have no intention of starting the effort until 1.1.x is at least in beta (no point in wasting time on a moving target). It would help if OpenSSL publish more detailed migration information than is currently present in https://www.openssl.org/news/openssl-1.1.0-notes.html - including a full list of things that have been made opaque and some links to the accessor functions for things that were previously only reachable directly. -d From erik at efca.com Tue Feb 16 01:04:58 2016 From: erik at efca.com (Erik Forsberg) Date: Mon, 15 Feb 2016 17:04:58 -0800 Subject: [openssl-dev] OpenSSL 1.1 pre3 64-bit builds Message-ID: Latest pre3 release doesnt build CFLAGS correctly, noticed it when doing a 64-bit build and the -m64 cc argument was never passed down to cc, failing particularly when trying to assemble 64-bit code in 32-bit default mode. See attached make.log I used a standard configuration perl Configure solaris64-x86_64-gcc suspect the problem is generic though. -------------- next part -------------- A non-text attachment was scrubbed... Name: make.log Type: application/octet-stream Size: 21094 bytes Desc: not available URL: From jeremy.farrell at oracle.com Tue Feb 16 01:39:12 2016 From: jeremy.farrell at oracle.com (Jeremy Farrell) Date: Tue, 16 Feb 2016 01:39:12 +0000 Subject: [openssl-dev] Question about dynamically loadable engines on Cygwin / Mingw In-Reply-To: <20160216.001656.1322821529737613607.levitte@openssl.org> References: <20160215.132903.588105753089173385.levitte@openssl.org> <56C210E7.5080804@oracle.com> <20160215.185953.117619649162395329.levitte@openssl.org> <20160216.001656.1322821529737613607.levitte@openssl.org> Message-ID: <56C27DC0.3030804@oracle.com> On 15/02/2016 23:16, Richard Levitte wrote: > In message <20160215.185953.117619649162395329.levitte at openssl.org> on Mon, 15 Feb 2016 18:59:53 +0100 (CET), Richard Levitte said: > > levitte> In message <56C210E7.5080804 at oracle.com> on Mon, 15 Feb 2016 17:54:47 +0000, Jeremy Farrell said: > levitte> > levitte> jeremy.farrell> It sounds good, except shouldn't it be "capi.so" for > levitte> jeremy.farrell> cygwin, like the other mainstream POSIXy > levitte> jeremy.farrell> implementations? The point of cygwin is that it's > levitte> jeremy.farrell> POSIX not Windows, and it generally follows common > levitte> jeremy.farrell> practices of POSIXy OSes for things which aren't > levitte> jeremy.farrell> specified by POSIX. It seems that it would be simpler > levitte> jeremy.farrell> all round (for users as well as development) to treat > levitte> jeremy.farrell> it the same as "normal" UNIX-like OSes except when it > levitte> jeremy.farrell> absolutely has to be treated differently. > levitte> > levitte> In practice, it really doesn't matter, it all comes down what the DSO > levitte> module supports, and the way I'm coding this, Configure will decide. > levitte> So it's a preference and nothing else. Me, I don't particularly care, > levitte> but if it disturbs the Cygwin community to see one .dll too many, I'm > levitte> ready to make the necessary changes (it's literally one line of code > levitte> to change). > > I had myself a look around in my little installation, and tried these > two commands: > > find /usr/lib -name '*.so' > > find /usr/lib -name '*.dll' > > The first one didn't even return a screenfull (in my 25 line terminal > screen), and the overwhelming majority was OpenSSL 1.0.2 engines ;-) > > The second one, on the other hand, gave a *lot* more output. All > aspell, babl, gawk, gegl, perl(!) loadable modules are named with > the FOO.dll naming convention (there are a few packages, a minority, > that have named them cygFOO.dll)... and the list goes on. > > So looking at how things seem to be done normally, I feel confident > that FOO.dll is a sane choice, even though not strictly POSIX in its > file name extension. And like I said, it matters very little for any > user, the goal is to allow this kind of command line: > > openssl s_server -engine FOO > > No extension, just a name for the user to worry about. Thanks Richard - it was just a thought, and clearly not a very helpful one. The rest of the proposal looks like a good improvement to me. -- J. J. Farrell - not speaking for Oracle -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Tue Feb 16 01:39:40 2016 From: levitte at openssl.org (Richard Levitte) Date: Tue, 16 Feb 2016 02:39:40 +0100 (CET) Subject: [openssl-dev] OpenSSL 1.1 pre3 64-bit builds In-Reply-To: References: Message-ID: <20160216.023940.1344061857137837940.levitte@openssl.org> In message on Mon, 15 Feb 2016 17:04:58 -0800, "Erik Forsberg" said: erik> Latest pre3 release doesnt build CFLAGS correctly, noticed it when doing a erik> 64-bit build and the -m64 cc argument was never passed down to cc, failing erik> particularly when trying to assemble 64-bit code in 32-bit default mode. Thank you, you found a but in 10-main.conf (and in your own 20-efca.conf for that matter). The add() and add_before() functions take a separator string as first argument, remaining argument are those that will be added to inherited values, after or before. Unfortunately, it seems like a number of them didn't get that separator argument. For example the following line in the solaris64-x86_64-gcc config: cflags => add_before("-m64 -Wall -DL_ENDIAN"), should really look like this: cflags => add_before(" ", "-m64 -Wall -DL_ENDIAN"), We will correct this, of course. In the mean time, I suggest you try out that kind of change. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From levitte at openssl.org Tue Feb 16 01:41:12 2016 From: levitte at openssl.org (Richard Levitte) Date: Tue, 16 Feb 2016 02:41:12 +0100 (CET) Subject: [openssl-dev] Question about dynamically loadable engines on Cygwin / Mingw In-Reply-To: <56C27DC0.3030804@oracle.com> References: <20160215.185953.117619649162395329.levitte@openssl.org> <20160216.001656.1322821529737613607.levitte@openssl.org> <56C27DC0.3030804@oracle.com> Message-ID: <20160216.024112.897734235396460923.levitte@openssl.org> In message <56C27DC0.3030804 at oracle.com> on Tue, 16 Feb 2016 01:39:12 +0000, Jeremy Farrell said: jeremy.farrell> Thanks Richard - it was just a thought, and clearly not a very helpful jeremy.farrell> one. The rest of the proposal looks like a good improvement to me. Quite all right. It answered a question that would have been asked sooner or later, and I much prefer sooner. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From levitte at openssl.org Tue Feb 16 01:46:51 2016 From: levitte at openssl.org (Richard Levitte) Date: Tue, 16 Feb 2016 02:46:51 +0100 (CET) Subject: [openssl-dev] OpenSSL 1.1 pre3 64-bit builds In-Reply-To: <20160216.023940.1344061857137837940.levitte@openssl.org> References: <20160216.023940.1344061857137837940.levitte@openssl.org> Message-ID: <20160216.024651.2192820273579036403.levitte@openssl.org> In message <20160216.023940.1344061857137837940.levitte at openssl.org> on Tue, 16 Feb 2016 02:39:40 +0100 (CET), Richard Levitte said: levitte> In message on Mon, 15 Feb 2016 17:04:58 -0800, "Erik Forsberg" said: levitte> levitte> erik> Latest pre3 release doesnt build CFLAGS correctly, noticed it when doing a levitte> erik> 64-bit build and the -m64 cc argument was never passed down to cc, failing levitte> erik> particularly when trying to assemble 64-bit code in 32-bit default mode. levitte> levitte> Thank you, you found a but in 10-main.conf (and in your own levitte> 20-efca.conf for that matter). levitte> levitte> The add() and add_before() functions take a separator string as first levitte> argument, remaining argument are those that will be added to inherited levitte> values, after or before. Unfortunately, it seems like a number of levitte> them didn't get that separator argument. For example the following levitte> line in the solaris64-x86_64-gcc config: levitte> levitte> cflags => add_before("-m64 -Wall -DL_ENDIAN"), levitte> levitte> should really look like this: levitte> levitte> cflags => add_before(" ", "-m64 -Wall -DL_ENDIAN"), levitte> levitte> We will correct this, of course. In the mean time, I suggest you try levitte> out that kind of change. Fixing patch attached for you to try with. -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ -------------- next part -------------- A non-text attachment was scrubbed... Name: conf-bug.diff Type: text/x-patch Size: 5975 bytes Desc: not available URL: From steve at openssl.org Tue Feb 16 02:52:51 2016 From: steve at openssl.org (Dr. Stephen Henson) Date: Tue, 16 Feb 2016 02:52:51 +0000 Subject: [openssl-dev] Call for testing: OpenSSH 7.2 In-Reply-To: <20160215184527.GB11163@doctor.nl2k.ab.ca> References: <20160215184527.GB11163@doctor.nl2k.ab.ca> Message-ID: <20160216025251.GA27994@openssl.org> On Mon, Feb 15, 2016, The Doctor wrote: > Just tested this on the old BSD/OS machine > > works with openssl 1.0.2X > > Openssl 1.1.X issues > > cipher.h in openssl 1.1 needs to read > > struct sshcipher; > struct sshcipher_ctx { > int plaintext; > int encrypt; > struct evp_cipher_ctx_st *evp; > struct chachapoly_ctx cp_ctx; /* XXX union with evp? */ > struct aesctr_ctx ac_ctx; /* XXX union with evp? */ > const struct sshcipher *cipher; > }; > > > I am running into issues with sshkey.c > > > line 3787 > > if (pk->type == EVP_PKEY_RSA && > > line 3802 > > } else if (pk->type == EVP_PKEY_DSA && > > line 3814 > > } else if (pk->type == EVP_PKEY_EC && > > Now > > EVP_PKEY *pk = NULL; > The EVP_PKEY structure is now opaque and so you need to call the accessor function EVP_PKEY_id(pk) instead. That function exists in OpenSSL 1.0 and later though not 0.9.8. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From sms at antinode.info Tue Feb 16 02:56:58 2016 From: sms at antinode.info (Steven M. Schweda) Date: Mon, 15 Feb 2016 20:56:58 -0600 (CST) Subject: [openssl-dev] OpenSSL version 1.1.0 pre release 3 v. VMS Message-ID: <16021520565814_2020C747@antinode.info> There's (still) a curious (but non-fatal) error message from somewhere in the VMS configure procedure: ALP $ @config Configuring OpenSSL version 1.1.0-pre3 (0x0x10100003L) no-crypto-mdebug [default] OPENSSL_NO_CRYPTO_MDEBUG (skip dir) [...] Configuring for vms-alpha %DCL-W-MAXPARM, too many parameters - reenter command with fewer parameters \2\ IsMK1MF =no CC =CC/DECC [...] From somewhere in the "Configure" Perl script? INSTALL.VMS: [...] This will buidl and install OpenSSL in the default location, which is ^^ SYS$COMMON:[OPENSSL-'VERSION']. If you want it to be anywhere else, run config.com like this: $ @config --prefix=PROGRAM:[OPENSSL] Sadly, this causes a failure with obtuse messages: ALP $ @ config.com --prefix=ALP$DKC100:[UTILITY.SOURCE.OPENSSL.1_1_0-pre3] [...] ALP $ mms SET DEFAULT [.crypto.aes] CC/DECC /DEFINE=(OPENSSL_THREADS,OPENSSLDIR="""SYS$COMMON:[SSL]""",ENGINESDIR="""OSSL$ENGINES:""") /STANDARD=RELAXED/NOLIST/PREFIX=ALL/NAMES=(AS_IS,SHORTENED) /OPTIMIZE/NODEBUG --PREFIX=ALP$DKC100:[UTILITY.SOURCE.OPENSSL.1_1_0-PRE3]/INCLUDE=([--.- include],[--],[--.crypto.include]) /OBJECT=[]aes_cbc.OBJ /REPOSITORY=[--] aes_cbc.c %DCL-W-PARMDEL, invalid parameter delimiter - check use of special characters \=ALP$DKC100\ %MMS-F-ABORT, For target [.CRYPTO.AES]AES_CBC.OBJ, CLI returned abort status: %X00038110 -CLI-W-PARMDEL, invalid parameter delimiter - check use of special characters Apparently, the test for "--prefix" is case-sensitive, and DCL can't be trusted. Quotation helps: ALP $ @ config.com "--prefix=ALP$DKC100:[UTILITY.SOURCE.OPENSSL.1_1_0-pre3]" [...] ALP $ mms SET DEFAULT [.crypto.aes] CC/DECC /DEFINE=(OPENSSL_THREADS,OPENSSLDIR="""ALP$DKC100:[UTILITY.SOURCE.OPENSSL.1_1_0-pre3.SSL]""",ENGINESDIR="""OSSL$ENGINES:""") /STANDARD=RELAXED/NOLIST/PREFIX=ALL/NAMES=(AS_IS,SHORTENED) /OPTIMIZE/NODEBUG/INCLUDE=([--.include],[--],[--.crypto.- include]) /OBJECT=[]aes_cbc.OBJ /REPOSITORY=[--] aes_cbc.c [...] Installation fails, however: ALP $ mms install *** Installing development files CREATE/DIR ossl_installroot:[include.openssl] COPY/PROT=W:R openssl:*.h ossl_installroot:[include.openssl] %COPY-F-OPENIN, error opening openssl:*.h as input -RMS-F-FNM, error in file name %MMS-F-ABORT, For target INSTALL_DEV, CLI returned abort status: %X1067109C. ALP $ I haven't yet looked into that one. Things seem to be improved, but not yet perfect. ------------------------------------------------------------------------ Steven M. Schweda sms at antinode-info 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 From erik at efca.com Tue Feb 16 07:19:10 2016 From: erik at efca.com (Erik Forsberg) Date: Mon, 15 Feb 2016 23:19:10 -0800 Subject: [openssl-dev] OpenSSL 1.1-pre3 fails on Solaris Message-ID: Linking on Solaris is broken configuration was basically identical to solaris64-x86_64-cc but looks like a generic failure in Makefile.shared the -z argument is malformed on Solaris platforms. LD_LIBRARY_PATH=.: cc -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_THREADS -DOPENSSL_PIC -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_ MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DOPENSSLDIR="/usr/local/ssl" -DENGINESDIR="/usr/local/lib/amd64/engines" -KPIC -D_REENTRANT -m64 -xarch=generic -xstrconst - Xa -DL_ENDIAN -DFILIO_H -xO5 -xdepend -xbuiltin -G -dy -z text -R/usr/local/lib/amd64 -h libcrypto.so.1.1 -Wl,-Bsymbolic -o ./libcrypto.so.1 .1 -z allextract,-M,crypto.map ./libcrypto.a -z defaultextract -L. -lsocket -lnsl -ldl -lpthread ld: fatal: option '-z' has illegal argument 'allextract,-M,crypto.map' *** Error code 2 The following command caused the error: if (cc -Wl,-V /dev/null 2>&1 | grep '^GNU ld' )>/dev/null; then \ SHLIB_COMPAT=; SHLIB_SOVER=; if [ -n "1.1;" ]; then prev=""; for v in `echo "1.1 ;" | cut -d';' -f1`; do SHLIB_SOVER_NODOT=$v; SHLI B_SOVER=.$v; if [ -n "$prev" ]; then SHLIB_COMPAT="$SHLIB_COMPAT .$prev"; fi; prev=$v; done; fi; SHLIB=libcrypto.so; SHLIB_SUFFIX=; ALLSYMSFLAGS='-Wl,--whole-archive'; NOALLSYMSFLAGS='-Wl,--no-whole-archive'; SHAREDFLAGS="-DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_THREADS -D OPENSSL_PIC -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD 5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/local/ssl\"" -DENGINESDIR="\"/usr /local/lib/amd64/engines\"" -KPIC -D_REENTRANT -m64 -xarch=generic -xstrconst -Xa -DL_ENDIAN -DFILIO_H -xO5 -xdepend -xbuiltin -G -dy -z te xt -R/usr/local/lib/amd64 -shared -Wl,-Bsymbolic -Wl,-soname=$SHLIB$SHLIB_SOVER$SHLIB_SUFFIX"; \ else \ SHLIB_COMPAT=; SHLIB_SOVER=; if [ -n "1.1;" ]; then prev=""; for v in `echo "1.1 ;" | cut -d';' -f1`; do SHLIB_SOVER_NODOT=$v; SHLI B_SOVER=.$v; if [ -n "$prev" ]; then SHLIB_COMPAT="$SHLIB_COMPAT .$prev"; fi; prev=$v; done; fi; \ MINUSZ='-z '; \ (cc -v 2>&1 | grep gcc) > /dev/null && MINUSZ='-Wl,-z,'; \ SHLIB=libcrypto.so; \ SHLIB_SUFFIX=;\ if [ crypto != "crypto" -a crypto != "ssl" ]; then \ ALLSYMSFLAGS="${MINUSZ}allextract"; \ else \ /usr/local/bin/perl ./util/mkdef.pl crypto linux >crypto.map; \ ALLSYMSFLAGS="${MINUSZ}allextract,-M,crypto.map"; \ fi; \ NOALLSYMSFLAGS="${MINUSZ}defaultextract"; \ SHAREDFLAGS="-DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_THREADS -DOPENSSL_PIC -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOL Y1305_ASM -DOPENSSLDIR="\"/usr/local/ssl\"" -DENGINESDIR="\"/usr/local/lib/amd64/engines\"" -KPIC -D_REENTRANT -m64 -xarch=generic -xstrcon st -Xa -DL_ENDIAN -DFILIO_H -xO5 -xdepend -xbuiltin -G -dy -z text -R/usr/local/lib/amd64 -h $SHLIB$SHLIB_SOVER$SHLIB_SUFFIX -Wl,-Bsymbolic" ; \ fi; \ SHOBJECTS="./libcrypto.a "; ( :; LIBDEPS="${LIBDEPS:--L. -lsocket -lnsl -ldl -lpthread}"; SHAREDCMD="${SHAREDCMD:-cc}"; SHAREDFLAGS="$ {SHAREDFLAGS:--DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_THREADS -DOPENSSL_PIC -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -D OPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY13 05_ASM -DOPENSSLDIR="\"/usr/local/ssl\"" -DENGINESDIR="\"/usr/local/lib/amd64/engines\"" -KPIC -D_REENTRANT -m64 -xarch=generic -xstrconst -Xa -DL_ENDIAN -DFILIO_H -xO5 -xdepend -xbuiltin -G -dy -z text -R/usr/local/lib/amd64}"; LIBPATH=`for x in $LIBDEPS; do echo $x; done | se d -e 's/^ *-L//;t' -e d | uniq`; LIBPATH=`echo $LIBPATH | sed -e 's/ /:/g'`; echo LD_LIBRARY_PATH=$LIBPATH:$LD_LIBRARY_PATH ${SHAREDCMD} ${SHAREDFLAGS} -o ./$SHLIB$SHLIB_SOVER$SHLIB_SUFFIX $ALLSYMSFLAGS $SHOBJECTS $NOALLSYMSFLAGS $LIBDEPS; LD_LIBRARY_PATH=$LIBPATH:$LD_LIBRA RY_PATH ${SHAREDCMD} ${SHAREDFLAGS} -o ./$SHLIB$SHLIB_SOVER$SHLIB_SUFFIX $ALLSYMSFLAGS $SHOBJECTS $NOALLSYMSFLAGS $LIBDEPS ) && if [ -n "$INHIBIT_SYMLINKS" ]; then :; else prev=$SHLIB$SHLIB_SOVER$SHLIB_SUFFIX; if [ -n "$SHLIB_COMPAT" ]; then for x in $SHLIB_COMPAT; do ( : ; rm -f ./$SHLIB$x$SHLIB_SUFFIX; ln -s $prev ./$SHLIB$x$SHLIB_SUFFIX ); prev=$SHLIB$x$SHLIB_SUFFIX; done; fi; if [ -n "$SHLIB_SOVER" ]; then ( :; rm -f ./$SHLIB$SHLIB_SUFFIX; ln -s $prev ./$SHLIB$SHLIB_SUFFIX ); fi; fi make: Fatal error: Command failed for target `link_a.solaris' Current working directory /export/home/src/openssl-1.1/x64 *** Error code 1 From erik at efca.com Tue Feb 16 07:28:22 2016 From: erik at efca.com (Erik Forsberg) Date: Mon, 15 Feb 2016 23:28:22 -0800 Subject: [openssl-dev] OpenSSL 1.1 pre 3 compilation errors on Solaris Message-ID: do not use any variable, structure named "sun" When compiling on any SunOS/Solaris platform, preprocessor replaces it with 1 This fragment in crypto/bio/bio_lcl.h breaks all Solaris builds using cc union bio_addr_st { struct sockaddr sa; # ifdef AF_INET6 struct sockaddr_in6 sin6; # endif struct sockaddr_in sin; # ifdef AF_UNIX struct sockaddr_un sun; # endif }; Suggest renaming both the sin and sun members to s_in and s_un for readability. crypto/bio/b_addr.c needs corresponding changes. From zhjwpku at gmail.com Tue Feb 16 08:03:26 2016 From: zhjwpku at gmail.com (John Hunter) Date: Tue, 16 Feb 2016 16:03:26 +0800 Subject: [openssl-dev] build issue about engine-corner/Lesson-2-A-digest Message-ID: Hi levitte, I am studyding how to write an engine nowadays, so I download your repo [1] and try to build it. 1. When the first time I run 'autoreconf -i', I got an error: * configure.ac:18 : error: possibly undefined macro: AC_MSG_FAILURE If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf Documentation.* 2. Then I run 'autoreconf -i' the second time, the error gone. 3. I continue as running './configure', and got the error: * ./configure: line 12192: syntax error near unexpected token `newline' ./configure: line 12192: `AX_CHECK_OPENSSL('* 4. I googled and downloaded the latest version of *ax_check_openssl.m4[2] * and move it to the m4 directory, then I run 'autoreconf -i' and './configure', got some other error: * checking whether compiling and linking against OpenSSL works... no* * configure: error: in `/home/hunter/Lesson-2-A-digest':* * configure: error: could not locate OpenSSL* * See `config.log' for more details* 5. I googled and tried the following methods but still can't build it a) ./configure --with-openssl=/usr/include/openssl b) sudo apt-get install libssl-dev hope you can help me, thanks in advance. [1] https://github.com/engine-corner/Lesson-2-A-digest [2] http://www.gnu.org/software/autoconf-archive/ax_check_openssl.html BR, Zhao -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Tue Feb 16 09:04:10 2016 From: levitte at openssl.org (Richard Levitte) Date: Tue, 16 Feb 2016 10:04:10 +0100 (CET) Subject: [openssl-dev] OpenSSL version 1.1.0 pre release 3 v. VMS In-Reply-To: <16021520565814_2020C747@antinode.info> References: <16021520565814_2020C747@antinode.info> Message-ID: <20160216.100410.298589179419935124.levitte@openssl.org> In message <16021520565814_2020C747 at antinode.info> on Mon, 15 Feb 2016 20:56:58 -0600 (CST), "Steven M. Schweda" said: sms> There's (still) a curious (but non-fatal) error message from sms> somewhere in the VMS configure procedure: sms> sms> ALP $ @config sms> Configuring OpenSSL version 1.1.0-pre3 (0x0x10100003L) sms> no-crypto-mdebug [default] OPENSSL_NO_CRYPTO_MDEBUG (skip dir) sms> [...] sms> Configuring for vms-alpha sms> %DCL-W-MAXPARM, too many parameters - reenter command with fewer parameters sms> \2\ sms> IsMK1MF =no sms> CC =CC/DECC sms> [...] sms> sms> From somewhere in the "Configure" Perl script? Yeah, that one is entirely harmless (and known). sms> INSTALL.VMS: sms> sms> [...] sms> This will buidl and install OpenSSL in the default location, which is sms> ^^ Thank you. sms> SYS$COMMON:[OPENSSL-'VERSION']. If you want it to be anywhere else, sms> run config.com like this: sms> sms> $ @config --prefix=PROGRAM:[OPENSSL] sms> sms> Sadly, this causes a failure with obtuse messages: sms> sms> ALP $ @ config.com --prefix=ALP$DKC100:[UTILITY.SOURCE.OPENSSL.1_1_0-pre3] sms> [...] sms> sms> ALP $ mms sms> sms> SET DEFAULT [.crypto.aes] sms> CC/DECC /DEFINE=(OPENSSL_THREADS,OPENSSLDIR="""SYS$COMMON:[SSL]""",ENGINESDIR="""OSSL$ENGINES:""") /STANDARD=RELAXED/NOLIST/PREFIX=ALL/NAMES=(AS_IS,SHORTENED) /OPTIMIZE/NODEBUG --PREFIX=ALP$DKC100:[UTILITY.SOURCE.OPENSSL.1_1_0-PRE3]/INCLUDE=([--.- sms> include],[--],[--.crypto.include]) /OBJECT=[]aes_cbc.OBJ /REPOSITORY=[--] aes_cbc.c sms> %DCL-W-PARMDEL, invalid parameter delimiter - check use of special characters sms> \=ALP$DKC100\ sms> %MMS-F-ABORT, For target [.CRYPTO.AES]AES_CBC.OBJ, CLI returned abort status: %X00038110 sms> -CLI-W-PARMDEL, invalid parameter delimiter - check use of special characters sms> sms> Apparently, the test for "--prefix" is case-sensitive, and DCL can't sms> be trusted. Quotation helps: sms> sms> ALP $ @ config.com "--prefix=ALP$DKC100:[UTILITY.SOURCE.OPENSSL.1_1_0-pre3]" sms> [...] You're running with the extended parsing style, aren't you? I always forget that possibility ... sms> ALP $ mms sms> sms> SET DEFAULT [.crypto.aes] sms> CC/DECC /DEFINE=(OPENSSL_THREADS,OPENSSLDIR="""ALP$DKC100:[UTILITY.SOURCE.OPENSSL.1_1_0-pre3.SSL]""",ENGINESDIR="""OSSL$ENGINES:""") /STANDARD=RELAXED/NOLIST/PREFIX=ALL/NAMES=(AS_IS,SHORTENED) /OPTIMIZE/NODEBUG/INCLUDE=([--.include],[--],[--.crypto.- sms> include]) /OBJECT=[]aes_cbc.OBJ /REPOSITORY=[--] aes_cbc.c sms> [...] sms> sms> Installation fails, however: sms> sms> ALP $ mms install sms> sms> *** Installing development files sms> CREATE/DIR ossl_installroot:[include.openssl] sms> COPY/PROT=W:R openssl:*.h ossl_installroot:[include.openssl] sms> %COPY-F-OPENIN, error opening openssl:*.h as input sms> -RMS-F-FNM, error in file name sms> %MMS-F-ABORT, For target INSTALL_DEV, CLI returned abort status: %X1067109C. sms> ALP $ sms> sms> I haven't yet looked into that one. When looking into it, I suggest you do so with mms/macro="NODEBUG=""""", that'll display the temporary logicals that get created under the hood. (fair warning, it's not the most elegant coding) sms> Things seem to be improved, but not yet perfect. True. I didn't expect perfect at this point, though. I certainly hope we will have been able to tighten things up 'til April. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From doctor at doctor.nl2k.ab.ca Tue Feb 16 09:00:30 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Tue, 16 Feb 2016 02:00:30 -0700 Subject: [openssl-dev] Openssl-SNAP-20160216 issues Message-ID: <20160216090030.GA11685@doctor.nl2k.ab.ca> In the make test I am getting TOP=.. PERL=/usr/bin/perl5 /usr/bin/perl5 run_tests.pl alltests ../test/recipes/01-test_ordinals.t ........ ok ../test/recipes/05-test_bf.t .............. ok ../test/recipes/05-test_cast.t ............ ok ../test/recipes/05-test_des.t ............. ok ../test/recipes/05-test_hmac.t ............ ok ../test/recipes/05-test_idea.t ............ ok ../test/recipes/05-test_md2.t ............. skipped: md2 is not supported by this OpenSSL build ../test/recipes/05-test_md4.t ............. ok ../test/recipes/05-test_md5.t ............. ok ../test/recipes/05-test_mdc2.t ............ ok ../test/recipes/05-test_rand.t ............ 1/1 # Failed test 'running randtest' # at ../test/testlib/OpenSSL/Test/Simple.pm line 70. # Looks like you failed 1 test of 1. ../test/recipes/05-test_rand.t ............ Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/05-test_rc2.t ............. ok ../test/recipes/05-test_rc4.t ............. ok ../test/recipes/05-test_rc5.t ............. ok ../test/recipes/05-test_rmd.t ............. ok ../test/recipes/05-test_sha1.t ............ ok ../test/recipes/05-test_sha256.t .......... ok ../test/recipes/05-test_sha512.t .......... ok ../test/recipes/05-test_wp.t .............. ok ../test/recipes/10-test_bn.t .............. ok ../test/recipes/10-test_exp.t ............. ok ../test/recipes/15-test_dh.t .............. ok ../test/recipes/15-test_dsa.t ............. ok ../test/recipes/15-test_ec.t .............. ok ../test/recipes/15-test_ecdh.t ............ ok ../test/recipes/15-test_ecdsa.t ........... ok ../test/recipes/15-test_rsa.t ............. ok ../test/recipes/20-test_enc.t ............. 2/127 # Failed test 'aes-128-cbc' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'aes-128-cbc base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'aes-128-ecb base64' # at ../test/recipes/20-test_enc.t line 54. ../test/recipes/20-test_enc.t ............. 6/127 # Failed test 'aes-192-cbc' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'aes-192-cbc base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'aes-192-ecb' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'aes-192-ecb base64' # at ../test/recipes/20-test_enc.t line 54. ../test/recipes/20-test_enc.t ............. 11/127 # Failed test 'aes-256-cbc base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'aes-256-ecb' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'aes-256-ecb base64' # at ../test/recipes/20-test_enc.t line 54. ../test/recipes/20-test_enc.t ............. 16/127 # Failed test 'bf' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'bf-cbc' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'bf-cbc base64' # at ../test/recipes/20-test_enc.t line 54. ../test/recipes/20-test_enc.t ............. 20/127 # Failed test 'bf-cfb' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'bf-cfb base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'bf-ecb' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'bf-ecb base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'bf-ofb' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'bf-ofb base64' # at ../test/recipes/20-test_enc.t line 54. ../test/recipes/20-test_enc.t ............. 26/127 # Failed test 'camellia-128-cbc' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'camellia-128-cbc base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'camellia-128-ecb' # at ../test/recipes/20-test_enc.t line 54. ../test/recipes/20-test_enc.t ............. 30/127 # Failed test 'camellia-192-cbc' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'camellia-192-cbc base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'camellia-192-ecb' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'camellia-192-ecb base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'camellia-256-cbc' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'camellia-256-cbc base64' # at ../test/recipes/20-test_enc.t line 54. ../test/recipes/20-test_enc.t ............. 36/127 # Failed test 'camellia-256-ecb' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'camellia-256-ecb base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'cast' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'cast base64' # at ../test/recipes/20-test_enc.t line 54. ../test/recipes/20-test_enc.t ............. 41/127 # Failed test 'cast-cbc base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'cast5-cbc' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'cast5-cbc base64' # at ../test/recipes/20-test_enc.t line 54. ../test/recipes/20-test_enc.t ............. 45/127 # Failed test 'cast5-cfb base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'cast5-ecb' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'cast5-ecb base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'cast5-ofb' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'cast5-ofb base64' # at ../test/recipes/20-test_enc.t line 54. ../test/recipes/20-test_enc.t ............. 50/127 # Failed test 'des' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'des base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'des-cbc' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'des-cbc base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'des-cfb' # at ../test/recipes/20-test_enc.t line 54. ../test/recipes/20-test_enc.t ............. 55/127 # Failed test 'des-cfb base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'des-ecb' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'des-ecb base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'des-ede' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'des-ede base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'des-ede-cbc' # at ../test/recipes/20-test_enc.t line 54. ../test/recipes/20-test_enc.t ............. 61/127 # Failed test 'des-ede-cfb' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'des-ede-cfb base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'des-ede-ofb' # at ../test/recipes/20-test_enc.t line 54. ../test/recipes/20-test_enc.t ............. 65/127 # Failed test 'des-ede-ofb base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'des-ede3' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'des-ede3 base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'des-ede3-cbc' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'des-ede3-cbc base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'des-ede3-cfb' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'des-ede3-cfb base64' # at ../test/recipes/20-test_enc.t line 54. ../test/recipes/20-test_enc.t ............. 72/127 # Failed test 'des-ede3-ofb' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'des-ede3-ofb base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'des-ofb' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'des-ofb base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'des3' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'des3 base64' # at ../test/recipes/20-test_enc.t line 54. ../test/recipes/20-test_enc.t ............. 78/127 # Failed test 'desx' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'desx base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'idea' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'idea base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'idea-cbc' # at ../test/recipes/20-test_enc.t line 54. ../test/recipes/20-test_enc.t ............. 83/127 # Failed test 'idea-cbc base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'idea-cfb' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'idea-cfb base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'idea-ecb' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'idea-ecb base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'idea-ofb' # at ../test/recipes/20-test_enc.t line 54. ../test/recipes/20-test_enc.t ............. 89/127 # Failed test 'idea-ofb base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'rc2' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'rc2 base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'rc2-40-cbc' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'rc2-40-cbc base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'rc2-64-cbc' # at ../test/recipes/20-test_enc.t line 54. ../test/recipes/20-test_enc.t ............. 95/127 # Failed test 'rc2-64-cbc base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'rc2-cbc' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'rc2-cbc base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'rc2-cfb' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'rc2-cfb base64' # at ../test/recipes/20-test_enc.t line 54. ../test/recipes/20-test_enc.t ............. 100/127 # Failed test 'rc2-ecb' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'rc2-ecb base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'rc2-ofb' # at ../test/recipes/20-test_enc.t line 54. ../test/recipes/20-test_enc.t ............. 103/127 # Failed test 'rc2-ofb base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'rc4' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'rc4 base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'rc4-40' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'rc4-40 base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'rc5' # at ../test/recipes/20-test_enc.t line 54. ../test/recipes/20-test_enc.t ............. 109/127 # Failed test 'rc5 base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'rc5-cbc' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'rc5-cbc base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'rc5-cfb' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'rc5-cfb base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'rc5-ecb' # at ../test/recipes/20-test_enc.t line 54. ../test/recipes/20-test_enc.t ............. 115/127 # Failed test 'rc5-ecb base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'rc5-ofb' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'rc5-ofb base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'seed' # at ../test/recipes/20-test_enc.t line 54. ../test/recipes/20-test_enc.t ............. 119/127 # Failed test 'seed base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'seed-cbc' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'seed-cbc base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'seed-cfb' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'seed-cfb base64' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'seed-ecb' # at ../test/recipes/20-test_enc.t line 54. ../test/recipes/20-test_enc.t ............. 125/127 # Failed test 'seed-ofb' # at ../test/recipes/20-test_enc.t line 54. # Failed test 'seed-ofb base64' # at ../test/recipes/20-test_enc.t line 54. # Looks like you failed 116 tests of 127. ../test/recipes/20-test_enc.t ............. Dubious, test returned 116 (wstat 29696, 0x7400) Failed 116/127 subtests ../test/recipes/25-test_crl.t ............. ok ../test/recipes/25-test_gen.t ............. ok ../test/recipes/25-test_pkcs7.t ........... ok ../test/recipes/25-test_req.t ............. ok ../test/recipes/25-test_sid.t ............. ok ../test/recipes/25-test_verify.t .......... ok ../test/recipes/25-test_x509.t ............ ok ../test/recipes/30-test_engine.t .......... ok ../test/recipes/30-test_evp.t ............. 1/1 # Failed test 'running evp_test evptests.txt' # at ../test/recipes/30-test_evp.t line 11. # Looks like you failed 1 test of 1. ../test/recipes/30-test_evp.t ............. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/30-test_evp_extra.t ....... 1/1 # Failed test 'running evp_extra_test' # at ../test/recipes/30-test_evp_extra.t line 11. # Looks like you failed 1 test of 1. ../test/recipes/30-test_evp_extra.t ....... Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/30-test_pbelu.t ........... ok ../test/recipes/40-test_rehash.t .......... 2/5 # Failed test 'Testing that we aren't running as a priviledged user, such as root' # at ../test/recipes/40-test_rehash.t line 41. # Looks like you failed 1 test of 5. ../test/recipes/40-test_rehash.t .......... Dubious, test returned 1 (wstat 256, 0x100) Failed 1/5 subtests (less 1 skipped subtest: 3 okay) ../test/recipes/70-test_clienthello.t ..... 1/1 # Failed test 'running clienthellotest' # at ../test/recipes/70-test_clienthello.t line 13. # Looks like you failed 1 test of 1. ../test/recipes/70-test_clienthello.t ..... Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/70-test_packet.t .......... 1/1 # Failed test 'running packettest' # at ../test/testlib/OpenSSL/Test/Simple.pm line 70. # Looks like you failed 1 test of 1. ../test/recipes/70-test_packet.t .......... Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/70-test_sslcertstatus.t ... All right the ../test/recipes/70-test_sslcertstatus.t is hanging into infinity. What can do to see why these tests are failing? -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Broadcasting the truth for 25 years From levitte at openssl.org Tue Feb 16 09:42:21 2016 From: levitte at openssl.org (Richard Levitte) Date: Tue, 16 Feb 2016 10:42:21 +0100 (CET) Subject: [openssl-dev] Openssl-SNAP-20160216 issues In-Reply-To: <20160216090030.GA11685@doctor.nl2k.ab.ca> References: <20160216090030.GA11685@doctor.nl2k.ab.ca> Message-ID: <20160216.104221.469775936406219219.levitte@openssl.org> In message <20160216090030.GA11685 at doctor.nl2k.ab.ca> on Tue, 16 Feb 2016 02:00:30 -0700, The Doctor said: doctor> In the make test I am getting doctor> doctor> TOP=.. PERL=/usr/bin/perl5 /usr/bin/perl5 run_tests.pl alltests doctor> ../test/recipes/01-test_ordinals.t ........ ok doctor> ../test/recipes/05-test_bf.t .............. ok doctor> ../test/recipes/05-test_cast.t ............ ok doctor> ../test/recipes/05-test_des.t ............. ok doctor> ../test/recipes/05-test_hmac.t ............ ok doctor> ../test/recipes/05-test_idea.t ............ ok doctor> ../test/recipes/05-test_md2.t ............. skipped: md2 is not supported by this OpenSSL build doctor> ../test/recipes/05-test_md4.t ............. ok doctor> ../test/recipes/05-test_md5.t ............. ok doctor> ../test/recipes/05-test_mdc2.t ............ ok doctor> ../test/recipes/05-test_rand.t ............ 1/1 doctor> # Failed test 'running randtest' doctor> # at ../test/testlib/OpenSSL/Test/Simple.pm line 70. doctor> # Looks like you failed 1 test of 1. doctor> ../test/recipes/05-test_rand.t ............ Dubious, test returned 1 (wstat 256, 0x100) doctor> Failed 1/1 subtests doctor> ../test/recipes/05-test_rc2.t ............. ok doctor> ../test/recipes/05-test_rc4.t ............. ok doctor> ../test/recipes/05-test_rc5.t ............. ok doctor> ../test/recipes/05-test_rmd.t ............. ok doctor> ../test/recipes/05-test_sha1.t ............ ok doctor> ../test/recipes/05-test_sha256.t .......... ok doctor> ../test/recipes/05-test_sha512.t .......... ok doctor> ../test/recipes/05-test_wp.t .............. ok doctor> ../test/recipes/10-test_bn.t .............. ok doctor> ../test/recipes/10-test_exp.t ............. ok doctor> ../test/recipes/15-test_dh.t .............. ok doctor> ../test/recipes/15-test_dsa.t ............. ok doctor> ../test/recipes/15-test_ec.t .............. ok doctor> ../test/recipes/15-test_ecdh.t ............ ok doctor> ../test/recipes/15-test_ecdsa.t ........... ok doctor> ../test/recipes/15-test_rsa.t ............. ok doctor> ../test/recipes/20-test_enc.t ............. 2/127 doctor> # Failed test 'aes-128-cbc' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'aes-128-cbc base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'aes-128-ecb base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> ../test/recipes/20-test_enc.t ............. 6/127 doctor> # Failed test 'aes-192-cbc' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'aes-192-cbc base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'aes-192-ecb' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'aes-192-ecb base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> ../test/recipes/20-test_enc.t ............. 11/127 doctor> # Failed test 'aes-256-cbc base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'aes-256-ecb' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'aes-256-ecb base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> ../test/recipes/20-test_enc.t ............. 16/127 doctor> # Failed test 'bf' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'bf-cbc' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'bf-cbc base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> ../test/recipes/20-test_enc.t ............. 20/127 doctor> # Failed test 'bf-cfb' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'bf-cfb base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'bf-ecb' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'bf-ecb base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'bf-ofb' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'bf-ofb base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> ../test/recipes/20-test_enc.t ............. 26/127 doctor> # Failed test 'camellia-128-cbc' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'camellia-128-cbc base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'camellia-128-ecb' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> ../test/recipes/20-test_enc.t ............. 30/127 doctor> # Failed test 'camellia-192-cbc' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'camellia-192-cbc base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'camellia-192-ecb' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'camellia-192-ecb base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'camellia-256-cbc' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'camellia-256-cbc base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> ../test/recipes/20-test_enc.t ............. 36/127 doctor> # Failed test 'camellia-256-ecb' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'camellia-256-ecb base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'cast' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'cast base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> ../test/recipes/20-test_enc.t ............. 41/127 doctor> # Failed test 'cast-cbc base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'cast5-cbc' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'cast5-cbc base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> ../test/recipes/20-test_enc.t ............. 45/127 doctor> # Failed test 'cast5-cfb base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'cast5-ecb' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'cast5-ecb base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'cast5-ofb' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'cast5-ofb base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> ../test/recipes/20-test_enc.t ............. 50/127 doctor> # Failed test 'des' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'des base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'des-cbc' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'des-cbc base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'des-cfb' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> ../test/recipes/20-test_enc.t ............. 55/127 doctor> # Failed test 'des-cfb base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'des-ecb' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'des-ecb base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'des-ede' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'des-ede base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'des-ede-cbc' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> ../test/recipes/20-test_enc.t ............. 61/127 doctor> # Failed test 'des-ede-cfb' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'des-ede-cfb base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'des-ede-ofb' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> ../test/recipes/20-test_enc.t ............. 65/127 doctor> # Failed test 'des-ede-ofb base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'des-ede3' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'des-ede3 base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'des-ede3-cbc' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'des-ede3-cbc base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'des-ede3-cfb' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'des-ede3-cfb base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> ../test/recipes/20-test_enc.t ............. 72/127 doctor> # Failed test 'des-ede3-ofb' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'des-ede3-ofb base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'des-ofb' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'des-ofb base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'des3' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'des3 base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> ../test/recipes/20-test_enc.t ............. 78/127 doctor> # Failed test 'desx' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'desx base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'idea' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'idea base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'idea-cbc' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> ../test/recipes/20-test_enc.t ............. 83/127 doctor> # Failed test 'idea-cbc base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'idea-cfb' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'idea-cfb base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'idea-ecb' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'idea-ecb base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'idea-ofb' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> ../test/recipes/20-test_enc.t ............. 89/127 doctor> # Failed test 'idea-ofb base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'rc2' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'rc2 base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'rc2-40-cbc' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'rc2-40-cbc base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'rc2-64-cbc' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> ../test/recipes/20-test_enc.t ............. 95/127 doctor> # Failed test 'rc2-64-cbc base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'rc2-cbc' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'rc2-cbc base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'rc2-cfb' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'rc2-cfb base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> ../test/recipes/20-test_enc.t ............. 100/127 doctor> # Failed test 'rc2-ecb' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'rc2-ecb base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'rc2-ofb' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> ../test/recipes/20-test_enc.t ............. 103/127 doctor> # Failed test 'rc2-ofb base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'rc4' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'rc4 base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'rc4-40' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'rc4-40 base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'rc5' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> ../test/recipes/20-test_enc.t ............. 109/127 doctor> # Failed test 'rc5 base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'rc5-cbc' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'rc5-cbc base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'rc5-cfb' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'rc5-cfb base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'rc5-ecb' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> ../test/recipes/20-test_enc.t ............. 115/127 doctor> # Failed test 'rc5-ecb base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'rc5-ofb' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'rc5-ofb base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'seed' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> ../test/recipes/20-test_enc.t ............. 119/127 doctor> # Failed test 'seed base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'seed-cbc' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'seed-cbc base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'seed-cfb' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'seed-cfb base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'seed-ecb' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> ../test/recipes/20-test_enc.t ............. 125/127 doctor> # Failed test 'seed-ofb' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> doctor> # Failed test 'seed-ofb base64' doctor> # at ../test/recipes/20-test_enc.t line 54. doctor> # Looks like you failed 116 tests of 127. doctor> ../test/recipes/20-test_enc.t ............. Dubious, test returned 116 (wstat 29696, 0x7400) doctor> Failed 116/127 subtests doctor> ../test/recipes/25-test_crl.t ............. ok doctor> ../test/recipes/25-test_gen.t ............. ok doctor> ../test/recipes/25-test_pkcs7.t ........... ok doctor> ../test/recipes/25-test_req.t ............. ok doctor> ../test/recipes/25-test_sid.t ............. ok doctor> ../test/recipes/25-test_verify.t .......... ok doctor> ../test/recipes/25-test_x509.t ............ ok doctor> ../test/recipes/30-test_engine.t .......... ok doctor> ../test/recipes/30-test_evp.t ............. 1/1 doctor> # Failed test 'running evp_test evptests.txt' doctor> # at ../test/recipes/30-test_evp.t line 11. doctor> # Looks like you failed 1 test of 1. doctor> ../test/recipes/30-test_evp.t ............. Dubious, test returned 1 (wstat 256, 0x100) doctor> Failed 1/1 subtests doctor> ../test/recipes/30-test_evp_extra.t ....... 1/1 doctor> # Failed test 'running evp_extra_test' doctor> # at ../test/recipes/30-test_evp_extra.t line 11. doctor> # Looks like you failed 1 test of 1. doctor> ../test/recipes/30-test_evp_extra.t ....... Dubious, test returned 1 (wstat 256, 0x100) doctor> Failed 1/1 subtests doctor> ../test/recipes/30-test_pbelu.t ........... ok doctor> ../test/recipes/40-test_rehash.t .......... 2/5 doctor> # Failed test 'Testing that we aren't running as a priviledged user, such as root' doctor> # at ../test/recipes/40-test_rehash.t line 41. doctor> # Looks like you failed 1 test of 5. doctor> ../test/recipes/40-test_rehash.t .......... Dubious, test returned 1 (wstat 256, 0x100) doctor> Failed 1/5 subtests doctor> (less 1 skipped subtest: 3 okay) doctor> ../test/recipes/70-test_clienthello.t ..... 1/1 doctor> # Failed test 'running clienthellotest' doctor> # at ../test/recipes/70-test_clienthello.t line 13. doctor> # Looks like you failed 1 test of 1. doctor> ../test/recipes/70-test_clienthello.t ..... Dubious, test returned 1 (wstat 256, 0x100) doctor> Failed 1/1 subtests doctor> ../test/recipes/70-test_packet.t .......... 1/1 doctor> # Failed test 'running packettest' doctor> # at ../test/testlib/OpenSSL/Test/Simple.pm line 70. doctor> # Looks like you failed 1 test of 1. doctor> ../test/recipes/70-test_packet.t .......... Dubious, test returned 1 (wstat 256, 0x100) doctor> Failed 1/1 subtests doctor> ../test/recipes/70-test_sslcertstatus.t ... doctor> doctor> doctor> doctor> All right the ../test/recipes/70-test_sslcertstatus.t is hanging into infinity. doctor> doctor> What can do to see why these tests are failing? You can do this: HARNESS_VERBOSE=yes make test Fair warning, that's a *lot* of output If you want to be selective, you can pick specific tests into the TESTS variable, like this: HARNESS_VERBOSE=yes make test TESTS='tesl_ssl test_packet' The words in that variable are taken from the test recipes, it's the {name} part in nn-{name}.t, so for the recipe file ../test/recipes/70-test_clienthello.t, the name to put into the TESTS variable is test_clienthello. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From tmraz at redhat.com Tue Feb 16 10:34:10 2016 From: tmraz at redhat.com (Tomas Mraz) Date: Tue, 16 Feb 2016 11:34:10 +0100 Subject: [openssl-dev] OpenSSL version 1.1.0 pre release 3 published In-Reply-To: <56C24E6B.5090808@openssl.org> References: <20160215190420.GA12045@openssl.org> <20160215205227.GA18770@w1.fi> <20160215212530.GA13775@w1.fi> <56C24469.2050605@openssl.org> <20160215215040.GA23301@w1.fi> <56C24E6B.5090808@openssl.org> Message-ID: <1455618850.15167.21.camel@redhat.com> On Po, 2016-02-15 at 22:17 +0000, Matt Caswell wrote: > > On 15/02/16 21:50, Jouni Malinen wrote: > > On Mon, Feb 15, 2016 at 09:34:33PM +0000, Matt Caswell wrote: > > > On 15/02/16 21:25, Jouni Malinen wrote: > > > > Is this change in OpenSSL behavior expected? Is it not allowed > > > > to call > > > > EVP_cleanup() and then re-initialize OpenSSL digests with > > > > SSL_library_init()? > > > > > > Correct, you cannot reinit once you have deinit. > > > > OK.. That used to work, though, so it would be good to mention this > > clearly in the release notes since this can cause a difficult to > > find > > issues for existing programs. Luckily I happened to have automated > > test > > cases that found this now with wpa_supplicant. > > > > > You should not need to explicitly init or deinit at all. Try > > > removing > > > all such calls. If you are getting memory leaks not caused by > > > your > > > application then that is a bug in OpenSSL. > > > > I agree with the "should not need" part, but there is a reason why > > I > > added those calls in the first place, i.e., these were needed with > > older > > OpenSSL releases (well, all releases so far since 1.1.0 has not > > been > > released). I guess I can remove these calls with #ifdef > > OPENSSL_VERSION_NUMBER < 0x10100000L to maintain support for older > > versions. > > > > I'd also recommend updating EVP_cleanup man page to be clearer > > about > > EVP_cleanup() being something that must not be called if there is > > going > > to be any future calls to OpenSSL before the process exits. > > Maybe EVP_cleanup() and other similar explicit deinit functions > should > be deprecated, and do nothing in 1.1.0? The auto-deinit capability > should handle it. That way you would not need to do anything > "special" > for 1.1.0 with "#ifdef" etc. What do you think? +1 I think this is "no brainer" change as the semantics of these functions changed anyway due to the auto-initialization. --? Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb (You'll never know whether the road is wrong though.) From rt at openssl.org Tue Feb 16 14:59:03 2016 From: rt at openssl.org (David Woodhouse via RT) Date: Tue, 16 Feb 2016 14:59:03 +0000 Subject: [openssl-dev] [openssl.org #4309] [PATCH] Fix UEFI/EDK2 build error by defining PRIu64 In-Reply-To: <1455634716.4832.128.camel@infradead.org> References: <1455634716.4832.128.camel@infradead.org> Message-ID: Provide an appropriate definition of PRIu64 for the EDK2 build, since we don't have there. --- ?include/openssl/e_os2.h | 1 + ?1 file changed, 1 insertion(+) diff --git a/include/openssl/e_os2.h b/include/openssl/e_os2.h index 1a1fe3e..59af447 100644 --- a/include/openssl/e_os2.h +++ b/include/openssl/e_os2.h @@ -299,6 +299,7 @@ typedef INT32 int32_t; ?typedef UINT32 uint32_t; ?typedef INT64 int64_t; ?typedef UINT64 uint64_t; +#define PRIu64 "%Lu" ?# elif defined(_MSC_VER) && _MSC_VER<=1500 ?/* ? * minimally required typdefs for systems not supporting inttypes.h or --? 2.5.0 -- David Woodhouse Open Source Technology Centre David.Woodhouse at intel.com Intel Corporation -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4309 Please log in as guest with password guest if prompted -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5691 bytes Desc: not available URL: From rt at openssl.org Tue Feb 16 15:06:22 2016 From: rt at openssl.org (David Woodhouse via RT) Date: Tue, 16 Feb 2016 15:06:22 +0000 Subject: [openssl-dev] [openssl.org #4310] Fix various no-XXX build options In-Reply-To: <1455635174.4832.131.camel@infradead.org> References: <1455635174.4832.131.camel@infradead.org> Message-ID: The UEFI/EDK2 build turns off a lot of options that it doesn't use, and a few of them got broken recently in OpenSSL HEAD. Even no-engine and no-ui doesn't seem to work correctly any more. Here are some fixes... -- David Woodhouse Open Source Technology Centre David.Woodhouse at intel.com Intel Corporation -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4310 Please log in as guest with password guest if prompted -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-Fix-no-async-build.patch Type: text/x-patch Size: 1580 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Fix-no-sock-build.patch Type: text/x-patch Size: 683 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Fix-no-engine-build.patch Type: text/x-patch Size: 882 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Allow-configuration-with-no-pqueue-no-ripemd-no-ts-n.patch Type: text/x-patch Size: 1290 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5691 bytes Desc: not available URL: From doctor at doctor.nl2k.ab.ca Tue Feb 16 15:48:56 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Tue, 16 Feb 2016 08:48:56 -0700 Subject: [openssl-dev] Call for testing: OpenSSH 7.2 In-Reply-To: <20160216025251.GA27994@openssl.org> References: <20160215184527.GB11163@doctor.nl2k.ab.ca> <20160216025251.GA27994@openssl.org> Message-ID: <20160216154855.GA27532@doctor.nl2k.ab.ca> On Tue, Feb 16, 2016 at 02:52:51AM +0000, Dr. Stephen Henson wrote: > On Mon, Feb 15, 2016, The Doctor wrote: > > > Just tested this on the old BSD/OS machine > > > > works with openssl 1.0.2X > > > > Openssl 1.1.X issues > > > > cipher.h in openssl 1.1 needs to read > > > > struct sshcipher; > > struct sshcipher_ctx { > > int plaintext; > > int encrypt; > > struct evp_cipher_ctx_st *evp; > > struct chachapoly_ctx cp_ctx; /* XXX union with evp? */ > > struct aesctr_ctx ac_ctx; /* XXX union with evp? */ > > const struct sshcipher *cipher; > > }; > > > > > > I am running into issues with sshkey.c > > > > > > line 3787 > > > > if (pk->type == EVP_PKEY_RSA && > > > > line 3802 > > > > } else if (pk->type == EVP_PKEY_DSA && > > > > line 3814 > > > > } else if (pk->type == EVP_PKEY_EC && > > > > Now > > > > EVP_PKEY *pk = NULL; > > > > The EVP_PKEY structure is now opaque and so you need to call the accessor > function EVP_PKEY_id(pk) instead. That function exists in OpenSSL 1.0 and > later though not 0.9.8. > > Steve. So how exactly would you rewrite EVP_PKEY *pk = NULL; ? > -- > Dr Stephen N. Henson. OpenSSL project core developer. > Commercial tech support now available see: http://www.openssl.org > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Broadcasting the truth for 25 years From levitte at openssl.org Tue Feb 16 15:56:44 2016 From: levitte at openssl.org (Richard Levitte) Date: Tue, 16 Feb 2016 16:56:44 +0100 (CET) Subject: [openssl-dev] Call for testing: OpenSSH 7.2 In-Reply-To: <20160216154855.GA27532@doctor.nl2k.ab.ca> References: <20160215184527.GB11163@doctor.nl2k.ab.ca> <20160216025251.GA27994@openssl.org> <20160216154855.GA27532@doctor.nl2k.ab.ca> Message-ID: <20160216.165644.2175819590437553788.levitte@openssl.org> In message <20160216154855.GA27532 at doctor.nl2k.ab.ca> on Tue, 16 Feb 2016 08:48:56 -0700, The Doctor said: doctor> So how exactly would you rewrite doctor> doctor> EVP_PKEY *pk = NULL; doctor> doctor> ? Not at all. Pointers to opaque types are perfectly fine in C. However, you may have to tinker with how you use the pointer further down the code. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From dwmw2 at infradead.org Tue Feb 16 16:17:02 2016 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 16 Feb 2016 16:17:02 +0000 Subject: [openssl-dev] OpenSSL version 1.1.0 pre release 3 published In-Reply-To: <56C24E6B.5090808@openssl.org> References: <20160215190420.GA12045@openssl.org> <20160215205227.GA18770@w1.fi> <20160215212530.GA13775@w1.fi> <56C24469.2050605@openssl.org> <20160215215040.GA23301@w1.fi> <56C24E6B.5090808@openssl.org> Message-ID: <1455639422.4832.171.camel@infradead.org> On Mon, 2016-02-15 at 22:17 +0000, Matt Caswell wrote: > > Maybe EVP_cleanup() and other similar explicit deinit functions should > be deprecated, and do nothing in 1.1.0? The auto-deinit capability > should handle it. That way you would not need to do anything "special" > for 1.1.0 with "#ifdef" etc. What do you think? > > If applications *must* do explicit cleanup they can always use the new > OPENSSL_cleanup() function (which is clear in the docs that you cannot > reinit afterwards). What about libraries? If a library (or loadable plugin within an application) uses OpenSSL, how should it clean up after itself? It has no control over, and no visibility into, whether another library or the application itself might subsequently use OpenSSL again. Any cleanup function which, as a side-effect, means that nobody can ever use OpenSSL for the remainder of the lifetime of the running process, seems entirely broken. -- David Woodhouse Open Source Technology Centre David.Woodhouse at intel.com Intel Corporation -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5691 bytes Desc: not available URL: From openssl-users at dukhovni.org Tue Feb 16 16:38:08 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 16 Feb 2016 11:38:08 -0500 Subject: [openssl-dev] OpenSSL version 1.1.0 pre release 3 published In-Reply-To: <1455639422.4832.171.camel@infradead.org> References: <20160215190420.GA12045@openssl.org> <20160215205227.GA18770@w1.fi> <20160215212530.GA13775@w1.fi> <56C24469.2050605@openssl.org> <20160215215040.GA23301@w1.fi> <56C24E6B.5090808@openssl.org> <1455639422.4832.171.camel@infradead.org> Message-ID: > On Feb 16, 2016, at 11:17 AM, David Woodhouse wrote: > > If a library (or loadable plugin within an application) uses OpenSSL, > how should it clean up after itself? I must do nothing. That's what auto-initialization is for. It is wrong for libraries to initialize OpenSSL, because that can't be done safely. So in libraries that use OpenSSL, no OpenSSL initialization, and no cleanup. -- Viktor. From matt at openssl.org Tue Feb 16 16:58:18 2016 From: matt at openssl.org (Matt Caswell) Date: Tue, 16 Feb 2016 16:58:18 +0000 Subject: [openssl-dev] OpenSSL version 1.1.0 pre release 3 published In-Reply-To: <1455639422.4832.171.camel@infradead.org> References: <20160215190420.GA12045@openssl.org> <20160215205227.GA18770@w1.fi> <20160215212530.GA13775@w1.fi> <56C24469.2050605@openssl.org> <20160215215040.GA23301@w1.fi> <56C24E6B.5090808@openssl.org> <1455639422.4832.171.camel@infradead.org> Message-ID: <56C3552A.6020306@openssl.org> On 16/02/16 16:17, David Woodhouse wrote: > On Mon, 2016-02-15 at 22:17 +0000, Matt Caswell wrote: >> >> Maybe EVP_cleanup() and other similar explicit deinit functions should >> be deprecated, and do nothing in 1.1.0? The auto-deinit capability >> should handle it. That way you would not need to do anything "special" >> for 1.1.0 with "#ifdef" etc. What do you think? >> >> If applications *must* do explicit cleanup they can always use the new >> OPENSSL_cleanup() function (which is clear in the docs that you cannot >> reinit afterwards). > > What about libraries? > > If a library (or loadable plugin within an application) uses OpenSSL, > how should it clean up after itself? > > It has no control over, and no visibility into, whether another library > or the application itself might subsequently use OpenSSL again. > > Any cleanup function which, as a side-effect, means that nobody can > ever use OpenSSL for the remainder of the lifetime of the running > process, seems entirely broken. > The whole concept of a library cleaning up is broken. If a library de-inits OpenSSL it cannot know if the application has finished using it or not. This is explicitly pointed out in the docs: "The OPENSSL_cleanup() function deinitialises OpenSSL (both libcrypto and libssl). All resources allocated by OpenSSL are freed. Typically there should be no need to call this function directly as it is initiated automatically on application exit. This is done via the standard C library atexit function. In the event that the application will close in a manner that will not call the registered atexit() handlers then the application should call OPENSSL_cleanup() directly. Developers of libraries using OpenSSL are discouraged from calling this function and should instead, typically, rely on auto-deinitialisation. This is to avoid error conditions where both an application and a library it depends on both use OpenSSL, and the library deinitialises it before the application has finished using it." i.e. libraries should not explicitly deinit. Matt From j at w1.fi Tue Feb 16 17:31:12 2016 From: j at w1.fi (Jouni Malinen) Date: Tue, 16 Feb 2016 19:31:12 +0200 Subject: [openssl-dev] OpenSSL version 1.1.0 pre release 3 published In-Reply-To: <56C24E6B.5090808@openssl.org> References: <20160215190420.GA12045@openssl.org> <20160215205227.GA18770@w1.fi> <20160215212530.GA13775@w1.fi> <56C24469.2050605@openssl.org> <20160215215040.GA23301@w1.fi> <56C24E6B.5090808@openssl.org> Message-ID: <20160216173112.GA25160@w1.fi> On Mon, Feb 15, 2016 at 10:17:15PM +0000, Matt Caswell wrote: > Maybe EVP_cleanup() and other similar explicit deinit functions should > be deprecated, and do nothing in 1.1.0? The auto-deinit capability > should handle it. That way you would not need to do anything "special" > for 1.1.0 with "#ifdef" etc. What do you think? That may be a reasonable approach to avoid unexpected failures with existing users. As far as wpa_supplicant is concerned, I ran quite a bit of valgrind testing with the OpenSSL init/deinit calls commented out. While I did find some memory leaks, those were not caused by the OpenSSL library itself. As such, I've already added the #ifdef based on OpenSSL version. This has the additional benefit of marking up code for cleanup once OpenSSL 1.0.2 support terminates in the future. -- Jouni Malinen PGP id EFC895FA From doctor at doctor.nl2k.ab.ca Tue Feb 16 17:42:48 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Tue, 16 Feb 2016 10:42:48 -0700 Subject: [openssl-dev] Openssl-SNAP-20160216 issues In-Reply-To: <20160216.104221.469775936406219219.levitte@openssl.org> References: <20160216090030.GA11685@doctor.nl2k.ab.ca> <20160216.104221.469775936406219219.levitte@openssl.org> Message-ID: <20160216174248.GB5339@doctor.nl2k.ab.ca> On Tue, Feb 16, 2016 at 10:42:21AM +0100, Richard Levitte wrote: > In message <20160216090030.GA11685 at doctor.nl2k.ab.ca> on Tue, 16 Feb 2016 02:00:30 -0700, The Doctor said: > > doctor> In the make test I am getting > doctor> > doctor> TOP=.. PERL=/usr/bin/perl5 /usr/bin/perl5 run_tests.pl alltests > doctor> ../test/recipes/01-test_ordinals.t ........ ok > doctor> ../test/recipes/05-test_bf.t .............. ok > doctor> ../test/recipes/05-test_cast.t ............ ok > doctor> ../test/recipes/05-test_des.t ............. ok > doctor> ../test/recipes/05-test_hmac.t ............ ok > doctor> ../test/recipes/05-test_idea.t ............ ok > doctor> ../test/recipes/05-test_md2.t ............. skipped: md2 is not supported by this OpenSSL build > doctor> ../test/recipes/05-test_md4.t ............. ok > doctor> ../test/recipes/05-test_md5.t ............. ok > doctor> ../test/recipes/05-test_mdc2.t ............ ok > doctor> ../test/recipes/05-test_rand.t ............ 1/1 > doctor> # Failed test 'running randtest' > doctor> # at ../test/testlib/OpenSSL/Test/Simple.pm line 70. > doctor> # Looks like you failed 1 test of 1. > doctor> ../test/recipes/05-test_rand.t ............ Dubious, test returned 1 (wstat 256, 0x100) > doctor> Failed 1/1 subtests > doctor> ../test/recipes/05-test_rc2.t ............. ok > doctor> ../test/recipes/05-test_rc4.t ............. ok > doctor> ../test/recipes/05-test_rc5.t ............. ok > doctor> ../test/recipes/05-test_rmd.t ............. ok > doctor> ../test/recipes/05-test_sha1.t ............ ok > doctor> ../test/recipes/05-test_sha256.t .......... ok > doctor> ../test/recipes/05-test_sha512.t .......... ok > doctor> ../test/recipes/05-test_wp.t .............. ok > doctor> ../test/recipes/10-test_bn.t .............. ok > doctor> ../test/recipes/10-test_exp.t ............. ok > doctor> ../test/recipes/15-test_dh.t .............. ok > doctor> ../test/recipes/15-test_dsa.t ............. ok > doctor> ../test/recipes/15-test_ec.t .............. ok > doctor> ../test/recipes/15-test_ecdh.t ............ ok > doctor> ../test/recipes/15-test_ecdsa.t ........... ok > doctor> ../test/recipes/15-test_rsa.t ............. ok > doctor> ../test/recipes/20-test_enc.t ............. 2/127 > doctor> # Failed test 'aes-128-cbc' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'aes-128-cbc base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'aes-128-ecb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 6/127 > doctor> # Failed test 'aes-192-cbc' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'aes-192-cbc base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'aes-192-ecb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'aes-192-ecb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 11/127 > doctor> # Failed test 'aes-256-cbc base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'aes-256-ecb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'aes-256-ecb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 16/127 > doctor> # Failed test 'bf' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'bf-cbc' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'bf-cbc base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 20/127 > doctor> # Failed test 'bf-cfb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'bf-cfb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'bf-ecb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'bf-ecb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'bf-ofb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'bf-ofb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 26/127 > doctor> # Failed test 'camellia-128-cbc' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'camellia-128-cbc base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'camellia-128-ecb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 30/127 > doctor> # Failed test 'camellia-192-cbc' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'camellia-192-cbc base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'camellia-192-ecb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'camellia-192-ecb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'camellia-256-cbc' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'camellia-256-cbc base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 36/127 > doctor> # Failed test 'camellia-256-ecb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'camellia-256-ecb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'cast' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'cast base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 41/127 > doctor> # Failed test 'cast-cbc base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'cast5-cbc' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'cast5-cbc base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 45/127 > doctor> # Failed test 'cast5-cfb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'cast5-ecb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'cast5-ecb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'cast5-ofb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'cast5-ofb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 50/127 > doctor> # Failed test 'des' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'des base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'des-cbc' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'des-cbc base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'des-cfb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 55/127 > doctor> # Failed test 'des-cfb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'des-ecb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'des-ecb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'des-ede' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'des-ede base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'des-ede-cbc' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 61/127 > doctor> # Failed test 'des-ede-cfb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'des-ede-cfb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'des-ede-ofb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 65/127 > doctor> # Failed test 'des-ede-ofb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'des-ede3' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'des-ede3 base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'des-ede3-cbc' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'des-ede3-cbc base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'des-ede3-cfb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'des-ede3-cfb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 72/127 > doctor> # Failed test 'des-ede3-ofb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'des-ede3-ofb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'des-ofb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'des-ofb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'des3' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'des3 base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 78/127 > doctor> # Failed test 'desx' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'desx base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'idea' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'idea base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'idea-cbc' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 83/127 > doctor> # Failed test 'idea-cbc base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'idea-cfb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'idea-cfb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'idea-ecb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'idea-ecb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'idea-ofb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 89/127 > doctor> # Failed test 'idea-ofb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'rc2' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'rc2 base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'rc2-40-cbc' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'rc2-40-cbc base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'rc2-64-cbc' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 95/127 > doctor> # Failed test 'rc2-64-cbc base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'rc2-cbc' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'rc2-cbc base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'rc2-cfb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'rc2-cfb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 100/127 > doctor> # Failed test 'rc2-ecb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'rc2-ecb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'rc2-ofb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 103/127 > doctor> # Failed test 'rc2-ofb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'rc4' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'rc4 base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'rc4-40' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'rc4-40 base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'rc5' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 109/127 > doctor> # Failed test 'rc5 base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'rc5-cbc' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'rc5-cbc base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'rc5-cfb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'rc5-cfb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'rc5-ecb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 115/127 > doctor> # Failed test 'rc5-ecb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'rc5-ofb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'rc5-ofb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'seed' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 119/127 > doctor> # Failed test 'seed base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'seed-cbc' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'seed-cbc base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'seed-cfb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'seed-cfb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'seed-ecb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 125/127 > doctor> # Failed test 'seed-ofb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'seed-ofb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> # Looks like you failed 116 tests of 127. > doctor> ../test/recipes/20-test_enc.t ............. Dubious, test returned 116 (wstat 29696, 0x7400) > doctor> Failed 116/127 subtests > doctor> ../test/recipes/25-test_crl.t ............. ok > doctor> ../test/recipes/25-test_gen.t ............. ok > doctor> ../test/recipes/25-test_pkcs7.t ........... ok > doctor> ../test/recipes/25-test_req.t ............. ok > doctor> ../test/recipes/25-test_sid.t ............. ok > doctor> ../test/recipes/25-test_verify.t .......... ok > doctor> ../test/recipes/25-test_x509.t ............ ok > doctor> ../test/recipes/30-test_engine.t .......... ok > doctor> ../test/recipes/30-test_evp.t ............. 1/1 > doctor> # Failed test 'running evp_test evptests.txt' > doctor> # at ../test/recipes/30-test_evp.t line 11. > doctor> # Looks like you failed 1 test of 1. > doctor> ../test/recipes/30-test_evp.t ............. Dubious, test returned 1 (wstat 256, 0x100) > doctor> Failed 1/1 subtests > doctor> ../test/recipes/30-test_evp_extra.t ....... 1/1 > doctor> # Failed test 'running evp_extra_test' > doctor> # at ../test/recipes/30-test_evp_extra.t line 11. > doctor> # Looks like you failed 1 test of 1. > doctor> ../test/recipes/30-test_evp_extra.t ....... Dubious, test returned 1 (wstat 256, 0x100) > doctor> Failed 1/1 subtests > doctor> ../test/recipes/30-test_pbelu.t ........... ok > doctor> ../test/recipes/40-test_rehash.t .......... 2/5 > doctor> # Failed test 'Testing that we aren't running as a priviledged user, such as root' > doctor> # at ../test/recipes/40-test_rehash.t line 41. > doctor> # Looks like you failed 1 test of 5. > doctor> ../test/recipes/40-test_rehash.t .......... Dubious, test returned 1 (wstat 256, 0x100) > doctor> Failed 1/5 subtests > doctor> (less 1 skipped subtest: 3 okay) > doctor> ../test/recipes/70-test_clienthello.t ..... 1/1 > doctor> # Failed test 'running clienthellotest' > doctor> # at ../test/recipes/70-test_clienthello.t line 13. > doctor> # Looks like you failed 1 test of 1. > doctor> ../test/recipes/70-test_clienthello.t ..... Dubious, test returned 1 (wstat 256, 0x100) > doctor> Failed 1/1 subtests > doctor> ../test/recipes/70-test_packet.t .......... 1/1 > doctor> # Failed test 'running packettest' > doctor> # at ../test/testlib/OpenSSL/Test/Simple.pm line 70. > doctor> # Looks like you failed 1 test of 1. > doctor> ../test/recipes/70-test_packet.t .......... Dubious, test returned 1 (wstat 256, 0x100) > doctor> Failed 1/1 subtests > doctor> ../test/recipes/70-test_sslcertstatus.t ... > doctor> > doctor> > doctor> > doctor> All right the ../test/recipes/70-test_sslcertstatus.t is hanging into infinity. > doctor> > doctor> What can do to see why these tests are failing? > > You can do this: > > HARNESS_VERBOSE=yes make test > > Fair warning, that's a *lot* of output > > If you want to be selective, you can pick specific tests into the > TESTS variable, like this: > > HARNESS_VERBOSE=yes make test TESTS='tesl_ssl test_packet' > > The words in that variable are taken from the test recipes, it's the > {name} part in nn-{name}.t, so for the recipe file > ../test/recipes/70-test_clienthello.t, the name to put into the TESTS > variable is test_clienthello. > > Cheers, > Richard > And thank you. So for test_sslcertstatus.t TOP=.. PERL=/usr/bin/perl5 /usr/bin/perl5 run_tests.pl test_sslcertstatus ../test/recipes/70-test_sslcertstatus.t .. 1..1 Proxy started on port 4453 So why does this hang? On 20160203 no problems > -- > Richard Levitte levitte at openssl.org > OpenSSL Project http://www.openssl.org/~levitte/ > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Broadcasting the truth for 25 years From doctor at doctor.nl2k.ab.ca Tue Feb 16 18:13:56 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Tue, 16 Feb 2016 11:13:56 -0700 Subject: [openssl-dev] Openssl-SNAP-20160216 issues In-Reply-To: <20160216.104221.469775936406219219.levitte@openssl.org> References: <20160216090030.GA11685@doctor.nl2k.ab.ca> <20160216.104221.469775936406219219.levitte@openssl.org> Message-ID: <20160216181356.GD5339@doctor.nl2k.ab.ca> On Tue, Feb 16, 2016 at 10:42:21AM +0100, Richard Levitte wrote: > In message <20160216090030.GA11685 at doctor.nl2k.ab.ca> on Tue, 16 Feb 2016 02:00:30 -0700, The Doctor said: > > doctor> In the make test I am getting > doctor> > doctor> TOP=.. PERL=/usr/bin/perl5 /usr/bin/perl5 run_tests.pl alltests > doctor> ../test/recipes/01-test_ordinals.t ........ ok > doctor> ../test/recipes/05-test_bf.t .............. ok > doctor> ../test/recipes/05-test_cast.t ............ ok > doctor> ../test/recipes/05-test_des.t ............. ok > doctor> ../test/recipes/05-test_hmac.t ............ ok > doctor> ../test/recipes/05-test_idea.t ............ ok > doctor> ../test/recipes/05-test_md2.t ............. skipped: md2 is not supported by this OpenSSL build > doctor> ../test/recipes/05-test_md4.t ............. ok > doctor> ../test/recipes/05-test_md5.t ............. ok > doctor> ../test/recipes/05-test_mdc2.t ............ ok > doctor> ../test/recipes/05-test_rand.t ............ 1/1 > doctor> # Failed test 'running randtest' > doctor> # at ../test/testlib/OpenSSL/Test/Simple.pm line 70. > doctor> # Looks like you failed 1 test of 1. > doctor> ../test/recipes/05-test_rand.t ............ Dubious, test returned 1 (wstat 256, 0x100) > doctor> Failed 1/1 subtests > doctor> ../test/recipes/05-test_rc2.t ............. ok > doctor> ../test/recipes/05-test_rc4.t ............. ok > doctor> ../test/recipes/05-test_rc5.t ............. ok > doctor> ../test/recipes/05-test_rmd.t ............. ok > doctor> ../test/recipes/05-test_sha1.t ............ ok > doctor> ../test/recipes/05-test_sha256.t .......... ok > doctor> ../test/recipes/05-test_sha512.t .......... ok > doctor> ../test/recipes/05-test_wp.t .............. ok > doctor> ../test/recipes/10-test_bn.t .............. ok > doctor> ../test/recipes/10-test_exp.t ............. ok > doctor> ../test/recipes/15-test_dh.t .............. ok > doctor> ../test/recipes/15-test_dsa.t ............. ok > doctor> ../test/recipes/15-test_ec.t .............. ok > doctor> ../test/recipes/15-test_ecdh.t ............ ok > doctor> ../test/recipes/15-test_ecdsa.t ........... ok > doctor> ../test/recipes/15-test_rsa.t ............. ok > doctor> ../test/recipes/20-test_enc.t ............. 2/127 > doctor> # Failed test 'aes-128-cbc' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'aes-128-cbc base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'aes-128-ecb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 6/127 > doctor> # Failed test 'aes-192-cbc' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'aes-192-cbc base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'aes-192-ecb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'aes-192-ecb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 11/127 > doctor> # Failed test 'aes-256-cbc base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'aes-256-ecb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'aes-256-ecb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 16/127 > doctor> # Failed test 'bf' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'bf-cbc' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'bf-cbc base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 20/127 > doctor> # Failed test 'bf-cfb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'bf-cfb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'bf-ecb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'bf-ecb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'bf-ofb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'bf-ofb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 26/127 > doctor> # Failed test 'camellia-128-cbc' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'camellia-128-cbc base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'camellia-128-ecb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 30/127 > doctor> # Failed test 'camellia-192-cbc' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'camellia-192-cbc base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'camellia-192-ecb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'camellia-192-ecb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'camellia-256-cbc' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'camellia-256-cbc base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 36/127 > doctor> # Failed test 'camellia-256-ecb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'camellia-256-ecb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'cast' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'cast base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 41/127 > doctor> # Failed test 'cast-cbc base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'cast5-cbc' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'cast5-cbc base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 45/127 > doctor> # Failed test 'cast5-cfb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'cast5-ecb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'cast5-ecb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'cast5-ofb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'cast5-ofb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 50/127 > doctor> # Failed test 'des' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'des base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'des-cbc' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'des-cbc base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'des-cfb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 55/127 > doctor> # Failed test 'des-cfb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'des-ecb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'des-ecb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'des-ede' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'des-ede base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'des-ede-cbc' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 61/127 > doctor> # Failed test 'des-ede-cfb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'des-ede-cfb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'des-ede-ofb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 65/127 > doctor> # Failed test 'des-ede-ofb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'des-ede3' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'des-ede3 base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'des-ede3-cbc' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'des-ede3-cbc base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'des-ede3-cfb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'des-ede3-cfb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 72/127 > doctor> # Failed test 'des-ede3-ofb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'des-ede3-ofb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'des-ofb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'des-ofb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'des3' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'des3 base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 78/127 > doctor> # Failed test 'desx' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'desx base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'idea' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'idea base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'idea-cbc' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 83/127 > doctor> # Failed test 'idea-cbc base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'idea-cfb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'idea-cfb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'idea-ecb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'idea-ecb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'idea-ofb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 89/127 > doctor> # Failed test 'idea-ofb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'rc2' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'rc2 base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'rc2-40-cbc' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'rc2-40-cbc base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'rc2-64-cbc' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 95/127 > doctor> # Failed test 'rc2-64-cbc base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'rc2-cbc' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'rc2-cbc base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'rc2-cfb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'rc2-cfb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 100/127 > doctor> # Failed test 'rc2-ecb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'rc2-ecb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'rc2-ofb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 103/127 > doctor> # Failed test 'rc2-ofb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'rc4' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'rc4 base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'rc4-40' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'rc4-40 base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'rc5' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 109/127 > doctor> # Failed test 'rc5 base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'rc5-cbc' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'rc5-cbc base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'rc5-cfb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'rc5-cfb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'rc5-ecb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 115/127 > doctor> # Failed test 'rc5-ecb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'rc5-ofb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'rc5-ofb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'seed' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 119/127 > doctor> # Failed test 'seed base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'seed-cbc' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'seed-cbc base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'seed-cfb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'seed-cfb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'seed-ecb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 125/127 > doctor> # Failed test 'seed-ofb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'seed-ofb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> # Looks like you failed 116 tests of 127. > doctor> ../test/recipes/20-test_enc.t ............. Dubious, test returned 116 (wstat 29696, 0x7400) > doctor> Failed 116/127 subtests > doctor> ../test/recipes/25-test_crl.t ............. ok > doctor> ../test/recipes/25-test_gen.t ............. ok > doctor> ../test/recipes/25-test_pkcs7.t ........... ok > doctor> ../test/recipes/25-test_req.t ............. ok > doctor> ../test/recipes/25-test_sid.t ............. ok > doctor> ../test/recipes/25-test_verify.t .......... ok > doctor> ../test/recipes/25-test_x509.t ............ ok > doctor> ../test/recipes/30-test_engine.t .......... ok > doctor> ../test/recipes/30-test_evp.t ............. 1/1 > doctor> # Failed test 'running evp_test evptests.txt' > doctor> # at ../test/recipes/30-test_evp.t line 11. > doctor> # Looks like you failed 1 test of 1. > doctor> ../test/recipes/30-test_evp.t ............. Dubious, test returned 1 (wstat 256, 0x100) > doctor> Failed 1/1 subtests > doctor> ../test/recipes/30-test_evp_extra.t ....... 1/1 > doctor> # Failed test 'running evp_extra_test' > doctor> # at ../test/recipes/30-test_evp_extra.t line 11. > doctor> # Looks like you failed 1 test of 1. > doctor> ../test/recipes/30-test_evp_extra.t ....... Dubious, test returned 1 (wstat 256, 0x100) > doctor> Failed 1/1 subtests > doctor> ../test/recipes/30-test_pbelu.t ........... ok > doctor> ../test/recipes/40-test_rehash.t .......... 2/5 > doctor> # Failed test 'Testing that we aren't running as a priviledged user, such as root' > doctor> # at ../test/recipes/40-test_rehash.t line 41. > doctor> # Looks like you failed 1 test of 5. > doctor> ../test/recipes/40-test_rehash.t .......... Dubious, test returned 1 (wstat 256, 0x100) > doctor> Failed 1/5 subtests > doctor> (less 1 skipped subtest: 3 okay) > doctor> ../test/recipes/70-test_clienthello.t ..... 1/1 > doctor> # Failed test 'running clienthellotest' > doctor> # at ../test/recipes/70-test_clienthello.t line 13. > doctor> # Looks like you failed 1 test of 1. > doctor> ../test/recipes/70-test_clienthello.t ..... Dubious, test returned 1 (wstat 256, 0x100) > doctor> Failed 1/1 subtests > doctor> ../test/recipes/70-test_packet.t .......... 1/1 > doctor> # Failed test 'running packettest' > doctor> # at ../test/testlib/OpenSSL/Test/Simple.pm line 70. > doctor> # Looks like you failed 1 test of 1. > doctor> ../test/recipes/70-test_packet.t .......... Dubious, test returned 1 (wstat 256, 0x100) > doctor> Failed 1/1 subtests > doctor> ../test/recipes/70-test_sslcertstatus.t ... > doctor> > doctor> > doctor> > doctor> All right the ../test/recipes/70-test_sslcertstatus.t is hanging into infinity. > doctor> > doctor> What can do to see why these tests are failing? > > You can do this: > > HARNESS_VERBOSE=yes make test > > Fair warning, that's a *lot* of output > > If you want to be selective, you can pick specific tests into the > TESTS variable, like this: > > HARNESS_VERBOSE=yes make test TESTS='tesl_ssl test_packet' > > The words in that variable are taken from the test recipes, it's the > {name} part in nn-{name}.t, so for the recipe file > ../test/recipes/70-test_clienthello.t, the name to put into the TESTS > variable is test_clienthello. > > Cheers, > Richard > HARNESS_VERBOSE=yes make test TESTS='test_rand' gave me shlib_target=; if [ -n "libcrypto.so.1.1 libssl.so.1.1" ]; then shlib_target="bsd-gcc-shared"; fi; LIBRARIES="-L.. -lssl -L.. -lcrypto" ; make -f ../Makefile.shared -e APPNAME=openssl OBJECTS="openssl.o asn1pars.o ca.o ciphers.o cms.o crl.o crl2p7.o dgst.o dhparam.o dsa.o dsaparam.o ec.o ecparam.o enc.o engine.o errstr.o gendsa.o genpkey.o genrsa.o nseq.o ocsp.o passwd.o pkcs12.o pkcs7.o pkcs8.o pkey.o pkeyparam.o pkeyutl.o prime.o rand.o req.o rsa.o rsautl.o s_client.o s_server.o s_time.o sess_id.o smime.o speed.o spkac.o srp.o ts.o verify.o version.o x509.o rehash.o apps.o opt.o s_cb.o s_socket.o app_rand.o" LDFLAG="-ldl -lgmp -lm -lc -lz" LIBDEPS=" $LIBRARIES " link_app.${shlib_target} LD_LIBRARY_PATH=..: gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_EXPERIMENTAL_JPAKE -DOPENSSL_THREADS -DOPENSSL_PIC -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DOPENSSLDIR="/usr/contrib" -DENGINESDIR="/usr/contrib/lib/engines" -fPIC -pthread -D_THREAD_SAFE -D_REENTRANT -DPERL5 -DL_ENDIAN -DTERMIOS -fomit-frame-pointer -O2 -march=i486 -Wall -g -rdynamic -ldl -lgmp -lm -lc -lz -Wl,-rpath,/usr/contrib/lib -o openssl openssl.o asn1pars.o ca.o ciphers.o cms.o crl.o crl2p7.o dgst.o dhparam.o dsa.o dsaparam.o ec.o ecparam.o enc.o engine.o errstr.o gendsa.o genpkey.o genrsa.o nseq.o ocsp.o passwd.o pkcs12.o pkcs7.o pkcs8.o pkey.o pkeyparam.o pkeyutl.o prime.o rand.o req.o rsa.o rsautl.o s_client.o s_server.o s_time.o sess_id.o smime.o speed.o spkac.o srp.o ts.o verify.o version.o x509.o rehash.o apps.o opt.o s_cb.o s_socket.o app_rand.o -L.. -lssl -L.. -lcrypto TOP=.. PERL=/usr/bin/perl5 /usr/bin/perl5 run_tests.pl test_rand ../test/recipes/05-test_rand.t .. 1..1 init failed, the rand method is not properly installed not ok 1 - running randtest # Failed test 'running randtest' # at ../test/testlib/OpenSSL/Test/Simple.pm line 70. # Looks like you failed 1 test of 1. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests Test Summary Report ------------------- ../test/recipes/05-test_rand.t (Wstat: 256 Tests: 1 Failed: 1) Failed test: 1 Non-zero exit status: 1 Files=1, Tests=1, 3 wallclock secs ( 0.07 usr 0.05 sys + 0.15 cusr 0.13 csys = 0.40 CPU) Result: FAIL > -- > Richard Levitte levitte at openssl.org > OpenSSL Project http://www.openssl.org/~levitte/ > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Broadcasting the truth for 25 years From rt at openssl.org Tue Feb 16 18:34:01 2016 From: rt at openssl.org (Rainer Jung via RT) Date: Tue, 16 Feb 2016 18:34:01 +0000 Subject: [openssl-dev] [openssl.org #4311] OpenSSL 1.1.0-pre3: quote PERL=$(PERL) in Makefiles In-Reply-To: <56C36B8A.50507@kippdata.de> References: <56C36B8A.50507@kippdata.de> Message-ID: Hi there, I built OpenSSL 1.1.0-pre3 with PERL="/usr/bin/env perl" This has the nice effect, that any generated perl artefact that itself uses perl via the "#!" notation contains #!/usr/bin/env perl and not the perl path to which "/usr/bin/env perl" resolves during build time on the build machine. The only tweak I had to apply to make this work, was quoting a few lines that use PERL=$(PERL) in Makefile.in: --- Makefile.in 2016-02-15 20:51:46.000000000 +0100 +++ Makefile.in 2016-02-16 00:28:16.510730000 +0100 @@ -512,8 +512,8 @@ errors: $(PERL) util/ck_errf.pl -strict */*.c */*/*.c $(PERL) util/mkerr.pl -recurse -write - (cd engines; $(MAKE) PERL=$(PERL) errors) - (cd crypto/ct; $(MAKE) PERL=$(PERL) errors) + (cd engines; $(MAKE) PERL="$(PERL)" errors) + (cd crypto/ct; $(MAKE) PERL="$(PERL)" errors) ordinals: util/libeay.num util/ssleay.num test_ordinals TABLE util/libeay.num:: @@ -521,7 +521,7 @@ util/ssleay.num:: $(PERL) util/mkdef.pl ssl update test_ordinals: - TOP=$(TOP) PERL=$(PERL) $(PERL) test/run_tests.pl test_ordinals + TOP=$(TOP) PERL="$(PERL)" $(PERL) test/run_tests.pl test_ordinals TABLE: Configure Configurations/*.conf (echo 'Output of `Configure TABLE'"':"; \ --- test/Makefile.in 2016-02-15 20:51:48.000000000 +0100 +++ test/Makefile.in 2016-02-16 00:28:16.545897000 +0100 @@ -155,12 +155,12 @@ @sh $(TOP)/util/point.sh dummytest.c $@ tests: exe apps - TOP=$(TOP) PERL=$(PERL) $(PERL) run_tests.pl $(TESTS) + TOP=$(TOP) PERL="$(PERL)" $(PERL) run_tests.pl $(TESTS) errors: list-tests: - @TOP=$(TOP) PERL=$(PERL) $(PERL) run_tests.pl list + @TOP=$(TOP) PERL="$(PERL)" $(PERL) run_tests.pl list apps: @(cd ..; $(MAKE) DIRS=apps all) You might want to consider this change. Looking through all assignments in Makefile.in files and ignoring the possible use of paths with spaces (people shouldn't use them), i see one other line which might benefit from quoting. It is in test/Makefile.in: top: (cd ..; $(MAKE) DIRS=$(DIR) TESTS=$(TESTS) all) Here the TESTS=$(TESTS) by default assigns "alltests" which is just one token, but the plural form of the variable suggests one could also set it to contain multiple test names and then the above line might fail. Regards and thanks, Rainer -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4311 Please log in as guest with password guest if prompted From doctor at doctor.nl2k.ab.ca Tue Feb 16 19:36:47 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Tue, 16 Feb 2016 12:36:47 -0700 Subject: [openssl-dev] Openssl-SNAP-20160216 issues In-Reply-To: <20160216.104221.469775936406219219.levitte@openssl.org> References: <20160216090030.GA11685@doctor.nl2k.ab.ca> <20160216.104221.469775936406219219.levitte@openssl.org> Message-ID: <20160216193647.GA29270@doctor.nl2k.ab.ca> Interested, I added zlib and egd. Now I try HARNESS_VERBOSE=yes make test TESTS='test_networking' REsult: shlib_target=; if [ -n "libcrypto.so.1.1 libssl.so.1.1" ]; then shlib_target="bsd-gcc-shared"; fi; LIBRARIES="-L.. -lssl -L.. -lcrypto" ; make -f ../Makefile.shared -e APPNAME=openssl OBJECTS="openssl.o asn1pars.o ca.o ciphers.o cms.o crl.o crl2p7.o dgst.o dhparam.o dsa.o dsaparam.o ec.o ecparam.o enc.o engine.o errstr.o gendsa.o genpkey.o genrsa.o nseq.o ocsp.o passwd.o pkcs12.o pkcs7.o pkcs8.o pkey.o pkeyparam.o pkeyutl.o prime.o rand.o req.o rsa.o rsautl.o s_client.o s_server.o s_time.o sess_id.o smime.o speed.o spkac.o srp.o ts.o verify.o version.o x509.o rehash.o apps.o opt.o s_cb.o s_socket.o app_rand.o" LDFLAG="-ldl -lgmp -lm -lc -lz" LIBDEPS=" $LIBRARIES " link_app.${shlib_target} LD_LIBRARY_PATH=..: gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_EXPERIMENTAL_JPAKE -DOPENSSL_THREADS -DZLIB -DZLIB_SHARED -DOPENSSL_PIC -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DOPENSSLDIR="/usr/contrib" -DENGINESDIR="/usr/contrib/lib/engines" -fPIC -pthread -D_THREAD_SAFE -D_REENTRANT -DPERL5 -DL_ENDIAN -DTERMIOS -fomit-frame-pointer -O2 -march=i486 -Wall -g -rdynamic -ldl -lgmp -lm -lc -lz -Wl,-rpath,/usr/contrib/lib -o openssl openssl.o asn1pars.o ca.o ciphers.o cms.o crl.o crl2p7.o dgst.o dhparam.o dsa.o dsaparam.o ec.o ecparam.o enc.o engine.o errstr.o gendsa.o genpkey.o genrsa.o nseq.o ocsp.o passwd.o pkcs12.o pkcs7.o pkcs8.o pkey.o pkeyparam.o pkeyutl.o prime.o rand.o req.o rsa.o rsautl.o s_client.o s_server.o s_time.o sess_id.o smime.o speed.o spkac.o srp.o ts.o verify.o version.o x509.o rehash.o apps.o opt.o s_cb.o s_socket.o app_rand.o -L.. -lssl -L.. -lcrypto TOP=.. PERL=/usr/bin/perl5 /usr/bin/perl5 run_tests.pl test_networking ../test/recipes/90-test_networking.t .. 1..2 Proxy connection failed: Failed creating proxy socket (127.0.0.1,4453): Address already in use not ok 1 - Trying IPv4 # Failed test 'Trying IPv4' # at ../test/recipes/90-test_networking.t line 90. Proxy started on port 4453 and stuck. Also TOP=.. PERL=/usr/bin/perl5 /usr/bin/perl5 run_tests.pl alltests ../test/recipes/01-test_ordinals.t ........ ok ../test/recipes/05-test_bf.t .............. ok ../test/recipes/05-test_cast.t ............ ok ../test/recipes/05-test_des.t ............. ok ../test/recipes/05-test_hmac.t ............ ok ../test/recipes/05-test_idea.t ............ ok ../test/recipes/05-test_md2.t ............. skipped: md2 is not supported by this OpenSSL build ../test/recipes/05-test_md4.t ............. ok ../test/recipes/05-test_md5.t ............. ok ../test/recipes/05-test_mdc2.t ............ ok ../test/recipes/05-test_rand.t ............ ok ../test/recipes/05-test_rc2.t ............. ok ../test/recipes/05-test_rc4.t ............. ok ../test/recipes/05-test_rc5.t ............. ok ../test/recipes/05-test_rmd.t ............. ok ../test/recipes/05-test_sha1.t ............ ok ../test/recipes/05-test_sha256.t .......... ok ../test/recipes/05-test_sha512.t .......... ok ../test/recipes/05-test_wp.t .............. ok ../test/recipes/10-test_bn.t .............. ok ../test/recipes/10-test_exp.t ............. ok ../test/recipes/15-test_dh.t .............. ok ../test/recipes/15-test_dsa.t ............. ok ../test/recipes/15-test_ec.t .............. ok ../test/recipes/15-test_ecdh.t ............ ok ../test/recipes/15-test_ecdsa.t ........... ok ../test/recipes/15-test_rsa.t ............. ok ../test/recipes/20-test_enc.t ............. ok ../test/recipes/25-test_crl.t ............. ok ../test/recipes/25-test_gen.t ............. ok ../test/recipes/25-test_pkcs7.t ........... ok ../test/recipes/25-test_req.t ............. ok ../test/recipes/25-test_sid.t ............. ok ../test/recipes/25-test_verify.t .......... ok ../test/recipes/25-test_x509.t ............ ok ../test/recipes/30-test_engine.t .......... ok ../test/recipes/30-test_evp.t ............. 1/1 # Failed test 'running evp_test evptests.txt' # at ../test/recipes/30-test_evp.t line 11. # Looks like you failed 1 test of 1. ../test/recipes/30-test_evp.t ............. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/30-test_evp_extra.t ....... ok ../test/recipes/30-test_pbelu.t ........... ok ../test/recipes/40-test_rehash.t .......... 4/5 # Failed test 'Testing that we aren't running as a priviledged user, such as root' # at ../test/recipes/40-test_rehash.t line 41. # Looks like you failed 1 test of 5. ../test/recipes/40-test_rehash.t .......... Dubious, test returned 1 (wstat 256, 0x100) Failed 1/5 subtests (less 1 skipped subtest: 3 okay) ../test/recipes/70-test_clienthello.t ..... ok ../test/recipes/70-test_packet.t .......... 1/1 # Failed test 'running packettest' # at ../test/testlib/OpenSSL/Test/Simple.pm line 70. # Looks like you failed 1 test of 1. ../test/recipes/70-test_packet.t .......... Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/70-test_sslcertstatus.t ... Failed creating proxy socket (localhost,4453): Address already in use # Looks like your test exited with 48 before it could output anything. ../test/recipes/70-test_sslcertstatus.t ... Dubious, test returned 48 (wstat 12288, 0x3000) Failed 1/1 subtests ../test/recipes/70-test_sslextension.t .... Failed creating proxy socket (localhost,4453): Address already in use # Looks like your test exited with 48 before it could output anything. ../test/recipes/70-test_sslextension.t .... Dubious, test returned 48 (wstat 12288, 0x3000) Failed 1/1 subtests ../test/recipes/70-test_sslsessiontick.t .. Failed creating proxy socket (localhost,4453): Address already in use # Looks like your test exited with 48 before it could output anything. ../test/recipes/70-test_sslsessiontick.t .. Dubious, test returned 48 (wstat 12288, 0x3000) Failed 8/8 subtests ../test/recipes/70-test_sslskewith0p.t .... Failed creating proxy socket (localhost,4453): Address already in use # Looks like your test exited with 48 before it could output anything. ../test/recipes/70-test_sslskewith0p.t .... Dubious, test returned 48 (wstat 12288, 0x3000) Failed 1/1 subtests ../test/recipes/70-test_sslvertol.t ....... Failed creating proxy socket (localhost,4453): Address already in use # Looks like your test exited with 48 before it could output anything. ../test/recipes/70-test_sslvertol.t ....... Dubious, test returned 48 (wstat 12288, 0x3000) Failed 2/2 subtests ../test/recipes/70-test_tlsextms.t ........ Failed creating proxy socket (localhost,4453): Address already in use # Looks like your test exited with 48 before it could output anything. ../test/recipes/70-test_tlsextms.t ........ Dubious, test returned 48 (wstat 12288, 0x3000) Failed 9/9 subtests ../test/recipes/70-test_verify_extra.t .... ok ../test/recipes/80-test_ca.t .............. ok ../test/recipes/80-test_cms.t ............. ok ../test/recipes/80-test_dane.t ............ ok ../test/recipes/80-test_dtlsv1listen.t .... ok ../test/recipes/80-test_ocsp.t ............ ok ../test/recipes/80-test_ssl.t ............. 1/44 # Failed test 'test TLS via IPv4' # at ../test/recipes/80-test_ssl.t line 437. # Failed test 'test TLS via IPv6' # at ../test/recipes/80-test_ssl.t line 444. # Looks like you failed 2 tests of 29. ../test/recipes/80-test_ssl.t ............. 3/44 # Failed test 'standard SSL tests' # at ../test/recipes/80-test_ssl.t line 448. ../test/recipes/80-test_ssl.t ............. 41/44 # Looks like you failed 1 test of 44. ../test/recipes/80-test_ssl.t ............. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/44 subtests ../test/recipes/80-test_tsa.t ............. ok ../test/recipes/90-test_async.t ........... ok ../test/recipes/90-test_constant_time.t ... ok ../test/recipes/90-test_gmdiff.t .......... ok ../test/recipes/90-test_heartbeat.t ....... skipped: heartbeats is not supported by this OpenSSL build ../test/recipes/90-test_ige.t ............. ok ../test/recipes/90-test_jpake.t ........... ok ../test/recipes/90-test_memleak.t ......... ok ../test/recipes/90-test_networking.t ...... Proxy connection failed: Failed creating proxy socket (127.0.0.1,4453): Address already in use ../test/recipes/90-test_networking.t ...... 1/2 # Failed test 'Trying IPv4' # at ../test/recipes/90-test_networking.t line 90. SO a little better but something is going not right with the proxy. -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Broadcasting the truth for 25 years From openssl at roumenpetrov.info Tue Feb 16 19:48:50 2016 From: openssl at roumenpetrov.info (Roumen Petrov) Date: Tue, 16 Feb 2016 21:48:50 +0200 Subject: [openssl-dev] duplicate opt* declaration in apps.h Message-ID: <56C37D22.2090208@roumenpetrov.info> Hello, Currently opt_next, opt_imax and opt_umax are declared more than once in apps.h - see attached patch Roumen -------------- next part -------------- A non-text attachment was scrubbed... Name: 0005-redundant-opt-declarations.patch Type: text/x-diff Size: 1730 bytes Desc: not available URL: From rt at openssl.org Tue Feb 16 19:50:58 2016 From: rt at openssl.org (Roumen Petrov via RT) Date: Tue, 16 Feb 2016 19:50:58 +0000 Subject: [openssl-dev] [openssl.org #4312] documentation: RSA_new_method argument In-Reply-To: <56C37D98.8030009@roumenpetrov.info> References: <56C37D98.8030009@roumenpetrov.info> Message-ID: Hello, Function argument is pointer to ENGINE - please find attached patch Regards, Roumen Petrov -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4312 Please log in as guest with password guest if prompted -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-documentation-RSA_new_method-argument.patch Type: text/x-diff Size: 693 bytes Desc: not available URL: From openssl at roumenpetrov.info Tue Feb 16 19:54:13 2016 From: openssl at roumenpetrov.info (Roumen Petrov) Date: Tue, 16 Feb 2016 21:54:13 +0200 Subject: [openssl-dev] OPENSSL_config with default configuration Message-ID: <56C37E65.3010204@roumenpetrov.info> Hello, OPENSSL_config with NULL argument crash in master branch. Please find attached file with proposed patch. Regards, Roumen -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-OPENSSL_config-with-default-configuration.patch Type: text/x-diff Size: 857 bytes Desc: not available URL: From rsalz at akamai.com Tue Feb 16 21:22:43 2016 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 16 Feb 2016 21:22:43 +0000 Subject: [openssl-dev] Call for testing: OpenSSH 7.2 In-Reply-To: <20160215184527.GB11163@doctor.nl2k.ab.ca> References: <20160215184527.GB11163@doctor.nl2k.ab.ca> Message-ID: <76d625b29f1a453b9bbd471afab5f0fa@ustx2ex-dag1mb1.msg.corp.akamai.com> In OpenSSL 1.1, the fields of most structures are not available, the structures are made opaque. Instead accessors need to be used; if more need to be provided, that's an OpenSSL bug. Else it's an openssh porting issue. From rsalz at akamai.com Tue Feb 16 21:24:08 2016 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 16 Feb 2016 21:24:08 +0000 Subject: [openssl-dev] [openssl-users] OpenSSL version 1.1.0 pre release 3 published In-Reply-To: <20160215190420.GA12045@openssl.org> References: <20160215190420.GA12045@openssl.org> Message-ID: <5676344ef8684de0b44603b528127657@ustx2ex-dag1mb1.msg.corp.akamai.com> > OpenSSL 1.1.0 is currently in alpha. OpenSSL 1.1.0 pre release 3 has now > been made available. For details of changes and known issues see the > release notes at: Just to emphasize one important point: Our next release is planned to be Beta-1, in about a month. After that, no new API's or features will be added to OpenSSL 1.1 /r$ From rsalz at akamai.com Tue Feb 16 21:38:42 2016 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 16 Feb 2016 21:38:42 +0000 Subject: [openssl-dev] OpenSSL 1.1 pre-3 CRYPTO_set_mem_functions In-Reply-To: <20160216.005609.2264501703125197202.levitte@openssl.org> References: <0v59RC3DjidYWsO@srv.efca.com> <20160216.003341.1330342472230157667.levitte@openssl.org> <20160216.005609.2264501703125197202.levitte@openssl.org> Message-ID: > You know, you're entirely right. That's a flaw and needs correction. > Thanks for the notification. Yes, the macro's in crypto.h should call through the function pointers. From rt at openssl.org Sun Feb 7 04:33:31 2016 From: rt at openssl.org (Sammy Kurdo via RT) Date: Sun, 07 Feb 2016 04:33:31 +0000 Subject: [openssl-dev] [openssl.org #4294] [bug] failed to install in Ubuntu In-Reply-To: References: Message-ID: system info: user at ubuntu:~/Downloads/openssl$ uname -a Linux ubuntu 4.2.0-16-generic #19-Ubuntu SMP Thu Oct 8 15:35:06 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux procedure: 1. git clone https://github.com/openssl/openssl 2. cd openssl/ 3. ./config 4. make depend 5. sudo make install output Test Summary Report ------------------- ../test/recipes/40-test_rehash.t (Wstat: 256 Tests: 5 Failed: 1) Failed test: 4 Non-zero exit status: 1 Files=70, Tests=362, 21 wallclock secs ( 0.39 usr 0.04 sys + 14.59 cusr 0.61 csys = 15.63 CPU) Result: FAIL Failed 1/70 test programs. 1/362 subtests failed. Makefile:159: recipe for target 'tests' failed make[2]: *** [tests] Error 255 make[2]: Leaving directory '/home/user/Downloads/openssl/test' Makefile:419: recipe for target 'tests' failed make[1]: *** [tests] Error 2 make[1]: Leaving directory '/home/user/Downloads/openssl' ----------------------------------------------------------------------------- -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4294 Please log in as guest with password guest if prompted -------------- next part -------------- A non-text attachment was scrubbed... Name: testlog Type: application/octet-stream Size: 31750 bytes Desc: not available URL: From rt at openssl.org Mon Feb 15 15:36:52 2016 From: rt at openssl.org (Gueron, Shay via RT) Date: Mon, 15 Feb 2016 15:36:52 +0000 Subject: [openssl-dev] [openssl.org #4307] [PATCH] Multi Block (MB) SHA512 for x86_64 Architectures that support AVX2/AVX512 instructions set In-Reply-To: <3DE91BD01FD68540858FC917201D9B9939D75B71@hasmsx107.ger.corp.intel.com> References: <3DE91BD01FD68540858FC917201D9B9939D75B71@hasmsx107.ger.corp.intel.com> Message-ID: Hello all, This patch is a contribution to OpenSSL. It deals the Multi Block (MB) SHA256 & SHA512 implementations. It adds new SHA512 Multi Block implementations for x86_64 architecture supporting AVX2 and AVX512. The AVX512 extension is expected to gain more than 2x improvement over AVX2, due to the wider architecture and the use of the vpternlog, vpror, pvrol instructions. In addition, this patch adds standalone Multi block functionality and interface for SHA256/SHA512 (not only through the cbc-sha combination). A new "openssl speed" call is added. to measure the Multi Block Digest using SHA256/SHA512: openssl speed -mb -evp sha256 openssl speed -mb -evp sha512 This patch incorporates the previous patches [1] and [2], and extends them. Currently, compiled with binutils version 2.25. Results Multi-Block results obtained by: openssl speed -mb -evp sha256 openssl speed -mb -evp sha512 On Serial results ontained by" openssl speed -evp sha256 openssl speed -evp sha512 (reporting the 8192 bytes input, converter Cycles/Byte metric) Architecture SHA256 Serial SHA256 - Multi Block HSW: 7.82 2.99 BDW: 7.82 2.85 SKL: 7.73 2.59 Architecture SHA512 Serial SHA512 - Multi Block HSW: 5.43 3.79 BDW: 5.35 3.64 SKL: 5.23 3.42 [1] Patch #3850 - Improved performance Multi Block CBC-SHA1 and CBC-SHA256. https://mta.openssl.org/pipermail/openssl-dev/2015-May/001417.html [2] Patch #4221 - Accelerating Multi Block (MB) CBC SHA256 on architectures that support AVX512 instructions set http://openssl.6102.n7.nabble.com/openssl-org-4221-PATCH-Accelerating-Multi-Block-MB-CBC-SHA256-on-architectures-that-support-AVX512-it-td62058.html Developers and authors: *************************************************************************** Shay Gueron (1, 2), Regev Shemy (2) (1) University of Haifa, Israel (2) Intel Corporation, Israel Development Center, Haifa, Israel *************************************************************************** --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4307 Please log in as guest with password guest if prompted -------------- next part -------------- A non-text attachment was scrubbed... Name: SHA_Multi_Block_SHA256_SHA512.PATCH Type: application/octet-stream Size: 307167 bytes Desc: not available URL: From doctor at doctor.nl2k.ab.ca Tue Feb 16 17:57:19 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Tue, 16 Feb 2016 10:57:19 -0700 Subject: [openssl-dev] Openssl-SNAP-20160216 issues In-Reply-To: <20160216.104221.469775936406219219.levitte@openssl.org> References: <20160216090030.GA11685@doctor.nl2k.ab.ca> <20160216.104221.469775936406219219.levitte@openssl.org> Message-ID: <20160216175719.GC5339@doctor.nl2k.ab.ca> On Tue, Feb 16, 2016 at 10:42:21AM +0100, Richard Levitte wrote: > In message <20160216090030.GA11685 at doctor.nl2k.ab.ca> on Tue, 16 Feb 2016 02:00:30 -0700, The Doctor said: > > doctor> In the make test I am getting > doctor> > doctor> TOP=.. PERL=/usr/bin/perl5 /usr/bin/perl5 run_tests.pl alltests > doctor> ../test/recipes/01-test_ordinals.t ........ ok > doctor> ../test/recipes/05-test_bf.t .............. ok > doctor> ../test/recipes/05-test_cast.t ............ ok > doctor> ../test/recipes/05-test_des.t ............. ok > doctor> ../test/recipes/05-test_hmac.t ............ ok > doctor> ../test/recipes/05-test_idea.t ............ ok > doctor> ../test/recipes/05-test_md2.t ............. skipped: md2 is not supported by this OpenSSL build > doctor> ../test/recipes/05-test_md4.t ............. ok > doctor> ../test/recipes/05-test_md5.t ............. ok > doctor> ../test/recipes/05-test_mdc2.t ............ ok > doctor> ../test/recipes/05-test_rand.t ............ 1/1 > doctor> # Failed test 'running randtest' > doctor> # at ../test/testlib/OpenSSL/Test/Simple.pm line 70. > doctor> # Looks like you failed 1 test of 1. > doctor> ../test/recipes/05-test_rand.t ............ Dubious, test returned 1 (wstat 256, 0x100) > doctor> Failed 1/1 subtests > doctor> ../test/recipes/05-test_rc2.t ............. ok > doctor> ../test/recipes/05-test_rc4.t ............. ok > doctor> ../test/recipes/05-test_rc5.t ............. ok > doctor> ../test/recipes/05-test_rmd.t ............. ok > doctor> ../test/recipes/05-test_sha1.t ............ ok > doctor> ../test/recipes/05-test_sha256.t .......... ok > doctor> ../test/recipes/05-test_sha512.t .......... ok > doctor> ../test/recipes/05-test_wp.t .............. ok > doctor> ../test/recipes/10-test_bn.t .............. ok > doctor> ../test/recipes/10-test_exp.t ............. ok > doctor> ../test/recipes/15-test_dh.t .............. ok > doctor> ../test/recipes/15-test_dsa.t ............. ok > doctor> ../test/recipes/15-test_ec.t .............. ok > doctor> ../test/recipes/15-test_ecdh.t ............ ok > doctor> ../test/recipes/15-test_ecdsa.t ........... ok > doctor> ../test/recipes/15-test_rsa.t ............. ok > doctor> ../test/recipes/20-test_enc.t ............. 2/127 > doctor> # Failed test 'aes-128-cbc' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'aes-128-cbc base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'aes-128-ecb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 6/127 > doctor> # Failed test 'aes-192-cbc' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'aes-192-cbc base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'aes-192-ecb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'aes-192-ecb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 11/127 > doctor> # Failed test 'aes-256-cbc base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'aes-256-ecb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'aes-256-ecb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 16/127 > doctor> # Failed test 'bf' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'bf-cbc' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'bf-cbc base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 20/127 > doctor> # Failed test 'bf-cfb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'bf-cfb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'bf-ecb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'bf-ecb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'bf-ofb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'bf-ofb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 26/127 > doctor> # Failed test 'camellia-128-cbc' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'camellia-128-cbc base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'camellia-128-ecb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 30/127 > doctor> # Failed test 'camellia-192-cbc' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'camellia-192-cbc base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'camellia-192-ecb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'camellia-192-ecb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'camellia-256-cbc' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'camellia-256-cbc base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 36/127 > doctor> # Failed test 'camellia-256-ecb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'camellia-256-ecb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'cast' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'cast base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 41/127 > doctor> # Failed test 'cast-cbc base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'cast5-cbc' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'cast5-cbc base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 45/127 > doctor> # Failed test 'cast5-cfb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'cast5-ecb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'cast5-ecb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'cast5-ofb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'cast5-ofb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 50/127 > doctor> # Failed test 'des' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'des base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'des-cbc' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'des-cbc base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'des-cfb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 55/127 > doctor> # Failed test 'des-cfb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'des-ecb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'des-ecb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'des-ede' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'des-ede base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'des-ede-cbc' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 61/127 > doctor> # Failed test 'des-ede-cfb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'des-ede-cfb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'des-ede-ofb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 65/127 > doctor> # Failed test 'des-ede-ofb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'des-ede3' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'des-ede3 base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'des-ede3-cbc' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'des-ede3-cbc base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'des-ede3-cfb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'des-ede3-cfb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 72/127 > doctor> # Failed test 'des-ede3-ofb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'des-ede3-ofb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'des-ofb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'des-ofb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'des3' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'des3 base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 78/127 > doctor> # Failed test 'desx' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'desx base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'idea' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'idea base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'idea-cbc' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 83/127 > doctor> # Failed test 'idea-cbc base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'idea-cfb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'idea-cfb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'idea-ecb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'idea-ecb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'idea-ofb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 89/127 > doctor> # Failed test 'idea-ofb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'rc2' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'rc2 base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'rc2-40-cbc' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'rc2-40-cbc base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'rc2-64-cbc' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 95/127 > doctor> # Failed test 'rc2-64-cbc base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'rc2-cbc' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'rc2-cbc base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'rc2-cfb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'rc2-cfb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 100/127 > doctor> # Failed test 'rc2-ecb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'rc2-ecb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'rc2-ofb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 103/127 > doctor> # Failed test 'rc2-ofb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'rc4' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'rc4 base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'rc4-40' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'rc4-40 base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'rc5' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 109/127 > doctor> # Failed test 'rc5 base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'rc5-cbc' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'rc5-cbc base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'rc5-cfb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'rc5-cfb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'rc5-ecb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 115/127 > doctor> # Failed test 'rc5-ecb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'rc5-ofb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'rc5-ofb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'seed' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 119/127 > doctor> # Failed test 'seed base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'seed-cbc' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'seed-cbc base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'seed-cfb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'seed-cfb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'seed-ecb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> ../test/recipes/20-test_enc.t ............. 125/127 > doctor> # Failed test 'seed-ofb' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> > doctor> # Failed test 'seed-ofb base64' > doctor> # at ../test/recipes/20-test_enc.t line 54. > doctor> # Looks like you failed 116 tests of 127. > doctor> ../test/recipes/20-test_enc.t ............. Dubious, test returned 116 (wstat 29696, 0x7400) > doctor> Failed 116/127 subtests > doctor> ../test/recipes/25-test_crl.t ............. ok > doctor> ../test/recipes/25-test_gen.t ............. ok > doctor> ../test/recipes/25-test_pkcs7.t ........... ok > doctor> ../test/recipes/25-test_req.t ............. ok > doctor> ../test/recipes/25-test_sid.t ............. ok > doctor> ../test/recipes/25-test_verify.t .......... ok > doctor> ../test/recipes/25-test_x509.t ............ ok > doctor> ../test/recipes/30-test_engine.t .......... ok > doctor> ../test/recipes/30-test_evp.t ............. 1/1 > doctor> # Failed test 'running evp_test evptests.txt' > doctor> # at ../test/recipes/30-test_evp.t line 11. > doctor> # Looks like you failed 1 test of 1. > doctor> ../test/recipes/30-test_evp.t ............. Dubious, test returned 1 (wstat 256, 0x100) > doctor> Failed 1/1 subtests > doctor> ../test/recipes/30-test_evp_extra.t ....... 1/1 > doctor> # Failed test 'running evp_extra_test' > doctor> # at ../test/recipes/30-test_evp_extra.t line 11. > doctor> # Looks like you failed 1 test of 1. > doctor> ../test/recipes/30-test_evp_extra.t ....... Dubious, test returned 1 (wstat 256, 0x100) > doctor> Failed 1/1 subtests > doctor> ../test/recipes/30-test_pbelu.t ........... ok > doctor> ../test/recipes/40-test_rehash.t .......... 2/5 > doctor> # Failed test 'Testing that we aren't running as a priviledged user, such as root' > doctor> # at ../test/recipes/40-test_rehash.t line 41. > doctor> # Looks like you failed 1 test of 5. > doctor> ../test/recipes/40-test_rehash.t .......... Dubious, test returned 1 (wstat 256, 0x100) > doctor> Failed 1/5 subtests > doctor> (less 1 skipped subtest: 3 okay) > doctor> ../test/recipes/70-test_clienthello.t ..... 1/1 > doctor> # Failed test 'running clienthellotest' > doctor> # at ../test/recipes/70-test_clienthello.t line 13. > doctor> # Looks like you failed 1 test of 1. > doctor> ../test/recipes/70-test_clienthello.t ..... Dubious, test returned 1 (wstat 256, 0x100) > doctor> Failed 1/1 subtests > doctor> ../test/recipes/70-test_packet.t .......... 1/1 > doctor> # Failed test 'running packettest' > doctor> # at ../test/testlib/OpenSSL/Test/Simple.pm line 70. > doctor> # Looks like you failed 1 test of 1. > doctor> ../test/recipes/70-test_packet.t .......... Dubious, test returned 1 (wstat 256, 0x100) > doctor> Failed 1/1 subtests > doctor> ../test/recipes/70-test_sslcertstatus.t ... > doctor> > doctor> > doctor> > doctor> All right the ../test/recipes/70-test_sslcertstatus.t is hanging into infinity. > doctor> > doctor> What can do to see why these tests are failing? > > You can do this: > > HARNESS_VERBOSE=yes make test > > Fair warning, that's a *lot* of output > > If you want to be selective, you can pick specific tests into the > TESTS variable, like this: > > HARNESS_VERBOSE=yes make test TESTS='tesl_ssl test_packet' > > The words in that variable are taken from the test recipes, it's the > {name} part in nn-{name}.t, so for the recipe file > ../test/recipes/70-test_clienthello.t, the name to put into the TESTS > variable is test_clienthello. > HARNESS_VERBOSE=yes make test TESTS='test_enc' gave me TOP=.. PERL=/usr/bin/perl5 /usr/bin/perl5 run_tests.pl test_enc ../test/recipes/20-test_enc.t .. 1..127 ok 1 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 2 - aes-128-cbc # Failed test 'aes-128-cbc' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 3 - aes-128-cbc base64 # Failed test 'aes-128-cbc base64' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 4 - aes-128-ecb # Failed test 'aes-128-ecb' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 5 - aes-128-ecb base64 # Failed test 'aes-128-ecb base64' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 6 - aes-192-cbc # Failed test 'aes-192-cbc' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 7 - aes-192-cbc base64 # Failed test 'aes-192-cbc base64' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 8 - aes-192-ecb # Failed test 'aes-192-ecb' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 9 - aes-192-ecb base64 # Failed test 'aes-192-ecb base64' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 10 - aes-256-cbc # Failed test 'aes-256-cbc' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 11 - aes-256-cbc base64 # Failed test 'aes-256-cbc base64' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 12 - aes-256-ecb # Failed test 'aes-256-ecb' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 13 - aes-256-ecb base64 # Failed test 'aes-256-ecb base64' # at ../test/recipes/20-test_enc.t line 54. ok 14 - base64 ok 15 - base64 base64 ok 16 - bf 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 17 - bf base64 # Failed test 'bf base64' # at ../test/recipes/20-test_enc.t line 54. ok 18 - bf-cbc 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 19 - bf-cbc base64 # Failed test 'bf-cbc base64' # at ../test/recipes/20-test_enc.t line 54. ok 20 - bf-cfb ok 21 - bf-cfb base64 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 22 - bf-ecb # Failed test 'bf-ecb' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 23 - bf-ecb base64 # Failed test 'bf-ecb base64' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 24 - bf-ofb # Failed test 'bf-ofb' # at ../test/recipes/20-test_enc.t line 54. ok 25 - bf-ofb base64 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 26 - camellia-128-cbc # Failed test 'camellia-128-cbc' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 27 - camellia-128-cbc base64 # Failed test 'camellia-128-cbc base64' # at ../test/recipes/20-test_enc.t line 54. ok 28 - camellia-128-ecb 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 29 - camellia-128-ecb base64 # Failed test 'camellia-128-ecb base64' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 30 - camellia-192-cbc # Failed test 'camellia-192-cbc' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 31 - camellia-192-cbc base64 # Failed test 'camellia-192-cbc base64' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 32 - camellia-192-ecb # Failed test 'camellia-192-ecb' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 33 - camellia-192-ecb base64 # Failed test 'camellia-192-ecb base64' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 34 - camellia-256-cbc # Failed test 'camellia-256-cbc' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 35 - camellia-256-cbc base64 # Failed test 'camellia-256-cbc base64' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 36 - camellia-256-ecb # Failed test 'camellia-256-ecb' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 37 - camellia-256-ecb base64 # Failed test 'camellia-256-ecb base64' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 38 - cast # Failed test 'cast' # at ../test/recipes/20-test_enc.t line 54. ok 39 - cast base64 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 40 - cast-cbc # Failed test 'cast-cbc' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 41 - cast-cbc base64 # Failed test 'cast-cbc base64' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 42 - cast5-cbc # Failed test 'cast5-cbc' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 43 - cast5-cbc base64 # Failed test 'cast5-cbc base64' # at ../test/recipes/20-test_enc.t line 54. ok 44 - cast5-cfb 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 45 - cast5-cfb base64 # Failed test 'cast5-cfb base64' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 46 - cast5-ecb # Failed test 'cast5-ecb' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 47 - cast5-ecb base64 # Failed test 'cast5-ecb base64' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 48 - cast5-ofb # Failed test 'cast5-ofb' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 49 - cast5-ofb base64 # Failed test 'cast5-ofb base64' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 50 - des # Failed test 'des' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 51 - des base64 # Failed test 'des base64' # at ../test/recipes/20-test_enc.t line 54. ok 52 - des-cbc ok 53 - des-cbc base64 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 54 - des-cfb # Failed test 'des-cfb' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 55 - des-cfb base64 # Failed test 'des-cfb base64' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 56 - des-ecb # Failed test 'des-ecb' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 57 - des-ecb base64 # Failed test 'des-ecb base64' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 58 - des-ede # Failed test 'des-ede' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 59 - des-ede base64 # Failed test 'des-ede base64' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 60 - des-ede-cbc # Failed test 'des-ede-cbc' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 61 - des-ede-cbc base64 # Failed test 'des-ede-cbc base64' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 62 - des-ede-cfb # Failed test 'des-ede-cfb' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 63 - des-ede-cfb base64 # Failed test 'des-ede-cfb base64' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 64 - des-ede-ofb # Failed test 'des-ede-ofb' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 65 - des-ede-ofb base64 # Failed test 'des-ede-ofb base64' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 66 - des-ede3 # Failed test 'des-ede3' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 67 - des-ede3 base64 # Failed test 'des-ede3 base64' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 68 - des-ede3-cbc # Failed test 'des-ede3-cbc' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 69 - des-ede3-cbc base64 # Failed test 'des-ede3-cbc base64' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 70 - des-ede3-cfb # Failed test 'des-ede3-cfb' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 71 - des-ede3-cfb base64 # Failed test 'des-ede3-cfb base64' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 72 - des-ede3-ofb # Failed test 'des-ede3-ofb' # at ../test/recipes/20-test_enc.t line 54. ok 73 - des-ede3-ofb base64 ok 74 - des-ofb 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 75 - des-ofb base64 # Failed test 'des-ofb base64' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 76 - des3 # Failed test 'des3' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 77 - des3 base64 # Failed test 'des3 base64' # at ../test/recipes/20-test_enc.t line 54. ok 78 - desx 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 79 - desx base64 # Failed test 'desx base64' # at ../test/recipes/20-test_enc.t line 54. ok 80 - idea 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 81 - idea base64 # Failed test 'idea base64' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 82 - idea-cbc # Failed test 'idea-cbc' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 83 - idea-cbc base64 # Failed test 'idea-cbc base64' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 84 - idea-cfb # Failed test 'idea-cfb' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 85 - idea-cfb base64 # Failed test 'idea-cfb base64' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 86 - idea-ecb # Failed test 'idea-ecb' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 87 - idea-ecb base64 # Failed test 'idea-ecb base64' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 88 - idea-ofb # Failed test 'idea-ofb' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 89 - idea-ofb base64 # Failed test 'idea-ofb base64' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 90 - rc2 # Failed test 'rc2' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 91 - rc2 base64 # Failed test 'rc2 base64' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 92 - rc2-40-cbc # Failed test 'rc2-40-cbc' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 93 - rc2-40-cbc base64 # Failed test 'rc2-40-cbc base64' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 94 - rc2-64-cbc # Failed test 'rc2-64-cbc' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 95 - rc2-64-cbc base64 # Failed test 'rc2-64-cbc base64' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 96 - rc2-cbc # Failed test 'rc2-cbc' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 97 - rc2-cbc base64 # Failed test 'rc2-cbc base64' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 98 - rc2-cfb # Failed test 'rc2-cfb' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 99 - rc2-cfb base64 # Failed test 'rc2-cfb base64' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 100 - rc2-ecb # Failed test 'rc2-ecb' # at ../test/recipes/20-test_enc.t line 54. ok 101 - rc2-ecb base64 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 102 - rc2-ofb # Failed test 'rc2-ofb' # at ../test/recipes/20-test_enc.t line 54. ok 103 - rc2-ofb base64 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 104 - rc4 # Failed test 'rc4' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 105 - rc4 base64 # Failed test 'rc4 base64' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 106 - rc4-40 # Failed test 'rc4-40' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 107 - rc4-40 base64 # Failed test 'rc4-40 base64' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 108 - rc5 # Failed test 'rc5' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 109 - rc5 base64 # Failed test 'rc5 base64' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 110 - rc5-cbc # Failed test 'rc5-cbc' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 111 - rc5-cbc base64 # Failed test 'rc5-cbc base64' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 112 - rc5-cfb # Failed test 'rc5-cfb' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 113 - rc5-cfb base64 # Failed test 'rc5-cfb base64' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 114 - rc5-ecb # Failed test 'rc5-ecb' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 115 - rc5-ecb base64 # Failed test 'rc5-ecb base64' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 116 - rc5-ofb # Failed test 'rc5-ofb' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 117 - rc5-ofb base64 # Failed test 'rc5-ofb base64' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 118 - seed # Failed test 'seed' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 119 - seed base64 # Failed test 'seed base64' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 120 - seed-cbc # Failed test 'seed-cbc' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 121 - seed-cbc base64 # Failed test 'seed-cbc base64' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 122 - seed-cfb # Failed test 'seed-cfb' # at ../test/recipes/20-test_enc.t line 54. ok 123 - seed-cfb base64 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 124 - seed-ecb # Failed test 'seed-ecb' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 125 - seed-ecb base64 # Failed test 'seed-ecb base64' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 126 - seed-ofb # Failed test 'seed-ofb' # at ../test/recipes/20-test_enc.t line 54. 135029000:error:24064064:random number generator:RAND_bytes:PRNG not seeded:md_rand.c:597:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html not ok 127 - seed-ofb base64 # Failed test 'seed-ofb base64' # at ../test/recipes/20-test_enc.t line 54. # Looks like you failed 107 tests of 127. Dubious, test returned 107 (wstat 27392, 0x6b00) Failed 107/127 subtests Test Summary Report ------------------- ../test/recipes/20-test_enc.t (Wstat: 27392 Tests: 127 Failed: 107) Failed tests: 2-13, 17, 19, 22-24, 26-27, 29-38, 40-43 45-51, 54-72, 75-77, 79, 81-100, 102, 104-122 124-127 Non-zero exit status: 107 Files=1, Tests=127, 36 wallclock secs ( 0.10 usr 0.17 sys + 3.55 cusr 13.90 csys = 17.72 CPU) Result: FAIL Failed 1/1 test programs. 107/127 subtests failed. *** Error code 107 Stop. *** Error code 1 Stop. I use EGD around here. > Cheers, > Richard > > -- > Richard Levitte levitte at openssl.org > OpenSSL Project http://www.openssl.org/~levitte/ > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Broadcasting the truth for 25 years From rsalz at akamai.com Tue Feb 16 22:35:22 2016 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 16 Feb 2016 22:35:22 +0000 Subject: [openssl-dev] Openssl-SNAP-20160216 issues In-Reply-To: <20160216175719.GC5339@doctor.nl2k.ab.ca> References: <20160216090030.GA11685@doctor.nl2k.ab.ca> <20160216.104221.469775936406219219.levitte@openssl.org> <20160216175719.GC5339@doctor.nl2k.ab.ca> Message-ID: <637656b113244f65854866f81f8deb41@ustx2ex-dag1mb1.msg.corp.akamai.com> Can I make a few suggestions? Wait a day or two and see if the problem is fixed. Snapshots are expected to be broken now and then. Posting your config line is very important ./config have-egd For example. Or whatever it is. Remove/ignore things that pass, just show what fails. Thanks. We appreciate your efforts to help improve OpenSSL! From hyc at highlandsun.com Tue Feb 16 23:06:32 2016 From: hyc at highlandsun.com (Howard Chu) Date: Tue, 16 Feb 2016 23:06:32 +0000 Subject: [openssl-dev] OpenSSL version 1.1.0 pre release 3 published In-Reply-To: References: <20160215190420.GA12045@openssl.org> <20160215205227.GA18770@w1.fi> <20160215212530.GA13775@w1.fi> <56C24469.2050605@openssl.org> <20160215215040.GA23301@w1.fi> <56C24E6B.5090808@openssl.org> <1455639422.4832.171.camel@infradead.org> Message-ID: <56C3AB78.1030300@highlandsun.com> Viktor Dukhovni wrote: > >> On Feb 16, 2016, at 11:17 AM, David Woodhouse wrote: >> >> If a library (or loadable plugin within an application) uses OpenSSL, >> how should it clean up after itself? > > I must do nothing. That's what auto-initialization is for. It is > wrong for libraries to initialize OpenSSL, because that can't be > done safely. So in libraries that use OpenSSL, no OpenSSL initialization, > and no cleanup. > I like this direction, but is it actually stable? There are programs out there that dynamically load and then unload modules repeatedly thru their life. We see libldap getting loaded and unloaded this way a lot, and that naturally means libssl/libcrypto go along for the ride too. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ From openssl-users at dukhovni.org Tue Feb 16 23:11:15 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 16 Feb 2016 23:11:15 +0000 Subject: [openssl-dev] OpenSSL version 1.1.0 pre release 3 published In-Reply-To: <56C3AB78.1030300@highlandsun.com> References: <20160215190420.GA12045@openssl.org> <20160215205227.GA18770@w1.fi> <20160215212530.GA13775@w1.fi> <56C24469.2050605@openssl.org> <20160215215040.GA23301@w1.fi> <56C24E6B.5090808@openssl.org> <1455639422.4832.171.camel@infradead.org> <56C3AB78.1030300@highlandsun.com> Message-ID: <20160216231114.GB19242@mournblade.imrryr.org> On Tue, Feb 16, 2016 at 11:06:32PM +0000, Howard Chu wrote: > >I[t] must do nothing. That's what auto-initialization is for. It is > >wrong for libraries to initialize OpenSSL, because that can't be > >done safely. So in libraries that use OpenSSL, no OpenSSL initialization, > >and no cleanup. > > I like this direction, but is it actually stable? There are programs out > there that dynamically load and then unload modules repeatedly thru their > life. We see libldap getting loaded and unloaded this way a lot, and that > naturally means libssl/libcrypto go along for the ride too. Nico Williams has some cool ideas for keeping a library from getting unloaded, but regardless deinitialization is only for the application, and only really to appease valgrind and the like. De-initialization is not intended to happen when the library gets unloaded, Nico assures me that there's no safe way to do that, and the only safe thing to do when a library is unloaded is to leak! However, we may be able to arrange for the library to never be unloaded once it is loaded and initialized. -- Viktor. From michel.sales at free.fr Tue Feb 16 23:25:50 2016 From: michel.sales at free.fr (Michel) Date: Wed, 17 Feb 2016 00:25:50 +0100 Subject: [openssl-dev] memory leaks detected using libSSL 1.1 In-Reply-To: <56C25BFD.3060708@openssl.org> References: <000001d166ac$9660f640$c322e2c0$@sales@free.fr> <56BFBC88.1010901@openssl.org> <000001d166bc$308f5680$91ae0380$@sales@free.fr> <56C25BFD.3060708@openssl.org> Message-ID: <006001d16911$5fd1a3b0$1f74eb10$@sales@free.fr> Hi Matt, Yes I am linking statically and I read the man about OPENSSL_init_crypto(), thanks. However I still have leaks reported. :-( What I have changed to adapt to v1.1 is calling OPENSSL_thread_stop() in each thread before it leaves, instead of ERR_remove_thread_state( NULL ), and I am calling OPENSSL_cleanup() before the main thread returns. Am I missing anything else ? Now I have 2 tests programs, almost identical, one is linked against v1.0.2 and the other against v1.1. The former (1.0.2) doesn't report any leak but the later (1.1) always report leaks. I tried lots of modifications to the 1.1 version in order to understand what is happening, but the only thing I noticed is leaks occur if at some point the program go to the OpenSSL error subsystem, like in the 2 reports below. Can you please help in this matter ? Detected memory leaks! Dumping objects -> {7453} normal block at 0x00895440, 8 bytes long. Data: < > 00 00 00 00 01 00 00 00 {5460} normal block at 0x00871B98, 12 bytes long. Data: < e > C8 19 87 00 00 00 00 00 B4 65 01 00 {5459} normal block at 0x008719C8, 400 bytes long. Data: < > 00 00 00 00 84 1B 00 00 00 00 00 00 00 00 00 00 {5457} normal block at 0x00871900, 64 bytes long. Data: < > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 {5455} normal block at 0x0086D7E8, 96 bytes long. Data: < ` > 00 19 87 00 60 CB 05 01 80 CB 05 01 08 00 00 00 Object dump complete. WARNING: Visual Leak Detector detected memory leaks! ---------- Block 5450 at 0x0086D7E8: 96 bytes ---------- Leak Hash: 0xE1A21867, Count: 1, Total 96 bytes Call Stack (TID 6956): ntdll.dll!RtlAllocateHeap() f:\dd\vctools\crt\crtw32\misc\dbgmalloc.c (56): TestsTLS-11.exe!malloc() + 0x15 bytes e:\openssl-1.1.git\crypto\mem.c (138): TestsTLS-11.exe!CRYPTO_malloc() + 0x9 bytes e:\openssl-1.1.git\crypto\mem.c (158): TestsTLS-11.exe!CRYPTO_zalloc() + 0x11 bytes e:\openssl-1.1.git\crypto\lhash\lhash.c (116): TestsTLS-11.exe!lh_new() + 0xB bytes e:\openssl-1.1.git\crypto\err\err_lcl.h (2): TestsTLS-11.exe!lh_ERR_STATE_new() + 0x10 bytes e:\openssl-1.1.git\crypto\err\err.c (321): TestsTLS-11.exe!int_thread_get() + 0xF bytes e:\openssl-1.1.git\crypto\err\err.c (369): TestsTLS-11.exe!int_thread_set_item() + 0x9 bytes e:\openssl-1.1.git\crypto\err\err.c (884): TestsTLS-11.exe!ERR_get_state() + 0xC bytes e:\openssl-1.1.git\crypto\err\err.c (581): TestsTLS-11.exe!ERR_put_error() + 0x5 bytes e:\openssl-1.1.git\crypto\pem\pem_lib.c (702): TestsTLS-11.exe!PEM_read_bio() + 0x15 bytes e:\openssl-1.1.git\crypto\pem\pem_info.c (117): TestsTLS-11.exe!PEM_X509_INFO_read_bio() + 0x19 bytes e:\openssl-1.1.git\crypto\x509\by_file.c (249): TestsTLS-11.exe!X509_load_cert_crl_file() + 0xF bytes e:\openssl-1.1.git\crypto\x509\by_file.c (113): TestsTLS-11.exe!by_file_ctrl() + 0xF bytes e:\openssl-1.1.git\crypto\x509\x509_lu.c (117): TestsTLS-11.exe!X509_LOOKUP_ctrl() + 0x1F bytes e:\openssl-1.1.git\crypto\x509\x509_d2.c (92): TestsTLS-11.exe!X509_STORE_load_locations() + 0x13 bytes e:\openssl-1.1.git\ssl\ssl_lib.c (3344): TestsTLS-11.exe!SSL_CTX_load_verify_locations() + 0x14 bytes p:\mes programmes\shared\ocrypto-11\tls.cpp (410): TestsTLS-11.exe!OTLS::TLSCtx::LoadTrustedCertsFile() + 0x12 bytes p:\mes programmes\tests\_testsshared\teststls-11\tlscltsetup.cpp (99): TestsTLS-11.exe!TLSCltConfig::Setup() + 0x26 bytes p:\mes programmes\tests\_testsshared\teststls-11\clttasks.cpp (90): TestsTLS-11.exe!CltThread::Main() + 0x17 bytes p:\mes programmes\shared\sthread.cpp (17): TestsTLS-11.exe!SThread::Run() + 0xE bytes f:\dd\vctools\crt\crtw32\startup\threadex.c (359): TestsTLS-11.exe!_threadstartex() ---------- Block 5452 at 0x00871900: 64 bytes ---------- Leak Hash: 0x188D6136, Count: 1, Total 64 bytes Call Stack (TID 6956): ntdll.dll!RtlAllocateHeap() f:\dd\vctools\crt\crtw32\misc\dbgmalloc.c (56): TestsTLS-11.exe!malloc() + 0x15 bytes e:\openssl-1.1.git\crypto\mem.c (138): TestsTLS-11.exe!CRYPTO_malloc() + 0x9 bytes e:\openssl-1.1.git\crypto\mem.c (158): TestsTLS-11.exe!CRYPTO_zalloc() + 0x11 bytes e:\openssl-1.1.git\crypto\lhash\lhash.c (118): TestsTLS-11.exe!lh_new() + 0xB bytes e:\openssl-1.1.git\crypto\err\err_lcl.h (2): TestsTLS-11.exe!lh_ERR_STATE_new() + 0x10 bytes e:\openssl-1.1.git\crypto\err\err.c (321): TestsTLS-11.exe!int_thread_get() + 0xF bytes e:\openssl-1.1.git\crypto\err\err.c (369): TestsTLS-11.exe!int_thread_set_item() + 0x9 bytes e:\openssl-1.1.git\crypto\err\err.c (884): TestsTLS-11.exe!ERR_get_state() + 0xC bytes e:\openssl-1.1.git\crypto\err\err.c (581): TestsTLS-11.exe!ERR_put_error() + 0x5 bytes e:\openssl-1.1.git\crypto\pem\pem_lib.c (702): TestsTLS-11.exe!PEM_read_bio() + 0x15 bytes e:\openssl-1.1.git\crypto\pem\pem_info.c (117): TestsTLS-11.exe!PEM_X509_INFO_read_bio() + 0x19 bytes e:\openssl-1.1.git\crypto\x509\by_file.c (249): TestsTLS-11.exe!X509_load_cert_crl_file() + 0xF bytes e:\openssl-1.1.git\crypto\x509\by_file.c (113): TestsTLS-11.exe!by_file_ctrl() + 0xF bytes e:\openssl-1.1.git\crypto\x509\x509_lu.c (117): TestsTLS-11.exe!X509_LOOKUP_ctrl() + 0x1F bytes e:\openssl-1.1.git\crypto\x509\x509_d2.c (92): TestsTLS-11.exe!X509_STORE_load_locations() + 0x13 bytes e:\openssl-1.1.git\ssl\ssl_lib.c (3344): TestsTLS-11.exe!SSL_CTX_load_verify_locations() + 0x14 bytes p:\mes programmes\shared\ocrypto-11\tls.cpp (410): TestsTLS-11.exe!OTLS::TLSCtx::LoadTrustedCertsFile() + 0x12 bytes p:\mes programmes\tests\_testsshared\teststls-11\tlscltsetup.cpp (99): TestsTLS-11.exe!TLSCltConfig::Setup() + 0x26 bytes p:\mes programmes\tests\_testsshared\teststls-11\clttasks.cpp (90): TestsTLS-11.exe!CltThread::Main() + 0x17 bytes p:\mes programmes\shared\sthread.cpp (17): TestsTLS-11.exe!SThread::Run() + 0xE bytes f:\dd\vctools\crt\crtw32\startup\threadex.c (359): TestsTLS-11.exe!_threadstartex() ---------- Block 5454 at 0x008719C8: 400 bytes ---------- Leak Hash: 0x21826292, Count: 1, Total 400 bytes Call Stack (TID 7044): ntdll.dll!RtlAllocateHeap() f:\dd\vctools\crt\crtw32\misc\dbgmalloc.c (56): TestsTLS-11.exe!malloc() + 0x15 bytes e:\openssl-1.1.git\crypto\mem.c (138): TestsTLS-11.exe!CRYPTO_malloc() + 0x9 bytes e:\openssl-1.1.git\crypto\err\err.c (874): TestsTLS-11.exe!ERR_get_state() + 0xE bytes e:\openssl-1.1.git\crypto\err\err.c (581): TestsTLS-11.exe!ERR_put_error() + 0x5 bytes e:\openssl-1.1.git\crypto\pem\pem_lib.c (702): TestsTLS-11.exe!PEM_read_bio() + 0x15 bytes e:\openssl-1.1.git\crypto\pem\pem_info.c (117): TestsTLS-11.exe!PEM_X509_INFO_read_bio() + 0x19 bytes e:\openssl-1.1.git\crypto\x509\by_file.c (249): TestsTLS-11.exe!X509_load_cert_crl_file() + 0xF bytes e:\openssl-1.1.git\crypto\x509\by_file.c (113): TestsTLS-11.exe!by_file_ctrl() + 0xF bytes e:\openssl-1.1.git\crypto\x509\x509_lu.c (117): TestsTLS-11.exe!X509_LOOKUP_ctrl() + 0x1F bytes e:\openssl-1.1.git\crypto\x509\x509_d2.c (92): TestsTLS-11.exe!X509_STORE_load_locations() + 0x13 bytes e:\openssl-1.1.git\ssl\ssl_lib.c (3344): TestsTLS-11.exe!SSL_CTX_load_verify_locations() + 0x14 bytes p:\mes programmes\shared\ocrypto-11\tls.cpp (410): TestsTLS-11.exe!OTLS::TLSCtx::LoadTrustedCertsFile() + 0x12 bytes p:\mes programmes\tests\_testsshared\teststls-11\tlssrvsetup.cpp (214): TestsTLS-11.exe!TLSSrvConfig::Setup() + 0x26 bytes p:\mes programmes\tests\_testsshared\teststls-11\srvtasks.cpp (103): TestsTLS-11.exe!SrvThread::Main() + 0x17 bytes p:\mes programmes\shared\sthread.cpp (17): TestsTLS-11.exe!SThread::Run() + 0xE bytes f:\dd\vctools\crt\crtw32\startup\threadex.c (359): TestsTLS-11.exe!_threadstartex() ---------- Block 5455 at 0x00871B98: 12 bytes ---------- Leak Hash: 0x6B9B46D4, Count: 1, Total 12 bytes Call Stack (TID 7044): ntdll.dll!RtlAllocateHeap() f:\dd\vctools\crt\crtw32\misc\dbgmalloc.c (56): TestsTLS-11.exe!malloc() + 0x15 bytes e:\openssl-1.1.git\crypto\mem.c (138): TestsTLS-11.exe!CRYPTO_malloc() + 0x9 bytes e:\openssl-1.1.git\crypto\lhash\lhash.c (168): TestsTLS-11.exe!lh_insert() + 0xB bytes e:\openssl-1.1.git\crypto\err\err_lcl.h (2): TestsTLS-11.exe!lh_ERR_STATE_insert() + 0x10 bytes e:\openssl-1.1.git\crypto\err\err.c (371): TestsTLS-11.exe!int_thread_set_item() + 0xD bytes e:\openssl-1.1.git\crypto\err\err.c (884): TestsTLS-11.exe!ERR_get_state() + 0xC bytes e:\openssl-1.1.git\crypto\err\err.c (581): TestsTLS-11.exe!ERR_put_error() + 0x5 bytes e:\openssl-1.1.git\crypto\pem\pem_lib.c (702): TestsTLS-11.exe!PEM_read_bio() + 0x15 bytes e:\openssl-1.1.git\crypto\pem\pem_info.c (117): TestsTLS-11.exe!PEM_X509_INFO_read_bio() + 0x19 bytes e:\openssl-1.1.git\crypto\x509\by_file.c (249): TestsTLS-11.exe!X509_load_cert_crl_file() + 0xF bytes e:\openssl-1.1.git\crypto\x509\by_file.c (113): TestsTLS-11.exe!by_file_ctrl() + 0xF bytes e:\openssl-1.1.git\crypto\x509\x509_lu.c (117): TestsTLS-11.exe!X509_LOOKUP_ctrl() + 0x1F bytes e:\openssl-1.1.git\crypto\x509\x509_d2.c (92): TestsTLS-11.exe!X509_STORE_load_locations() + 0x13 bytes e:\openssl-1.1.git\ssl\ssl_lib.c (3344): TestsTLS-11.exe!SSL_CTX_load_verify_locations() + 0x14 bytes p:\mes programmes\shared\ocrypto-11\tls.cpp (410): TestsTLS-11.exe!OTLS::TLSCtx::LoadTrustedCertsFile() + 0x12 bytes p:\mes programmes\tests\_testsshared\teststls-11\tlssrvsetup.cpp (214): TestsTLS-11.exe!TLSSrvConfig::Setup() + 0x26 bytes p:\mes programmes\tests\_testsshared\teststls-11\srvtasks.cpp (103): TestsTLS-11.exe!SrvThread::Main() + 0x17 bytes p:\mes programmes\shared\sthread.cpp (17): TestsTLS-11.exe!SThread::Run() + 0xE bytes f:\dd\vctools\crt\crtw32\startup\threadex.c (359): TestsTLS-11.exe!_threadstartex() ---------- Block 7448 at 0x00895440: 8 bytes ---------- Leak Hash: 0x977858EE, Count: 1, Total 8 bytes Call Stack (TID 7044): ntdll.dll!RtlAllocateHeap() f:\dd\vctools\crt\crtw32\misc\dbgmalloc.c (56): TestsTLS-11.exe!malloc() + 0x15 bytes e:\openssl-1.1.git\crypto\mem.c (138): TestsTLS-11.exe!CRYPTO_malloc() + 0x9 bytes e:\openssl-1.1.git\crypto\mem.c (158): TestsTLS-11.exe!CRYPTO_zalloc() + 0x11 bytes e:\openssl-1.1.git\crypto\init.c (198): TestsTLS-11.exe!ossl_init_get_thread_local() + 0xB bytes e:\openssl-1.1.git\crypto\init.c (512): TestsTLS-11.exe!ossl_init_thread_start() + 0x7 bytes e:\openssl-1.1.git\crypto\err\err.c (898): TestsTLS-11.exe!ERR_get_state() + 0x9 bytes e:\openssl-1.1.git\crypto\err\err.c (581): TestsTLS-11.exe!ERR_put_error() + 0x5 bytes e:\openssl-1.1.git\crypto\pem\pem_lib.c (702): TestsTLS-11.exe!PEM_read_bio() + 0x15 bytes e:\openssl-1.1.git\crypto\pem\pem_info.c (117): TestsTLS-11.exe!PEM_X509_INFO_read_bio() + 0x19 bytes e:\openssl-1.1.git\crypto\x509\by_file.c (249): TestsTLS-11.exe!X509_load_cert_crl_file() + 0xF bytes e:\openssl-1.1.git\crypto\x509\by_file.c (113): TestsTLS-11.exe!by_file_ctrl() + 0xF bytes e:\openssl-1.1.git\crypto\x509\x509_lu.c (117): TestsTLS-11.exe!X509_LOOKUP_ctrl() + 0x1F bytes e:\openssl-1.1.git\crypto\x509\x509_d2.c (92): TestsTLS-11.exe!X509_STORE_load_locations() + 0x13 bytes e:\openssl-1.1.git\ssl\ssl_lib.c (3344): TestsTLS-11.exe!SSL_CTX_load_verify_locations() + 0x14 bytes p:\mes programmes\shared\ocrypto-11\tls.cpp (410): TestsTLS-11.exe!OTLS::TLSCtx::LoadTrustedCertsFile() + 0x12 bytes p:\mes programmes\tests\_testsshared\teststls-11\tlssrvsetup.cpp (214): TestsTLS-11.exe!TLSSrvConfig::Setup() + 0x26 bytes p:\mes programmes\tests\_testsshared\teststls-11\srvtasks.cpp (103): TestsTLS-11.exe!SrvThread::Main() + 0x17 bytes p:\mes programmes\shared\sthread.cpp (17): TestsTLS-11.exe!SThread::Run() + 0xE bytes f:\dd\vctools\crt\crtw32\startup\threadex.c (359): TestsTLS-11.exe!_threadstartex() or another example : Detected memory leaks! Dumping objects -> {7105} normal block at 0x00484A40, 8 bytes long. Data: < > 00 00 00 00 01 00 00 00 {5112} normal block at 0x004601D8, 12 bytes long. Data: < F hE > 08 00 46 00 00 00 00 00 68 45 01 00 {5110} normal block at 0x0045FEC0, 64 bytes long. Data: < F > D8 01 46 00 00 00 00 00 00 00 00 00 00 00 00 00 {5109} normal block at 0x0045FE20, 96 bytes long. Data: < E @ P ` P > C0 FE 45 00 40 D3 50 01 60 D3 50 01 08 00 00 00 {5108} normal block at 0x00460008, 400 bytes long. Data: < > 00 00 00 00 08 19 00 00 00 00 00 00 00 00 00 00 Object dump complete. WARNING: Visual Leak Detector detected memory leaks! ---------- Block 5097 at 0x0045FE20: 96 bytes ---------- Leak Hash: 0xB3142E7A, Count: 1, Total 96 bytes Call Stack (TID 6396): ntdll.dll!RtlAllocateHeap() f:\dd\vctools\crt\crtw32\misc\dbgmalloc.c (56): TestsTLS-11.exe!malloc() + 0x15 bytes e:\openssl-1.1.git\crypto\mem.c (138): TestsTLS-11.exe!CRYPTO_malloc() + 0x9 bytes e:\openssl-1.1.git\crypto\mem.c (158): TestsTLS-11.exe!CRYPTO_zalloc() + 0x11 bytes e:\openssl-1.1.git\crypto\lhash\lhash.c (116): TestsTLS-11.exe!lh_new() + 0xB bytes e:\openssl-1.1.git\crypto\err\err_lcl.h (2): TestsTLS-11.exe!lh_ERR_STATE_new() + 0x10 bytes e:\openssl-1.1.git\crypto\err\err.c (321): TestsTLS-11.exe!int_thread_get() + 0xF bytes e:\openssl-1.1.git\crypto\err\err.c (369): TestsTLS-11.exe!int_thread_set_item() + 0x9 bytes e:\openssl-1.1.git\crypto\err\err.c (884): TestsTLS-11.exe!ERR_get_state() + 0xC bytes e:\openssl-1.1.git\crypto\err\err.c (598): TestsTLS-11.exe!ERR_clear_error() + 0x5 bytes e:\openssl-1.1.git\ssl\statem\statem.c (279): TestsTLS-11.exe!state_machine() e:\openssl-1.1.git\ssl\statem\statem.c (217): TestsTLS-11.exe!ossl_statem_connect() + 0xB bytes e:\openssl-1.1.git\ssl\ssl_lib.c (2908): TestsTLS-11.exe!SSL_do_handshake() + 0xC bytes p:\mes programmes\shared\ocrypto-11\tls.cpp (953): TestsTLS-11.exe!OTLS::TLSSss::DoHandshake() + 0xC bytes p:\mes programmes\tests\_testsshared\teststls-11\clttasks.cpp (64): TestsTLS-11.exe!CltThread::Main() + 0xB bytes p:\mes programmes\shared\sthread.cpp (17): TestsTLS-11.exe!SThread::Run() + 0xE bytes f:\dd\vctools\crt\crtw32\startup\threadex.c (359): TestsTLS-11.exe!_threadstartex() ---------- Block 5098 at 0x0045FEC0: 64 bytes ---------- Leak Hash: 0xDF96285B, Count: 1, Total 64 bytes Call Stack (TID 6396): ntdll.dll!RtlAllocateHeap() f:\dd\vctools\crt\crtw32\misc\dbgmalloc.c (56): TestsTLS-11.exe!malloc() + 0x15 bytes e:\openssl-1.1.git\crypto\mem.c (138): TestsTLS-11.exe!CRYPTO_malloc() + 0x9 bytes e:\openssl-1.1.git\crypto\mem.c (158): TestsTLS-11.exe!CRYPTO_zalloc() + 0x11 bytes e:\openssl-1.1.git\crypto\lhash\lhash.c (118): TestsTLS-11.exe!lh_new() + 0xB bytes e:\openssl-1.1.git\crypto\err\err_lcl.h (2): TestsTLS-11.exe!lh_ERR_STATE_new() + 0x10 bytes e:\openssl-1.1.git\crypto\err\err.c (321): TestsTLS-11.exe!int_thread_get() + 0xF bytes e:\openssl-1.1.git\crypto\err\err.c (369): TestsTLS-11.exe!int_thread_set_item() + 0x9 bytes e:\openssl-1.1.git\crypto\err\err.c (884): TestsTLS-11.exe!ERR_get_state() + 0xC bytes e:\openssl-1.1.git\crypto\err\err.c (598): TestsTLS-11.exe!ERR_clear_error() + 0x5 bytes e:\openssl-1.1.git\ssl\statem\statem.c (279): TestsTLS-11.exe!state_machine() e:\openssl-1.1.git\ssl\statem\statem.c (217): TestsTLS-11.exe!ossl_statem_connect() + 0xB bytes e:\openssl-1.1.git\ssl\ssl_lib.c (2908): TestsTLS-11.exe!SSL_do_handshake() + 0xC bytes p:\mes programmes\shared\ocrypto-11\tls.cpp (953): TestsTLS-11.exe!OTLS::TLSSss::DoHandshake() + 0xC bytes p:\mes programmes\tests\_testsshared\teststls-11\clttasks.cpp (64): TestsTLS-11.exe!CltThread::Main() + 0xB bytes p:\mes programmes\shared\sthread.cpp (17): TestsTLS-11.exe!SThread::Run() + 0xE bytes f:\dd\vctools\crt\crtw32\startup\threadex.c (359): TestsTLS-11.exe!_threadstartex() ---------- Block 5096 at 0x00460008: 400 bytes ---------- Leak Hash: 0xC49DE418, Count: 1, Total 400 bytes Call Stack (TID 6408): ntdll.dll!RtlAllocateHeap() f:\dd\vctools\crt\crtw32\misc\dbgmalloc.c (56): TestsTLS-11.exe!malloc() + 0x15 bytes e:\openssl-1.1.git\crypto\mem.c (138): TestsTLS-11.exe!CRYPTO_malloc() + 0x9 bytes e:\openssl-1.1.git\crypto\err\err.c (874): TestsTLS-11.exe!ERR_get_state() + 0xE bytes e:\openssl-1.1.git\crypto\err\err.c (598): TestsTLS-11.exe!ERR_clear_error() + 0x5 bytes e:\openssl-1.1.git\ssl\statem\statem.c (279): TestsTLS-11.exe!state_machine() e:\openssl-1.1.git\ssl\statem\statem.c (222): TestsTLS-11.exe!ossl_statem_accept() + 0xB bytes e:\openssl-1.1.git\ssl\ssl_lib.c (2908): TestsTLS-11.exe!SSL_do_handshake() + 0xC bytes p:\mes programmes\shared\ocrypto-11\tls.cpp (953): TestsTLS-11.exe!OTLS::TLSSss::DoHandshake() + 0xC bytes p:\mes programmes\tests\_testsshared\teststls-11\srvtasks.cpp (79): TestsTLS-11.exe!SrvThread::Main() + 0xB bytes p:\mes programmes\shared\sthread.cpp (17): TestsTLS-11.exe!SThread::Run() + 0xE bytes f:\dd\vctools\crt\crtw32\startup\threadex.c (359): TestsTLS-11.exe!_threadstartex() ---------- Block 5100 at 0x004601D8: 12 bytes ---------- Leak Hash: 0x8F14E2A9, Count: 1, Total 12 bytes Call Stack (TID 6408): ntdll.dll!RtlAllocateHeap() f:\dd\vctools\crt\crtw32\misc\dbgmalloc.c (56): TestsTLS-11.exe!malloc() + 0x15 bytes e:\openssl-1.1.git\crypto\mem.c (138): TestsTLS-11.exe!CRYPTO_malloc() + 0x9 bytes e:\openssl-1.1.git\crypto\lhash\lhash.c (168): TestsTLS-11.exe!lh_insert() + 0xB bytes e:\openssl-1.1.git\crypto\err\err_lcl.h (2): TestsTLS-11.exe!lh_ERR_STATE_insert() + 0x10 bytes e:\openssl-1.1.git\crypto\err\err.c (371): TestsTLS-11.exe!int_thread_set_item() + 0xD bytes e:\openssl-1.1.git\crypto\err\err.c (884): TestsTLS-11.exe!ERR_get_state() + 0xC bytes e:\openssl-1.1.git\crypto\err\err.c (598): TestsTLS-11.exe!ERR_clear_error() + 0x5 bytes e:\openssl-1.1.git\ssl\statem\statem.c (279): TestsTLS-11.exe!state_machine() e:\openssl-1.1.git\ssl\statem\statem.c (222): TestsTLS-11.exe!ossl_statem_accept() + 0xB bytes e:\openssl-1.1.git\ssl\ssl_lib.c (2908): TestsTLS-11.exe!SSL_do_handshake() + 0xC bytes p:\mes programmes\shared\ocrypto-11\tls.cpp (953): TestsTLS-11.exe!OTLS::TLSSss::DoHandshake() + 0xC bytes p:\mes programmes\tests\_testsshared\teststls-11\srvtasks.cpp (79): TestsTLS-11.exe!SrvThread::Main() + 0xB bytes p:\mes programmes\shared\sthread.cpp (17): TestsTLS-11.exe!SThread::Run() + 0xE bytes f:\dd\vctools\crt\crtw32\startup\threadex.c (359): TestsTLS-11.exe!_threadstartex() ---------- Block 7093 at 0x00484A40: 8 bytes ---------- Leak Hash: 0x160A9734, Count: 1, Total 8 bytes Call Stack (TID 6408): ntdll.dll!RtlAllocateHeap() f:\dd\vctools\crt\crtw32\misc\dbgmalloc.c (56): TestsTLS-11.exe!malloc() + 0x15 bytes e:\openssl-1.1.git\crypto\mem.c (138): TestsTLS-11.exe!CRYPTO_malloc() + 0x9 bytes e:\openssl-1.1.git\crypto\mem.c (158): TestsTLS-11.exe!CRYPTO_zalloc() + 0x11 bytes e:\openssl-1.1.git\crypto\init.c (198): TestsTLS-11.exe!ossl_init_get_thread_local() + 0xB bytes e:\openssl-1.1.git\crypto\init.c (512): TestsTLS-11.exe!ossl_init_thread_start() + 0x7 bytes e:\openssl-1.1.git\crypto\err\err.c (898): TestsTLS-11.exe!ERR_get_state() + 0x9 bytes e:\openssl-1.1.git\crypto\err\err.c (598): TestsTLS-11.exe!ERR_clear_error() + 0x5 bytes e:\openssl-1.1.git\ssl\statem\statem.c (279): TestsTLS-11.exe!state_machine() e:\openssl-1.1.git\ssl\statem\statem.c (222): TestsTLS-11.exe!ossl_statem_accept() + 0xB bytes e:\openssl-1.1.git\ssl\ssl_lib.c (2908): TestsTLS-11.exe!SSL_do_handshake() + 0xC bytes p:\mes programmes\shared\ocrypto-11\tls.cpp (953): TestsTLS-11.exe!OTLS::TLSSss::DoHandshake() + 0xC bytes p:\mes programmes\tests\_testsshared\teststls-11\srvtasks.cpp (79): TestsTLS-11.exe!SrvThread::Main() + 0xB bytes p:\mes programmes\shared\sthread.cpp (17): TestsTLS-11.exe!SThread::Run() + 0xE bytes f:\dd\vctools\crt\crtw32\startup\threadex.c (359): TestsTLS-11.exe!_threadstartex() -----Message d'origine----- De?: openssl-dev [mailto:openssl-dev-bounces at openssl.org] De la part de Matt Caswell Envoy??: mardi 16 f?vrier 2016 00:15 ??: openssl-dev at openssl.org Objet?: Re: [openssl-dev] memory leaks detected using libSSL 1.1 Are you linking to OpenSSL statically? Please see the "Notes" section on this page: https://www.openssl.org/docs/manmaster/crypto/OPENSSL_atexit.html Matt From sms at antinode.info Wed Feb 17 01:15:01 2016 From: sms at antinode.info (Steven M. Schweda) Date: Tue, 16 Feb 2016 19:15:01 -0600 (CST) Subject: [openssl-dev] OpenSSL version 1.1.0 pre release 3 v. VMS Message-ID: <16021619150191_20205A47@antinode.info> From: Richard Levitte > sms> Configuring for vms-alpha > sms> %DCL-W-MAXPARM, too many parameters - reenter command with fewer parameters > sms> \2\ > > Yeah, that one is entirely harmless (and known). Ok. > sms> Apparently, the test for "--prefix" is case-sensitive, and DCL can't > sms> be trusted. Quotation helps: > sms> > sms> ALP $ @ config.com "--prefix=ALP$DKC100:[UTILITY.SOURCE.OPENSSL.1_1_0-pre3]" > sms> [...] > > You're running with the extended parsing style, aren't you? I always > forget that possibility ... Of course. Isn't everyone? > sms> Installation fails, however: > sms> > sms> ALP $ mms install > sms> > sms> *** Installing development files > sms> CREATE/DIR ossl_installroot:[include.openssl] > sms> COPY/PROT=W:R openssl:*.h ossl_installroot:[include.openssl] > sms> %COPY-F-OPENIN, error opening openssl:*.h as input > sms> -RMS-F-FNM, error in file name > sms> %MMS-F-ABORT, For target INSTALL_DEV, CLI returned abort status: %X1067109C. > sms> ALP $ > sms> > sms> I haven't yet looked into that one. > > When looking into it, I suggest you do so with > mms/macro="NODEBUG=""""", that'll display the temporary logicals that > get created under the hood. (fair warning, it's not the most elegant > coding) I'll see if I can work up some ambition. Before it died, the installation procedure seemed to create a new/strange/bad directory for the header files: Directory ALP$DKC100:[UTILITY.SOURCE.OPENSSL.1_1_0-pre3.include.openssl] aes.h;1 11 15-FEB-2016 20:33:03.39 (RWED,RWED,RE,R) [...] The [.openssl] subdirectory looks new (and undesirable). (And, nothing beyond the header files got installed.) ------------------------------------------------------------------------ Steven M. Schweda sms at antinode-info 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 From levitte at openssl.org Wed Feb 17 01:50:24 2016 From: levitte at openssl.org (Richard Levitte) Date: Wed, 17 Feb 2016 02:50:24 +0100 (CET) Subject: [openssl-dev] OpenSSL version 1.1.0 pre release 3 v. VMS In-Reply-To: <16021619150191_20205A47@antinode.info> References: <16021619150191_20205A47@antinode.info> Message-ID: <20160217.025024.1991899478188225830.levitte@openssl.org> In message <16021619150191_20205A47 at antinode.info> on Tue, 16 Feb 2016 19:15:01 -0600 (CST), "Steven M. Schweda" said: sms> From: Richard Levitte sms> sms> > sms> Configuring for vms-alpha sms> > sms> %DCL-W-MAXPARM, too many parameters - reenter command with fewer parameters sms> > sms> \2\ sms> > sms> > Yeah, that one is entirely harmless (and known). sms> sms> Ok. sms> sms> > sms> Apparently, the test for "--prefix" is case-sensitive, and DCL can't sms> > sms> be trusted. Quotation helps: sms> > sms> sms> > sms> ALP $ @ config.com "--prefix=ALP$DKC100:[UTILITY.SOURCE.OPENSSL.1_1_0-pre3]" sms> > sms> [...] sms> > sms> > You're running with the extended parsing style, aren't you? I always sms> > forget that possibility ... sms> sms> Of course. Isn't everyone? Nope. I'm a traditional kinda guy in that regard ;-) (frankly, I've been away from the VMS scene for a chunk of years. I do recall the parsing style thing, but that was fairly new back then and nothing I cared about too much... I may learn to like it soon enough, just let me catch my breath a bit first while I catch up ;-)) sms> > sms> Installation fails, however: sms> > sms> sms> > sms> ALP $ mms install sms> > sms> sms> > sms> *** Installing development files sms> > sms> CREATE/DIR ossl_installroot:[include.openssl] sms> > sms> COPY/PROT=W:R openssl:*.h ossl_installroot:[include.openssl] sms> > sms> %COPY-F-OPENIN, error opening openssl:*.h as input sms> > sms> -RMS-F-FNM, error in file name sms> > sms> %MMS-F-ABORT, For target INSTALL_DEV, CLI returned abort status: %X1067109C. sms> > sms> ALP $ sms> > sms> sms> > sms> I haven't yet looked into that one. sms> > sms> > When looking into it, I suggest you do so with sms> > mms/macro="NODEBUG=""""", that'll display the temporary logicals that sms> > get created under the hood. (fair warning, it's not the most elegant sms> > coding) sms> sms> I'll see if I can work up some ambition. Before it died, the sms> installation procedure seemed to create a new/strange/bad directory for sms> the header files: sms> sms> Directory ALP$DKC100:[UTILITY.SOURCE.OPENSSL.1_1_0-pre3.include.openssl] sms> sms> aes.h;1 11 15-FEB-2016 20:33:03.39 (RWED,RWED,RE,R) sms> [...] sms> sms> The [.openssl] subdirectory looks new (and undesirable). (And, sms> nothing beyond the header files got installed.) That's perfectly intentional and correct. The day there comes a compiler that knows how to concatenate directories properly (the fact that DECompHP C doesn't know how to do that is beyond me and one of my pet peve among many with that compiler), I certainly want for anyone to be able to say something like: /INCLUDE=ALP$DKC100:[UTILITY.SOURCE.OPENSSL.1_1_0-pre3.include] or possibly: /INCLUDE=ALP$DKC100:[UTILITY.SOURCE.OPENSSL.1_1_0-pre3.include.] and the compiler will know exactly what to do with something like this without having to define a logical name: #include The current need to have a logical name (such as OPENSSL:) for every such inclusion directory is a formidable pain in the nether regions. So yeah, there's meaning with that layout. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From rajesh_seetharam at thbs.com Wed Feb 17 03:48:50 2016 From: rajesh_seetharam at thbs.com (rajesh_seetharam at thbs.com) Date: Wed, 17 Feb 2016 09:18:50 +0530 (IST) Subject: [openssl-dev] OpenSSL Message-ID: <1455680930.02459675@webmail.thbs.com> Dear Team We have installed httpd-2.2.25-win32-x86-openssl-0.9.8y apache web server which has openssl .9.8y as a part of the package, we ran the vulnerability scan for the same The system admin team has suggested to upgrade openssl 0.9.8zb, how do we go about it? We have used openssl to generate the server key and csr for ssl certificate installation and the ssl certificate certificate has been successfully installed. After upgrading to the openssl 0.9.8zb, should we regenerate the server key and csr and reinstall the ssl certificate.. What is the advantage of using openssl 0.9.8zb over openssl-0.9.8y Regards Rajesh ******* DISCLAIMER: This email and any files transmitted with it are privileged and confidential information and intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Torry Harris Business Solutions has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. The recipient should check this email and any attachments for the presence of viruses. THBS reserves the right to monitor and review the content of all messages sent to or from this e-mail address******** ******* DISCLAIMER: This email and any files transmitted with it are privileged and confidential information and intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Torry Harris Business Solutions has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. The recipient should check this email and any attachments for the presence of viruses. THBS reserves the right to monitor and review the content of all messages sent to or from this e-mail address.******** -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Wed Feb 17 03:56:41 2016 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 17 Feb 2016 03:56:41 +0000 Subject: [openssl-dev] OpenSSL In-Reply-To: <1455680930.02459675@webmail.thbs.com> References: <1455680930.02459675@webmail.thbs.com> Message-ID: You should not run 0.9.8, any version. It is old, has known security bugs, and is end of life. Go to the website, click on download, and get a recent version. From beldmit at gmail.com Wed Feb 17 08:04:34 2016 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Wed, 17 Feb 2016 11:04:34 +0300 Subject: [openssl-dev] [openssl-users] OpenSSL version 1.1.0 pre release 3 published In-Reply-To: <5676344ef8684de0b44603b528127657@ustx2ex-dag1mb1.msg.corp.akamai.com> References: <20160215190420.GA12045@openssl.org> <5676344ef8684de0b44603b528127657@ustx2ex-dag1mb1.msg.corp.akamai.com> Message-ID: Dear Rich, > Just to emphasize one important point: Our next release is planned to be > Beta-1, in about a month. After that, no new API's or features will be > added to OpenSSL 1.1 > > If so, could you take a look at RT#4267? Thank you! -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From j at w1.fi Wed Feb 17 09:35:35 2016 From: j at w1.fi (Jouni Malinen) Date: Wed, 17 Feb 2016 11:35:35 +0200 Subject: [openssl-dev] OpenSSL 1.1.0 and OCSP stapling with status_request_v2 (RFC 6961) Message-ID: <20160217093535.GA4017@w1.fi> It looks like there are some upcoming use cases that would need to be able to use OCSP stapling to verify both the server certificate and the intermediate CA certificate that issued that server certificate. This would require support for RFC 6961 extensions to OCSP stapling. Since the actual OCSP stapling processing is currently done outside the OpenSSL library, the changes to allow this to be used on the TLS client side would be pretty minimal for the library. The current API does not allow this to be done since the SSL_set_tlsext_status_type() function allows only one value (TLSEXT_STATUSTYPE_ocsp = 1) to be used. It would be nice if OpenSSL 1.1.0 would make it possible to use the ocsp_multi(2) value in status_request_v2(17) ClientHello extension. Other than the different extension type and status type values (and listing both ocsp and ocsp_multi types), the contents on that extension is identical to the existing status_request case. Since the OCSP stapling response is processed outside the library handshake processing, a minimal support for this within OpenSSL would not need other changes there than just accepting ocsp_multi(2) in addition to the current TLSEXT_STATUSTYPE_ocsp(1). More could obviously be added later to help parsing in applications, but that is not critical for OpenSSL 1.1.0 to enable this functionality. Would there be interest in getting at least the minimal changes in place before the beta release so that OpenSSL 1.1.0 could be used to implement ocsp_multi support for TLS client? As far as the TLS messages are concerned, these are the changes needed for the use cases I'm thinking of: Building ClientHello: Add status_request_v2 extension with minimal contents: 00 11 00 07 00 05 02 00 00 00 00 This is very similar to status_request extension that can currently be added: 00 05 00 05 01 00 00 00 00 Parsing ServerHello: Accept status_request_v2 extension Parsing CertificateStatus: Accept certificate status type ocsp_multi(2) -- Jouni Malinen PGP id EFC895FA From rt at openssl.org Wed Feb 17 09:42:16 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Wed, 17 Feb 2016 09:42:16 +0000 Subject: [openssl-dev] [openssl.org #4267] Missing accessor to the EVP_CIPHER_CTX member oiv In-Reply-To: References: Message-ID: Hi, I'm sorry, the oiv field is EVP private. Sure, it's been accessible (and thoroughly misused in some cases) when EVP_CIPHER_CTX was open, but in essence, it's a EVP private store of the IV that was given at EVP_CipherInit(). If you want to retain a copy of the original IV, I suggest you have one in GOSTs structure and take a copy of the IV given to the init() function. Thank you for the reminder, I meant to deal with this further. oiv should really not be publically accessible at all, not even as a constant. Cheers, Richard Vid Sat, 23 Jan 2016 kl. 09.40.19, skrev beldmit at gmail.com: > Hello, > > After making the EVP_CIPHER_CTX struct opaque I found that there is a > missing non-const accessor to the oiv member. It is used in GOST engine > when we set the cipher parameters from the ASN1 parameters. > > Thank you! > -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4267 Please log in as guest with password guest if prompted From beldmit at gmail.com Wed Feb 17 09:52:46 2016 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Wed, 17 Feb 2016 12:52:46 +0300 Subject: [openssl-dev] [openssl.org #4267] Missing accessor to the EVP_CIPHER_CTX member oiv In-Reply-To: References: Message-ID: Dear Richard, I am not sure it will not break the compatibility. Both implementations of the GOST ciphers require access to this field. On Wed, Feb 17, 2016 at 12:42 PM, Richard Levitte via RT wrote: > Hi, > > I'm sorry, the oiv field is EVP private. Sure, it's been accessible (and > thoroughly misused in some cases) when EVP_CIPHER_CTX was open, but in > essence, > it's a EVP private store of the IV that was given at EVP_CipherInit(). > > If you want to retain a copy of the original IV, I suggest you have one in > GOSTs structure and take a copy of the IV given to the init() function. > > Thank you for the reminder, I meant to deal with this further. oiv should > really not be publically accessible at all, not even as a constant. > > Cheers, > Richard > > Vid Sat, 23 Jan 2016 kl. 09.40.19, skrev beldmit at gmail.com: > > Hello, > > > > After making the EVP_CIPHER_CTX struct opaque I found that there is a > > missing non-const accessor to the oiv member. It is used in GOST engine > > when we set the cipher parameters from the ASN1 parameters. > > > > Thank you! > > > > > -- > Richard Levitte > levitte at openssl.org > > -- > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4267 > Please log in as guest with password guest if prompted > > -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Wed Feb 17 09:53:04 2016 From: rt at openssl.org (Dmitry Belyavsky via RT) Date: Wed, 17 Feb 2016 09:53:04 +0000 Subject: [openssl-dev] [openssl.org #4267] Missing accessor to the EVP_CIPHER_CTX member oiv In-Reply-To: References: Message-ID: Dear Richard, I am not sure it will not break the compatibility. Both implementations of the GOST ciphers require access to this field. On Wed, Feb 17, 2016 at 12:42 PM, Richard Levitte via RT wrote: > Hi, > > I'm sorry, the oiv field is EVP private. Sure, it's been accessible (and > thoroughly misused in some cases) when EVP_CIPHER_CTX was open, but in > essence, > it's a EVP private store of the IV that was given at EVP_CipherInit(). > > If you want to retain a copy of the original IV, I suggest you have one in > GOSTs structure and take a copy of the IV given to the init() function. > > Thank you for the reminder, I meant to deal with this further. oiv should > really not be publically accessible at all, not even as a constant. > > Cheers, > Richard > > Vid Sat, 23 Jan 2016 kl. 09.40.19, skrev beldmit at gmail.com: > > Hello, > > > > After making the EVP_CIPHER_CTX struct opaque I found that there is a > > missing non-const accessor to the oiv member. It is used in GOST engine > > when we set the cipher parameters from the ASN1 parameters. > > > > Thank you! > > > > > -- > Richard Levitte > levitte at openssl.org > > -- > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4267 > Please log in as guest with password guest if prompted > > -- SY, Dmitry Belyavsky -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4267 Please log in as guest with password guest if prompted From rt at openssl.org Wed Feb 17 11:25:27 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Wed, 17 Feb 2016 11:25:27 +0000 Subject: [openssl-dev] [openssl.org #4267] Missing accessor to the EVP_CIPHER_CTX member oiv In-Reply-To: References: Message-ID: May I suggest that you use EVP_CIPHER_set_asn1_iv() and/or EVP_CIPHER_get_asn1_iv()? With a temporary ASN1_TYPE to which you assign gcp->iv, that should be perfectly possible, no? Cheers, Richard Vid Ons, 17 Feb 2016 kl. 09.53.04, skrev beldmit at gmail.com: > Dear Richard, > > I am not sure it will not break the compatibility. > Both implementations of the GOST ciphers require access to this field. > > On Wed, Feb 17, 2016 at 12:42 PM, Richard Levitte via RT > wrote: > > > Hi, > > > > I'm sorry, the oiv field is EVP private. Sure, it's been accessible (and > > thoroughly misused in some cases) when EVP_CIPHER_CTX was open, but in > > essence, > > it's a EVP private store of the IV that was given at EVP_CipherInit(). > > > > If you want to retain a copy of the original IV, I suggest you have one in > > GOSTs structure and take a copy of the IV given to the init() function. > > > > Thank you for the reminder, I meant to deal with this further. oiv should > > really not be publically accessible at all, not even as a constant. > > > > Cheers, > > Richard > > > > Vid Sat, 23 Jan 2016 kl. 09.40.19, skrev beldmit at gmail.com: > > > Hello, > > > > > > After making the EVP_CIPHER_CTX struct opaque I found that there is a > > > missing non-const accessor to the oiv member. It is used in GOST engine > > > when we set the cipher parameters from the ASN1 parameters. > > > > > > Thank you! > > > > > > > > > -- > > Richard Levitte > > levitte at openssl.org > > > > -- > > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4267 > > Please log in as guest with password guest if prompted > > > > > > -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4267 Please log in as guest with password guest if prompted From dwmw2 at infradead.org Wed Feb 17 11:51:53 2016 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 17 Feb 2016 11:51:53 +0000 Subject: [openssl-dev] [openssl.org #4175] Add new macro or PKCS7 flag to disable the check for both data and content In-Reply-To: References: Message-ID: <1455709913.4832.244.camel@infradead.org> On Tue, 2015-12-08 at 12:56 +0000, Salz, Rich via RT wrote: > I think that instead of the #ifdef being removed, the if() test > should be removed. This was my mistake. Like this, then...? https://github.com/openssl/openssl/pull/694?for HEAD https://github.com/openssl/openssl/pull/695?for 1.0.2 If you say that removing the #ifdef instead of removing the whole code block that it contained was a mistake, then I shall take you at your word and refrain from harping on *too* much about how naughty it was to have a functional change hidden away in a commit which simply entitled itself "Memory leak fixes", without even any acknowledgement of the change in the body of the commit comment :) -- David Woodhouse Open Source Technology Centre David.Woodhouse at intel.com Intel Corporation -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-RT4175-Fix-regression-using-PKCS7_verify-with-Authen.patch Type: text/x-patch Size: 1614 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5691 bytes Desc: not available URL: From rt at openssl.org Wed Feb 17 11:52:04 2016 From: rt at openssl.org (David Woodhouse via RT) Date: Wed, 17 Feb 2016 11:52:04 +0000 Subject: [openssl-dev] [openssl.org #4175] Add new macro or PKCS7 flag to disable the check for both data and content In-Reply-To: <1455709913.4832.244.camel@infradead.org> References: <1455709913.4832.244.camel@infradead.org> Message-ID: On Tue, 2015-12-08 at 12:56 +0000, Salz, Rich via RT wrote: > I think that instead of the #ifdef being removed, the if() test > should be removed. This was my mistake. Like this, then...? https://github.com/openssl/openssl/pull/694?for HEAD https://github.com/openssl/openssl/pull/695?for 1.0.2 If you say that removing the #ifdef instead of removing the whole code block that it contained was a mistake, then I shall take you at your word and refrain from harping on *too* much about how naughty it was to have a functional change hidden away in a commit which simply entitled itself "Memory leak fixes", without even any acknowledgement of the change in the body of the commit comment :) -- David Woodhouse Open Source Technology Centre David.Woodhouse at intel.com Intel Corporation -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4175 Please log in as guest with password guest if prompted -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-RT4175-Fix-regression-using-PKCS7_verify-with-Authen.patch Type: text/x-patch Size: 1615 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5691 bytes Desc: not available URL: From rt at openssl.org Wed Feb 17 13:45:22 2016 From: rt at openssl.org (David Woodhouse via RT) Date: Wed, 17 Feb 2016 13:45:22 +0000 Subject: [openssl-dev] [openssl.org #4313] [PATCH] Fix build for !IMPLEMENTED code path in CRYPTO_secure_free() In-Reply-To: <1455716711.4735.0.camel@infradead.org> References: <1455716711.4735.0.camel@infradead.org> Message-ID: Commit 05c7b1631 ("Implement the use of heap manipulator implementions") added 'file' and 'line' arguments to CRYPTO_free() and friends, but neglected to fix up the !IMPLEMENTED case within CRYPTO_secure_free(). Add the missing arguments there too. --- ?crypto/mem_sec.c | 2 +- ?1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/crypto/mem_sec.c b/crypto/mem_sec.c index be3bb9a..fdda487 100644 --- a/crypto/mem_sec.c +++ b/crypto/mem_sec.c @@ -138,7 +138,7 @@ void CRYPTO_secure_free(void *ptr, const char *file, int line) ?????sh_free(ptr); ?????UNLOCK(); ?#else -????CRYPTO_free(ptr); +????CRYPTO_free(ptr, file, line); ?#endif /* IMPLEMENTED */ ?} ? --? 2.5.0 -- David Woodhouse Open Source Technology Centre David.Woodhouse at intel.com Intel Corporation -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4313 Please log in as guest with password guest if prompted -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5691 bytes Desc: not available URL: From rsalz at akamai.com Wed Feb 17 13:47:28 2016 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 17 Feb 2016 13:47:28 +0000 Subject: [openssl-dev] OpenSSL 1.1.0 and OCSP stapling with status_request_v2 (RFC 6961) In-Reply-To: <20160217093535.GA4017@w1.fi> References: <20160217093535.GA4017@w1.fi> Message-ID: <5ce33cbc9e634026ac8a85951e3abd47@ustx2ex-dag1mb1.msg.corp.akamai.com> A GitHub Pull Request to do this would be very helpful. We have a month and the team is busy... From rt at openssl.org Wed Feb 17 13:52:55 2016 From: rt at openssl.org (Kiyoshi KANAZAWA via RT) Date: Wed, 17 Feb 2016 13:52:55 +0000 Subject: [openssl-dev] [openssl.org #4314] openssl-1.1.0-pre3 make error on Solaris 10 x86 In-Reply-To: <296003.71230.qm@web101203.mail.kks.yahoo.co.jp> References: <296003.71230.qm@web101203.mail.kks.yahoo.co.jp> Message-ID: Hello, Openssl-1.1.0-pre3 make fails on Solaris 10 x86, such as make[2]: Entering directory '/tmp/openssl-1.1.0-pre3/crypto/bio' gcc -I.. -I../.. -I../modes -I../include -I../../include? -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_T HREADS -DOPENSSL_PIC -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPE NSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_A SM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/local/ssl\"" -DENGINESDIR= "\"/usr/local/lib/engines\"" -fPIC? -pthread -DFILIO_H -O3 -fomit-frame-pointer -DWHIRLPOOL_ASM ? -c -o bss_fd.o bss_fd.c bio_lcl.h:60:24: error: expected identifier or '(' before numeric constant ???? struct sockaddr_un sun; ??????????????????????? ^ In file included from bss_fd.c:61:0: bio_lcl.h:62:1: warning: no semicolon at end of struct or union [enabled by default] ?}; This happens because "sun" is #defined as 1 on Solaris. On the other hand, the same name is used in crypto/bio/bio_lcl.h, ??? 53? union bio_addr_st { ??? 54????? struct sockaddr sa; ??? 55? # ifdef AF_INET6 ??? 56????? struct sockaddr_in6 sin6; ??? 57? # endif ??? 58????? struct sockaddr_in sin; ??? 59? # ifdef AF_UNIX ??? 60????? struct sockaddr_un sun; ??? 61? # endif ??? 62? }; ??? 63? #endif Best regards, --- Kiyoshi -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4314 Please log in as guest with password guest if prompted From rt at openssl.org Wed Feb 17 14:04:23 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Wed, 17 Feb 2016 14:04:23 +0000 Subject: [openssl-dev] [openssl.org #4175] Add new macro or PKCS7 flag to disable the check for both data and content In-Reply-To: <26207f6faf354c4e9d10bfbd8a1f8c8e@ustx2ex-dag1mb1.msg.corp.akamai.com> References: <1455709913.4832.244.camel@infradead.org> <26207f6faf354c4e9d10bfbd8a1f8c8e@ustx2ex-dag1mb1.msg.corp.akamai.com> Message-ID: > If you say that removing the #ifdef instead of removing the whole code block > that it contained was a mistake, then I shall take you at your word and refrain > from harping on *too* much about how naughty it was to have a functional > change hidden away in a commit which simply entitled itself "Memory leak > fixes", without even any acknowledgement of the change in the body of the > commit comment :) Feel free to dock my pay :) Looks good. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4175 Please log in as guest with password guest if prompted From rt at openssl.org Wed Feb 17 14:19:14 2016 From: rt at openssl.org (Rich Salz via RT) Date: Wed, 17 Feb 2016 14:19:14 +0000 Subject: [openssl-dev] [openssl.org #4314] openssl-1.1.0-pre3 make error on Solaris 10 x86 In-Reply-To: <296003.71230.qm@web101203.mail.kks.yahoo.co.jp> References: <296003.71230.qm@web101203.mail.kks.yahoo.co.jp> Message-ID: fixed in mater. commit 29620124ff1624af5411d8d2998fdd7b102a5d48 Author: Richard Levitte Date: Tue Feb 16 10:27:16 2016 +0100 On solaris, the variable name sun clashes, use s_un instead For orthogonality, we change sin -> s_in and sin6 -> s_in6 as well. Reviewed-by: Matt Caswell -- Rich Salz, OpenSSL dev team; rsalz at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4314 Please log in as guest with password guest if prompted From rt at openssl.org Wed Feb 17 14:31:46 2016 From: rt at openssl.org (Rich Salz via RT) Date: Wed, 17 Feb 2016 14:31:46 +0000 Subject: [openssl-dev] [openssl.org #4313] [PATCH] Fix build for !IMPLEMENTED code path in CRYPTO_secure_free() In-Reply-To: <1455716711.4735.0.camel@infradead.org> References: <1455716711.4735.0.camel@infradead.org> Message-ID: commit 6a78ae2821e89a8838714496524fd39d9d21fb1b is in master now, thanks! -- Rich Salz, OpenSSL dev team; rsalz at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4313 Please log in as guest with password guest if prompted From rt at openssl.org Wed Feb 17 14:56:48 2016 From: rt at openssl.org (Michele Cicciotti via RT) Date: Wed, 17 Feb 2016 14:56:48 +0000 Subject: [openssl-dev] [openssl.org #4316] Build failure with OPENSSL_NO_DES or OPENSSL_NO_AES defined In-Reply-To: <56C4885B.1090805@privatewave.com> References: <56C4885B.1090805@privatewave.com> Message-ID: Affected version: 1.0.2f crypto/cms/cms_kari.c calls EVP_des_ede3_wrap without checking whether OPENSSL_NO_DES is defined, and EVP_aes_XXX_wrap without checking if OPENSSL_NO_AES is defined. See the attached patch for the fix -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4316 Please log in as guest with password guest if prompted -------------- next part -------------- --- crypto/cms/cms_kari.c +++ crypto/cms/cms_kari.c @@ -402,13 +402,22 @@ * DES3 wrap otherwise use AES wrap similar to key size. */ if (EVP_CIPHER_type(cipher) == NID_des_ede3_cbc) +#ifdef OPENSSL_NO_DES + return 0; +#else kekcipher = EVP_des_ede3_wrap(); - else if (keylen <= 16) +#endif + else +#ifdef OPENSSL_NO_AES + return 0; +#else + if (keylen <= 16) kekcipher = EVP_aes_128_wrap(); else if (keylen <= 24) kekcipher = EVP_aes_192_wrap(); else kekcipher = EVP_aes_256_wrap(); +#endif return EVP_EncryptInit_ex(ctx, kekcipher, NULL, NULL, NULL); } From rt at openssl.org Wed Feb 17 14:56:47 2016 From: rt at openssl.org (David Woodhouse via RT) Date: Wed, 17 Feb 2016 14:56:47 +0000 Subject: [openssl-dev] [openssl.org #4315] [PATCH] Fix UEFI build in crypto/init.c In-Reply-To: <1455720995.4735.6.camel@infradead.org> References: <1455720995.4735.6.camel@infradead.org> Message-ID: We don't have atexit() in the EDK2 environment. Firmware never exits. --- ?crypto/init.c | 2 ++ ?1 file changed, 2 insertions(+) diff --git a/crypto/init.c b/crypto/init.c index 25e3dc7..c7eff8b 100644 --- a/crypto/init.c +++ b/crypto/init.c @@ -270,7 +270,9 @@ static void ossl_init_base(void) ?????fprintf(stderr, "OPENSSL_INIT: ossl_init_base: Setting up stop handlers\n"); ?#endif ?????ossl_init_setup_thread_stop(); +#ifndef OPENSSL_SYS_UEFI ?????atexit(OPENSSL_cleanup); +#endif ?????OPENSSL_cpuid_setup(); ?????base_inited = 1; ?} --? 2.5.0 -- David Woodhouse Open Source Technology Centre David.Woodhouse at intel.com Intel Corporation -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4315 Please log in as guest with password guest if prompted -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5691 bytes Desc: not available URL: From rt at openssl.org Wed Feb 17 15:07:10 2016 From: rt at openssl.org (Kiyoshi KANAZAWA via RT) Date: Wed, 17 Feb 2016 15:07:10 +0000 Subject: [openssl-dev] [openssl.org #4317] openssl-1.1.0-pre3 make error with Configure option "zlib-dynamic" In-Reply-To: <371612.13391.qm@web101209.mail.kks.yahoo.co.jp> References: <371612.13391.qm@web101209.mail.kks.yahoo.co.jp> Message-ID: Openssl-1.1.0-pre3 make fails with Configure option "zlib-dynamic". Without "zlib-dynamic", make & make check passed. With "zlib", make & make check also passed. Tried on Solaris10 x86, with #4314 fix. % ./Configure solaris-x86-gcc threads shared zlib-dynamic no-ssl3 % make ? : gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_THREADS -DOPENSSL_PIC -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DOPENSSLDIR="/opt/openssl/ssl" -DENGINESDIR="/opt/openssl/lib/engines" -fPIC -pthread -DFILIO_H -O3 -fomit-frame-pointer -DWHIRLPOOL_ASM -R /opt/openssl/lib -o openssl openssl.o asn1pars.o ca.o ciphers.o cms.o crl.o crl2p7.o dgst.o dhparam.o dsa.o dsaparam.o ec.o ecparam.o enc.o engine.o errstr.o gendsa.o genpkey.o genrsa.o nseq.o ocsp.o passwd.o pkcs12.o pkcs7.o pkcs8.o pkey.o pkeyparam.o pkeyutl.o prime.o rand.o req.o rsa.o rsautl.o s_client.o s_server.o s_time.o sess_id.o smime.o speed.o spkac.o srp.o ts.o verify.o version.o x509.o rehash.o apps.o opt.o s_cb.o s_socket.o app_rand.o -L.. -lssl -L.. -lcrypto -lsocket -lnsl -ldl Undefined?????????????????????? first referenced ?symbol???????????????????????????? in file BIO_f_zlib????????????????????????? ../libcrypto.so ld: fatal: symbol referencing errors. No output written to openssl collect2: error: ld returned 1 exit status ../Makefile.shared:412: recipe for target 'link_app.solaris' failed Best regards, --- Kiyoshi -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4317 Please log in as guest with password guest if prompted From rt at openssl.org Wed Feb 17 15:08:54 2016 From: rt at openssl.org (Rich Salz via RT) Date: Wed, 17 Feb 2016 15:08:54 +0000 Subject: [openssl-dev] [openssl.org #4315] [PATCH] Fix UEFI build in crypto/init.c In-Reply-To: <1455720995.4735.6.camel@infradead.org> References: <1455720995.4735.6.camel@infradead.org> Message-ID: Fixed in master with commit c7b7938 thank you! -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4315 Please log in as guest with password guest if prompted From rt at openssl.org Wed Feb 17 15:13:04 2016 From: rt at openssl.org (David Woodhouse via RT) Date: Wed, 17 Feb 2016 15:13:04 +0000 Subject: [openssl-dev] [openssl.org #4318] [PATCH] Fix OSSL_SSIZE_MAX for UEFI build In-Reply-To: <1455721971.4735.8.camel@infradead.org> References: <1455721971.4735.8.camel@infradead.org> Message-ID: Commit e634b448c ("Defines OSSL_SSIZE_MAX") introduced a definition of OSSL_SSIZE_MAX which broke the UEFI build. Fix that by making UEFI take the same definition as Ultrix (ssize_t == int). --- ?include/openssl/e_os2.h | 2 +- ?1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/openssl/e_os2.h b/include/openssl/e_os2.h index 1a1fe3e..8cf6c84 100644 --- a/include/openssl/e_os2.h +++ b/include/openssl/e_os2.h @@ -269,7 +269,7 @@ extern "C" { ?#??endif ?# endif ? -# if defined(__ultrix) && !defined(ssize_t) +# if (defined(__ultrix) || defined(OPENSSL_SYS_UEFI)) && !defined(ssize_t) ?#??define ossl_ssize_t int ?#??define OSSL_SSIZE_MAX INT_MAX ?# endif --? 2.5.0 -- David Woodhouse Open Source Technology Centre David.Woodhouse at intel.com Intel Corporation -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4318 Please log in as guest with password guest if prompted -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5691 bytes Desc: not available URL: From doctor at doctor.nl2k.ab.ca Wed Feb 17 15:23:00 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Wed, 17 Feb 2016 08:23:00 -0700 Subject: [openssl-dev] Openssl-SNAP-20160216 issues In-Reply-To: <20160216.104221.469775936406219219.levitte@openssl.org> References: <20160216090030.GA11685@doctor.nl2k.ab.ca> <20160216.104221.469775936406219219.levitte@openssl.org> Message-ID: <20160217152300.GA18074@doctor.nl2k.ab.ca> On Tue, Feb 16, 2016 at 10:42:21AM +0100, Richard Levitte wrote: > In message <20160216090030.GA11685 at doctor.nl2k.ab.ca> on Tue, 16 Feb 2016 02:00:30 -0700, The Doctor said: > > doctor> In the make test I am getting > doctor> > doctor> What can do to see why these tests are failing? > > You can do this: > > HARNESS_VERBOSE=yes make test > > Fair warning, that's a *lot* of output Just like openssl 1.0.X but it helps > > If you want to be selective, you can pick specific tests into the > TESTS variable, like this: > > HARNESS_VERBOSE=yes make test TESTS='tesl_ssl test_packet' > > The words in that variable are taken from the test recipes, it's the > {name} part in nn-{name}.t, so for the recipe file > ../test/recipes/70-test_clienthello.t, the name to put into the TESTS > variable is test_clienthello. > All right what about ../test/recipes/70-test_packet.t .......... 1..1 test_PACKET_buf_init() failed not ok 1 - running packettest # Failed test 'running packettest' # at ../test/testlib/OpenSSL/Test/Simple.pm line 70. # Looks like you failed 1 test of 1. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/70-test_sslcertstatus.t ... 1..1 Failed creating proxy socket (localhost,4453): Address already in use # Looks like your test exited with 48 before it could output anything. Dubious, test returned 48 (wstat 12288, 0x3000) Failed 1/1 subtests ../test/recipes/90-test_networking.t ...... 1..2 Proxy connection failed: Failed creating proxy socket (127.0.0.1,4453): Address already in use not ok 1 - Trying IPv4 # Failed test 'Trying IPv4' # at ../test/recipes/90-test_networking.t line 90. Proxy started on port 4453 Something seems to be stuck. > Cheers, > Richard > > -- > Richard Levitte levitte at openssl.org > OpenSSL Project http://www.openssl.org/~levitte/ > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Broadcasting the truth for 25 years From rt at openssl.org Wed Feb 17 15:40:31 2016 From: rt at openssl.org (Rich Salz via RT) Date: Wed, 17 Feb 2016 15:40:31 +0000 Subject: [openssl-dev] [openssl.org #4318] [PATCH] Fix OSSL_SSIZE_MAX for UEFI build In-Reply-To: <1455721971.4735.8.camel@infradead.org> References: <1455721971.4735.8.camel@infradead.org> Message-ID: checked into master at 21b80f9 thanks! -- Rich Salz, OpenSSL dev team; rsalz at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4318 Please log in as guest with password guest if prompted From matt at openssl.org Wed Feb 17 16:22:47 2016 From: matt at openssl.org (Matt Caswell) Date: Wed, 17 Feb 2016 16:22:47 +0000 Subject: [openssl-dev] memory leaks detected using libSSL 1.1 In-Reply-To: <006001d16911$5fd1a3b0$1f74eb10$@sales@free.fr> References: <000001d166ac$9660f640$c322e2c0$@sales@free.fr> <56BFBC88.1010901@openssl.org> <000001d166bc$308f5680$91ae0380$@sales@free.fr> <56C25BFD.3060708@openssl.org> <006001d16911$5fd1a3b0$1f74eb10$@sales@free.fr> Message-ID: <56C49E57.5060407@openssl.org> On 16/02/16 23:25, Michel wrote: > Hi Matt, > > Yes I am linking statically and I read the man about OPENSSL_init_crypto(), > thanks. > However I still have leaks reported. > :-( > > What I have changed to adapt to v1.1 is calling OPENSSL_thread_stop() in > each thread before it leaves, > instead of ERR_remove_thread_state( NULL ), > and I am calling OPENSSL_cleanup() before the main thread returns. > Am I missing anything else ? That should be sufficient (although the OPENSSL_cleanup() should not be required). You could try compiling OpenSSL with OPENSSL_INIT_DEBUG defined, e.g. perl Configure your-platform-here -DOPENSSL_INIT_DEBUG This should print out some debugging information to stderr every time the init functions attempt to do something interesting. In particular when you call OPENSSL_thread_stop() you should see the following printed out: OPENSSL_INIT: ossl_init_thread_stop: ERR_remove_thread_state(NULL) Matt > > Now I have 2 tests programs, almost identical, one is linked against v1.0.2 > and the other against v1.1. > The former (1.0.2) doesn't report any leak but the later (1.1) always report > leaks. > > I tried lots of modifications to the 1.1 version in order to understand what > is happening, > but the only thing I noticed is leaks occur if at some point the program go > to the OpenSSL error subsystem, > like in the 2 reports below. > > Can you please help in this matter ? > > Detected memory leaks! > Dumping objects -> > {7453} normal block at 0x00895440, 8 bytes long. > Data: < > 00 00 00 00 01 00 00 00 > {5460} normal block at 0x00871B98, 12 bytes long. > Data: < e > C8 19 87 00 00 00 00 00 B4 65 01 00 > {5459} normal block at 0x008719C8, 400 bytes long. > Data: < > 00 00 00 00 84 1B 00 00 00 00 00 00 00 00 00 00 > {5457} normal block at 0x00871900, 64 bytes long. > Data: < > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > {5455} normal block at 0x0086D7E8, 96 bytes long. > Data: < ` > 00 19 87 00 60 CB 05 01 80 CB 05 01 08 00 00 00 > Object dump complete. > > WARNING: Visual Leak Detector detected memory leaks! > ---------- Block 5450 at 0x0086D7E8: 96 bytes ---------- > Leak Hash: 0xE1A21867, Count: 1, Total 96 bytes > Call Stack (TID 6956): > ntdll.dll!RtlAllocateHeap() > f:\dd\vctools\crt\crtw32\misc\dbgmalloc.c (56): TestsTLS-11.exe!malloc() > + 0x15 bytes > e:\openssl-1.1.git\crypto\mem.c (138): TestsTLS-11.exe!CRYPTO_malloc() + > 0x9 bytes > e:\openssl-1.1.git\crypto\mem.c (158): TestsTLS-11.exe!CRYPTO_zalloc() + > 0x11 bytes > e:\openssl-1.1.git\crypto\lhash\lhash.c (116): TestsTLS-11.exe!lh_new() > + 0xB bytes > e:\openssl-1.1.git\crypto\err\err_lcl.h (2): > TestsTLS-11.exe!lh_ERR_STATE_new() + 0x10 bytes > e:\openssl-1.1.git\crypto\err\err.c (321): > TestsTLS-11.exe!int_thread_get() + 0xF bytes > e:\openssl-1.1.git\crypto\err\err.c (369): > TestsTLS-11.exe!int_thread_set_item() + 0x9 bytes > e:\openssl-1.1.git\crypto\err\err.c (884): > TestsTLS-11.exe!ERR_get_state() + 0xC bytes > e:\openssl-1.1.git\crypto\err\err.c (581): > TestsTLS-11.exe!ERR_put_error() + 0x5 bytes > e:\openssl-1.1.git\crypto\pem\pem_lib.c (702): > TestsTLS-11.exe!PEM_read_bio() + 0x15 bytes > e:\openssl-1.1.git\crypto\pem\pem_info.c (117): > TestsTLS-11.exe!PEM_X509_INFO_read_bio() + 0x19 bytes > e:\openssl-1.1.git\crypto\x509\by_file.c (249): > TestsTLS-11.exe!X509_load_cert_crl_file() + 0xF bytes > e:\openssl-1.1.git\crypto\x509\by_file.c (113): > TestsTLS-11.exe!by_file_ctrl() + 0xF bytes > e:\openssl-1.1.git\crypto\x509\x509_lu.c (117): > TestsTLS-11.exe!X509_LOOKUP_ctrl() + 0x1F bytes > e:\openssl-1.1.git\crypto\x509\x509_d2.c (92): > TestsTLS-11.exe!X509_STORE_load_locations() + 0x13 bytes > e:\openssl-1.1.git\ssl\ssl_lib.c (3344): > TestsTLS-11.exe!SSL_CTX_load_verify_locations() + 0x14 bytes > p:\mes programmes\shared\ocrypto-11\tls.cpp (410): > TestsTLS-11.exe!OTLS::TLSCtx::LoadTrustedCertsFile() + 0x12 bytes > p:\mes programmes\tests\_testsshared\teststls-11\tlscltsetup.cpp (99): > TestsTLS-11.exe!TLSCltConfig::Setup() + 0x26 bytes > p:\mes programmes\tests\_testsshared\teststls-11\clttasks.cpp (90): > TestsTLS-11.exe!CltThread::Main() + 0x17 bytes > p:\mes programmes\shared\sthread.cpp (17): > TestsTLS-11.exe!SThread::Run() + 0xE bytes > f:\dd\vctools\crt\crtw32\startup\threadex.c (359): > TestsTLS-11.exe!_threadstartex() > > > ---------- Block 5452 at 0x00871900: 64 bytes ---------- > Leak Hash: 0x188D6136, Count: 1, Total 64 bytes > Call Stack (TID 6956): > ntdll.dll!RtlAllocateHeap() > f:\dd\vctools\crt\crtw32\misc\dbgmalloc.c (56): TestsTLS-11.exe!malloc() > + 0x15 bytes > e:\openssl-1.1.git\crypto\mem.c (138): TestsTLS-11.exe!CRYPTO_malloc() + > 0x9 bytes > e:\openssl-1.1.git\crypto\mem.c (158): TestsTLS-11.exe!CRYPTO_zalloc() + > 0x11 bytes > e:\openssl-1.1.git\crypto\lhash\lhash.c (118): TestsTLS-11.exe!lh_new() > + 0xB bytes > e:\openssl-1.1.git\crypto\err\err_lcl.h (2): > TestsTLS-11.exe!lh_ERR_STATE_new() + 0x10 bytes > e:\openssl-1.1.git\crypto\err\err.c (321): > TestsTLS-11.exe!int_thread_get() + 0xF bytes > e:\openssl-1.1.git\crypto\err\err.c (369): > TestsTLS-11.exe!int_thread_set_item() + 0x9 bytes > e:\openssl-1.1.git\crypto\err\err.c (884): > TestsTLS-11.exe!ERR_get_state() + 0xC bytes > e:\openssl-1.1.git\crypto\err\err.c (581): > TestsTLS-11.exe!ERR_put_error() + 0x5 bytes > e:\openssl-1.1.git\crypto\pem\pem_lib.c (702): > TestsTLS-11.exe!PEM_read_bio() + 0x15 bytes > e:\openssl-1.1.git\crypto\pem\pem_info.c (117): > TestsTLS-11.exe!PEM_X509_INFO_read_bio() + 0x19 bytes > e:\openssl-1.1.git\crypto\x509\by_file.c (249): > TestsTLS-11.exe!X509_load_cert_crl_file() + 0xF bytes > e:\openssl-1.1.git\crypto\x509\by_file.c (113): > TestsTLS-11.exe!by_file_ctrl() + 0xF bytes > e:\openssl-1.1.git\crypto\x509\x509_lu.c (117): > TestsTLS-11.exe!X509_LOOKUP_ctrl() + 0x1F bytes > e:\openssl-1.1.git\crypto\x509\x509_d2.c (92): > TestsTLS-11.exe!X509_STORE_load_locations() + 0x13 bytes > e:\openssl-1.1.git\ssl\ssl_lib.c (3344): > TestsTLS-11.exe!SSL_CTX_load_verify_locations() + 0x14 bytes > p:\mes programmes\shared\ocrypto-11\tls.cpp (410): > TestsTLS-11.exe!OTLS::TLSCtx::LoadTrustedCertsFile() + 0x12 bytes > p:\mes programmes\tests\_testsshared\teststls-11\tlscltsetup.cpp (99): > TestsTLS-11.exe!TLSCltConfig::Setup() + 0x26 bytes > p:\mes programmes\tests\_testsshared\teststls-11\clttasks.cpp (90): > TestsTLS-11.exe!CltThread::Main() + 0x17 bytes > p:\mes programmes\shared\sthread.cpp (17): > TestsTLS-11.exe!SThread::Run() + 0xE bytes > f:\dd\vctools\crt\crtw32\startup\threadex.c (359): > TestsTLS-11.exe!_threadstartex() > > > ---------- Block 5454 at 0x008719C8: 400 bytes ---------- > Leak Hash: 0x21826292, Count: 1, Total 400 bytes > Call Stack (TID 7044): > ntdll.dll!RtlAllocateHeap() > f:\dd\vctools\crt\crtw32\misc\dbgmalloc.c (56): TestsTLS-11.exe!malloc() > + 0x15 bytes > e:\openssl-1.1.git\crypto\mem.c (138): TestsTLS-11.exe!CRYPTO_malloc() + > 0x9 bytes > e:\openssl-1.1.git\crypto\err\err.c (874): > TestsTLS-11.exe!ERR_get_state() + 0xE bytes > e:\openssl-1.1.git\crypto\err\err.c (581): > TestsTLS-11.exe!ERR_put_error() + 0x5 bytes > e:\openssl-1.1.git\crypto\pem\pem_lib.c (702): > TestsTLS-11.exe!PEM_read_bio() + 0x15 bytes > e:\openssl-1.1.git\crypto\pem\pem_info.c (117): > TestsTLS-11.exe!PEM_X509_INFO_read_bio() + 0x19 bytes > e:\openssl-1.1.git\crypto\x509\by_file.c (249): > TestsTLS-11.exe!X509_load_cert_crl_file() + 0xF bytes > e:\openssl-1.1.git\crypto\x509\by_file.c (113): > TestsTLS-11.exe!by_file_ctrl() + 0xF bytes > e:\openssl-1.1.git\crypto\x509\x509_lu.c (117): > TestsTLS-11.exe!X509_LOOKUP_ctrl() + 0x1F bytes > e:\openssl-1.1.git\crypto\x509\x509_d2.c (92): > TestsTLS-11.exe!X509_STORE_load_locations() + 0x13 bytes > e:\openssl-1.1.git\ssl\ssl_lib.c (3344): > TestsTLS-11.exe!SSL_CTX_load_verify_locations() + 0x14 bytes > p:\mes programmes\shared\ocrypto-11\tls.cpp (410): > TestsTLS-11.exe!OTLS::TLSCtx::LoadTrustedCertsFile() + 0x12 bytes > p:\mes programmes\tests\_testsshared\teststls-11\tlssrvsetup.cpp (214): > TestsTLS-11.exe!TLSSrvConfig::Setup() + 0x26 bytes > p:\mes programmes\tests\_testsshared\teststls-11\srvtasks.cpp (103): > TestsTLS-11.exe!SrvThread::Main() + 0x17 bytes > p:\mes programmes\shared\sthread.cpp (17): > TestsTLS-11.exe!SThread::Run() + 0xE bytes > f:\dd\vctools\crt\crtw32\startup\threadex.c (359): > TestsTLS-11.exe!_threadstartex() > > > ---------- Block 5455 at 0x00871B98: 12 bytes ---------- > Leak Hash: 0x6B9B46D4, Count: 1, Total 12 bytes > Call Stack (TID 7044): > ntdll.dll!RtlAllocateHeap() > f:\dd\vctools\crt\crtw32\misc\dbgmalloc.c (56): TestsTLS-11.exe!malloc() > + 0x15 bytes > e:\openssl-1.1.git\crypto\mem.c (138): TestsTLS-11.exe!CRYPTO_malloc() + > 0x9 bytes > e:\openssl-1.1.git\crypto\lhash\lhash.c (168): > TestsTLS-11.exe!lh_insert() + 0xB bytes > e:\openssl-1.1.git\crypto\err\err_lcl.h (2): > TestsTLS-11.exe!lh_ERR_STATE_insert() + 0x10 bytes > e:\openssl-1.1.git\crypto\err\err.c (371): > TestsTLS-11.exe!int_thread_set_item() + 0xD bytes > e:\openssl-1.1.git\crypto\err\err.c (884): > TestsTLS-11.exe!ERR_get_state() + 0xC bytes > e:\openssl-1.1.git\crypto\err\err.c (581): > TestsTLS-11.exe!ERR_put_error() + 0x5 bytes > e:\openssl-1.1.git\crypto\pem\pem_lib.c (702): > TestsTLS-11.exe!PEM_read_bio() + 0x15 bytes > e:\openssl-1.1.git\crypto\pem\pem_info.c (117): > TestsTLS-11.exe!PEM_X509_INFO_read_bio() + 0x19 bytes > e:\openssl-1.1.git\crypto\x509\by_file.c (249): > TestsTLS-11.exe!X509_load_cert_crl_file() + 0xF bytes > e:\openssl-1.1.git\crypto\x509\by_file.c (113): > TestsTLS-11.exe!by_file_ctrl() + 0xF bytes > e:\openssl-1.1.git\crypto\x509\x509_lu.c (117): > TestsTLS-11.exe!X509_LOOKUP_ctrl() + 0x1F bytes > e:\openssl-1.1.git\crypto\x509\x509_d2.c (92): > TestsTLS-11.exe!X509_STORE_load_locations() + 0x13 bytes > e:\openssl-1.1.git\ssl\ssl_lib.c (3344): > TestsTLS-11.exe!SSL_CTX_load_verify_locations() + 0x14 bytes > p:\mes programmes\shared\ocrypto-11\tls.cpp (410): > TestsTLS-11.exe!OTLS::TLSCtx::LoadTrustedCertsFile() + 0x12 bytes > p:\mes programmes\tests\_testsshared\teststls-11\tlssrvsetup.cpp (214): > TestsTLS-11.exe!TLSSrvConfig::Setup() + 0x26 bytes > p:\mes programmes\tests\_testsshared\teststls-11\srvtasks.cpp (103): > TestsTLS-11.exe!SrvThread::Main() + 0x17 bytes > p:\mes programmes\shared\sthread.cpp (17): > TestsTLS-11.exe!SThread::Run() + 0xE bytes > f:\dd\vctools\crt\crtw32\startup\threadex.c (359): > TestsTLS-11.exe!_threadstartex() > > > ---------- Block 7448 at 0x00895440: 8 bytes ---------- > Leak Hash: 0x977858EE, Count: 1, Total 8 bytes > Call Stack (TID 7044): > ntdll.dll!RtlAllocateHeap() > f:\dd\vctools\crt\crtw32\misc\dbgmalloc.c (56): TestsTLS-11.exe!malloc() > + 0x15 bytes > e:\openssl-1.1.git\crypto\mem.c (138): TestsTLS-11.exe!CRYPTO_malloc() + > 0x9 bytes > e:\openssl-1.1.git\crypto\mem.c (158): TestsTLS-11.exe!CRYPTO_zalloc() + > 0x11 bytes > e:\openssl-1.1.git\crypto\init.c (198): > TestsTLS-11.exe!ossl_init_get_thread_local() + 0xB bytes > e:\openssl-1.1.git\crypto\init.c (512): > TestsTLS-11.exe!ossl_init_thread_start() + 0x7 bytes > e:\openssl-1.1.git\crypto\err\err.c (898): > TestsTLS-11.exe!ERR_get_state() + 0x9 bytes > e:\openssl-1.1.git\crypto\err\err.c (581): > TestsTLS-11.exe!ERR_put_error() + 0x5 bytes > e:\openssl-1.1.git\crypto\pem\pem_lib.c (702): > TestsTLS-11.exe!PEM_read_bio() + 0x15 bytes > e:\openssl-1.1.git\crypto\pem\pem_info.c (117): > TestsTLS-11.exe!PEM_X509_INFO_read_bio() + 0x19 bytes > e:\openssl-1.1.git\crypto\x509\by_file.c (249): > TestsTLS-11.exe!X509_load_cert_crl_file() + 0xF bytes > e:\openssl-1.1.git\crypto\x509\by_file.c (113): > TestsTLS-11.exe!by_file_ctrl() + 0xF bytes > e:\openssl-1.1.git\crypto\x509\x509_lu.c (117): > TestsTLS-11.exe!X509_LOOKUP_ctrl() + 0x1F bytes > e:\openssl-1.1.git\crypto\x509\x509_d2.c (92): > TestsTLS-11.exe!X509_STORE_load_locations() + 0x13 bytes > e:\openssl-1.1.git\ssl\ssl_lib.c (3344): > TestsTLS-11.exe!SSL_CTX_load_verify_locations() + 0x14 bytes > p:\mes programmes\shared\ocrypto-11\tls.cpp (410): > TestsTLS-11.exe!OTLS::TLSCtx::LoadTrustedCertsFile() + 0x12 bytes > p:\mes programmes\tests\_testsshared\teststls-11\tlssrvsetup.cpp (214): > TestsTLS-11.exe!TLSSrvConfig::Setup() + 0x26 bytes > p:\mes programmes\tests\_testsshared\teststls-11\srvtasks.cpp (103): > TestsTLS-11.exe!SrvThread::Main() + 0x17 bytes > p:\mes programmes\shared\sthread.cpp (17): > TestsTLS-11.exe!SThread::Run() + 0xE bytes > f:\dd\vctools\crt\crtw32\startup\threadex.c (359): > TestsTLS-11.exe!_threadstartex() > > or another example : > > Detected memory leaks! > Dumping objects -> > {7105} normal block at 0x00484A40, 8 bytes long. > Data: < > 00 00 00 00 01 00 00 00 > {5112} normal block at 0x004601D8, 12 bytes long. > Data: < F hE > 08 00 46 00 00 00 00 00 68 45 01 00 > {5110} normal block at 0x0045FEC0, 64 bytes long. > Data: < F > D8 01 46 00 00 00 00 00 00 00 00 00 00 00 00 00 > {5109} normal block at 0x0045FE20, 96 bytes long. > Data: < E @ P ` P > C0 FE 45 00 40 D3 50 01 60 D3 50 01 08 00 00 00 > {5108} normal block at 0x00460008, 400 bytes long. > Data: < > 00 00 00 00 08 19 00 00 00 00 00 00 00 00 00 00 > Object dump complete. > > WARNING: Visual Leak Detector detected memory leaks! > ---------- Block 5097 at 0x0045FE20: 96 bytes ---------- > Leak Hash: 0xB3142E7A, Count: 1, Total 96 bytes > Call Stack (TID 6396): > ntdll.dll!RtlAllocateHeap() > f:\dd\vctools\crt\crtw32\misc\dbgmalloc.c (56): TestsTLS-11.exe!malloc() > + 0x15 bytes > e:\openssl-1.1.git\crypto\mem.c (138): TestsTLS-11.exe!CRYPTO_malloc() + > 0x9 bytes > e:\openssl-1.1.git\crypto\mem.c (158): TestsTLS-11.exe!CRYPTO_zalloc() + > 0x11 bytes > e:\openssl-1.1.git\crypto\lhash\lhash.c (116): TestsTLS-11.exe!lh_new() > + 0xB bytes > e:\openssl-1.1.git\crypto\err\err_lcl.h (2): > TestsTLS-11.exe!lh_ERR_STATE_new() + 0x10 bytes > e:\openssl-1.1.git\crypto\err\err.c (321): > TestsTLS-11.exe!int_thread_get() + 0xF bytes > e:\openssl-1.1.git\crypto\err\err.c (369): > TestsTLS-11.exe!int_thread_set_item() + 0x9 bytes > e:\openssl-1.1.git\crypto\err\err.c (884): > TestsTLS-11.exe!ERR_get_state() + 0xC bytes > e:\openssl-1.1.git\crypto\err\err.c (598): > TestsTLS-11.exe!ERR_clear_error() + 0x5 bytes > e:\openssl-1.1.git\ssl\statem\statem.c (279): > TestsTLS-11.exe!state_machine() > e:\openssl-1.1.git\ssl\statem\statem.c (217): > TestsTLS-11.exe!ossl_statem_connect() + 0xB bytes > e:\openssl-1.1.git\ssl\ssl_lib.c (2908): > TestsTLS-11.exe!SSL_do_handshake() + 0xC bytes > p:\mes programmes\shared\ocrypto-11\tls.cpp (953): > TestsTLS-11.exe!OTLS::TLSSss::DoHandshake() + 0xC bytes > p:\mes programmes\tests\_testsshared\teststls-11\clttasks.cpp (64): > TestsTLS-11.exe!CltThread::Main() + 0xB bytes > p:\mes programmes\shared\sthread.cpp (17): > TestsTLS-11.exe!SThread::Run() + 0xE bytes > f:\dd\vctools\crt\crtw32\startup\threadex.c (359): > TestsTLS-11.exe!_threadstartex() > > > ---------- Block 5098 at 0x0045FEC0: 64 bytes ---------- > Leak Hash: 0xDF96285B, Count: 1, Total 64 bytes > Call Stack (TID 6396): > ntdll.dll!RtlAllocateHeap() > f:\dd\vctools\crt\crtw32\misc\dbgmalloc.c (56): TestsTLS-11.exe!malloc() > + 0x15 bytes > e:\openssl-1.1.git\crypto\mem.c (138): TestsTLS-11.exe!CRYPTO_malloc() + > 0x9 bytes > e:\openssl-1.1.git\crypto\mem.c (158): TestsTLS-11.exe!CRYPTO_zalloc() + > 0x11 bytes > e:\openssl-1.1.git\crypto\lhash\lhash.c (118): TestsTLS-11.exe!lh_new() > + 0xB bytes > e:\openssl-1.1.git\crypto\err\err_lcl.h (2): > TestsTLS-11.exe!lh_ERR_STATE_new() + 0x10 bytes > e:\openssl-1.1.git\crypto\err\err.c (321): > TestsTLS-11.exe!int_thread_get() + 0xF bytes > e:\openssl-1.1.git\crypto\err\err.c (369): > TestsTLS-11.exe!int_thread_set_item() + 0x9 bytes > e:\openssl-1.1.git\crypto\err\err.c (884): > TestsTLS-11.exe!ERR_get_state() + 0xC bytes > e:\openssl-1.1.git\crypto\err\err.c (598): > TestsTLS-11.exe!ERR_clear_error() + 0x5 bytes > e:\openssl-1.1.git\ssl\statem\statem.c (279): > TestsTLS-11.exe!state_machine() > e:\openssl-1.1.git\ssl\statem\statem.c (217): > TestsTLS-11.exe!ossl_statem_connect() + 0xB bytes > e:\openssl-1.1.git\ssl\ssl_lib.c (2908): > TestsTLS-11.exe!SSL_do_handshake() + 0xC bytes > p:\mes programmes\shared\ocrypto-11\tls.cpp (953): > TestsTLS-11.exe!OTLS::TLSSss::DoHandshake() + 0xC bytes > p:\mes programmes\tests\_testsshared\teststls-11\clttasks.cpp (64): > TestsTLS-11.exe!CltThread::Main() + 0xB bytes > p:\mes programmes\shared\sthread.cpp (17): > TestsTLS-11.exe!SThread::Run() + 0xE bytes > f:\dd\vctools\crt\crtw32\startup\threadex.c (359): > TestsTLS-11.exe!_threadstartex() > > > ---------- Block 5096 at 0x00460008: 400 bytes ---------- > Leak Hash: 0xC49DE418, Count: 1, Total 400 bytes > Call Stack (TID 6408): > ntdll.dll!RtlAllocateHeap() > f:\dd\vctools\crt\crtw32\misc\dbgmalloc.c (56): TestsTLS-11.exe!malloc() > + 0x15 bytes > e:\openssl-1.1.git\crypto\mem.c (138): TestsTLS-11.exe!CRYPTO_malloc() + > 0x9 bytes > e:\openssl-1.1.git\crypto\err\err.c (874): > TestsTLS-11.exe!ERR_get_state() + 0xE bytes > e:\openssl-1.1.git\crypto\err\err.c (598): > TestsTLS-11.exe!ERR_clear_error() + 0x5 bytes > e:\openssl-1.1.git\ssl\statem\statem.c (279): > TestsTLS-11.exe!state_machine() > e:\openssl-1.1.git\ssl\statem\statem.c (222): > TestsTLS-11.exe!ossl_statem_accept() + 0xB bytes > e:\openssl-1.1.git\ssl\ssl_lib.c (2908): > TestsTLS-11.exe!SSL_do_handshake() + 0xC bytes > p:\mes programmes\shared\ocrypto-11\tls.cpp (953): > TestsTLS-11.exe!OTLS::TLSSss::DoHandshake() + 0xC bytes > p:\mes programmes\tests\_testsshared\teststls-11\srvtasks.cpp (79): > TestsTLS-11.exe!SrvThread::Main() + 0xB bytes > p:\mes programmes\shared\sthread.cpp (17): > TestsTLS-11.exe!SThread::Run() + 0xE bytes > f:\dd\vctools\crt\crtw32\startup\threadex.c (359): > TestsTLS-11.exe!_threadstartex() > > > ---------- Block 5100 at 0x004601D8: 12 bytes ---------- > Leak Hash: 0x8F14E2A9, Count: 1, Total 12 bytes > Call Stack (TID 6408): > ntdll.dll!RtlAllocateHeap() > f:\dd\vctools\crt\crtw32\misc\dbgmalloc.c (56): TestsTLS-11.exe!malloc() > + 0x15 bytes > e:\openssl-1.1.git\crypto\mem.c (138): TestsTLS-11.exe!CRYPTO_malloc() + > 0x9 bytes > e:\openssl-1.1.git\crypto\lhash\lhash.c (168): > TestsTLS-11.exe!lh_insert() + 0xB bytes > e:\openssl-1.1.git\crypto\err\err_lcl.h (2): > TestsTLS-11.exe!lh_ERR_STATE_insert() + 0x10 bytes > e:\openssl-1.1.git\crypto\err\err.c (371): > TestsTLS-11.exe!int_thread_set_item() + 0xD bytes > e:\openssl-1.1.git\crypto\err\err.c (884): > TestsTLS-11.exe!ERR_get_state() + 0xC bytes > e:\openssl-1.1.git\crypto\err\err.c (598): > TestsTLS-11.exe!ERR_clear_error() + 0x5 bytes > e:\openssl-1.1.git\ssl\statem\statem.c (279): > TestsTLS-11.exe!state_machine() > e:\openssl-1.1.git\ssl\statem\statem.c (222): > TestsTLS-11.exe!ossl_statem_accept() + 0xB bytes > e:\openssl-1.1.git\ssl\ssl_lib.c (2908): > TestsTLS-11.exe!SSL_do_handshake() + 0xC bytes > p:\mes programmes\shared\ocrypto-11\tls.cpp (953): > TestsTLS-11.exe!OTLS::TLSSss::DoHandshake() + 0xC bytes > p:\mes programmes\tests\_testsshared\teststls-11\srvtasks.cpp (79): > TestsTLS-11.exe!SrvThread::Main() + 0xB bytes > p:\mes programmes\shared\sthread.cpp (17): > TestsTLS-11.exe!SThread::Run() + 0xE bytes > f:\dd\vctools\crt\crtw32\startup\threadex.c (359): > TestsTLS-11.exe!_threadstartex() > > > ---------- Block 7093 at 0x00484A40: 8 bytes ---------- > Leak Hash: 0x160A9734, Count: 1, Total 8 bytes > Call Stack (TID 6408): > ntdll.dll!RtlAllocateHeap() > f:\dd\vctools\crt\crtw32\misc\dbgmalloc.c (56): TestsTLS-11.exe!malloc() > + 0x15 bytes > e:\openssl-1.1.git\crypto\mem.c (138): TestsTLS-11.exe!CRYPTO_malloc() + > 0x9 bytes > e:\openssl-1.1.git\crypto\mem.c (158): TestsTLS-11.exe!CRYPTO_zalloc() + > 0x11 bytes > e:\openssl-1.1.git\crypto\init.c (198): > TestsTLS-11.exe!ossl_init_get_thread_local() + 0xB bytes > e:\openssl-1.1.git\crypto\init.c (512): > TestsTLS-11.exe!ossl_init_thread_start() + 0x7 bytes > e:\openssl-1.1.git\crypto\err\err.c (898): > TestsTLS-11.exe!ERR_get_state() + 0x9 bytes > e:\openssl-1.1.git\crypto\err\err.c (598): > TestsTLS-11.exe!ERR_clear_error() + 0x5 bytes > e:\openssl-1.1.git\ssl\statem\statem.c (279): > TestsTLS-11.exe!state_machine() > e:\openssl-1.1.git\ssl\statem\statem.c (222): > TestsTLS-11.exe!ossl_statem_accept() + 0xB bytes > e:\openssl-1.1.git\ssl\ssl_lib.c (2908): > TestsTLS-11.exe!SSL_do_handshake() + 0xC bytes > p:\mes programmes\shared\ocrypto-11\tls.cpp (953): > TestsTLS-11.exe!OTLS::TLSSss::DoHandshake() + 0xC bytes > p:\mes programmes\tests\_testsshared\teststls-11\srvtasks.cpp (79): > TestsTLS-11.exe!SrvThread::Main() + 0xB bytes > p:\mes programmes\shared\sthread.cpp (17): > TestsTLS-11.exe!SThread::Run() + 0xE bytes > f:\dd\vctools\crt\crtw32\startup\threadex.c (359): > TestsTLS-11.exe!_threadstartex() > > -----Message d'origine----- > De : openssl-dev [mailto:openssl-dev-bounces at openssl.org] De la part de Matt > Caswell > Envoy? : mardi 16 f?vrier 2016 00:15 > ? : openssl-dev at openssl.org > Objet : Re: [openssl-dev] memory leaks detected using libSSL 1.1 > > Are you linking to OpenSSL statically? > > Please see the "Notes" section on this page: > https://www.openssl.org/docs/manmaster/crypto/OPENSSL_atexit.html > > Matt > From agostrer at gmail.com Wed Feb 17 16:32:43 2016 From: agostrer at gmail.com (Alexander Gostrer) Date: Wed, 17 Feb 2016 08:32:43 -0800 Subject: [openssl-dev] ECDH engine In-Reply-To: References: <20160120201925.17788998.82513.46556@ll.mit.edu> <569FF2F0.60905@gmail.com> Message-ID: Hi Uri, On Wed, Jan 27, 2016 at 9:25 AM, Blumenthal, Uri - 0553 - MITLL < uri at ll.mit.edu> wrote: > When I started to write the ECDSA code for engine_pkcs11 in 2011 the code > to support the method hooks was not > in the code. So I used internal OpenSSL header files to copy the > ECDSA_METHOD and replace the function needed. > Look for "BUILD_WITH_ECS_LOCL_H" in libp11. Not until 1.0.2 did OpenSSL > support the needed calls to hook ECDSA. > They did not add the hooks for ECDH. > > > I am missing one thing here. Hopefully you can help me understanding it. > > OpenSSL-1.0.2 currently supports ECDH, as I observe by running > > openssl pkeyutl -derive -inkey /tmp/derive.29494.priv.pem -peerkey > /tmp/derive.29494.token.pub.pem -out /tmp/derive.29494.shared1 > > So clearly there is working code available inside OpenSSL that does what > is needed. The only issue then is to add code to libp11 to access that > code. > > Am I correct? If not, could you please point at where/what I?m mistaken in? > > If you can't wait then you have to do it your self. *YOU* could do the > same thing for ECDH. But your code would only > be good for 1.0.2 because the whole way of doing EC methods changes in > 1.1. > > > That?s perfectly OK, because if my tea leaves reading is correct, > OpenSSL-1.0.2 will be around for several years at least. And most of the > package providers such as Macports won?t move their packages to OpenSSL-1.1 > for probably that long. So making 1.0.2 working with ECDH now will > definitely make sense for me. > > In fact, I think making libp11 compliant with OpenSSL-1.1 now is an > overreach, because this effort (unlike work on 1.0.2) is highly unlikely to > bring benefits to users for a few years. > > I believe Alexander said he had changes to OpenSSL, which is another > approach. > He has said there were here: > https://github.com/AtmelCSO/cryptoauth-openssl-engine/tree/master/patches > > > I see that the actual patch is very small. And the only meaningful (for > me) change is adding a new method EC_generate_key(). I would like to > understand why this method is needed ? is it only to allow OpenSSL to > *generate* key pair on the token? Alexander, could you comment please? > I was already responding to it. Here is the copy-paste from my previous response: In the TLS-1.2 protocol (sl_srvr.c) the server generates an ephemeral key pair for ECDH and sends the public key in the server key exchange message (see ssl3_send_server_key_exchange(SSL *s) function). It does not use the private key until it gets the client public key in the "ssl3_send_server_key_exchange(SSL *s)". Just then it calls the "ECDH_compute_key()" with the client public key and the server private key generated much earlier. If I do not call this new function (EC_generate_ key()) then the openssl sends a software-generated ephemeral key to the client. Adding this function was the simplest way to fix the problem. On client everything happens in the same function so it wasn't a problem. > > You could also hire someone who could do more then: "test it and offer > minor enhancements". > > > First, I cannot. Second, I don?t think (and haven?t seen any evidence to > the contrary yet) that anything more is needed. Especially seeing the > minuscule amount of changes Alexander had to do to OpenSSL, and I?m not > even sure I need those if I don?t insist on being able to generate new key > pair on the token using only OpenSSL. > > (And not me. I am taking the 1.1 approach to getting ECDH. working in > engine.) > > > :-) OK, I withdraw my unexpressed and unformulated offer. Consider > yourself un-asked. :-) > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Wed Feb 17 17:17:09 2016 From: rt at openssl.org (Kiyoshi KANAZAWA via RT) Date: Wed, 17 Feb 2016 17:17:09 +0000 Subject: [openssl-dev] [openssl.org #4319] openssl-1.1.0-pre3 Configure does not set cflags correctly on Solaris10 x64 In-Reply-To: <109678.47711.qm@web101206.mail.kks.yahoo.co.jp> References: <109678.47711.qm@web101206.mail.kks.yahoo.co.jp> Message-ID: Configure does not set cflags correctly on Solaris10 x64. In Configurations/10-main.conf line 75, it is written as ???? cflags?????????? => add_before("-m64 -Wall -DL_ENDIAN"), but, it is not set to CFLAGS. Make does not generate 64-bits code (-m64 is not used). Configure log is attached. % ./Configure solaris64-x86_64-gcc % make ? : gcc -I. -I.. -I../include -Iinclude? -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_THREADS -DOPENSSL_IA32 _SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM ?-DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1 305_ASM -DOPENSSLDIR="\"/usr/local/ssl\"" -DENGINESDIR="\"/usr/local/lib/engines\""? -pthread -D FILIO_H -O3?? -c -o cryptlib.o cryptlib.c ? : /opt/perl5/bin/perl x86_64cpuid.pl elf > x86_64cpuid.s gcc -I. -I.. -I../include -Iinclude? -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_THREADS -DOPENSSL_IA32 _SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM ?-DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1 305_ASM -DOPENSSLDIR="\"/usr/local/ssl\"" -DENGINESDIR="\"/usr/local/lib/engines\""? -pthread -D FILIO_H -O3 -c? -o x86_64cpuid.o x86_64cpuid.s x86_64cpuid.s: Assembler messages: x86_64cpuid.s:15: Error: bad register name `%rdi)' x86_64cpuid.s:16: Error: bad register name `%rsi' x86_64cpuid.s:18: Error: bad register name `%r8d' x86_64cpuid.s:20: Error: bad register name `%r8d' x86_64cpuid.s:30: Error: bad register name `%rdx' x86_64cpuid.s:31: Error: bad register name `%rdx' x86_64cpuid.s:39: Error: bad register name `%rbx' x86_64cpuid.s:42: Error: bad register name `%rdi)' x86_64cpuid.s:44: Error: bad register name `%r11d' x86_64cpuid.s:49: Error: bad register name `%r9d' x86_64cpuid.s:52: Error: bad register name `%r9d' x86_64cpuid.s:55: Error: bad register name `%r9d' x86_64cpuid.s:60: Error: bad register name `%r10d' x86_64cpuid.s:63: Error: bad register name `%r10d' x86_64cpuid.s:66: Error: bad register name `%r10d' x86_64cpuid.s:74: Error: bad register name `%r10d' x86_64cpuid.s:77: Error: bad register name `%r9d' x86_64cpuid.s:78: Error: bad register name `%r9d' x86_64cpuid.s:80: Error: bad register name `%r10d' x86_64cpuid.s:85: Error: `movzbq' is only supported in 64-bit mode ? : Best Regards, --- Kiyoshi -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4319 Please log in as guest with password guest if prompted -------------- next part -------------- A non-text attachment was scrubbed... Name: Configure.log Type: application/octet-stream Size: 2854 bytes Desc: not available URL: From uri at ll.mit.edu Wed Feb 17 17:25:43 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Wed, 17 Feb 2016 17:25:43 +0000 Subject: [openssl-dev] ECDH engine In-Reply-To: References: <20160120201925.17788998.82513.46556@ll.mit.edu> <569FF2F0.60905@gmail.com> Message-ID: Yea, my nice email server decided that it needed to re-send that piece. ;) But there have been changes since our conversation in January. I?d greatly appreciate if you could take a look at the current Github master of openssl/libp11 (it now has subsumed engine_pkcs11, and integrated ECDH support) and check if it alleviates the need for your ECDH engine. -- Regards, Uri Blumenthal From: openssl-dev on behalf of Alexander Gostrer Reply-To: openssl-dev Date: Wednesday, February 17, 2016 at 11:32 To: openssl-dev Subject: Re: [openssl-dev] ECDH engine > Hi Uri, > > On Wed, Jan 27, 2016 at 9:25 AM, Blumenthal, Uri - 0553 - MITLL > wrote: >>> When I started to write the ECDSA code for engine_pkcs11 in 2011 the code >>> to support the method hooks was not >>> in the code. So I used internal OpenSSL header files to copy the >>> ECDSA_METHOD and replace the function needed. >>> Look for "BUILD_WITH_ECS_LOCL_H" in libp11. Not until 1.0.2 did OpenSSL >>> support the needed calls to hook ECDSA. >>> They did not add the hooks for ECDH. >> >> I am missing one thing here. Hopefully you can help me understanding it. >> >> OpenSSL-1.0.2 currently supports ECDH, as I observe by running >> openssl pkeyutl -derive -inkey /tmp/derive.29494.priv.pem -peerkey >> /tmp/derive.29494.token.pub.pem -out /tmp/derive.29494.shared1 >> >> >> So clearly there is working code available inside OpenSSL that does what is >> needed. The only issue then is to add code to libp11 to access that code. >> >> Am I correct? If not, could you please point at where/what I?m mistaken in? >> >>> If you can't wait then you have to do it your self. *YOU* could do the same >>> thing for ECDH. But your code would only >>> be good for 1.0.2 because the whole way of doing EC methods changes in 1.1. >> >> That?s perfectly OK, because if my tea leaves reading is correct, >> OpenSSL-1.0.2 will be around for several years at least. And most of the >> package providers such as Macports won?t move their packages to OpenSSL-1.1 >> for probably that long. So making 1.0.2 working with ECDH now will definitely >> make sense for me. >> >> In fact, I think making libp11 compliant with OpenSSL-1.1 now is an >> overreach, because this effort (unlike work on 1.0.2) is highly unlikely to >> bring benefits to users for a few years. >> >>> I believe Alexander said he had changes to OpenSSL, which is another >>> approach. >>> He has said there were here: >>> https://github.com/AtmelCSO/cryptoauth-openssl-engine/tree/master/patches >> >> I see that the actual patch is very small. And the only meaningful (for me) >> change is adding a new method EC_generate_key(). I would like to understand >> why this method is needed ? is it only to allow OpenSSL to generate key pair >> on the token? Alexander, could you comment please? > > I was already responding to it. Here is the copy-paste from my previous > response: > In the TLS-1.2 protocol (sl_srvr.c) the server generates an ephemeral key pair > for ECDH and sends the public key in the server key exchange message (see > ssl3_send_server_key_exchange(SSL *s) function). It does not use the private > key until it gets the client public key in the > "ssl3_send_server_key_exchange(SSL *s)". Just then it calls the > "ECDH_compute_key()" with the client public key and the server private key > generated much earlier. If I do not call this new function (EC_generate_key()) > then the openssl sends a software-generated ephemeral key to the client. > Adding this function was the simplest way to fix the problem. On client > everything happens in the same function so it wasn't a problem. > >> >>> You could also hire someone who could do more then: "test it and offer minor >>> enhancements". >> >> First, I cannot. Second, I don?t think (and haven?t seen any evidence to the >> contrary yet) that anything more is needed. Especially seeing the minuscule >> amount of changes Alexander had to do to OpenSSL, and I?m not even sure I >> need those if I don?t insist on being able to generate new key pair on the >> token using only OpenSSL. >> >>> (And not me. I am taking the 1.1 approach to getting ECDH. working in >>> engine.) >> >> :-) OK, I withdraw my unexpressed and unformulated offer. Consider yourself >> un-asked. :-) >> >> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4324 bytes Desc: not available URL: From dwmw2 at infradead.org Wed Feb 17 17:38:40 2016 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 17 Feb 2016 17:38:40 +0000 Subject: [openssl-dev] [openssl.org #3964] Fix OPENSSL_NO_STDIO build In-Reply-To: References: <1438170735.26511.33.camel@intel.com> <1454690069.4788.309.camel@infradead.org> Message-ID: <1455730720.4735.45.camel@infradead.org> On Tue, 2016-02-09 at 02:57 +0000, Long, Qin wrote: > these two weeks.> > > David, I agree it's really horrid to include those xxxx_lcl.h to meet > EDK2 API requirement.??I am thinking it's better to re-design some > APIs to align the new opaque structure style. E.g. replacing the > HmacSha1GetContextSize() with HmacSha1ContextNew()... It should be > feasible.? That sounds ideal; thanks. In the meantime, I've sorted out everything we need on the OpenSSL side. A bunch has been merged today (thanks, Rich and Matt), and we are now down to the following four RT tickets and associated pull requests: ?RT4175: Fix regression using PKCS7_verify() with Authenticode ?https://github.com/openssl/openssl/pull/694 (https://github.com/openssl/openssl/pull/695?for 1.0.2) ?RT4309: Define PRIu64 for UEFI build ?https://github.com/openssl/openssl/pull/696 ? ?RT4310: Fix breakage of various no-xxx configuration options in HEAD? ?https://github.com/openssl/openssl/pull/697 ?RT3628: Allow filenames to be eliminated from compiled library ?https://github.com/openssl/openssl/pull/698 It looks like we're in fairly good shape for the OpenSSL 1.1.0 release to work "out of the box". I would like to see what we can do in the way of automated testing, though. It should be possible to at least have Travis-CI make libcrypto.so for the Linux target, with the 'no-everything' options that UEFI uses. It's a blunt instrument, but would have caught quite a few of the things I've just fixed, I think. > In addition, I would like to retire the IntrinsicLib in CryptoPkg. > This library is designed to satisfy the link requirement when > integrating openssl in EDKII environment. Some code segments in > OpenSSL will produce the intrinsic functions. E.g.??in the function > load_iv() in Pem_lib.c:? > ????for (i = 0; i < num; i++) > ????????to[i] = 0; > I think it's better to update this to the direct memset(). What's > your opinion? I am not keen.? If you don't want the compiler to 'spot' that certain patterns in C code can be replaced with intrinsic functions, then ask it nicely not to do that. Do *not* just attempt to tweak the code so that today's compiler doesn't happen to spot anything it can replace, in the *current* phase of the moon. That way lies madness. Isn't this what -ffreestanding (or is it -fno-builtins) is for? How does this work elsewhere in the EDK2 code base? Surely you can't play whack-a-mole with *every* piece of code ?that the compiler might decide to swap for an intrinsic memset/memcpy/etc., including all structure assignments? -- David Woodhouse Open Source Technology Centre David.Woodhouse at intel.com Intel Corporation -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5691 bytes Desc: not available URL: From rsalz at akamai.com Wed Feb 17 17:43:49 2016 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 17 Feb 2016 17:43:49 +0000 Subject: [openssl-dev] [openssl.org #3964] Fix OPENSSL_NO_STDIO build In-Reply-To: <1455730720.4735.45.camel@infradead.org> References: <1438170735.26511.33.camel@intel.com> <1454690069.4788.309.camel@infradead.org> <1455730720.4735.45.camel@infradead.org> Message-ID: > It looks like we're in fairly good shape for the OpenSSL 1.1.0 release > to work "out of the box". That will be great. > I would like to see what we can do in the way of automated testing, > though. It should be possible to at least have Travis-CI make > libcrypto.so for the Linux target, with the 'no-everything' options > that UEFI uses. It's a blunt instrument, but would have caught quite a > few of the things I've just fixed, I think. I think UEFI is important and would be willing to add a build to our travis. Make a PR :) /r$ From rt at openssl.org Wed Feb 17 18:21:12 2016 From: rt at openssl.org (Rainer Jung via RT) Date: Wed, 17 Feb 2016 18:21:12 +0000 Subject: [openssl-dev] [openssl.org #4320] [Patch] OpenSSL 1.1.0-pre3: "unable to load Key" error in PEM_get_EVP_CIPHER_INFO() In-Reply-To: <56C4BA0E.7090603@kippdata.de> References: <56C4BA0E.7090603@kippdata.de> Message-ID: Change https://github.com/openssl/openssl/commit/33a6d5a0e565e08758bcb6af456ec657c3a7a76a introduced a bug in crypto/pem/pem_lib.c function PEM_get_EVP_CIPHER_INFO(). One line was removed that is actually needed. The following patch fixes it: --- crypto/pem/pem_lib.c 2016-02-15 19:08:07.000000000 +0100 +++ crypto/pem/pem_lib.c 2016-02-17 18:45:14.092815000 +0100 @@ -537,6 +537,7 @@ *header = '\0'; cipher->cipher = enc = EVP_get_cipherbyname(dekinfostart); *header = c; + header++; if (enc == NULL) { PEMerr(PEM_F_PEM_GET_EVP_CIPHER_INFO, PEM_R_UNSUPPORTED_ENCRYPTION); While you are at it, the following is a small improvement which is used in similar ways close to this place: --- crypto/pem/pem_lib.c.orig 2016-02-17 18:45:14.092815000 +0100 +++ crypto/pem/pem_lib.c 2016-02-17 19:15:19.901402000 +0100 @@ -509,6 +509,7 @@ PEMerr(PEM_F_PEM_GET_EVP_CIPHER_INFO, PEM_R_NOT_ENCRYPTED); return (0); } + header += 9; for (; (*header != '\n') && (*header != '\0'); header++) ; if (*header == '\0') { PEMerr(PEM_F_PEM_GET_EVP_CIPHER_INFO, PEM_R_SHORT_HEADER); How to reproduce the bug: OpenSSL> dsaparam -out dsa-test 2048 Generating DSA parameters, 2048 bit long prime This could take some time ... OpenSSL> gendsa -out dsa-test.pem -aes128 dsa-test Generating DSA key, 2048 bits Enter PEM pass phrase: Verifying - Enter PEM pass phrase: OpenSSL> dsa -in dsa-test.pem -text read DSA key unable to load Private Key 4280523828:error:09065067:PEM routines:load_iv:bad iv chars:pem_lib.c:568: unable to load Key error in dsa The same happens e.g. when using -des or -des3 instead of -aes128. Without incrementing the header pointer, the parsing of the line DEK-Info: AES-128-CBC,CBFAADAF91039DF800391FB382CAC3B9 proceeds at the comma, instead of the hex string and bombs out. Thanks and Regards, Rainer -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4320 Please log in as guest with password guest if prompted From rt at openssl.org Wed Feb 17 18:37:06 2016 From: rt at openssl.org (Rich Salz via RT) Date: Wed, 17 Feb 2016 18:37:06 +0000 Subject: [openssl-dev] [openssl.org #4310] Fix various no-XXX build options In-Reply-To: <1455635174.4832.131.camel@infradead.org> References: <1455635174.4832.131.camel@infradead.org> Message-ID: fixed with commit 1288f26 pushed to master. thanks! -- Rich Salz, OpenSSL dev team; rsalz at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4310 Please log in as guest with password guest if prompted From rt at openssl.org Wed Feb 17 18:42:34 2016 From: rt at openssl.org (Rich Salz via RT) Date: Wed, 17 Feb 2016 18:42:34 +0000 Subject: [openssl-dev] [openssl.org #3628] [PATCH] NDEBUG macro and redundant strings In-Reply-To: References: Message-ID: fixed in 90fddb380977fa4f0a5de75b8fa889f29e399994 pushed to master, thanks. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3628 Please log in as guest with password guest if prompted From rsalz at akamai.com Wed Feb 17 18:51:21 2016 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 17 Feb 2016 18:51:21 +0000 Subject: [openssl-dev] [openssl.org #4320] [Patch] OpenSSL 1.1.0-pre3: "unable to load Key" error in PEM_get_EVP_CIPHER_INFO() In-Reply-To: References: <56C4BA0E.7090603@kippdata.de> Message-ID: <60a89faab22b4e549bce468dff46cdc7@ustx2ex-dag1mb1.msg.corp.akamai.com> > *header = c; > + header++; Header isn't used after that assignment. How does this line change anything? From rt at openssl.org Wed Feb 17 18:51:25 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Wed, 17 Feb 2016 18:51:25 +0000 Subject: [openssl-dev] [openssl.org #4320] [Patch] OpenSSL 1.1.0-pre3: "unable to load Key" error in PEM_get_EVP_CIPHER_INFO() In-Reply-To: <60a89faab22b4e549bce468dff46cdc7@ustx2ex-dag1mb1.msg.corp.akamai.com> References: <56C4BA0E.7090603@kippdata.de> <60a89faab22b4e549bce468dff46cdc7@ustx2ex-dag1mb1.msg.corp.akamai.com> Message-ID: > *header = c; > + header++; Header isn't used after that assignment. How does this line change anything? -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4320 Please log in as guest with password guest if prompted From rainer.jung at kippdata.de Wed Feb 17 23:15:02 2016 From: rainer.jung at kippdata.de (Rainer Jung) Date: Thu, 18 Feb 2016 00:15:02 +0100 Subject: [openssl-dev] [openssl.org #4320] [Patch] OpenSSL 1.1.0-pre3: "unable to load Key" error in PEM_get_EVP_CIPHER_INFO() In-Reply-To: <60a89faab22b4e549bce468dff46cdc7@ustx2ex-dag1mb1.msg.corp.akamai.com> References: <56C4BA0E.7090603@kippdata.de> <60a89faab22b4e549bce468dff46cdc7@ustx2ex-dag1mb1.msg.corp.akamai.com> Message-ID: <56C4FEF6.8010608@kippdata.de> Am 17.02.2016 um 19:51 schrieb Salz, Rich: > >> *header = c; >> + header++; > > Header isn't used after that assignment. How does this line change anything? The call to load_iv() that occurs next, has as its first argument header_pp which is a pointer to header: char **header_pp = &header; Inside load_iv() this pointer is named fromp and is immediately being dereferenced: from = *fromp; so "from" is an alias to "header", it contains the same address as "header". When being dereferenced, "from" will return the same char, that "header" points to. Now in load_iv() "from" is used to iterate over the IV hex chars: for (i = 0; i < num; i++) { if ((*from >= '0') && (*from <= '9')) v = *from - '0'; else if ((*from >= 'A') && (*from <= 'F')) v = *from - 'A' + 10; else if ((*from >= 'a') && (*from <= 'f')) v = *from - 'a' + 10; else { PEMerr(PEM_F_LOAD_IV, PEM_R_BAD_IV_CHARS); return (0); } from++; to[i / 2] |= v << (long)((!(i & 1)) * 4); } Since *from == *header == ',' at the beginning of the loop, this bombs. "header" needs to be incremented to actually point to the beginning of the IV. I hope this is understandable. It took me a moment as well to understand, how "from" in load_iv() relates to "header" in PEM_get_EVP_CIPHER_INFO(). I checked the patch with the reproduction case before posting and also added some debug logging to the "from" loop to double check. Regards, Rainer From rt at openssl.org Wed Feb 17 23:15:19 2016 From: rt at openssl.org (Rainer Jung via RT) Date: Wed, 17 Feb 2016 23:15:19 +0000 Subject: [openssl-dev] [openssl.org #4320] [Patch] OpenSSL 1.1.0-pre3: "unable to load Key" error in PEM_get_EVP_CIPHER_INFO() In-Reply-To: <56C4FEF6.8010608@kippdata.de> References: <56C4BA0E.7090603@kippdata.de> <60a89faab22b4e549bce468dff46cdc7@ustx2ex-dag1mb1.msg.corp.akamai.com> <56C4FEF6.8010608@kippdata.de> Message-ID: Am 17.02.2016 um 19:51 schrieb Salz, Rich: > >> *header = c; >> + header++; > > Header isn't used after that assignment. How does this line change anything? The call to load_iv() that occurs next, has as its first argument header_pp which is a pointer to header: char **header_pp = &header; Inside load_iv() this pointer is named fromp and is immediately being dereferenced: from = *fromp; so "from" is an alias to "header", it contains the same address as "header". When being dereferenced, "from" will return the same char, that "header" points to. Now in load_iv() "from" is used to iterate over the IV hex chars: for (i = 0; i < num; i++) { if ((*from >= '0') && (*from <= '9')) v = *from - '0'; else if ((*from >= 'A') && (*from <= 'F')) v = *from - 'A' + 10; else if ((*from >= 'a') && (*from <= 'f')) v = *from - 'a' + 10; else { PEMerr(PEM_F_LOAD_IV, PEM_R_BAD_IV_CHARS); return (0); } from++; to[i / 2] |= v << (long)((!(i & 1)) * 4); } Since *from == *header == ',' at the beginning of the loop, this bombs. "header" needs to be incremented to actually point to the beginning of the IV. I hope this is understandable. It took me a moment as well to understand, how "from" in load_iv() relates to "header" in PEM_get_EVP_CIPHER_INFO(). I checked the patch with the reproduction case before posting and also added some debug logging to the "from" loop to double check. Regards, Rainer -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4320 Please log in as guest with password guest if prompted From rsalz at akamai.com Wed Feb 17 23:17:30 2016 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 17 Feb 2016 23:17:30 +0000 Subject: [openssl-dev] [openssl.org #4320] [Patch] OpenSSL 1.1.0-pre3: "unable to load Key" error in PEM_get_EVP_CIPHER_INFO() In-Reply-To: <56C4FEF6.8010608@kippdata.de> References: <56C4BA0E.7090603@kippdata.de> <60a89faab22b4e549bce468dff46cdc7@ustx2ex-dag1mb1.msg.corp.akamai.com> <56C4FEF6.8010608@kippdata.de> Message-ID: <9b18d3e1dd474df2919f607df0f74f11@ustx2ex-dag1mb1.msg.corp.akamai.com> Yes, thanks, I was being dumb :( From michel.sales at free.fr Thu Feb 18 00:13:32 2016 From: michel.sales at free.fr (Michel) Date: Thu, 18 Feb 2016 01:13:32 +0100 Subject: [openssl-dev] memory leaks detected using libSSL 1.1 In-Reply-To: <56C49E57.5060407@openssl.org> References: <000001d166ac$9660f640$c322e2c0$@sales@free.fr> <56BFBC88.1010901@openssl.org> <000001d166bc$308f5680$91ae0380$@sales@free.fr> <56C25BFD.3060708@openssl.org> <006001d16911$5fd1a3b0$1f74eb10$@sales@free.fr> <56C49E57.5060407@openssl.org> Message-ID: <009d01d169e1$3402c590$9c0850b0$@sales@free.fr> Hi Matt, Thanks for the suggestion. This is what was printed to stderr : OPENSSL_INIT: ossl_init_base: Setting up stop handlers OPENSSL_INIT: ossl_init_add_all_ciphers: openssl_add_all_ciphers_internal() OPENSSL_INIT: ossl_init_add_all_digests: openssl_add_all_digests_internal() OPENSSL_INIT: ossl_init_ssl_base: Adding SSL ciphers and digests OPENSSL_INIT: ossl_init_ssl_base: SSL_COMP_get_compression_methods() OPENSSL_INIT: ossl_init_ssl_base: SSL_add_ssl_module() OPENSSL_INIT: ossl_init_load_ssl_strings: ERR_load_SSL_strings() OPENSSL_INIT: ossl_init_async: async_init() OPENSSL_INIT: ossl_init_load_crypto_strings: err_load_crypto_strings_intern() OPENSSL_INIT: ossl_init_thread_start: marking thread for err_state OPENSSL_INIT: ossl_init_thread_start: marking thread for err_state OPENSSL_INIT: ossl_init_thread_stop: ERR_remove_thread_state(NULL) OPENSSL_INIT: ssl_library_stop: SSL_COMP_free_compression_methods() OPENSSL_INIT: ssl_library_stop: ERR_free_strings() OPENSSL_INIT: OPENSSL_cleanup: ERR_free_strings() OPENSSL_INIT: OPENSSL_INIT_library_stop: CRYPTO_cleanup_all_ex_data() OPENSSL_INIT: OPENSSL_INIT_library_stop: EVP_cleanup() OPENSSL_INIT: OPENSSL_INIT_library_stop: CONF_modules_free() OPENSSL_INIT: OPENSSL_INIT_library_stop: RAND_cleanup() Shouldn't there be at least another line with ERR_remove_thread_state() (one for each thread) ? This test program launch 1 server thread and 1 client thread. Both of them have OPENSSL_thread_stop() in their [pre-]exit member function. Michel. -----Message d'origine----- De?: openssl-dev [mailto:openssl-dev-bounces at openssl.org] De la part de Matt Caswell Envoy??: mercredi 17 f?vrier 2016 17:23 ??: openssl-dev at openssl.org Objet?: Re: [openssl-dev] memory leaks detected using libSSL 1.1 > Am I missing anything else ? That should be sufficient (although the OPENSSL_cleanup() should not be required). You could try compiling OpenSSL with OPENSSL_INIT_DEBUG defined, e.g. perl Configure your-platform-here -DOPENSSL_INIT_DEBUG This should print out some debugging information to stderr every time the init functions attempt to do something interesting. In particular when you call OPENSSL_thread_stop() you should see the following printed out: OPENSSL_INIT: ossl_init_thread_stop: ERR_remove_thread_state(NULL) Matt From matt at openssl.org Thu Feb 18 10:17:45 2016 From: matt at openssl.org (Matt Caswell) Date: Thu, 18 Feb 2016 10:17:45 +0000 Subject: [openssl-dev] memory leaks detected using libSSL 1.1 In-Reply-To: <009d01d169e1$3402c590$9c0850b0$@sales@free.fr> References: <000001d166ac$9660f640$c322e2c0$@sales@free.fr> <56BFBC88.1010901@openssl.org> <000001d166bc$308f5680$91ae0380$@sales@free.fr> <56C25BFD.3060708@openssl.org> <006001d16911$5fd1a3b0$1f74eb10$@sales@free.fr> <56C49E57.5060407@openssl.org> <009d01d169e1$3402c590$9c0850b0$@sales@free.fr> Message-ID: <56C59A49.6060205@openssl.org> On 18/02/16 00:13, Michel wrote: > Hi Matt, > > Thanks for the suggestion. > > This is what was printed to stderr : > OPENSSL_INIT: ossl_init_base: Setting up stop handlers > OPENSSL_INIT: ossl_init_add_all_ciphers: openssl_add_all_ciphers_internal() > OPENSSL_INIT: ossl_init_add_all_digests: openssl_add_all_digests_internal() > OPENSSL_INIT: ossl_init_ssl_base: Adding SSL ciphers and digests > OPENSSL_INIT: ossl_init_ssl_base: SSL_COMP_get_compression_methods() > OPENSSL_INIT: ossl_init_ssl_base: SSL_add_ssl_module() > OPENSSL_INIT: ossl_init_load_ssl_strings: ERR_load_SSL_strings() > OPENSSL_INIT: ossl_init_async: async_init() > OPENSSL_INIT: ossl_init_load_crypto_strings: > err_load_crypto_strings_intern() > OPENSSL_INIT: ossl_init_thread_start: marking thread for err_state > OPENSSL_INIT: ossl_init_thread_start: marking thread for err_state > OPENSSL_INIT: ossl_init_thread_stop: ERR_remove_thread_state(NULL) > OPENSSL_INIT: ssl_library_stop: SSL_COMP_free_compression_methods() > OPENSSL_INIT: ssl_library_stop: ERR_free_strings() > OPENSSL_INIT: OPENSSL_cleanup: ERR_free_strings() > OPENSSL_INIT: OPENSSL_INIT_library_stop: CRYPTO_cleanup_all_ex_data() > OPENSSL_INIT: OPENSSL_INIT_library_stop: EVP_cleanup() > OPENSSL_INIT: OPENSSL_INIT_library_stop: CONF_modules_free() > OPENSSL_INIT: OPENSSL_INIT_library_stop: RAND_cleanup() > > Shouldn't there be at least another line with ERR_remove_thread_state() (one > for each thread) ? Yes. I can see we have two of these: OPENSSL_INIT: ossl_init_thread_start: marking thread for err_state OPENSSL_INIT: ossl_init_thread_start: marking thread for err_state Which means that the init code has spotted that there are two threads running and has initialised the error system for both of them. But we only get one of these: OPENSSL_INIT: ossl_init_thread_stop: ERR_remove_thread_state(NULL) Which means only one of the two threads has subsequently been de-inited. That's very odd. I have two possible theories: 1) OPENSSL_thread_stop() is not actually getting called as we think it is. Or 2) The Thread Local Structure that keeps track of what things need cleanup is not being obtained correctly for some reason during the thread stop...so we have "forgotten" that we initialised the error system. To try and help narrow down which of these possibilities it is I have created a patch (attached) which bumps up the logging significantly. Please can you apply it, rerun your code (with OPENSSL_INIT_DEBUG defined still) and post the output here? Thanks Matt > This test program launch 1 server thread and 1 client thread. > Both of them have OPENSSL_thread_stop() in their [pre-]exit member function. > > Michel. > > -----Message d'origine----- > De : openssl-dev [mailto:openssl-dev-bounces at openssl.org] De la part de Matt > Caswell > Envoy? : mercredi 17 f?vrier 2016 17:23 > ? : openssl-dev at openssl.org > Objet : Re: [openssl-dev] memory leaks detected using libSSL 1.1 > >> Am I missing anything else ? > > That should be sufficient (although the OPENSSL_cleanup() should not be > required). > > You could try compiling OpenSSL with OPENSSL_INIT_DEBUG defined, e.g. > > perl Configure your-platform-here -DOPENSSL_INIT_DEBUG > > This should print out some debugging information to stderr every time the > init functions attempt to do something interesting. In particular when you > call OPENSSL_thread_stop() you should see the following printed > out: > > OPENSSL_INIT: ossl_init_thread_stop: ERR_remove_thread_state(NULL) > > Matt > -------------- next part -------------- A non-text attachment was scrubbed... Name: thread-stop-debug.patch Type: text/x-patch Size: 5301 bytes Desc: not available URL: From michel.sales at free.fr Thu Feb 18 11:37:53 2016 From: michel.sales at free.fr (Michel) Date: Thu, 18 Feb 2016 12:37:53 +0100 Subject: [openssl-dev] memory leaks detected using libSSL 1.1 In-Reply-To: <56C59A49.6060205@openssl.org> References: <000001d166ac$9660f640$c322e2c0$@sales@free.fr> <56BFBC88.1010901@openssl.org> <000001d166bc$308f5680$91ae0380$@sales@free.fr> <56C25BFD.3060708@openssl.org> <006001d16911$5fd1a3b0$1f74eb10$@sales@free.fr> <56C49E57.5060407@openssl.org> <009d01d169e1$3402c590$9c0850b0$@sales@free.fr> <56C59A49.6060205@openssl.org> Message-ID: <001601d16a40$ce772120$6b656360$@sales@free.fr> Hi Matt, Here under is the new results after applying your patch. Let me know anything I could do to investigate deeper. Regards, Michel. Thread serveur 5324 demarre Thread client 6348 demarre OPENSSL_INIT: ossl_init_base: Setting up stop handlers OPENSSL_INIT: ossl_init_add_all_ciphers: openssl_add_all_ciphers_internal() OPENSSL_INIT: ossl_init_add_all_digests: openssl_add_all_digests_internal() OPENSSL_INIT: ossl_init_ssl_base: Adding SSL ciphers and digests OPENSSL_INIT: ossl_init_ssl_base: SSL_COMP_get_compression_methods() OPENSSL_INIT: ossl_init_ssl_base: SSL_add_ssl_module() OPENSSL_INIT: ossl_init_load_ssl_strings: ERR_load_SSL_strings() OPENSSL_INIT: ossl_init_async: async_init() OPENSSL_INIT: ossl_init_load_crypto_strings: err_load_crypto_strings_intern() OPENSSL_INIT: ossl_init_get_thread_local: Starting: Local value is NULL, alloc is 1 (6348) OPENSSL_INIT: ossl_init_get_thread_local: Allocating a new local structure (6348) OPENSSL_INIT: ossl_init_get_thread_local: Ending: Local value is NOT NULL, alloc is 1 (6348) OPENSSL_INIT: ossl_init_thread_start: Starting (6348) OPENSSL_INIT: ossl_init_thread_start: marking thread for err_state (6348) OPENSSL_INIT: ossl_init_thread_start: End (6348) OPENSSL_INIT: ossl_init_get_thread_local: Starting: Local value is NULL, alloc is 1 (5324) OPENSSL_INIT: ossl_init_get_thread_local: Allocating a new local structure (5324) OPENSSL_INIT: ossl_init_get_thread_local: Ending: Local value is NOT NULL, alloc is 1 (5324) OPENSSL_INIT: ossl_init_thread_start: Starting (5324) OPENSSL_INIT: ossl_init_thread_start: marking thread for err_state (5324) OPENSSL_INIT: ossl_init_thread_start: End (5324) ... OPENSSL_INIT: OPENSSL_thread_stop: starting (6348) OPENSSL_INIT: ossl_init_get_thread_local: Starting: Local value is NOT NULL, alloc is 0 (6348) OPENSSL_INIT: ossl_init_get_thread_local: Clearing Thread Locals (6348) OPENSSL_INIT: ossl_init_get_thread_local: Ending: Local value is NOT NULL, alloc is 0 (6348) OPENSSL_INIT: ossl_init_thread_stop: starting (6348) OPENSSL_INIT: ossl_init_thread_stop: ERR_remove_thread_state(NULL) (6348) OPENSSL_INIT: OPENSSL_thread_stop: starting (5324) OPENSSL_INIT: ossl_init_get_thread_local: Starting: Local value is NULL, alloc is 0 (5324) OPENSSL_INIT: ossl_init_get_thread_local: Clearing Thread Locals (5324) OPENSSL_INIT: ossl_init_get_thread_local: Ending: Local value is NULL, alloc is 0 (5324) OPENSSL_INIT: ossl_init_thread_stop: starting (5324) OPENSSL_INIT: ossl_init_thread_stop: locals are NULL returning (5324) OPENSSL_INIT: OPENSSL_thread_stop: ending (5324) OPENSSL_INIT: ossl_init_thread_stop: end (6348) OPENSSL_INIT: OPENSSL_thread_stop: ending (6348) Thread serveur 5324 termine Thread client 6348 termine OPENSSL_INIT: ossl_init_get_thread_local: Starting: Local value is NULL, alloc is 0 (6240) OPENSSL_INIT: ossl_init_get_thread_local: Clearing Thread Locals (6240) OPENSSL_INIT: ossl_init_get_thread_local: Ending: Local value is NULL, alloc is 0 (6240) OPENSSL_INIT: ossl_init_thread_stop: starting (6240) OPENSSL_INIT: ossl_init_thread_stop: locals are NULL returning (6240) OPENSSL_INIT: ssl_library_stop: SSL_COMP_free_compression_methods() OPENSSL_INIT: ssl_library_stop: ERR_free_strings() OPENSSL_INIT: OPENSSL_cleanup: ERR_free_strings() OPENSSL_INIT: OPENSSL_INIT_library_stop: CRYPTO_cleanup_all_ex_data() OPENSSL_INIT: OPENSSL_INIT_library_stop: EVP_cleanup() OPENSSL_INIT: OPENSSL_INIT_library_stop: CONF_modules_free() OPENSSL_INIT: OPENSSL_INIT_library_stop: RAND_cleanup() Assertion failed: !bLeak, file p:\mes programmes\tests\_testsshared\teststls-11\testtls.cpp, line 165 Detected memory leaks! Dumping objects -> {7025} normal block at 0x00A75628, 8 bytes long. Data: < > 00 00 00 00 01 00 00 00 {5009} normal block at 0x00A3CB88, 12 bytes long. Data: < 4 > A8 0C A4 00 00 00 00 00 C0 34 01 00 {5008} normal block at 0x00A40CA8, 400 bytes long. Data: < > 00 00 00 00 C0 17 00 00 00 00 00 00 00 00 00 00 {5003} normal block at 0x00A3CCB8, 64 bytes long. Data: < > 88 CB A3 00 00 00 00 00 00 00 00 00 00 00 00 00 {5001} normal block at 0x00A3C9B0, 96 bytes long. Data: < P9P p9P > B8 CC A3 00 50 39 50 00 70 39 50 00 08 00 00 00 Object dump complete. WARNING: Visual Leak Detector detected memory leaks! ---------- Block 4993 at 0x00A3C9B0: 96 bytes ---------- Leak Hash: 0x7CDBED0B, Count: 1, Total 96 bytes Call Stack (TID 4804): ntdll.dll!RtlAllocateHeap() f:\dd\vctools\crt\crtw32\misc\dbgmalloc.c (56): TestsTLS-11.exe!malloc() + 0x15 bytes e:\openssl-1.1.git\crypto\mem.c (141): TestsTLS-11.exe!CRYPTO_malloc() + 0x9 bytes e:\openssl-1.1.git\crypto\mem.c (161): TestsTLS-11.exe!CRYPTO_zalloc() + 0x11 bytes e:\openssl-1.1.git\crypto\lhash\lhash.c (116): TestsTLS-11.exe!lh_new() + 0xE bytes e:\openssl-1.1.git\crypto\err\err_lcl.h (2): TestsTLS-11.exe!lh_ERR_STATE_new() + 0x10 bytes e:\openssl-1.1.git\crypto\err\err.c (321): TestsTLS-11.exe!int_thread_get() + 0xF bytes e:\openssl-1.1.git\crypto\err\err.c (369): TestsTLS-11.exe!int_thread_set_item() + 0x9 bytes e:\openssl-1.1.git\crypto\err\err.c (884): TestsTLS-11.exe!ERR_get_state() + 0xC bytes e:\openssl-1.1.git\crypto\err\err.c (598): TestsTLS-11.exe!ERR_clear_error() + 0x5 bytes e:\openssl-1.1.git\ssl\statem\statem.c (279): TestsTLS-11.exe!state_machine() e:\openssl-1.1.git\ssl\statem\statem.c (217): TestsTLS-11.exe!ossl_statem_connect() + 0xB bytes e:\openssl-1.1.git\ssl\ssl_lib.c (2905): TestsTLS-11.exe!SSL_do_handshake() + 0xC bytes p:\mes programmes\shared\ocrypto-11\tls.cpp (953): TestsTLS-11.exe!OTLS::TLSSss::DoHandshake() + 0xC bytes p:\mes programmes\tests\_testsshared\teststls-11\clttasks.cpp (64): TestsTLS-11.exe!CltThread::Main() + 0xB bytes p:\mes programmes\shared\sthread.cpp (17): TestsTLS-11.exe!SThread::Run() + 0xE bytes f:\dd\vctools\crt\crtw32\startup\threadex.c (359): TestsTLS-11.exe!_threadstartex() ---------- Block 5001 at 0x00A3CB88: 12 bytes ---------- Leak Hash: 0xE9B700C5, Count: 1, Total 12 bytes Call Stack (TID 6080): ntdll.dll!RtlAllocateHeap() f:\dd\vctools\crt\crtw32\misc\dbgmalloc.c (56): TestsTLS-11.exe!malloc() + 0x15 bytes e:\openssl-1.1.git\crypto\mem.c (141): TestsTLS-11.exe!CRYPTO_malloc() + 0x9 bytes e:\openssl-1.1.git\crypto\lhash\lhash.c (168): TestsTLS-11.exe!lh_insert() + 0x11 bytes e:\openssl-1.1.git\crypto\err\err_lcl.h (2): TestsTLS-11.exe!lh_ERR_STATE_insert() + 0x10 bytes e:\openssl-1.1.git\crypto\err\err.c (371): TestsTLS-11.exe!int_thread_set_item() + 0xD bytes e:\openssl-1.1.git\crypto\err\err.c (884): TestsTLS-11.exe!ERR_get_state() + 0xC bytes e:\openssl-1.1.git\crypto\err\err.c (598): TestsTLS-11.exe!ERR_clear_error() + 0x5 bytes e:\openssl-1.1.git\ssl\statem\statem.c (279): TestsTLS-11.exe!state_machine() e:\openssl-1.1.git\ssl\statem\statem.c (222): TestsTLS-11.exe!ossl_statem_accept() + 0xB bytes e:\openssl-1.1.git\ssl\ssl_lib.c (2905): TestsTLS-11.exe!SSL_do_handshake() + 0xC bytes p:\mes programmes\shared\ocrypto-11\tls.cpp (953): TestsTLS-11.exe!OTLS::TLSSss::DoHandshake() + 0xC bytes p:\mes programmes\tests\_testsshared\teststls-11\srvtasks.cpp (79): TestsTLS-11.exe!SrvThread::Main() + 0xB bytes p:\mes programmes\shared\sthread.cpp (17): TestsTLS-11.exe!SThread::Run() + 0xE bytes f:\dd\vctools\crt\crtw32\startup\threadex.c (359): TestsTLS-11.exe!_threadstartex() ---------- Block 4995 at 0x00A3CCB8: 64 bytes ---------- Leak Hash: 0x8337F4DE, Count: 1, Total 64 bytes Call Stack (TID 4804): ntdll.dll!RtlAllocateHeap() f:\dd\vctools\crt\crtw32\misc\dbgmalloc.c (56): TestsTLS-11.exe!malloc() + 0x15 bytes e:\openssl-1.1.git\crypto\mem.c (141): TestsTLS-11.exe!CRYPTO_malloc() + 0x9 bytes e:\openssl-1.1.git\crypto\mem.c (161): TestsTLS-11.exe!CRYPTO_zalloc() + 0x11 bytes e:\openssl-1.1.git\crypto\lhash\lhash.c (118): TestsTLS-11.exe!lh_new() + 0xE bytes e:\openssl-1.1.git\crypto\err\err_lcl.h (2): TestsTLS-11.exe!lh_ERR_STATE_new() + 0x10 bytes e:\openssl-1.1.git\crypto\err\err.c (321): TestsTLS-11.exe!int_thread_get() + 0xF bytes e:\openssl-1.1.git\crypto\err\err.c (369): TestsTLS-11.exe!int_thread_set_item() + 0x9 bytes e:\openssl-1.1.git\crypto\err\err.c (884): TestsTLS-11.exe!ERR_get_state() + 0xC bytes e:\openssl-1.1.git\crypto\err\err.c (598): TestsTLS-11.exe!ERR_clear_error() + 0x5 bytes e:\openssl-1.1.git\ssl\statem\statem.c (279): TestsTLS-11.exe!state_machine() e:\openssl-1.1.git\ssl\statem\statem.c (217): TestsTLS-11.exe!ossl_statem_connect() + 0xB bytes e:\openssl-1.1.git\ssl\ssl_lib.c (2905): TestsTLS-11.exe!SSL_do_handshake() + 0xC bytes p:\mes programmes\shared\ocrypto-11\tls.cpp (953): TestsTLS-11.exe!OTLS::TLSSss::DoHandshake() + 0xC bytes p:\mes programmes\tests\_testsshared\teststls-11\clttasks.cpp (64): TestsTLS-11.exe!CltThread::Main() + 0xB bytes p:\mes programmes\shared\sthread.cpp (17): TestsTLS-11.exe!SThread::Run() + 0xE bytes f:\dd\vctools\crt\crtw32\startup\threadex.c (359): TestsTLS-11.exe!_threadstartex() ---------- Block 5000 at 0x00A40CA8: 400 bytes ---------- Leak Hash: 0x2037555F, Count: 1, Total 400 bytes Call Stack (TID 6080): ntdll.dll!RtlAllocateHeap() f:\dd\vctools\crt\crtw32\misc\dbgmalloc.c (56): TestsTLS-11.exe!malloc() + 0x15 bytes e:\openssl-1.1.git\crypto\mem.c (141): TestsTLS-11.exe!CRYPTO_malloc() + 0x9 bytes e:\openssl-1.1.git\crypto\err\err.c (874): TestsTLS-11.exe!ERR_get_state() + 0x14 bytes e:\openssl-1.1.git\crypto\err\err.c (598): TestsTLS-11.exe!ERR_clear_error() + 0x5 bytes e:\openssl-1.1.git\ssl\statem\statem.c (279): TestsTLS-11.exe!state_machine() e:\openssl-1.1.git\ssl\statem\statem.c (222): TestsTLS-11.exe!ossl_statem_accept() + 0xB bytes e:\openssl-1.1.git\ssl\ssl_lib.c (2905): TestsTLS-11.exe!SSL_do_handshake() + 0xC bytes p:\mes programmes\shared\ocrypto-11\tls.cpp (953): TestsTLS-11.exe!OTLS::TLSSss::DoHandshake() + 0xC bytes p:\mes programmes\tests\_testsshared\teststls-11\srvtasks.cpp (79): TestsTLS-11.exe!SrvThread::Main() + 0xB bytes p:\mes programmes\shared\sthread.cpp (17): TestsTLS-11.exe!SThread::Run() + 0xE bytes f:\dd\vctools\crt\crtw32\startup\threadex.c (359): TestsTLS-11.exe!_threadstartex() ---------- Block 7017 at 0x00A75628: 8 bytes ---------- Leak Hash: 0x82CA3A37, Count: 1, Total 8 bytes Call Stack (TID 6080): ntdll.dll!RtlAllocateHeap() f:\dd\vctools\crt\crtw32\misc\dbgmalloc.c (56): TestsTLS-11.exe!malloc() + 0x15 bytes e:\openssl-1.1.git\crypto\mem.c (141): TestsTLS-11.exe!CRYPTO_malloc() + 0x9 bytes e:\openssl-1.1.git\crypto\mem.c (161): TestsTLS-11.exe!CRYPTO_zalloc() + 0x11 bytes e:\openssl-1.1.git\crypto\init.c (212): TestsTLS-11.exe!ossl_init_get_thread_local() + 0x11 bytes e:\openssl-1.1.git\crypto\init.c (568): TestsTLS-11.exe!ossl_init_thread_start() + 0x7 bytes e:\openssl-1.1.git\crypto\err\err.c (898): TestsTLS-11.exe!ERR_get_state() + 0x9 bytes e:\openssl-1.1.git\crypto\err\err.c (598): TestsTLS-11.exe!ERR_clear_error() + 0x5 bytes e:\openssl-1.1.git\ssl\statem\statem.c (279): TestsTLS-11.exe!state_machine() e:\openssl-1.1.git\ssl\statem\statem.c (222): TestsTLS-11.exe!ossl_statem_accept() + 0xB bytes e:\openssl-1.1.git\ssl\ssl_lib.c (2905): TestsTLS-11.exe!SSL_do_handshake() + 0xC bytes p:\mes programmes\shared\ocrypto-11\tls.cpp (953): TestsTLS-11.exe!OTLS::TLSSss::DoHandshake() + 0xC bytes p:\mes programmes\tests\_testsshared\teststls-11\srvtasks.cpp (79): TestsTLS-11.exe!SrvThread::Main() + 0xB bytes p:\mes programmes\shared\sthread.cpp (17): TestsTLS-11.exe!SThread::Run() + 0xE bytes f:\dd\vctools\crt\crtw32\startup\threadex.c (359): TestsTLS-11.exe!_threadstartex() Visual Leak Detector detected 5 memory leaks (16416 bytes). Largest number used: 442154 bytes. Total allocations: 1908126 bytes. From rt at openssl.org Thu Feb 18 12:23:59 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 18 Feb 2016 12:23:59 +0000 Subject: [openssl-dev] [openssl.org #2047] [PATCH][Beta3] Fix IPv6 handling in BIO_get_accept_socket() In-Reply-To: <8f62e1cd0908202313x7cd809c8oe6c1f8ff99ddef5a@mail.gmail.com> References: <8f62e1cd0908202313x7cd809c8oe6c1f8ff99ddef5a@mail.gmail.com> Message-ID: fixed in master. Rich Salz, OpenSSL dev team; rsalz at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2047 Please log in as guest with password guest if prompted From matt at openssl.org Thu Feb 18 12:26:53 2016 From: matt at openssl.org (Matt Caswell) Date: Thu, 18 Feb 2016 12:26:53 +0000 Subject: [openssl-dev] memory leaks detected using libSSL 1.1 In-Reply-To: <001601d16a40$ce772120$6b656360$@sales@free.fr> References: <000001d166ac$9660f640$c322e2c0$@sales@free.fr> <56BFBC88.1010901@openssl.org> <000001d166bc$308f5680$91ae0380$@sales@free.fr> <56C25BFD.3060708@openssl.org> <006001d16911$5fd1a3b0$1f74eb10$@sales@free.fr> <56C49E57.5060407@openssl.org> <009d01d169e1$3402c590$9c0850b0$@sales@free.fr> <56C59A49.6060205@openssl.org> <001601d16a40$ce772120$6b656360$@sales@free.fr> Message-ID: <56C5B88D.6090208@openssl.org> On 18/02/16 11:37, Michel wrote: > Hi Matt, > > Here under is the new results after applying your patch. > Let me know anything I could do to investigate deeper. Thanks. That was very helpful. I think I may have identified the issue. Please can you try the attached patch and see if that fixes things? Thanks Matt > > Regards, > > Michel. > > Thread serveur 5324 demarre > Thread client 6348 demarre > OPENSSL_INIT: ossl_init_base: Setting up stop handlers > OPENSSL_INIT: ossl_init_add_all_ciphers: openssl_add_all_ciphers_internal() > OPENSSL_INIT: ossl_init_add_all_digests: openssl_add_all_digests_internal() > OPENSSL_INIT: ossl_init_ssl_base: Adding SSL ciphers and digests > OPENSSL_INIT: ossl_init_ssl_base: SSL_COMP_get_compression_methods() > OPENSSL_INIT: ossl_init_ssl_base: SSL_add_ssl_module() > OPENSSL_INIT: ossl_init_load_ssl_strings: ERR_load_SSL_strings() > OPENSSL_INIT: ossl_init_async: async_init() > OPENSSL_INIT: ossl_init_load_crypto_strings: > err_load_crypto_strings_intern() > OPENSSL_INIT: ossl_init_get_thread_local: Starting: Local value is NULL, > alloc is 1 (6348) > OPENSSL_INIT: ossl_init_get_thread_local: Allocating a new local structure > (6348) > OPENSSL_INIT: ossl_init_get_thread_local: Ending: Local value is NOT NULL, > alloc is 1 (6348) > OPENSSL_INIT: ossl_init_thread_start: Starting (6348) > OPENSSL_INIT: ossl_init_thread_start: marking thread for err_state (6348) > OPENSSL_INIT: ossl_init_thread_start: End (6348) > OPENSSL_INIT: ossl_init_get_thread_local: Starting: Local value is NULL, > alloc is 1 (5324) > OPENSSL_INIT: ossl_init_get_thread_local: Allocating a new local structure > (5324) > OPENSSL_INIT: ossl_init_get_thread_local: Ending: Local value is NOT NULL, > alloc is 1 (5324) > OPENSSL_INIT: ossl_init_thread_start: Starting (5324) > OPENSSL_INIT: ossl_init_thread_start: marking thread for err_state (5324) > OPENSSL_INIT: ossl_init_thread_start: End (5324) > ... > OPENSSL_INIT: OPENSSL_thread_stop: starting (6348) > OPENSSL_INIT: ossl_init_get_thread_local: Starting: Local value is NOT NULL, > alloc is 0 (6348) > OPENSSL_INIT: ossl_init_get_thread_local: Clearing Thread Locals (6348) > OPENSSL_INIT: ossl_init_get_thread_local: Ending: Local value is NOT NULL, > alloc is 0 (6348) > OPENSSL_INIT: ossl_init_thread_stop: starting (6348) > OPENSSL_INIT: ossl_init_thread_stop: ERR_remove_thread_state(NULL) (6348) > OPENSSL_INIT: OPENSSL_thread_stop: starting (5324) > OPENSSL_INIT: ossl_init_get_thread_local: Starting: Local value is NULL, > alloc is 0 (5324) > OPENSSL_INIT: ossl_init_get_thread_local: Clearing Thread Locals (5324) > OPENSSL_INIT: ossl_init_get_thread_local: Ending: Local value is NULL, alloc > is 0 (5324) > OPENSSL_INIT: ossl_init_thread_stop: starting (5324) > OPENSSL_INIT: ossl_init_thread_stop: locals are NULL returning (5324) > OPENSSL_INIT: OPENSSL_thread_stop: ending (5324) > OPENSSL_INIT: ossl_init_thread_stop: end (6348) > OPENSSL_INIT: OPENSSL_thread_stop: ending (6348) > > Thread serveur 5324 termine > Thread client 6348 termine > > OPENSSL_INIT: ossl_init_get_thread_local: Starting: Local value is NULL, > alloc is 0 (6240) > OPENSSL_INIT: ossl_init_get_thread_local: Clearing Thread Locals (6240) > OPENSSL_INIT: ossl_init_get_thread_local: Ending: Local value is NULL, alloc > is 0 (6240) > OPENSSL_INIT: ossl_init_thread_stop: starting (6240) > OPENSSL_INIT: ossl_init_thread_stop: locals are NULL returning (6240) > OPENSSL_INIT: ssl_library_stop: SSL_COMP_free_compression_methods() > OPENSSL_INIT: ssl_library_stop: ERR_free_strings() > OPENSSL_INIT: OPENSSL_cleanup: ERR_free_strings() > OPENSSL_INIT: OPENSSL_INIT_library_stop: CRYPTO_cleanup_all_ex_data() > OPENSSL_INIT: OPENSSL_INIT_library_stop: EVP_cleanup() > OPENSSL_INIT: OPENSSL_INIT_library_stop: CONF_modules_free() > OPENSSL_INIT: OPENSSL_INIT_library_stop: RAND_cleanup() > Assertion failed: !bLeak, file p:\mes > programmes\tests\_testsshared\teststls-11\testtls.cpp, line 165 > > Detected memory leaks! > Dumping objects -> > {7025} normal block at 0x00A75628, 8 bytes long. > Data: < > 00 00 00 00 01 00 00 00 > {5009} normal block at 0x00A3CB88, 12 bytes long. > Data: < 4 > A8 0C A4 00 00 00 00 00 C0 34 01 00 > {5008} normal block at 0x00A40CA8, 400 bytes long. > Data: < > 00 00 00 00 C0 17 00 00 00 00 00 00 00 00 00 00 > {5003} normal block at 0x00A3CCB8, 64 bytes long. > Data: < > 88 CB A3 00 00 00 00 00 00 00 00 00 00 00 00 00 > {5001} normal block at 0x00A3C9B0, 96 bytes long. > Data: < P9P p9P > B8 CC A3 00 50 39 50 00 70 39 50 00 08 00 00 00 > Object dump complete. > > WARNING: Visual Leak Detector detected memory leaks! > ---------- Block 4993 at 0x00A3C9B0: 96 bytes ---------- > Leak Hash: 0x7CDBED0B, Count: 1, Total 96 bytes > Call Stack (TID 4804): > ntdll.dll!RtlAllocateHeap() > f:\dd\vctools\crt\crtw32\misc\dbgmalloc.c (56): TestsTLS-11.exe!malloc() > + 0x15 bytes > e:\openssl-1.1.git\crypto\mem.c (141): TestsTLS-11.exe!CRYPTO_malloc() + > 0x9 bytes > e:\openssl-1.1.git\crypto\mem.c (161): TestsTLS-11.exe!CRYPTO_zalloc() + > 0x11 bytes > e:\openssl-1.1.git\crypto\lhash\lhash.c (116): TestsTLS-11.exe!lh_new() > + 0xE bytes > e:\openssl-1.1.git\crypto\err\err_lcl.h (2): > TestsTLS-11.exe!lh_ERR_STATE_new() + 0x10 bytes > e:\openssl-1.1.git\crypto\err\err.c (321): > TestsTLS-11.exe!int_thread_get() + 0xF bytes > e:\openssl-1.1.git\crypto\err\err.c (369): > TestsTLS-11.exe!int_thread_set_item() + 0x9 bytes > e:\openssl-1.1.git\crypto\err\err.c (884): > TestsTLS-11.exe!ERR_get_state() + 0xC bytes > e:\openssl-1.1.git\crypto\err\err.c (598): > TestsTLS-11.exe!ERR_clear_error() + 0x5 bytes > e:\openssl-1.1.git\ssl\statem\statem.c (279): > TestsTLS-11.exe!state_machine() > e:\openssl-1.1.git\ssl\statem\statem.c (217): > TestsTLS-11.exe!ossl_statem_connect() + 0xB bytes > e:\openssl-1.1.git\ssl\ssl_lib.c (2905): > TestsTLS-11.exe!SSL_do_handshake() + 0xC bytes > p:\mes programmes\shared\ocrypto-11\tls.cpp (953): > TestsTLS-11.exe!OTLS::TLSSss::DoHandshake() + 0xC bytes > p:\mes programmes\tests\_testsshared\teststls-11\clttasks.cpp (64): > TestsTLS-11.exe!CltThread::Main() + 0xB bytes > p:\mes programmes\shared\sthread.cpp (17): > TestsTLS-11.exe!SThread::Run() + 0xE bytes > f:\dd\vctools\crt\crtw32\startup\threadex.c (359): > TestsTLS-11.exe!_threadstartex() > > > ---------- Block 5001 at 0x00A3CB88: 12 bytes ---------- > Leak Hash: 0xE9B700C5, Count: 1, Total 12 bytes > Call Stack (TID 6080): > ntdll.dll!RtlAllocateHeap() > f:\dd\vctools\crt\crtw32\misc\dbgmalloc.c (56): TestsTLS-11.exe!malloc() > + 0x15 bytes > e:\openssl-1.1.git\crypto\mem.c (141): TestsTLS-11.exe!CRYPTO_malloc() + > 0x9 bytes > e:\openssl-1.1.git\crypto\lhash\lhash.c (168): > TestsTLS-11.exe!lh_insert() + 0x11 bytes > e:\openssl-1.1.git\crypto\err\err_lcl.h (2): > TestsTLS-11.exe!lh_ERR_STATE_insert() + 0x10 bytes > e:\openssl-1.1.git\crypto\err\err.c (371): > TestsTLS-11.exe!int_thread_set_item() + 0xD bytes > e:\openssl-1.1.git\crypto\err\err.c (884): > TestsTLS-11.exe!ERR_get_state() + 0xC bytes > e:\openssl-1.1.git\crypto\err\err.c (598): > TestsTLS-11.exe!ERR_clear_error() + 0x5 bytes > e:\openssl-1.1.git\ssl\statem\statem.c (279): > TestsTLS-11.exe!state_machine() > e:\openssl-1.1.git\ssl\statem\statem.c (222): > TestsTLS-11.exe!ossl_statem_accept() + 0xB bytes > e:\openssl-1.1.git\ssl\ssl_lib.c (2905): > TestsTLS-11.exe!SSL_do_handshake() + 0xC bytes > p:\mes programmes\shared\ocrypto-11\tls.cpp (953): > TestsTLS-11.exe!OTLS::TLSSss::DoHandshake() + 0xC bytes > p:\mes programmes\tests\_testsshared\teststls-11\srvtasks.cpp (79): > TestsTLS-11.exe!SrvThread::Main() + 0xB bytes > p:\mes programmes\shared\sthread.cpp (17): > TestsTLS-11.exe!SThread::Run() + 0xE bytes > f:\dd\vctools\crt\crtw32\startup\threadex.c (359): > TestsTLS-11.exe!_threadstartex() > > > ---------- Block 4995 at 0x00A3CCB8: 64 bytes ---------- > Leak Hash: 0x8337F4DE, Count: 1, Total 64 bytes > Call Stack (TID 4804): > ntdll.dll!RtlAllocateHeap() > f:\dd\vctools\crt\crtw32\misc\dbgmalloc.c (56): TestsTLS-11.exe!malloc() > + 0x15 bytes > e:\openssl-1.1.git\crypto\mem.c (141): TestsTLS-11.exe!CRYPTO_malloc() + > 0x9 bytes > e:\openssl-1.1.git\crypto\mem.c (161): TestsTLS-11.exe!CRYPTO_zalloc() + > 0x11 bytes > e:\openssl-1.1.git\crypto\lhash\lhash.c (118): TestsTLS-11.exe!lh_new() > + 0xE bytes > e:\openssl-1.1.git\crypto\err\err_lcl.h (2): > TestsTLS-11.exe!lh_ERR_STATE_new() + 0x10 bytes > e:\openssl-1.1.git\crypto\err\err.c (321): > TestsTLS-11.exe!int_thread_get() + 0xF bytes > e:\openssl-1.1.git\crypto\err\err.c (369): > TestsTLS-11.exe!int_thread_set_item() + 0x9 bytes > e:\openssl-1.1.git\crypto\err\err.c (884): > TestsTLS-11.exe!ERR_get_state() + 0xC bytes > e:\openssl-1.1.git\crypto\err\err.c (598): > TestsTLS-11.exe!ERR_clear_error() + 0x5 bytes > e:\openssl-1.1.git\ssl\statem\statem.c (279): > TestsTLS-11.exe!state_machine() > e:\openssl-1.1.git\ssl\statem\statem.c (217): > TestsTLS-11.exe!ossl_statem_connect() + 0xB bytes > e:\openssl-1.1.git\ssl\ssl_lib.c (2905): > TestsTLS-11.exe!SSL_do_handshake() + 0xC bytes > p:\mes programmes\shared\ocrypto-11\tls.cpp (953): > TestsTLS-11.exe!OTLS::TLSSss::DoHandshake() + 0xC bytes > p:\mes programmes\tests\_testsshared\teststls-11\clttasks.cpp (64): > TestsTLS-11.exe!CltThread::Main() + 0xB bytes > p:\mes programmes\shared\sthread.cpp (17): > TestsTLS-11.exe!SThread::Run() + 0xE bytes > f:\dd\vctools\crt\crtw32\startup\threadex.c (359): > TestsTLS-11.exe!_threadstartex() > > > ---------- Block 5000 at 0x00A40CA8: 400 bytes ---------- > Leak Hash: 0x2037555F, Count: 1, Total 400 bytes > Call Stack (TID 6080): > ntdll.dll!RtlAllocateHeap() > f:\dd\vctools\crt\crtw32\misc\dbgmalloc.c (56): TestsTLS-11.exe!malloc() > + 0x15 bytes > e:\openssl-1.1.git\crypto\mem.c (141): TestsTLS-11.exe!CRYPTO_malloc() + > 0x9 bytes > e:\openssl-1.1.git\crypto\err\err.c (874): > TestsTLS-11.exe!ERR_get_state() + 0x14 bytes > e:\openssl-1.1.git\crypto\err\err.c (598): > TestsTLS-11.exe!ERR_clear_error() + 0x5 bytes > e:\openssl-1.1.git\ssl\statem\statem.c (279): > TestsTLS-11.exe!state_machine() > e:\openssl-1.1.git\ssl\statem\statem.c (222): > TestsTLS-11.exe!ossl_statem_accept() + 0xB bytes > e:\openssl-1.1.git\ssl\ssl_lib.c (2905): > TestsTLS-11.exe!SSL_do_handshake() + 0xC bytes > p:\mes programmes\shared\ocrypto-11\tls.cpp (953): > TestsTLS-11.exe!OTLS::TLSSss::DoHandshake() + 0xC bytes > p:\mes programmes\tests\_testsshared\teststls-11\srvtasks.cpp (79): > TestsTLS-11.exe!SrvThread::Main() + 0xB bytes > p:\mes programmes\shared\sthread.cpp (17): > TestsTLS-11.exe!SThread::Run() + 0xE bytes > f:\dd\vctools\crt\crtw32\startup\threadex.c (359): > TestsTLS-11.exe!_threadstartex() > > > ---------- Block 7017 at 0x00A75628: 8 bytes ---------- > Leak Hash: 0x82CA3A37, Count: 1, Total 8 bytes > Call Stack (TID 6080): > ntdll.dll!RtlAllocateHeap() > f:\dd\vctools\crt\crtw32\misc\dbgmalloc.c (56): TestsTLS-11.exe!malloc() > + 0x15 bytes > e:\openssl-1.1.git\crypto\mem.c (141): TestsTLS-11.exe!CRYPTO_malloc() + > 0x9 bytes > e:\openssl-1.1.git\crypto\mem.c (161): TestsTLS-11.exe!CRYPTO_zalloc() + > 0x11 bytes > e:\openssl-1.1.git\crypto\init.c (212): > TestsTLS-11.exe!ossl_init_get_thread_local() + 0x11 bytes > e:\openssl-1.1.git\crypto\init.c (568): > TestsTLS-11.exe!ossl_init_thread_start() + 0x7 bytes > e:\openssl-1.1.git\crypto\err\err.c (898): > TestsTLS-11.exe!ERR_get_state() + 0x9 bytes > e:\openssl-1.1.git\crypto\err\err.c (598): > TestsTLS-11.exe!ERR_clear_error() + 0x5 bytes > e:\openssl-1.1.git\ssl\statem\statem.c (279): > TestsTLS-11.exe!state_machine() > e:\openssl-1.1.git\ssl\statem\statem.c (222): > TestsTLS-11.exe!ossl_statem_accept() + 0xB bytes > e:\openssl-1.1.git\ssl\ssl_lib.c (2905): > TestsTLS-11.exe!SSL_do_handshake() + 0xC bytes > p:\mes programmes\shared\ocrypto-11\tls.cpp (953): > TestsTLS-11.exe!OTLS::TLSSss::DoHandshake() + 0xC bytes > p:\mes programmes\tests\_testsshared\teststls-11\srvtasks.cpp (79): > TestsTLS-11.exe!SrvThread::Main() + 0xB bytes > p:\mes programmes\shared\sthread.cpp (17): > TestsTLS-11.exe!SThread::Run() + 0xE bytes > f:\dd\vctools\crt\crtw32\startup\threadex.c (359): > TestsTLS-11.exe!_threadstartex() > > > Visual Leak Detector detected 5 memory leaks (16416 bytes). > Largest number used: 442154 bytes. > Total allocations: 1908126 bytes. > > -------------- next part -------------- A non-text attachment was scrubbed... Name: fix-win-thread-stop.patch Type: text/x-patch Size: 1081 bytes Desc: not available URL: From rt at openssl.org Thu Feb 18 12:27:49 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 18 Feb 2016 12:27:49 +0000 Subject: [openssl-dev] [openssl.org #2460] OCSP server uses only IP6 In-Reply-To: <4D6623AB.8070304@mobica.com> References: <4D597C56.5020903@nist.gov> <4D6623AB.8070304@mobica.com> Message-ID: fixed with full ipv6 support in master. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2460 Please log in as guest with password guest if prompted From gvanem at yahoo.no Thu Feb 18 12:38:56 2016 From: gvanem at yahoo.no (Gisle Vanem) Date: Thu, 18 Feb 2016 13:38:56 +0100 Subject: [openssl-dev] ssl/t1_enc.c with TLS_DEBUG Message-ID: <56C5BB60.8040303@yahoo.no> The ssl/t1_enc.c file doesn't compile with '-DTLS_DEBUG': ssl/t1_enc.c: In function 'tls1_setup_key_block': ssl/t1_enc.c:528:30: error: 'p1' undeclared (first use in this function) printf("%02X%c", p1[z], ((z + 1) % 16) ? ' ' : '\n'); I assume that should be: printf("%02X%c", p[z], ((z + 1) % 16) ? ' ' : '\n'); Besides, enabling '-DCIPHER_DEBUG', also generates lots of warnings. -- --gv From rsalz at akamai.com Thu Feb 18 12:48:21 2016 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 18 Feb 2016 12:48:21 +0000 Subject: [openssl-dev] ssl/t1_enc.c with TLS_DEBUG In-Reply-To: <56C5BB60.8040303@yahoo.no> References: <56C5BB60.8040303@yahoo.no> Message-ID: <74c368e3c2774be28552db734e2dc456@ustx2ex-dag1mb1.msg.corp.akamai.com> > The ssl/t1_enc.c file doesn't compile with '-DTLS_DEBUG': > Besides, enabling '-DCIPHER_DEBUG', also generates lots of warnings. Does the attached patch fix it? -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: diff.txt URL: From gvanem at yahoo.no Thu Feb 18 12:58:53 2016 From: gvanem at yahoo.no (Gisle Vanem) Date: Thu, 18 Feb 2016 13:58:53 +0100 Subject: [openssl-dev] ssl/t1_enc.c with TLS_DEBUG In-Reply-To: <74c368e3c2774be28552db734e2dc456@ustx2ex-dag1mb1.msg.corp.akamai.com> References: <56C5BB60.8040303@yahoo.no> <74c368e3c2774be28552db734e2dc456@ustx2ex-dag1mb1.msg.corp.akamai.com> Message-ID: <56C5C00D.2090006@yahoo.no> Rich Salz wrote: > #ifdef CIPHER_DEBUG > fprintf(stderr, > - "Applying rule %d with %08lx/%08lx/%08lx/%08lx/%08lx %08lx (%d)\n", > + "Applying rule %d with %08x/%08x/%08x/%08x/%08x %08x (%d)\n", > rule, alg_mkey, alg_auth, alg_enc, alg_mac, alg_ssl, > algo_strength, strength_bits); > #endif > @@ -936,7 +936,7 @@ static void ssl_cipher_apply_rule(uint32_t cipher_id, uint32_t alg_mkey, > } else { > #ifdef CIPHER_DEBUG > fprintf(stderr, > - "\nName: %s:\nAlgo = %08lx/%08lx/%08lx/%08lx/%08lx Algo_strength = %08lx\n", > + "\nName: %s:\nAlgo = %08x/%08x/%08x/%08x/%08x Algo_strength = %08x\n", > cp->name, cp->algorithm_mkey, cp->algorithm_auth, Perfect here on TDM-gcc. -- --gv From michel.sales at free.fr Thu Feb 18 13:59:06 2016 From: michel.sales at free.fr (Michel) Date: Thu, 18 Feb 2016 14:59:06 +0100 Subject: [openssl-dev] memory leaks detected using libSSL 1.1 In-Reply-To: <56C5B88D.6090208@openssl.org> References: <000001d166ac$9660f640$c322e2c0$@sales@free.fr> <56BFBC88.1010901@openssl.org> <000001d166bc$308f5680$91ae0380$@sales@free.fr> <56C25BFD.3060708@openssl.org> <006001d16911$5fd1a3b0$1f74eb10$@sales@free.fr> <56C49E57.5060407@openssl.org> <009d01d169e1$3402c590$9c0850b0$@sales@free.fr> <56C59A49.6060205@openssl.org> <001601d16a40$ce772120$6b656360$@sales@free.fr> <56C5B88D.6090208@openssl.org> Message-ID: <003201d16a54$886c96b0$9945c410$@sales@free.fr> Yes ! With your 2 patches applied, tls_decrypt_ticket.patch and fix-win-thread-stop.patch, (looks like I lost the first one yesterday), none of my tests programs using libSSL v1.1 reports leaks. I feel better. :-) Thank you Matt. Regards, Michel. -----Message d'origine----- De?: openssl-dev [mailto:openssl-dev-bounces at openssl.org] De la part de Matt Caswell Envoy??: jeudi 18 f?vrier 2016 13:27 ??: openssl-dev at openssl.org Objet?: Re: [openssl-dev] memory leaks detected using libSSL 1.1 On 18/02/16 11:37, Michel wrote: > Hi Matt, > > Here under is the new results after applying your patch. > Let me know anything I could do to investigate deeper. Thanks. That was very helpful. I think I may have identified the issue. Please can you try the attached patch and see if that fixes things? Thanks Matt From matt at openssl.org Thu Feb 18 14:06:42 2016 From: matt at openssl.org (Matt Caswell) Date: Thu, 18 Feb 2016 14:06:42 +0000 Subject: [openssl-dev] memory leaks detected using libSSL 1.1 In-Reply-To: <003201d16a54$886c96b0$9945c410$@sales@free.fr> References: <000001d166ac$9660f640$c322e2c0$@sales@free.fr> <56BFBC88.1010901@openssl.org> <000001d166bc$308f5680$91ae0380$@sales@free.fr> <56C25BFD.3060708@openssl.org> <006001d16911$5fd1a3b0$1f74eb10$@sales@free.fr> <56C49E57.5060407@openssl.org> <009d01d169e1$3402c590$9c0850b0$@sales@free.fr> <56C59A49.6060205@openssl.org> <001601d16a40$ce772120$6b656360$@sales@free.fr> <56C5B88D.6090208@openssl.org> <003201d16a54$886c96b0$9945c410$@sales@free.fr> Message-ID: <56C5CFF2.3090407@openssl.org> On 18/02/16 13:59, Michel wrote: > Yes ! > With your 2 patches applied, tls_decrypt_ticket.patch and > fix-win-thread-stop.patch, > (looks like I lost the first one yesterday), > none of my tests programs using libSSL v1.1 reports leaks. > > I feel better. :-) Great. I'll get those reviewed and committed. Matt From rsalz at akamai.com Thu Feb 18 15:26:04 2016 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 18 Feb 2016 15:26:04 +0000 Subject: [openssl-dev] OPENSSL_config with default configuration In-Reply-To: <56C37E65.3010204@roumenpetrov.info> References: <56C37E65.3010204@roumenpetrov.info> Message-ID: <48de1616a4fb42a0a731c667d3e662b4@ustx2ex-dag1mb1.msg.corp.akamai.com> > OPENSSL_config with NULL argument crash in master branch. > Please find attached file with proposed patch. Fixed with commit 4015adf0a3d352cc4013c722f1b2d5374989ac4c; thanks! From rt at openssl.org Thu Feb 18 18:37:32 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Thu, 18 Feb 2016 18:37:32 +0000 Subject: [openssl-dev] [openssl.org #4267] Missing accessor to the EVP_CIPHER_CTX member oiv In-Reply-To: References: Message-ID: Did that help, can we close this ticket now? Vid Ons, 17 Feb 2016 kl. 11.25.26, skrev levitte: > May I suggest that you use EVP_CIPHER_set_asn1_iv() and/or > EVP_CIPHER_get_asn1_iv()? With a temporary ASN1_TYPE to which you > assign > gcp->iv, that should be perfectly possible, no? > > Cheers, > Richard > > Vid Ons, 17 Feb 2016 kl. 09.53.04, skrev beldmit at gmail.com: > > Dear Richard, > > > > I am not sure it will not break the compatibility. > > Both implementations of the GOST ciphers require access to this > > field. > > > > On Wed, Feb 17, 2016 at 12:42 PM, Richard Levitte via RT > > > > wrote: > > > > > Hi, > > > > > > I'm sorry, the oiv field is EVP private. Sure, it's been accessible > > > (and > > > thoroughly misused in some cases) when EVP_CIPHER_CTX was open, but > > > in > > > essence, > > > it's a EVP private store of the IV that was given at > > > EVP_CipherInit(). > > > > > > If you want to retain a copy of the original IV, I suggest you have > > > one in > > > GOSTs structure and take a copy of the IV given to the init() > > > function. > > > > > > Thank you for the reminder, I meant to deal with this further. oiv > > > should > > > really not be publically accessible at all, not even as a constant. > > > > > > Cheers, > > > Richard > > > > > > Vid Sat, 23 Jan 2016 kl. 09.40.19, skrev beldmit at gmail.com: > > > > Hello, > > > > > > > > After making the EVP_CIPHER_CTX struct opaque I found that there > > > > is a > > > > missing non-const accessor to the oiv member. It is used in GOST > > > > engine > > > > when we set the cipher parameters from the ASN1 parameters. > > > > > > > > Thank you! > > > > > > > > > > > > > -- > > > Richard Levitte > > > levitte at openssl.org > > > > > > -- > > > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4267 > > > Please log in as guest with password guest if prompted > > > > > > > > > > > > > -- > Richard Levitte > levitte at openssl.org -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4267 Please log in as guest with password guest if prompted From rsalz at akamai.com Thu Feb 18 20:41:33 2016 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 18 Feb 2016 20:41:33 +0000 Subject: [openssl-dev] duplicate opt* declaration in apps.h In-Reply-To: <56C37D22.2090208@roumenpetrov.info> References: <56C37D22.2090208@roumenpetrov.info> Message-ID: Thanks, fix just pushed to master. From rt at openssl.org Thu Feb 18 21:40:50 2016 From: rt at openssl.org (Dmitry Belyavsky via RT) Date: Thu, 18 Feb 2016 21:40:50 +0000 Subject: [openssl-dev] [openssl.org #4321] Re: Missing accessor to the EVP_CIPHER_CTX member oiv In-Reply-To: References: Message-ID: Dear Richard, Sorry for the delay. I am out of office now so I will check it some days later. On Thursday, February 18, 2016, Richard Levitte via RT wrote: > Did that help, can we close this ticket now? > > Vid Ons, 17 Feb 2016 kl. 11.25.26, skrev levitte: > > May I suggest that you use EVP_CIPHER_set_asn1_iv() and/or > > EVP_CIPHER_get_asn1_iv()? With a temporary ASN1_TYPE to which you > > assign > > gcp->iv, that should be perfectly possible, no? > > > > Cheers, > > Richard > > > > Vid Ons, 17 Feb 2016 kl. 09.53.04, skrev beldmit at gmail.com > : > > > Dear Richard, > > > > > > I am not sure it will not break the compatibility. > > > Both implementations of the GOST ciphers require access to this > > > field. > > > > > > On Wed, Feb 17, 2016 at 12:42 PM, Richard Levitte via RT > > > > > > > wrote: > > > > > > > Hi, > > > > > > > > I'm sorry, the oiv field is EVP private. Sure, it's been accessible > > > > (and > > > > thoroughly misused in some cases) when EVP_CIPHER_CTX was open, but > > > > in > > > > essence, > > > > it's a EVP private store of the IV that was given at > > > > EVP_CipherInit(). > > > > > > > > If you want to retain a copy of the original IV, I suggest you have > > > > one in > > > > GOSTs structure and take a copy of the IV given to the init() > > > > function. > > > > > > > > Thank you for the reminder, I meant to deal with this further. oiv > > > > should > > > > really not be publically accessible at all, not even as a constant. > > > > > > > > Cheers, > > > > Richard > > > > > > > > Vid Sat, 23 Jan 2016 kl. 09.40.19, skrev beldmit at gmail.com > : > > > > > Hello, > > > > > > > > > > After making the EVP_CIPHER_CTX struct opaque I found that there > > > > > is a > > > > > missing non-const accessor to the oiv member. It is used in GOST > > > > > engine > > > > > when we set the cipher parameters from the ASN1 parameters. > > > > > > > > > > Thank you! > > > > > > > > > > > > > > > > > -- > > > > Richard Levitte > > > > levitte at openssl.org > > > > > > > > -- > > > > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4267 > > > > Please log in as guest with password guest if prompted > > > > > > > > > > > > > > > > > > > > -- > > Richard Levitte > > levitte at openssl.org > > > -- > Richard Levitte > levitte at openssl.org > > -- > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4267 > Please log in as guest with password guest if prompted > > -- SY, Dmitry Belyavsky -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4321 Please log in as guest with password guest if prompted From rt at openssl.org Thu Feb 18 22:19:02 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 18 Feb 2016 22:19:02 +0000 Subject: [openssl-dev] [openssl.org #4312] documentation: RSA_new_method argument In-Reply-To: <56C37D98.8030009@roumenpetrov.info> References: <56C37D98.8030009@roumenpetrov.info> Message-ID: pushed in commit 6baa3b430555d25b6eee6440a6b8bee80eaabfc3 thanks. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4312 Please log in as guest with password guest if prompted From dwmw2 at infradead.org Fri Feb 19 00:20:48 2016 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 19 Feb 2016 00:20:48 +0000 Subject: [openssl-dev] [openssl.org #3964] Fix OPENSSL_NO_STDIO build In-Reply-To: References: <1438170735.26511.33.camel@intel.com> <1454690069.4788.309.camel@infradead.org> <1455730720.4735.45.camel@infradead.org> Message-ID: <1455841248.4735.164.camel@infradead.org> On Wed, 2016-02-17 at 17:43 +0000, Salz, Rich wrote: > > It looks like we're in fairly good shape for the OpenSSL 1.1.0 release > > to work "out of the box". > > That will be great. > ? > > I would like to see what we can do in the way of automated testing, > > though. It should be possible to at least have Travis-CI make > > libcrypto.so for the Linux target, with the 'no-everything' options > > that UEFI uses. It's a blunt instrument, but would have caught quite a > > few of the things I've just fixed, I think. > > I think UEFI is important and would be willing to add a build to our travis.? Make a PR :) I think the simplest build test looks something like this: ./Configure linux-x86_64 no-asm no-async no-bf no-camellia no-capieng \ ? no-cast no-cms no-ct no-deprecated no-dgram no-dsa \ ? no-dynamic-engine no-ec no-engine no-err no-filenames no-hw \ ? no-idea no-locking no-mdc2 no-posix-io no-rc2 no-rfc3779 no-ripemd \ ? no-scrypt no-sct no-seed no-sock no-srp no-ssl no-stdio no-threads \ ? no-ts no-ui no-whirlpool shared ? ? && ? ? ?make build_libcrypto I'll try to work out how to put that into travis. Once the fixes for RT4309 and RT4715 are merged, I'll also look at testing actual EDK2 builds with the nightly snapshots. -- David Woodhouse Open Source Technology Centre David.Woodhouse at intel.com Intel Corporation -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5691 bytes Desc: not available URL: From rt at openssl.org Fri Feb 19 11:25:00 2016 From: rt at openssl.org (Matt Caswell via RT) Date: Fri, 19 Feb 2016 11:25:00 +0000 Subject: [openssl-dev] [openssl.org #1736] Enhancement Request: do away with error in chil engine in absence of dynamic locks In-Reply-To: <2312B038-BF08-4697-8D7E-19ECF02FA68B@temme.net> References: <4C40DBBD-B2FD-4EBF-830C-95BF93799853@temme.net> <2312B038-BF08-4697-8D7E-19ECF02FA68B@temme.net> Message-ID: Looks like the last suggested patch against this ticket was applied. No further activity since 2008, so assuming this is resolved. Closing. Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=1736 Please log in as guest with password guest if prompted From matt at openssl.org Fri Feb 19 11:31:06 2016 From: matt at openssl.org (Matt Caswell) Date: Fri, 19 Feb 2016 11:31:06 +0000 Subject: [openssl-dev] Ubsec and Chil engines Message-ID: <56C6FCFA.4040602@openssl.org> Hi all The ubsec and chil engines are currently disabled in 1.1.0 and do not build. As far as ubsec is concerned I understand that this is an engine for broadcom cards. There has been very little activity with this engine since it was first introduced. Google brings up some very old historic references to its use. There are a couple of more recent references. This post from 2014 suggests that OpenSSL's support for this is broken anyway and has been for some while: https://forum.pfsense.org/index.php?topic=71857.0 There is also this post from 2013 from someone trying to get it to work but with no (apparent) success: https://stackoverflow.com/questions/17715546/openssl-speed-test-for-broadcom-engine So for ubsec I can't find any evidence that it is being used successfully. For chil I found this dicussion from 2012 on openssl-users where apparently someone was using it (successfully): http://openssl.6102.n7.nabble.com/Tutorials-on-OpenSSL-integration-with-nCipher-HSM-nShield-td2311.html This RT ticket from 2008 is suggesting various fixes - the last of which was applied. There was a brief flurry of commits tweaking stuff in chil around this time: https://rt.openssl.org/Ticket/Display.html?id=1736 So it seems that for chil there may possibly be some rare use (but even the most recent evidence is 4 years old). However the OpenSSL dev team do not have access to this hardware to maintain the engine and (as noted above) this is currently not building in 1.1.0. In both cases I would like to remove these engines from 1.1.0. I'd like to hear from the community if there is any active use of these. One option if there is found to be some small scale use is to spin out the engine into a separately managed repo (as has happened recently with the GOST engine). If I don't hear from anyone I will remove these. Matt From tmraz at redhat.com Fri Feb 19 13:03:44 2016 From: tmraz at redhat.com (Tomas Mraz) Date: Fri, 19 Feb 2016 14:03:44 +0100 Subject: [openssl-dev] Ubsec and Chil engines In-Reply-To: <56C6FCFA.4040602@openssl.org> References: <56C6FCFA.4040602@openssl.org> Message-ID: <1455887024.912.17.camel@redhat.com> On P?, 2016-02-19 at 11:31 +0000, Matt Caswell wrote: > So it seems that for chil there may possibly be some rare use (but > even > the most recent evidence is 4 years old). However the OpenSSL dev > team > do not have access to this hardware to maintain the engine and (as > noted > above) this is currently not building in 1.1.0. > > In both cases I would like to remove these engines from 1.1.0. I'd > like > to hear from the community if there is any active use of these. One > option if there is found to be some small scale use is to spin out > the > engine into a separately managed repo (as has happened recently with > the > GOST engine). > > If I don't hear from anyone I will remove these. As far as I know there are some customers using the Chil engine with RHEL (openssl-1.0.1).? --? Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb (You'll never know whether the road is wrong though.) From jaroslav.imrich at gmail.com Fri Feb 19 13:11:24 2016 From: jaroslav.imrich at gmail.com (Jaroslav Imrich) Date: Fri, 19 Feb 2016 14:11:24 +0100 Subject: [openssl-dev] Ubsec and Chil engines In-Reply-To: <56C6FCFA.4040602@openssl.org> References: <56C6FCFA.4040602@openssl.org> Message-ID: Hello Matt, If I don't hear from anyone I will remove these. > I can confirm that CHIL engine is actively used with OpenSSL 1.0.* by the owners of nCipher/THALES nShield HSMs. I have notified vendor support about this thread. Regards, Jaroslav -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Fri Feb 19 13:12:28 2016 From: matt at openssl.org (Matt Caswell) Date: Fri, 19 Feb 2016 13:12:28 +0000 Subject: [openssl-dev] Ubsec and Chil engines In-Reply-To: <1455887024.912.17.camel@redhat.com> References: <56C6FCFA.4040602@openssl.org> <1455887024.912.17.camel@redhat.com> Message-ID: <56C714BC.3060307@openssl.org> On 19/02/16 13:03, Tomas Mraz wrote: > On P?, 2016-02-19 at 11:31 +0000, Matt Caswell wrote: > > >> So it seems that for chil there may possibly be some rare use (but >> even >> the most recent evidence is 4 years old). However the OpenSSL dev >> team >> do not have access to this hardware to maintain the engine and (as >> noted >> above) this is currently not building in 1.1.0. >> >> In both cases I would like to remove these engines from 1.1.0. I'd >> like >> to hear from the community if there is any active use of these. One >> option if there is found to be some small scale use is to spin out >> the >> engine into a separately managed repo (as has happened recently with >> the >> GOST engine). >> >> If I don't hear from anyone I will remove these. > > As far as I know there are some customers using the Chil engine with > RHEL (openssl-1.0.1). How do you feel about the engine being spun out into a separate repo? That of course assumes that a volunteer can be found to maintain it (I don't believe anyone on the dev team wishes to do so). If no such volunteer can be found how big a deal is it to remove it from 1.1.0 without a replacement? Obviously it won't be taken out of 1.0.1/1.0.2. Of course there's no reason, even if we take it out now, that if someone needs it badly enough in the future that they couldn't forward port the 1.0.2 version to 1.1.0 and maintain it themselves at that point. Matt From matt at openssl.org Fri Feb 19 13:14:50 2016 From: matt at openssl.org (Matt Caswell) Date: Fri, 19 Feb 2016 13:14:50 +0000 Subject: [openssl-dev] Ubsec and Chil engines In-Reply-To: References: <56C6FCFA.4040602@openssl.org> Message-ID: <56C7154A.80304@openssl.org> On 19/02/16 13:11, Jaroslav Imrich wrote: > Hello Matt, > > If I don't hear from anyone I will remove these. > > > I can confirm that CHIL engine is actively used with OpenSSL 1.0.* by > the owners of nCipher/THALES nShield HSMs. > > I have notified vendor support about this thread. > Great. Thanks Jaroslav. It would be good if the vendor could take on support of the engine themselves. Matt From levitte at openssl.org Fri Feb 19 13:37:27 2016 From: levitte at openssl.org (Richard Levitte) Date: Fri, 19 Feb 2016 14:37:27 +0100 Subject: [openssl-dev] Ubsec and Chil engines In-Reply-To: <56C714BC.3060307@openssl.org> References: <56C6FCFA.4040602@openssl.org> <1455887024.912.17.camel@redhat.com> <56C714BC.3060307@openssl.org> Message-ID: <237A197D-B53F-48FF-A3F1-5EA73A6D112A@openssl.org> Matt Caswell skrev: (19 februari 2016 14:12:28 CET) > > >On 19/02/16 13:03, Tomas Mraz wrote: >> On P?, 2016-02-19 at 11:31 +0000, Matt Caswell wrote: >> >> >>> So it seems that for chil there may possibly be some rare use (but >>> even >>> the most recent evidence is 4 years old). However the OpenSSL dev >>> team >>> do not have access to this hardware to maintain the engine and (as >>> noted >>> above) this is currently not building in 1.1.0. >>> >>> In both cases I would like to remove these engines from 1.1.0. I'd >>> like >>> to hear from the community if there is any active use of these. One >>> option if there is found to be some small scale use is to spin out >>> the >>> engine into a separately managed repo (as has happened recently with >>> the >>> GOST engine). >>> >>> If I don't hear from anyone I will remove these. >> >> As far as I know there are some customers using the Chil engine with >> RHEL (openssl-1.0.1). > >How do you feel about the engine being spun out into a separate repo? >That of course assumes that a volunteer can be found to maintain it (I >don't believe anyone on the dev team wishes to do so). Not so fast. I've my engine-corner on github that's intended for exactly this sort of thing. I'll happily help porting engines to become independent products. In my opinion, that will serve us all. Engine-corner is a personal project that has nothing to do with the team per se. Participation by anyone interested is welcome (frankly, engines that no one participates in *will* die, simple as that) > >If no such volunteer can be found how big a deal is it to remove it >from >1.1.0 without a replacement? Obviously it won't be taken out of >1.0.1/1.0.2. Of course there's no reason, even if we take it out now, >that if someone needs it badly enough in the future that they couldn't >forward port the 1.0.2 version to 1.1.0 and maintain it themselves at >that point. > >Matt > >-- >openssl-dev mailing list >To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From rt at openssl.org Fri Feb 19 13:58:34 2016 From: rt at openssl.org (Info via RT) Date: Fri, 19 Feb 2016 13:58:34 +0000 Subject: [openssl-dev] [openssl.org #4322] SSL_shutdown:shutdown while in init (1.0.2f) In-Reply-To: <19723783.214.1455871493760.JavaMail.SYSTEM@ECSHX2> References: <32989295.15.1360597074634.JavaMail.SYSTEM@ECSHX2> <19723783.214.1455871493760.JavaMail.SYSTEM@ECSHX2> Message-ID: openssl 1.0.2f static build with nginx 1.9.12 (development version) about https://github.com/openssl/openssl/commit/64193c8218540499984cd63cda41f3cd491f3f59 This may solve the initial issue but creates a new one: SSL_shutdown() failed (SSL: error:140E0197:SSL routines:SSL_shutdown:shutdown while in init) while SSL handshaking -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4322 Please log in as guest with password guest if prompted From rsalz at akamai.com Fri Feb 19 14:07:42 2016 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 19 Feb 2016 14:07:42 +0000 Subject: [openssl-dev] Ubsec and Chil engines In-Reply-To: <56C6FCFA.4040602@openssl.org> References: <56C6FCFA.4040602@openssl.org> Message-ID: > In both cases I would like to remove these engines from 1.1.0. I'd like to hear > from the community if there is any active use of these. One option if there is > found to be some small scale use is to spin out the engine into a separately > managed repo (as has happened recently with the GOST engine). Please do. I know Sander was interested in updating CHIL but never found time. That also removes the last remaining need for "dynamic locks" huzzah From levitte at openssl.org Fri Feb 19 14:35:38 2016 From: levitte at openssl.org (Richard Levitte) Date: Fri, 19 Feb 2016 15:35:38 +0100 Subject: [openssl-dev] Ubsec and Chil engines In-Reply-To: References: <56C6FCFA.4040602@openssl.org> Message-ID: <06384A1E-6815-4396-A72C-BEDBB48EADA9@openssl.org> "Salz, Rich" skrev: (19 februari 2016 15:07:42 CET) > >> In both cases I would like to remove these engines from 1.1.0. I'd >like to hear >> from the community if there is any active use of these. One option if >there is >> found to be some small scale use is to spin out the engine into a >separately >> managed repo (as has happened recently with the GOST engine). > >Please do. I know Sander was interested in updating CHIL but never >found time. > >That also removes the last remaining need for "dynamic locks" huzzah That should be removed either way. Engines should handle their own locks whatever way the programmer wants. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From rt at openssl.org Fri Feb 19 14:46:39 2016 From: rt at openssl.org (Matt Caswell via RT) Date: Fri, 19 Feb 2016 14:46:39 +0000 Subject: [openssl-dev] [openssl.org #4322] SSL_shutdown:shutdown while in init (1.0.2f) In-Reply-To: <19723783.214.1455871493760.JavaMail.SYSTEM@ECSHX2> References: <32989295.15.1360597074634.JavaMail.SYSTEM@ECSHX2> <19723783.214.1455871493760.JavaMail.SYSTEM@ECSHX2> Message-ID: On Fri Feb 19 13:58:34 2016, Info at ECSystems.nl wrote: > openssl 1.0.2f static build with nginx 1.9.12 (development version) > > about > https://github.com/openssl/openssl/commit/64193c8218540499984cd63cda41f3cd491f3f59 > > This may solve the initial issue but creates a new one: > SSL_shutdown() failed (SSL: error:140E0197:SSL > routines:SSL_shutdown:shutdown while in init) while SSL handshaking That is expected behaviour. The original behaviour returned a "success" result from SSL_shutdown() even though it had actually failed. The new behaviour reports that as an error. Closing this ticket. Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4322 Please log in as guest with password guest if prompted From nmav at redhat.com Fri Feb 19 14:53:39 2016 From: nmav at redhat.com (Nikos Mavrogiannopoulos) Date: Fri, 19 Feb 2016 15:53:39 +0100 Subject: [openssl-dev] Ubsec and Chil engines In-Reply-To: <56C714BC.3060307@openssl.org> References: <56C6FCFA.4040602@openssl.org> <1455887024.912.17.camel@redhat.com> <56C714BC.3060307@openssl.org> Message-ID: <1455893619.3919.62.camel@redhat.com> On Fri, 2016-02-19 at 13:12 +0000, Matt Caswell wrote: > As far as I know there are some customers using the Chil engine > > with > > RHEL (openssl-1.0.1).? > > How do you feel about the engine being spun out into a separate repo? > That of course assumes that a volunteer can be found to maintain it > (I > don't believe anyone on the dev team wishes to do so). > > If no such volunteer can be found how big a deal is it to remove it > from > 1.1.0 without a replacement? Obviously it won't be taken out of > 1.0.1/1.0.2. Of course there's no reason, even if we take it out now, > that if someone needs it badly enough in the future that they > couldn't forward port the 1.0.2 version to 1.1.0 and maintain it > themselves at that point. It may even be better, instead of pushing for different engines for different hardware, to make PKCS#11 the only API used to talk to hardware. There is a quite functional (and active as project) pkcs11 engine for openssl [0]. regards, Nikos [0].?https://github.com/OpenSC/engine_pkcs11 From uri at ll.mit.edu Fri Feb 19 16:14:04 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Fri, 19 Feb 2016 16:14:04 +0000 Subject: [openssl-dev] Ubsec and Chil engines Message-ID: <20160219161413.18296912.78417.52695@ll.mit.edu> +1.? With one exception: engine_pkcs11 has been subsumed (and merged into) libp11. I've tested it with a few different PIV tokens (RSA and ECC), and it was great. Sent?from?my?BlackBerry?10?smartphone?on?the Verizon?Wireless?4G?LTE?network. ? Original Message ? From: Nikos Mavrogiannopoulos Sent: Friday, February 19, 2016 09:53 To: openssl-dev at openssl.org Reply To: openssl-dev at openssl.org Subject: Re: [openssl-dev] Ubsec and Chil engines On Fri, 2016-02-19 at 13:12 +0000, Matt Caswell wrote: > As far as I know there are some customers using the Chil engine > > with > > RHEL (openssl-1.0.1).? > > How do you feel about the engine being spun out into a separate repo? > That of course assumes that a volunteer can be found to maintain it > (I > don't believe anyone on the dev team wishes to do so). > > If no such volunteer can be found how big a deal is it to remove it > from > 1.1.0 without a replacement? Obviously it won't be taken out of > 1.0.1/1.0.2. Of course there's no reason, even if we take it out now, > that if someone needs it badly enough in the future that they > couldn't forward port the 1.0.2 version to 1.1.0 and maintain it > themselves at that point. It may even be better, instead of pushing for different engines for different hardware, to make PKCS#11 the only API used to talk to hardware. There is a quite functional (and active as project) pkcs11 engine for openssl [0]. regards, Nikos [0].?https://github.com/OpenSC/engine_pkcs11 -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4350 bytes Desc: not available URL: From sugu.ece28 at gmail.com Fri Feb 19 16:13:44 2016 From: sugu.ece28 at gmail.com (Sugumar) Date: Fri, 19 Feb 2016 09:13:44 -0700 (MST) Subject: [openssl-dev] Problem in decryption using python which cipher text is encrypted in c++ Message-ID: <1455898424203-63825.post@n7.nabble.com> Hi, I have encrypted a free text in C++ using a EVP calls with CFB mode and 32 bytes of IV (Hex String). Then i am passing this cipher text to my another end which is using a python(PyCrypto library) code to decrypt a cipher text using same Key and IV. But i am getting error "IV must be of 16 bytes" in python. I tried to convert 32 bytes of Hex string to 16 bytes ascii string but nothing works. Please help me to resolve this. -- View this message in context: http://openssl.6102.n7.nabble.com/Problem-in-decryption-using-python-which-cipher-text-is-encrypted-in-c-tp63825.html Sent from the OpenSSL - Dev mailing list archive at Nabble.com. From rt at openssl.org Fri Feb 19 23:10:18 2016 From: rt at openssl.org (Felipe Sere via RT) Date: Fri, 19 Feb 2016 23:10:18 +0000 Subject: [openssl-dev] [openssl.org #4290] HMAC_Init_ex() return bug In-Reply-To: References: Message-ID: Was there any movement on this issue? --? Felipe Sere Sent with Airmail -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4290 Please log in as guest with password guest if prompted From rt at openssl.org Fri Feb 19 23:13:47 2016 From: rt at openssl.org (David Benjamin via RT) Date: Fri, 19 Feb 2016 23:13:47 +0000 Subject: [openssl-dev] [openssl.org #4323] chacha-armv4.pl bugs In-Reply-To: References: Message-ID: Hi Andy, The partial-block tail code in chacha-armv4.pl also seems to have problems. My colleague Steven and I made an attempt to debug it, but we're not familiar enough with ARM to fix it. >From playing with it in a debugger, it doesn't look like @t[3] contains the length. We suspect something is going wrong with the condition flags on loading or updating length. https://git.openssl.org/gitweb/?p=openssl.git;a=blob;f=crypto/chacha/asm/chacha-armv4.pl;h=55ebc9e586475a35e313b74483eb4b8d5b6f2b03;hb=HEAD#l585 It may be worth going back and testing these cases on all of the implementations as well. David -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4323 Please log in as guest with password guest if prompted From anirudhvr at gmail.com Sat Feb 20 01:47:19 2016 From: anirudhvr at gmail.com (Anirudh Ramachandran) Date: Fri, 19 Feb 2016 17:47:19 -0800 Subject: [openssl-dev] Callbacks for send_certificate/recv_certificate to enable TLS Cached Info Message-ID: Hello, For implementing the TLS Cached Info extension [1] that sends certificate hashes in place of the full certificate (if unchanged from a previous handshake), we need a way to check and modify the cerificate message being sent (for server) and received (for client). The callbacks could be, for example: void SSL_set_send_certificate_message_cb(SSL *ssl, void (*cb) (SSL *ssl, unsigned char *data, unsigned char **new_data, int *len, void *arg)); void SSL_set_recv_certificate_message_cb(SSL *ssl, void (*cb) (SSL *ssl, unsigned char *data, unsigned char **new_data, int *len, void *arg)); And they would be called while sending and receiving the certificate. Thoughts / comments? [*] https://tools.ietf.org/html/draft-ietf-tls-cached-info-22 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Sat Feb 20 06:45:35 2016 From: rt at openssl.org (Kiyoshi KANAZAWA via RT) Date: Sat, 20 Feb 2016 06:45:35 +0000 Subject: [openssl-dev] [openssl.org #4319] openssl-1.1.0-pre3 Configure does not set cflags correctly on Solaris10 x64 In-Reply-To: <812409.88939.qm@web101204.mail.kks.yahoo.co.jp> References: <812409.88939.qm@web101204.mail.kks.yahoo.co.jp> Message-ID: I do not know how to change "add_before" in Configure. So I tested changing Configurations/10-main.conf as follows, not to use "add_before", and found make & make check passes. (need to Apply fix #4314.) % ../openssl-1.1.0-pre3/Configure --unified solaris64-x86_64-gcc threads shared no-ssl3 % make % make check diff -cr ../openssl-1.1.0-pre3.orig/Configurations/10-main.conf ./Configurations/10-main.conf *** ../openssl-1.1.0-pre3.orig/Configurations/10-main.conf? 2016-02-16 03:08:07.000000000 +0900 --- ./Configurations/10-main.conf?? 2016-02-20 15:22:15.939637874 +0900 *************** *** 35,44 **** ????????? shared_extension => ".so", ????? }, ? ! #### Solaros configirations ????? "solaris-common" => { ????????? template???????? => 1, -???????? cflags?????????? => "-DFILIO_H", ????????? ex_libs????????? => "-lsocket -lnsl -ldl", ????????? dso_scheme?????? => "dlfcn", ????????? shared_target??? => "solaris-shared", --- 35,43 ---- ????????? shared_extension => ".so", ????? }, ? ! #### Solaris configurations ????? "solaris-common" => { ????????? template???????? => 1, ????????? ex_libs????????? => "-lsocket -lnsl -ldl", ????????? dso_scheme?????? => "dlfcn", ????????? shared_target??? => "solaris-shared", *************** *** 53,59 **** ????????? # with "Illegal mnemonic" error message. ????????? inherit_from???? => [ "solaris-common", asm("x86_elf_asm") ], ????????? cc?????????????? => "gcc", !???????? cflags?????????? => add_before("-march=pentium -Wall -DL_ENDIAN -DOPENSSL_NO_INLINE_ASM"), ????????? debug_cflags???? => "-O0 -g", ????????? release_cflags?? => "-O3 -fomit-frame-pointer", ????????? thread_cflag???? => "-pthread", --- 52,58 ---- ????????? # with "Illegal mnemonic" error message. ????????? inherit_from???? => [ "solaris-common", asm("x86_elf_asm") ], ????????? cc?????????????? => "gcc", !???????? cflags?????????? => "-march=pentium -Wall -DL_ENDIAN -DOPENSSL_NO_INLINE_ASM -DFILIO_H", ????????? debug_cflags???? => "-O0 -g", ????????? release_cflags?? => "-O3 -fomit-frame-pointer", ????????? thread_cflag???? => "-pthread", *************** *** 72,78 **** ????????? #???????????????? ????????? inherit_from???? => [ "solaris-common", asm("x86_64_asm") ], ????????? cc?????????????? => "gcc", !???????? cflags?????????? => add_before("-m64 -Wall -DL_ENDIAN"), ????????? debug_cflags???? => "-O0 -g", ????????? release_cflags?? => "-O3", ????????? thread_cflag???? => "-pthread", --- 71,77 ---- ????????? #???????????????? ????????? inherit_from???? => [ "solaris-common", asm("x86_64_asm") ], ????????? cc?????????????? => "gcc", !???????? cflags?????????? => "-m64 -Wall -DL_ENDIAN -DFILIO_H", ????????? debug_cflags???? => "-O0 -g", ????????? release_cflags?? => "-O3", ????????? thread_cflag???? => "-pthread", Best regards, --- Kiyoshi -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4319 Please log in as guest with password guest if prompted From doctor at doctor.nl2k.ab.ca Sat Feb 20 12:38:59 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Sat, 20 Feb 2016 05:38:59 -0700 Subject: [openssl-dev] 20160220 repository Message-ID: <20160220123859.GA17902@doctor.nl2k.ab.ca> Only Openssl 1.1 SNAP showed up. The other 2 choked off. -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Broadcasting the truth for 25 years From levitte at openssl.org Sat Feb 20 12:57:53 2016 From: levitte at openssl.org (Richard Levitte) Date: Sat, 20 Feb 2016 13:57:53 +0100 Subject: [openssl-dev] 20160220 repository In-Reply-To: <20160220123859.GA17902@doctor.nl2k.ab.ca> References: <20160220123859.GA17902@doctor.nl2k.ab.ca> Message-ID: Yes. Sorry about that, the disk space had filled out. It has been dealt with, and the next snapshots will be whole. Cheers Richard The Doctor skrev: (20 februari 2016 13:38:59 CET) >Only Openssl 1.1 SNAP showed up. > >The other 2 choked off. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From doctor at doctor.nl2k.ab.ca Sat Feb 20 13:49:02 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Sat, 20 Feb 2016 06:49:02 -0700 Subject: [openssl-dev] 20160220 repository In-Reply-To: References: <20160220123859.GA17902@doctor.nl2k.ab.ca> Message-ID: <20160220134902.GB10611@doctor.nl2k.ab.ca> On Sat, Feb 20, 2016 at 01:57:53PM +0100, Richard Levitte wrote: > Yes. Sorry about that, the disk space had filled out. It has been dealt with, and the next snapshots will be whole. > > Cheers > Richard > > The Doctor skrev: (20 februari 2016 13:38:59 CET) > >Only Openssl 1.1 SNAP showed up. > > > >The other 2 choked off. > You haveto watch that disc space ;-) > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Broadcasting the truth for 25 years From doctor at doctor.nl2k.ab.ca Sat Feb 20 13:47:22 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Sat, 20 Feb 2016 06:47:22 -0700 Subject: [openssl-dev] Openssl SNAP 20160220 issues Message-ID: <20160220134722.GA10611@doctor.nl2k.ab.ca> Major shop stopper ../test/recipes/30-test_pbelu.t ........... 1..1 ./pbelutest: can't load library 'ssl.so.1.1' not ok 1 - running pbelutest # Failed test 'running pbelutest' # at ../test/testlib/OpenSSL/Test/Simple.pm line 70. # Looks like you failed 1 test of 1. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/40-test_rehash.t .......... ../apps/openssl: can't load library 'ssl.so.1.1' 1..0 # SKIP test_rehash is not available on this platform skipped: test_rehash is not available on this platform ../test/recipes/70-test_clienthello.t ..... 1..1 ./clienthellotest: can't load library 'ssl.so.1.1' not ok 1 - running clienthellotest # Failed test 'running clienthellotest' # at ../test/recipes/70-test_clienthello.t line 13. # Looks like you failed 1 test of 1. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/70-test_packet.t .......... 1..1 ./packettest: can't load library 'ssl.so.1.1' not ok 1 - running packettest # Failed test 'running packettest' # at ../test/testlib/OpenSSL/Test/Simple.pm line 70. # Looks like you failed 1 test of 1. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/70-test_sslcertstatus.t ... 1..1 Proxy started on port 4453 ../apps/openssl: can't load library 'ssl.so.1.1' ../apps/openssl: can't load library 'ssl.so.1.1' -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Broadcasting the truth for 25 years From rt at openssl.org Sat Feb 20 14:10:25 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Sat, 20 Feb 2016 14:10:25 +0000 Subject: [openssl-dev] [openssl.org #4290] HMAC_Init_ex() return bug In-Reply-To: <9901de91e2a14612a1155d04cd74be30@ustx2ex-dag1mb1.msg.corp.akamai.com> References: <9901de91e2a14612a1155d04cd74be30@ustx2ex-dag1mb1.msg.corp.akamai.com> Message-ID: Still waiting to see from anyone else if it's a non-mac issue. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4290 Please log in as guest with password guest if prompted From rt at openssl.org Sat Feb 20 15:32:01 2016 From: rt at openssl.org (Kiyoshi KANAZAWA via RT) Date: Sat, 20 Feb 2016 15:32:01 +0000 Subject: [openssl-dev] [openssl.org #4324] openssl-1.1.0-pre3 with solaris-x86-cc & solaris64-x86_64-cc make fails In-Reply-To: <521557.3312.qm@web101212.mail.kks.yahoo.co.jp> References: <521557.3312.qm@web101212.mail.kks.yahoo.co.jp> Message-ID: Make fails with ./Configure solaris-x86-cc such as ? : cc -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_THREADS -DOPENSSL_PIC -DOPENSSLDIR=/opt/openssl/ssl -DENGINESDIR=/opt/openssl/lib/engines -KPIC -D_REENTRANT -xarch=generic -xstrconst -Xa -DL_ENDIAN -DFILIO_H -xO5 -xregs=frameptr -xdepend -xbuiltin -G -dy -z text -h libcrypto.so.1.1 -Wl,-Bsymbolic -o ./libcrypto.so.1.1 -z allextract,-M,crypto.map ./libcrypto.a -z defaultextract -lsocket -lnsl -ldl ld: fatal: option -z has illegal argument 'allextract,-M,crypto.map' ld: fatal: flags processing errors ./Configure solaris64-x86_64-cc fails with the same error. Tested on Solaris10 x86/64 cc: solarisstudio12.4 cc ld: /usr/ccs/bin/ld Before get here, you need #4314 fix & patch as follows, because "add_before" in 10-main.conf does not set cflags correctly. (See #4319) diff -cr ../openssl-1.1.0-pre3.orig/Configurations/10-main.conf ./Configurations/10-main.conf *** ../openssl-1.1.0-pre3.orig/Configurations/10-main.conf? 2016-02-16 03:08:07.000000000 +0900 --- ./Configurations/10-main.conf?? 2016-02-20 15:13:44.634129625 +0900 *************** *** 35,44 **** ????????? shared_extension => ".so", ????? }, ? ! #### Solaros configirations ????? "solaris-common" => { ????????? template???????? => 1, -???????? cflags?????????? => "-DFILIO_H", ????????? ex_libs????????? => "-lsocket -lnsl -ldl", ????????? dso_scheme?????? => "dlfcn", ????????? shared_target??? => "solaris-shared", --- 35,43 ---- ????????? shared_extension => ".so", ????? }, ? ! #### Solaris configurations ????? "solaris-common" => { ????????? template???????? => 1, ????????? ex_libs????????? => "-lsocket -lnsl -ldl", ????????? dso_scheme?????? => "dlfcn", ????????? shared_target??? => "solaris-shared", *************** *** 53,59 **** ????????? # with "Illegal mnemonic" error message. ????????? inherit_from???? => [ "solaris-common", asm("x86_elf_asm") ], ????????? cc?????????????? => "gcc", !???????? cflags?????????? => add_before("-march=pentium -Wall -DL_ENDIAN -DOPENSSL_NO_INLINE_ASM"), ????????? debug_cflags???? => "-O0 -g", ????????? release_cflags?? => "-O3 -fomit-frame-pointer", ????????? thread_cflag???? => "-pthread", --- 52,58 ---- ????????? # with "Illegal mnemonic" error message. ????????? inherit_from???? => [ "solaris-common", asm("x86_elf_asm") ], ????????? cc?????????????? => "gcc", !???????? cflags?????????? => "-march=pentium -Wall -DL_ENDIAN -DOPENSSL_NO_INLINE_ASM -DFILIO_H", ????????? debug_cflags???? => "-O0 -g", ????????? release_cflags?? => "-O3 -fomit-frame-pointer", ????????? thread_cflag???? => "-pthread", *************** *** 72,78 **** ????????? #???????????????? ????????? inherit_from???? => [ "solaris-common", asm("x86_64_asm") ], ????????? cc?????????????? => "gcc", !???????? cflags?????????? => add_before("-m64 -Wall -DL_ENDIAN"), ????????? debug_cflags???? => "-O0 -g", ????????? release_cflags?? => "-O3", ????????? thread_cflag???? => "-pthread", --- 71,77 ---- ????????? #???????????????? ????????? inherit_from???? => [ "solaris-common", asm("x86_64_asm") ], ????????? cc?????????????? => "gcc", !???????? cflags?????????? => "-m64 -Wall -DL_ENDIAN -DFILIO_H", ????????? debug_cflags???? => "-O0 -g", ????????? release_cflags?? => "-O3", ????????? thread_cflag???? => "-pthread", *************** *** 87,93 **** ????? "solaris-x86-cc" => { ????????? inherit_from???? => [ "solaris-common" ], ????????? cc?????????????? => "cc", !???????? cflags?????????? => add_before("-xarch=generic -xstrconst -Xa -DL_ENDIAN"), ????????? debug_cflags???? => "-g", ????????? release_cflags?? => "-xO5 -xregs=frameptr -xdepend -xbuiltin", ????????? thread_cflag???? => "-D_REENTRANT", --- 86,92 ---- ????? "solaris-x86-cc" => { ????????? inherit_from???? => [ "solaris-common" ], ????????? cc?????????????? => "cc", !???????? cflags?????????? => "-xarch=generic -xstrconst -Xa -DL_ENDIAN -DFILIO_H", ????????? debug_cflags???? => "-g", ????????? release_cflags?? => "-xO5 -xregs=frameptr -xdepend -xbuiltin", ????????? thread_cflag???? => "-D_REENTRANT", *************** *** 100,106 **** ????? "solaris64-x86_64-cc" => { ????????? inherit_from???? => [ "solaris-common", asm("x86_64_asm") ], ????????? cc?????????????? => "cc", !???????? cflags?????????? => add_before("-xarch=generic64 -xstrconst -Xa -DL_ENDIAN"), ????????? debug_cflags???? => "-g", ????????? release_cflags?? => "-xO5 -xdepend -xbuiltin", ????????? thread_cflag???? => "-D_REENTRANT", --- 99,105 ---- ????? "solaris64-x86_64-cc" => { ????????? inherit_from???? => [ "solaris-common", asm("x86_64_asm") ], ????????? cc?????????????? => "cc", !???????? cflags?????????? => "-m64 -xstrconst -Xa -DL_ENDIAN -DFILIO_H", ????????? debug_cflags???? => "-g", ????????? release_cflags?? => "-xO5 -xdepend -xbuiltin", ????????? thread_cflag???? => "-D_REENTRANT", *************** *** 109,115 **** ????????? bn_ops?????????? => "SIXTY_FOUR_BIT_LONG", ????????? perlasm_scheme?? => "elf", ????????? shared_cflag???? => "-KPIC", !???????? shared_ldflag??? => "-xarch=generic64 -G -dy -z text", ????????? multilib???????? => "/64", ????? }, ? --- 108,114 ---- ????????? bn_ops?????????? => "SIXTY_FOUR_BIT_LONG", ????????? perlasm_scheme?? => "elf", ????????? shared_cflag???? => "-KPIC", !???????? shared_ldflag??? => "-m64 -G -dy -z text", ????????? multilib???????? => "/64", ????? }, ? Best regards, --- Kiyoshi -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4324 Please log in as guest with password guest if prompted From rt at openssl.org Sat Feb 20 15:32:01 2016 From: rt at openssl.org (Kurt Cancemi via RT) Date: Sat, 20 Feb 2016 15:32:01 +0000 Subject: [openssl-dev] [openssl.org #4325] Unified Builds Don't Work With ARM In-Reply-To: References: Message-ID: Hello, There are a few problems that I am facing with unified builds with arm: 1. arm_arch.h is not in the include path. fatal error: arm_arch.h: No such file or directory 2. The arm assembler scripts output to stdout (see attached output.txt) I have a patch for aes-armv4.pl that fixes the stdout issue (I don't know if its proper) that uses the method from the x86_64 perl files if thats the way to go I'll make a complete patch. (see aes-armv4.pl.patch) -- Kurt Cancemi https://www.x64architecture.com -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4325 Please log in as guest with password guest if prompted -------------- next part -------------- pi at raspberrypi:/tmp/openssl $ ./config --unified Operating system: armv7l-whatever-linux2 Configuring for linux-armv4 Configuring OpenSSL version 1.1.0-pre4-dev (0x0x10100004L) no-crypto-mdebug [default] OPENSSL_NO_CRYPTO_MDEBUG (skip dir) no-crypto-mdebug-backtrace [forced] OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE (skip dir) no-ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128 (skip dir) no-egd [default] OPENSSL_NO_EGD (skip dir) no-heartbeats [default] OPENSSL_NO_HEARTBEATS (skip dir) no-md2 [default] OPENSSL_NO_MD2 (skip dir) no-rc5 [default] OPENSSL_NO_RC5 (skip dir) no-sctp [default] OPENSSL_NO_SCTP (skip dir) no-shared [default] no-ssl-trace [default] OPENSSL_NO_SSL_TRACE (skip dir) no-unit-test [default] OPENSSL_NO_UNIT_TEST (skip dir) no-zlib [default] no-zlib-dynamic [forced] Configuring for linux-armv4 IsMK1MF =no CC =gcc CFLAG = -pthread -Wall -O3 -march=armv7-a -Wa,--noexecstack DEFINES =DSO_DLFCN HAVE_DLFCN_H OPENSSL_THREADS OPENSSL_BN_ASM_MONT OPENSSL_BN_ASM_GF2m SHA1_ASM SHA256_ASM SHA512_ASM AES_ASM BSAES_ASM GHASH_ASM ECP_NISTZ256_ASM POLY1305_ASM LFLAG = PLIB_LFLAG = EX_LIBS =-ldl CPUID_OBJ =armcap.o armv4cpuid.o BN_ASM =bn_asm.o armv4-mont.o armv4-gf2m.o EC_ASM =ecp_nistz256.o ecp_nistz256-armv4.o DES_ENC =des_enc.o fcrypt_b.o AES_ENC =aes_cbc.o aes-armv4.o bsaes-armv7.o aesv8-armx.o BF_ENC =bf_enc.o CAST_ENC =c_enc.o RC4_ENC =rc4_enc.o rc4_skey.o RC5_ENC =rc5_enc.o MD5_OBJ_ASM = SHA1_OBJ_ASM =sha1-armv4-large.o sha256-armv4.o sha512-armv4.o RMD160_OBJ_ASM= CMLL_ENC =camellia.o cmll_misc.o cmll_cbc.o MODES_OBJ =ghash-armv4.o ghashv8-armx.o PADLOCK_OBJ = CHACHA_ENC =chacha-armv4.o POLY1305_OBJ =poly1305-armv4.o PROCESSOR = RANLIB =/usr/bin/ranlib ARFLAGS = PERL =/usr/bin/perl THIRTY_TWO_BIT mode BN_LLONG mode Configured for linux-armv4. pi at raspberrypi:/tmp/openssl $ make CC="gcc" /usr/bin/perl crypto/aes/asm/aes-armv4.pl linux32 crypto/aes/aes-armv4.S @ ==================================================================== @ Written by Andy Polyakov for the OpenSSL @ project. The module is, however, dual licensed under OpenSSL and @ CRYPTOGAMS licenses depending on where you obtain it. For further @ details see http://www.openssl.org/~appro/cryptogams/. @ ==================================================================== @ AES for ARMv4 @ January 2007. @ @ Code uses single 1K S-box and is >2 times faster than code generated @ by gcc-3.4.1. This is thanks to unique feature of ARMv4 ISA, which @ allows to merge logical or arithmetic operation with shift or rotate @ in one instruction and emit combined result every cycle. The module @ is endian-neutral. The performance is ~42 cycles/byte for 128-bit @ key [on single-issue Xscale PXA250 core]. @ May 2007. @ @ AES_set_[en|de]crypt_key is added. @ July 2010. @ @ Rescheduling for dual-issue pipeline resulted in 12% improvement on @ Cortex A8 core and ~25 cycles per byte processed with 128-bit key. @ February 2011. @ @ Profiler-assisted and platform-specific optimization resulted in 16% @ improvement on Cortex A8 core and ~21.5 cycles per byte. #ifndef __KERNEL__ # include "arm_arch.h" #else # define __ARM_ARCH__ __LINUX_ARM_ARCH__ #endif .text #if defined(__thumb2__) && !defined(__APPLE__) .syntax unified .thumb #else .code 32 #undef __thumb2__ #endif .type AES_Te,%object .align 5 AES_Te: .word 0xc66363a5, 0xf87c7c84, 0xee777799, 0xf67b7b8d .word 0xfff2f20d, 0xd66b6bbd, 0xde6f6fb1, 0x91c5c554 .word 0x60303050, 0x02010103, 0xce6767a9, 0x562b2b7d .word 0xe7fefe19, 0xb5d7d762, 0x4dababe6, 0xec76769a .word 0x8fcaca45, 0x1f82829d, 0x89c9c940, 0xfa7d7d87 .word 0xeffafa15, 0xb25959eb, 0x8e4747c9, 0xfbf0f00b .word 0x41adadec, 0xb3d4d467, 0x5fa2a2fd, 0x45afafea .word 0x239c9cbf, 0x53a4a4f7, 0xe4727296, 0x9bc0c05b .word 0x75b7b7c2, 0xe1fdfd1c, 0x3d9393ae, 0x4c26266a .word 0x6c36365a, 0x7e3f3f41, 0xf5f7f702, 0x83cccc4f .word 0x6834345c, 0x51a5a5f4, 0xd1e5e534, 0xf9f1f108 .word 0xe2717193, 0xabd8d873, 0x62313153, 0x2a15153f .word 0x0804040c, 0x95c7c752, 0x46232365, 0x9dc3c35e .word 0x30181828, 0x379696a1, 0x0a05050f, 0x2f9a9ab5 .word 0x0e070709, 0x24121236, 0x1b80809b, 0xdfe2e23d .word 0xcdebeb26, 0x4e272769, 0x7fb2b2cd, 0xea75759f .word 0x1209091b, 0x1d83839e, 0x582c2c74, 0x341a1a2e .word 0x361b1b2d, 0xdc6e6eb2, 0xb45a5aee, 0x5ba0a0fb .word 0xa45252f6, 0x763b3b4d, 0xb7d6d661, 0x7db3b3ce .word 0x5229297b, 0xdde3e33e, 0x5e2f2f71, 0x13848497 .word 0xa65353f5, 0xb9d1d168, 0x00000000, 0xc1eded2c .word 0x40202060, 0xe3fcfc1f, 0x79b1b1c8, 0xb65b5bed .word 0xd46a6abe, 0x8dcbcb46, 0x67bebed9, 0x7239394b .word 0x944a4ade, 0x984c4cd4, 0xb05858e8, 0x85cfcf4a .word 0xbbd0d06b, 0xc5efef2a, 0x4faaaae5, 0xedfbfb16 .word 0x864343c5, 0x9a4d4dd7, 0x66333355, 0x11858594 .word 0x8a4545cf, 0xe9f9f910, 0x04020206, 0xfe7f7f81 .word 0xa05050f0, 0x783c3c44, 0x259f9fba, 0x4ba8a8e3 .word 0xa25151f3, 0x5da3a3fe, 0x804040c0, 0x058f8f8a .word 0x3f9292ad, 0x219d9dbc, 0x70383848, 0xf1f5f504 .word 0x63bcbcdf, 0x77b6b6c1, 0xafdada75, 0x42212163 .word 0x20101030, 0xe5ffff1a, 0xfdf3f30e, 0xbfd2d26d .word 0x81cdcd4c, 0x180c0c14, 0x26131335, 0xc3ecec2f .word 0xbe5f5fe1, 0x359797a2, 0x884444cc, 0x2e171739 .word 0x93c4c457, 0x55a7a7f2, 0xfc7e7e82, 0x7a3d3d47 .word 0xc86464ac, 0xba5d5de7, 0x3219192b, 0xe6737395 .word 0xc06060a0, 0x19818198, 0x9e4f4fd1, 0xa3dcdc7f .word 0x44222266, 0x542a2a7e, 0x3b9090ab, 0x0b888883 .word 0x8c4646ca, 0xc7eeee29, 0x6bb8b8d3, 0x2814143c .word 0xa7dede79, 0xbc5e5ee2, 0x160b0b1d, 0xaddbdb76 .word 0xdbe0e03b, 0x64323256, 0x743a3a4e, 0x140a0a1e .word 0x924949db, 0x0c06060a, 0x4824246c, 0xb85c5ce4 .word 0x9fc2c25d, 0xbdd3d36e, 0x43acacef, 0xc46262a6 .word 0x399191a8, 0x319595a4, 0xd3e4e437, 0xf279798b .word 0xd5e7e732, 0x8bc8c843, 0x6e373759, 0xda6d6db7 .word 0x018d8d8c, 0xb1d5d564, 0x9c4e4ed2, 0x49a9a9e0 .word 0xd86c6cb4, 0xac5656fa, 0xf3f4f407, 0xcfeaea25 .word 0xca6565af, 0xf47a7a8e, 0x47aeaee9, 0x10080818 .word 0x6fbabad5, 0xf0787888, 0x4a25256f, 0x5c2e2e72 .word 0x381c1c24, 0x57a6a6f1, 0x73b4b4c7, 0x97c6c651 .word 0xcbe8e823, 0xa1dddd7c, 0xe874749c, 0x3e1f1f21 .word 0x964b4bdd, 0x61bdbddc, 0x0d8b8b86, 0x0f8a8a85 .word 0xe0707090, 0x7c3e3e42, 0x71b5b5c4, 0xcc6666aa .word 0x904848d8, 0x06030305, 0xf7f6f601, 0x1c0e0e12 .word 0xc26161a3, 0x6a35355f, 0xae5757f9, 0x69b9b9d0 .word 0x17868691, 0x99c1c158, 0x3a1d1d27, 0x279e9eb9 .word 0xd9e1e138, 0xebf8f813, 0x2b9898b3, 0x22111133 .word 0xd26969bb, 0xa9d9d970, 0x078e8e89, 0x339494a7 .word 0x2d9b9bb6, 0x3c1e1e22, 0x15878792, 0xc9e9e920 .word 0x87cece49, 0xaa5555ff, 0x50282878, 0xa5dfdf7a .word 0x038c8c8f, 0x59a1a1f8, 0x09898980, 0x1a0d0d17 .word 0x65bfbfda, 0xd7e6e631, 0x844242c6, 0xd06868b8 .word 0x824141c3, 0x299999b0, 0x5a2d2d77, 0x1e0f0f11 .word 0x7bb0b0cb, 0xa85454fc, 0x6dbbbbd6, 0x2c16163a @ Te4[256] .byte 0x63, 0x7c, 0x77, 0x7b, 0xf2, 0x6b, 0x6f, 0xc5 .byte 0x30, 0x01, 0x67, 0x2b, 0xfe, 0xd7, 0xab, 0x76 .byte 0xca, 0x82, 0xc9, 0x7d, 0xfa, 0x59, 0x47, 0xf0 .byte 0xad, 0xd4, 0xa2, 0xaf, 0x9c, 0xa4, 0x72, 0xc0 .byte 0xb7, 0xfd, 0x93, 0x26, 0x36, 0x3f, 0xf7, 0xcc .byte 0x34, 0xa5, 0xe5, 0xf1, 0x71, 0xd8, 0x31, 0x15 .byte 0x04, 0xc7, 0x23, 0xc3, 0x18, 0x96, 0x05, 0x9a .byte 0x07, 0x12, 0x80, 0xe2, 0xeb, 0x27, 0xb2, 0x75 .byte 0x09, 0x83, 0x2c, 0x1a, 0x1b, 0x6e, 0x5a, 0xa0 .byte 0x52, 0x3b, 0xd6, 0xb3, 0x29, 0xe3, 0x2f, 0x84 .byte 0x53, 0xd1, 0x00, 0xed, 0x20, 0xfc, 0xb1, 0x5b .byte 0x6a, 0xcb, 0xbe, 0x39, 0x4a, 0x4c, 0x58, 0xcf .byte 0xd0, 0xef, 0xaa, 0xfb, 0x43, 0x4d, 0x33, 0x85 .byte 0x45, 0xf9, 0x02, 0x7f, 0x50, 0x3c, 0x9f, 0xa8 .byte 0x51, 0xa3, 0x40, 0x8f, 0x92, 0x9d, 0x38, 0xf5 .byte 0xbc, 0xb6, 0xda, 0x21, 0x10, 0xff, 0xf3, 0xd2 .byte 0xcd, 0x0c, 0x13, 0xec, 0x5f, 0x97, 0x44, 0x17 .byte 0xc4, 0xa7, 0x7e, 0x3d, 0x64, 0x5d, 0x19, 0x73 .byte 0x60, 0x81, 0x4f, 0xdc, 0x22, 0x2a, 0x90, 0x88 .byte 0x46, 0xee, 0xb8, 0x14, 0xde, 0x5e, 0x0b, 0xdb .byte 0xe0, 0x32, 0x3a, 0x0a, 0x49, 0x06, 0x24, 0x5c .byte 0xc2, 0xd3, 0xac, 0x62, 0x91, 0x95, 0xe4, 0x79 .byte 0xe7, 0xc8, 0x37, 0x6d, 0x8d, 0xd5, 0x4e, 0xa9 .byte 0x6c, 0x56, 0xf4, 0xea, 0x65, 0x7a, 0xae, 0x08 .byte 0xba, 0x78, 0x25, 0x2e, 0x1c, 0xa6, 0xb4, 0xc6 .byte 0xe8, 0xdd, 0x74, 0x1f, 0x4b, 0xbd, 0x8b, 0x8a .byte 0x70, 0x3e, 0xb5, 0x66, 0x48, 0x03, 0xf6, 0x0e .byte 0x61, 0x35, 0x57, 0xb9, 0x86, 0xc1, 0x1d, 0x9e .byte 0xe1, 0xf8, 0x98, 0x11, 0x69, 0xd9, 0x8e, 0x94 .byte 0x9b, 0x1e, 0x87, 0xe9, 0xce, 0x55, 0x28, 0xdf .byte 0x8c, 0xa1, 0x89, 0x0d, 0xbf, 0xe6, 0x42, 0x68 .byte 0x41, 0x99, 0x2d, 0x0f, 0xb0, 0x54, 0xbb, 0x16 @ rcon[] .word 0x01000000, 0x02000000, 0x04000000, 0x08000000 .word 0x10000000, 0x20000000, 0x40000000, 0x80000000 .word 0x1B000000, 0x36000000, 0, 0, 0, 0, 0, 0 .size AES_Te,.-AES_Te @ void AES_encrypt(const unsigned char *in, unsigned char *out, @ const AES_KEY *key) { .globl AES_encrypt .type AES_encrypt,%function .align 5 AES_encrypt: #ifndef __thumb2__ sub r3,pc,#8 @ AES_encrypt #else adr r3,AES_encrypt #endif stmdb sp!,{r1,r4-r12,lr} #ifdef __APPLE__ adr r10,AES_Te #else sub r10,r3,#AES_encrypt-AES_Te @ Te #endif mov r12,r0 @ inp mov r11,r2 #if __ARM_ARCH__<7 ldrb r0,[r12,#3] @ load input data in endian-neutral ldrb r4,[r12,#2] @ manner... ldrb r5,[r12,#1] ldrb r6,[r12,#0] orr r0,r0,r4,lsl#8 ldrb r1,[r12,#7] orr r0,r0,r5,lsl#16 ldrb r4,[r12,#6] orr r0,r0,r6,lsl#24 ldrb r5,[r12,#5] ldrb r6,[r12,#4] orr r1,r1,r4,lsl#8 ldrb r2,[r12,#11] orr r1,r1,r5,lsl#16 ldrb r4,[r12,#10] orr r1,r1,r6,lsl#24 ldrb r5,[r12,#9] ldrb r6,[r12,#8] orr r2,r2,r4,lsl#8 ldrb r3,[r12,#15] orr r2,r2,r5,lsl#16 ldrb r4,[r12,#14] orr r2,r2,r6,lsl#24 ldrb r5,[r12,#13] ldrb r6,[r12,#12] orr r3,r3,r4,lsl#8 orr r3,r3,r5,lsl#16 orr r3,r3,r6,lsl#24 #else ldr r0,[r12,#0] ldr r1,[r12,#4] ldr r2,[r12,#8] ldr r3,[r12,#12] #ifdef __ARMEL__ rev r0,r0 rev r1,r1 rev r2,r2 rev r3,r3 #endif #endif bl _armv4_AES_encrypt ldr r12,[sp],#4 @ pop out #if __ARM_ARCH__>=7 #ifdef __ARMEL__ rev r0,r0 rev r1,r1 rev r2,r2 rev r3,r3 #endif str r0,[r12,#0] str r1,[r12,#4] str r2,[r12,#8] str r3,[r12,#12] #else mov r4,r0,lsr#24 @ write output in endian-neutral mov r5,r0,lsr#16 @ manner... mov r6,r0,lsr#8 strb r4,[r12,#0] strb r5,[r12,#1] mov r4,r1,lsr#24 strb r6,[r12,#2] mov r5,r1,lsr#16 strb r0,[r12,#3] mov r6,r1,lsr#8 strb r4,[r12,#4] strb r5,[r12,#5] mov r4,r2,lsr#24 strb r6,[r12,#6] mov r5,r2,lsr#16 strb r1,[r12,#7] mov r6,r2,lsr#8 strb r4,[r12,#8] strb r5,[r12,#9] mov r4,r3,lsr#24 strb r6,[r12,#10] mov r5,r3,lsr#16 strb r2,[r12,#11] mov r6,r3,lsr#8 strb r4,[r12,#12] strb r5,[r12,#13] strb r6,[r12,#14] strb r3,[r12,#15] #endif #if __ARM_ARCH__>=5 ldmia sp!,{r4,r5,r6,r7,r8,r9,r10,r11,r12,pc} #else ldmia sp!,{r4,r5,r6,r7,r8,r9,r10,r11,r12,lr} tst lr,#1 moveq pc,lr @ be binary compatible with V4, yet .word 0xe12fff1e @ interoperable with Thumb ISA:-) #endif .size AES_encrypt,.-AES_encrypt .type _armv4_AES_encrypt,%function .align 2 _armv4_AES_encrypt: str lr,[sp,#-4]! @ push lr ldmia r11!,{r4,r5,r6,r7} eor r0,r0,r4 ldr r12,[r11,#240-16] eor r1,r1,r5 eor r2,r2,r6 eor r3,r3,r7 sub r12,r12,#1 mov lr,#255 and r7,lr,r0 and r8,lr,r0,lsr#8 and r9,lr,r0,lsr#16 mov r0,r0,lsr#24 .Lenc_loop: ldr r4,[r10,r7,lsl#2] @ Te3[s0>>0] and r7,lr,r1,lsr#16 @ i0 ldr r5,[r10,r8,lsl#2] @ Te2[s0>>8] and r8,lr,r1 ldr r6,[r10,r9,lsl#2] @ Te1[s0>>16] and r9,lr,r1,lsr#8 ldr r0,[r10,r0,lsl#2] @ Te0[s0>>24] mov r1,r1,lsr#24 ldr r7,[r10,r7,lsl#2] @ Te1[s1>>16] ldr r8,[r10,r8,lsl#2] @ Te3[s1>>0] ldr r9,[r10,r9,lsl#2] @ Te2[s1>>8] eor r0,r0,r7,ror#8 ldr r1,[r10,r1,lsl#2] @ Te0[s1>>24] and r7,lr,r2,lsr#8 @ i0 eor r5,r5,r8,ror#8 and r8,lr,r2,lsr#16 @ i1 eor r6,r6,r9,ror#8 and r9,lr,r2 ldr r7,[r10,r7,lsl#2] @ Te2[s2>>8] eor r1,r1,r4,ror#24 ldr r8,[r10,r8,lsl#2] @ Te1[s2>>16] mov r2,r2,lsr#24 ldr r9,[r10,r9,lsl#2] @ Te3[s2>>0] eor r0,r0,r7,ror#16 ldr r2,[r10,r2,lsl#2] @ Te0[s2>>24] and r7,lr,r3 @ i0 eor r1,r1,r8,ror#8 and r8,lr,r3,lsr#8 @ i1 eor r6,r6,r9,ror#16 and r9,lr,r3,lsr#16 @ i2 ldr r7,[r10,r7,lsl#2] @ Te3[s3>>0] eor r2,r2,r5,ror#16 ldr r8,[r10,r8,lsl#2] @ Te2[s3>>8] mov r3,r3,lsr#24 ldr r9,[r10,r9,lsl#2] @ Te1[s3>>16] eor r0,r0,r7,ror#24 ldr r7,[r11],#16 eor r1,r1,r8,ror#16 ldr r3,[r10,r3,lsl#2] @ Te0[s3>>24] eor r2,r2,r9,ror#8 ldr r4,[r11,#-12] eor r3,r3,r6,ror#8 ldr r5,[r11,#-8] eor r0,r0,r7 ldr r6,[r11,#-4] and r7,lr,r0 eor r1,r1,r4 and r8,lr,r0,lsr#8 eor r2,r2,r5 and r9,lr,r0,lsr#16 eor r3,r3,r6 mov r0,r0,lsr#24 subs r12,r12,#1 bne .Lenc_loop add r10,r10,#2 ldrb r4,[r10,r7,lsl#2] @ Te4[s0>>0] and r7,lr,r1,lsr#16 @ i0 ldrb r5,[r10,r8,lsl#2] @ Te4[s0>>8] and r8,lr,r1 ldrb r6,[r10,r9,lsl#2] @ Te4[s0>>16] and r9,lr,r1,lsr#8 ldrb r0,[r10,r0,lsl#2] @ Te4[s0>>24] mov r1,r1,lsr#24 ldrb r7,[r10,r7,lsl#2] @ Te4[s1>>16] ldrb r8,[r10,r8,lsl#2] @ Te4[s1>>0] ldrb r9,[r10,r9,lsl#2] @ Te4[s1>>8] eor r0,r7,r0,lsl#8 ldrb r1,[r10,r1,lsl#2] @ Te4[s1>>24] and r7,lr,r2,lsr#8 @ i0 eor r5,r8,r5,lsl#8 and r8,lr,r2,lsr#16 @ i1 eor r6,r9,r6,lsl#8 and r9,lr,r2 ldrb r7,[r10,r7,lsl#2] @ Te4[s2>>8] eor r1,r4,r1,lsl#24 ldrb r8,[r10,r8,lsl#2] @ Te4[s2>>16] mov r2,r2,lsr#24 ldrb r9,[r10,r9,lsl#2] @ Te4[s2>>0] eor r0,r7,r0,lsl#8 ldrb r2,[r10,r2,lsl#2] @ Te4[s2>>24] and r7,lr,r3 @ i0 eor r1,r1,r8,lsl#16 and r8,lr,r3,lsr#8 @ i1 eor r6,r9,r6,lsl#8 and r9,lr,r3,lsr#16 @ i2 ldrb r7,[r10,r7,lsl#2] @ Te4[s3>>0] eor r2,r5,r2,lsl#24 ldrb r8,[r10,r8,lsl#2] @ Te4[s3>>8] mov r3,r3,lsr#24 ldrb r9,[r10,r9,lsl#2] @ Te4[s3>>16] eor r0,r7,r0,lsl#8 ldr r7,[r11,#0] ldrb r3,[r10,r3,lsl#2] @ Te4[s3>>24] eor r1,r1,r8,lsl#8 ldr r4,[r11,#4] eor r2,r2,r9,lsl#16 ldr r5,[r11,#8] eor r3,r6,r3,lsl#24 ldr r6,[r11,#12] eor r0,r0,r7 eor r1,r1,r4 eor r2,r2,r5 eor r3,r3,r6 sub r10,r10,#2 ldr pc,[sp],#4 @ pop and return .size _armv4_AES_encrypt,.-_armv4_AES_encrypt .globl AES_set_encrypt_key .type AES_set_encrypt_key,%function .align 5 AES_set_encrypt_key: _armv4_AES_set_encrypt_key: #ifndef __thumb2__ sub r3,pc,#8 @ AES_set_encrypt_key #else adr r3,AES_set_encrypt_key #endif teq r0,#0 #ifdef __thumb2__ itt eq @ Thumb2 thing, sanity check in ARM #endif moveq r0,#-1 beq .Labrt teq r2,#0 #ifdef __thumb2__ itt eq @ Thumb2 thing, sanity check in ARM #endif moveq r0,#-1 beq .Labrt teq r1,#128 beq .Lok teq r1,#192 beq .Lok teq r1,#256 #ifdef __thumb2__ itt ne @ Thumb2 thing, sanity check in ARM #endif movne r0,#-1 bne .Labrt .Lok: stmdb sp!,{r4,r5,r6,r7,r8,r9,r10,r11,r12,lr} mov r12,r0 @ inp mov lr,r1 @ bits mov r11,r2 @ key #ifdef __APPLE__ adr r10,AES_Te+1024 @ Te4 #else sub r10,r3,#_armv4_AES_set_encrypt_key-AES_Te-1024 @ Te4 #endif #if __ARM_ARCH__<7 ldrb r0,[r12,#3] @ load input data in endian-neutral ldrb r4,[r12,#2] @ manner... ldrb r5,[r12,#1] ldrb r6,[r12,#0] orr r0,r0,r4,lsl#8 ldrb r1,[r12,#7] orr r0,r0,r5,lsl#16 ldrb r4,[r12,#6] orr r0,r0,r6,lsl#24 ldrb r5,[r12,#5] ldrb r6,[r12,#4] orr r1,r1,r4,lsl#8 ldrb r2,[r12,#11] orr r1,r1,r5,lsl#16 ldrb r4,[r12,#10] orr r1,r1,r6,lsl#24 ldrb r5,[r12,#9] ldrb r6,[r12,#8] orr r2,r2,r4,lsl#8 ldrb r3,[r12,#15] orr r2,r2,r5,lsl#16 ldrb r4,[r12,#14] orr r2,r2,r6,lsl#24 ldrb r5,[r12,#13] ldrb r6,[r12,#12] orr r3,r3,r4,lsl#8 str r0,[r11],#16 orr r3,r3,r5,lsl#16 str r1,[r11,#-12] orr r3,r3,r6,lsl#24 str r2,[r11,#-8] str r3,[r11,#-4] #else ldr r0,[r12,#0] ldr r1,[r12,#4] ldr r2,[r12,#8] ldr r3,[r12,#12] #ifdef __ARMEL__ rev r0,r0 rev r1,r1 rev r2,r2 rev r3,r3 #endif str r0,[r11],#16 str r1,[r11,#-12] str r2,[r11,#-8] str r3,[r11,#-4] #endif teq lr,#128 bne .Lnot128 mov r12,#10 str r12,[r11,#240-16] add r6,r10,#256 @ rcon mov lr,#255 .L128_loop: and r5,lr,r3,lsr#24 and r7,lr,r3,lsr#16 ldrb r5,[r10,r5] and r8,lr,r3,lsr#8 ldrb r7,[r10,r7] and r9,lr,r3 ldrb r8,[r10,r8] orr r5,r5,r7,lsl#24 ldrb r9,[r10,r9] orr r5,r5,r8,lsl#16 ldr r4,[r6],#4 @ rcon[i++] orr r5,r5,r9,lsl#8 eor r5,r5,r4 eor r0,r0,r5 @ rk[4]=rk[0]^... eor r1,r1,r0 @ rk[5]=rk[1]^rk[4] str r0,[r11],#16 eor r2,r2,r1 @ rk[6]=rk[2]^rk[5] str r1,[r11,#-12] eor r3,r3,r2 @ rk[7]=rk[3]^rk[6] str r2,[r11,#-8] subs r12,r12,#1 str r3,[r11,#-4] bne .L128_loop sub r2,r11,#176 b .Ldone .Lnot128: #if __ARM_ARCH__<7 ldrb r8,[r12,#19] ldrb r4,[r12,#18] ldrb r5,[r12,#17] ldrb r6,[r12,#16] orr r8,r8,r4,lsl#8 ldrb r9,[r12,#23] orr r8,r8,r5,lsl#16 ldrb r4,[r12,#22] orr r8,r8,r6,lsl#24 ldrb r5,[r12,#21] ldrb r6,[r12,#20] orr r9,r9,r4,lsl#8 orr r9,r9,r5,lsl#16 str r8,[r11],#8 orr r9,r9,r6,lsl#24 str r9,[r11,#-4] #else ldr r8,[r12,#16] ldr r9,[r12,#20] #ifdef __ARMEL__ rev r8,r8 rev r9,r9 #endif str r8,[r11],#8 str r9,[r11,#-4] #endif teq lr,#192 bne .Lnot192 mov r12,#12 str r12,[r11,#240-24] add r6,r10,#256 @ rcon mov lr,#255 mov r12,#8 .L192_loop: and r5,lr,r9,lsr#24 and r7,lr,r9,lsr#16 ldrb r5,[r10,r5] and r8,lr,r9,lsr#8 ldrb r7,[r10,r7] and r9,lr,r9 ldrb r8,[r10,r8] orr r5,r5,r7,lsl#24 ldrb r9,[r10,r9] orr r5,r5,r8,lsl#16 ldr r4,[r6],#4 @ rcon[i++] orr r5,r5,r9,lsl#8 eor r9,r5,r4 eor r0,r0,r9 @ rk[6]=rk[0]^... eor r1,r1,r0 @ rk[7]=rk[1]^rk[6] str r0,[r11],#24 eor r2,r2,r1 @ rk[8]=rk[2]^rk[7] str r1,[r11,#-20] eor r3,r3,r2 @ rk[9]=rk[3]^rk[8] str r2,[r11,#-16] subs r12,r12,#1 str r3,[r11,#-12] #ifdef __thumb2__ itt eq @ Thumb2 thing, sanity check in ARM #endif subeq r2,r11,#216 beq .Ldone ldr r7,[r11,#-32] ldr r8,[r11,#-28] eor r7,r7,r3 @ rk[10]=rk[4]^rk[9] eor r9,r8,r7 @ rk[11]=rk[5]^rk[10] str r7,[r11,#-8] str r9,[r11,#-4] b .L192_loop .Lnot192: #if __ARM_ARCH__<7 ldrb r8,[r12,#27] ldrb r4,[r12,#26] ldrb r5,[r12,#25] ldrb r6,[r12,#24] orr r8,r8,r4,lsl#8 ldrb r9,[r12,#31] orr r8,r8,r5,lsl#16 ldrb r4,[r12,#30] orr r8,r8,r6,lsl#24 ldrb r5,[r12,#29] ldrb r6,[r12,#28] orr r9,r9,r4,lsl#8 orr r9,r9,r5,lsl#16 str r8,[r11],#8 orr r9,r9,r6,lsl#24 str r9,[r11,#-4] #else ldr r8,[r12,#24] ldr r9,[r12,#28] #ifdef __ARMEL__ rev r8,r8 rev r9,r9 #endif str r8,[r11],#8 str r9,[r11,#-4] #endif mov r12,#14 str r12,[r11,#240-32] add r6,r10,#256 @ rcon mov lr,#255 mov r12,#7 .L256_loop: and r5,lr,r9,lsr#24 and r7,lr,r9,lsr#16 ldrb r5,[r10,r5] and r8,lr,r9,lsr#8 ldrb r7,[r10,r7] and r9,lr,r9 ldrb r8,[r10,r8] orr r5,r5,r7,lsl#24 ldrb r9,[r10,r9] orr r5,r5,r8,lsl#16 ldr r4,[r6],#4 @ rcon[i++] orr r5,r5,r9,lsl#8 eor r9,r5,r4 eor r0,r0,r9 @ rk[8]=rk[0]^... eor r1,r1,r0 @ rk[9]=rk[1]^rk[8] str r0,[r11],#32 eor r2,r2,r1 @ rk[10]=rk[2]^rk[9] str r1,[r11,#-28] eor r3,r3,r2 @ rk[11]=rk[3]^rk[10] str r2,[r11,#-24] subs r12,r12,#1 str r3,[r11,#-20] #ifdef __thumb2__ itt eq @ Thumb2 thing, sanity check in ARM #endif subeq r2,r11,#256 beq .Ldone and r5,lr,r3 and r7,lr,r3,lsr#8 ldrb r5,[r10,r5] and r8,lr,r3,lsr#16 ldrb r7,[r10,r7] and r9,lr,r3,lsr#24 ldrb r8,[r10,r8] orr r5,r5,r7,lsl#8 ldrb r9,[r10,r9] orr r5,r5,r8,lsl#16 ldr r4,[r11,#-48] orr r5,r5,r9,lsl#24 ldr r7,[r11,#-44] ldr r8,[r11,#-40] eor r4,r4,r5 @ rk[12]=rk[4]^... ldr r9,[r11,#-36] eor r7,r7,r4 @ rk[13]=rk[5]^rk[12] str r4,[r11,#-16] eor r8,r8,r7 @ rk[14]=rk[6]^rk[13] str r7,[r11,#-12] eor r9,r9,r8 @ rk[15]=rk[7]^rk[14] str r8,[r11,#-8] str r9,[r11,#-4] b .L256_loop .align 2 .Ldone: mov r0,#0 ldmia sp!,{r4,r5,r6,r7,r8,r9,r10,r11,r12,lr} .Labrt: #if __ARM_ARCH__>=5 bx lr @ .word 0xe12fff1e #else tst lr,#1 moveq pc,lr @ be binary compatible with V4, yet .word 0xe12fff1e @ interoperable with Thumb ISA:-) #endif .size AES_set_encrypt_key,.-AES_set_encrypt_key .globl AES_set_decrypt_key .type AES_set_decrypt_key,%function .align 5 AES_set_decrypt_key: str lr,[sp,#-4]! @ push lr bl _armv4_AES_set_encrypt_key teq r0,#0 ldr lr,[sp],#4 @ pop lr bne .Labrt mov r0,r2 @ AES_set_encrypt_key preserves r2, mov r1,r2 @ which is AES_KEY *key b _armv4_AES_set_enc2dec_key .size AES_set_decrypt_key,.-AES_set_decrypt_key @ void AES_set_enc2dec_key(const AES_KEY *inp,AES_KEY *out) .globl AES_set_enc2dec_key .type AES_set_enc2dec_key,%function .align 5 AES_set_enc2dec_key: _armv4_AES_set_enc2dec_key: stmdb sp!,{r4,r5,r6,r7,r8,r9,r10,r11,r12,lr} ldr r12,[r0,#240] mov r7,r0 @ input add r8,r0,r12,lsl#4 mov r11,r1 @ output add r10,r1,r12,lsl#4 str r12,[r1,#240] .Linv: ldr r0,[r7],#16 ldr r1,[r7,#-12] ldr r2,[r7,#-8] ldr r3,[r7,#-4] ldr r4,[r8],#-16 ldr r5,[r8,#16+4] ldr r6,[r8,#16+8] ldr r9,[r8,#16+12] str r0,[r10],#-16 str r1,[r10,#16+4] str r2,[r10,#16+8] str r3,[r10,#16+12] str r4,[r11],#16 str r5,[r11,#-12] str r6,[r11,#-8] str r9,[r11,#-4] teq r7,r8 bne .Linv ldr r0,[r7] ldr r1,[r7,#4] ldr r2,[r7,#8] ldr r3,[r7,#12] str r0,[r11] str r1,[r11,#4] str r2,[r11,#8] str r3,[r11,#12] sub r11,r11,r12,lsl#3 ldr r0,[r11,#16]! @ prefetch tp1 mov r7,#0x80 mov r8,#0x1b orr r7,r7,#0x8000 orr r8,r8,#0x1b00 orr r7,r7,r7,lsl#16 orr r8,r8,r8,lsl#16 sub r12,r12,#1 mvn r9,r7 mov r12,r12,lsl#2 @ (rounds-1)*4 .Lmix: and r4,r0,r7 and r1,r0,r9 sub r4,r4,r4,lsr#7 and r4,r4,r8 eor r1,r4,r1,lsl#1 @ tp2 and r4,r1,r7 and r2,r1,r9 sub r4,r4,r4,lsr#7 and r4,r4,r8 eor r2,r4,r2,lsl#1 @ tp4 and r4,r2,r7 and r3,r2,r9 sub r4,r4,r4,lsr#7 and r4,r4,r8 eor r3,r4,r3,lsl#1 @ tp8 eor r4,r1,r2 eor r5,r0,r3 @ tp9 eor r4,r4,r3 @ tpe eor r4,r4,r1,ror#24 eor r4,r4,r5,ror#24 @ ^= ROTATE(tpb=tp9^tp2,8) eor r4,r4,r2,ror#16 eor r4,r4,r5,ror#16 @ ^= ROTATE(tpd=tp9^tp4,16) eor r4,r4,r5,ror#8 @ ^= ROTATE(tp9,24) ldr r0,[r11,#4] @ prefetch tp1 str r4,[r11],#4 subs r12,r12,#1 bne .Lmix mov r0,#0 #if __ARM_ARCH__>=5 ldmia sp!,{r4,r5,r6,r7,r8,r9,r10,r11,r12,pc} #else ldmia sp!,{r4,r5,r6,r7,r8,r9,r10,r11,r12,lr} tst lr,#1 moveq pc,lr @ be binary compatible with V4, yet .word 0xe12fff1e @ interoperable with Thumb ISA:-) #endif .size AES_set_enc2dec_key,.-AES_set_enc2dec_key .type AES_Td,%object .align 5 AES_Td: .word 0x51f4a750, 0x7e416553, 0x1a17a4c3, 0x3a275e96 .word 0x3bab6bcb, 0x1f9d45f1, 0xacfa58ab, 0x4be30393 .word 0x2030fa55, 0xad766df6, 0x88cc7691, 0xf5024c25 .word 0x4fe5d7fc, 0xc52acbd7, 0x26354480, 0xb562a38f .word 0xdeb15a49, 0x25ba1b67, 0x45ea0e98, 0x5dfec0e1 .word 0xc32f7502, 0x814cf012, 0x8d4697a3, 0x6bd3f9c6 .word 0x038f5fe7, 0x15929c95, 0xbf6d7aeb, 0x955259da .word 0xd4be832d, 0x587421d3, 0x49e06929, 0x8ec9c844 .word 0x75c2896a, 0xf48e7978, 0x99583e6b, 0x27b971dd .word 0xbee14fb6, 0xf088ad17, 0xc920ac66, 0x7dce3ab4 .word 0x63df4a18, 0xe51a3182, 0x97513360, 0x62537f45 .word 0xb16477e0, 0xbb6bae84, 0xfe81a01c, 0xf9082b94 .word 0x70486858, 0x8f45fd19, 0x94de6c87, 0x527bf8b7 .word 0xab73d323, 0x724b02e2, 0xe31f8f57, 0x6655ab2a .word 0xb2eb2807, 0x2fb5c203, 0x86c57b9a, 0xd33708a5 .word 0x302887f2, 0x23bfa5b2, 0x02036aba, 0xed16825c .word 0x8acf1c2b, 0xa779b492, 0xf307f2f0, 0x4e69e2a1 .word 0x65daf4cd, 0x0605bed5, 0xd134621f, 0xc4a6fe8a .word 0x342e539d, 0xa2f355a0, 0x058ae132, 0xa4f6eb75 .word 0x0b83ec39, 0x4060efaa, 0x5e719f06, 0xbd6e1051 .word 0x3e218af9, 0x96dd063d, 0xdd3e05ae, 0x4de6bd46 .word 0x91548db5, 0x71c45d05, 0x0406d46f, 0x605015ff .word 0x1998fb24, 0xd6bde997, 0x894043cc, 0x67d99e77 .word 0xb0e842bd, 0x07898b88, 0xe7195b38, 0x79c8eedb .word 0xa17c0a47, 0x7c420fe9, 0xf8841ec9, 0x00000000 .word 0x09808683, 0x322bed48, 0x1e1170ac, 0x6c5a724e .word 0xfd0efffb, 0x0f853856, 0x3daed51e, 0x362d3927 .word 0x0a0fd964, 0x685ca621, 0x9b5b54d1, 0x24362e3a .word 0x0c0a67b1, 0x9357e70f, 0xb4ee96d2, 0x1b9b919e .word 0x80c0c54f, 0x61dc20a2, 0x5a774b69, 0x1c121a16 .word 0xe293ba0a, 0xc0a02ae5, 0x3c22e043, 0x121b171d .word 0x0e090d0b, 0xf28bc7ad, 0x2db6a8b9, 0x141ea9c8 .word 0x57f11985, 0xaf75074c, 0xee99ddbb, 0xa37f60fd .word 0xf701269f, 0x5c72f5bc, 0x44663bc5, 0x5bfb7e34 .word 0x8b432976, 0xcb23c6dc, 0xb6edfc68, 0xb8e4f163 .word 0xd731dcca, 0x42638510, 0x13972240, 0x84c61120 .word 0x854a247d, 0xd2bb3df8, 0xaef93211, 0xc729a16d .word 0x1d9e2f4b, 0xdcb230f3, 0x0d8652ec, 0x77c1e3d0 .word 0x2bb3166c, 0xa970b999, 0x119448fa, 0x47e96422 .word 0xa8fc8cc4, 0xa0f03f1a, 0x567d2cd8, 0x223390ef .word 0x87494ec7, 0xd938d1c1, 0x8ccaa2fe, 0x98d40b36 .word 0xa6f581cf, 0xa57ade28, 0xdab78e26, 0x3fadbfa4 .word 0x2c3a9de4, 0x5078920d, 0x6a5fcc9b, 0x547e4662 .word 0xf68d13c2, 0x90d8b8e8, 0x2e39f75e, 0x82c3aff5 .word 0x9f5d80be, 0x69d0937c, 0x6fd52da9, 0xcf2512b3 .word 0xc8ac993b, 0x10187da7, 0xe89c636e, 0xdb3bbb7b .word 0xcd267809, 0x6e5918f4, 0xec9ab701, 0x834f9aa8 .word 0xe6956e65, 0xaaffe67e, 0x21bccf08, 0xef15e8e6 .word 0xbae79bd9, 0x4a6f36ce, 0xea9f09d4, 0x29b07cd6 .word 0x31a4b2af, 0x2a3f2331, 0xc6a59430, 0x35a266c0 .word 0x744ebc37, 0xfc82caa6, 0xe090d0b0, 0x33a7d815 .word 0xf104984a, 0x41ecdaf7, 0x7fcd500e, 0x1791f62f .word 0x764dd68d, 0x43efb04d, 0xccaa4d54, 0xe49604df .word 0x9ed1b5e3, 0x4c6a881b, 0xc12c1fb8, 0x4665517f .word 0x9d5eea04, 0x018c355d, 0xfa877473, 0xfb0b412e .word 0xb3671d5a, 0x92dbd252, 0xe9105633, 0x6dd64713 .word 0x9ad7618c, 0x37a10c7a, 0x59f8148e, 0xeb133c89 .word 0xcea927ee, 0xb761c935, 0xe11ce5ed, 0x7a47b13c .word 0x9cd2df59, 0x55f2733f, 0x1814ce79, 0x73c737bf .word 0x53f7cdea, 0x5ffdaa5b, 0xdf3d6f14, 0x7844db86 .word 0xcaaff381, 0xb968c43e, 0x3824342c, 0xc2a3405f .word 0x161dc372, 0xbce2250c, 0x283c498b, 0xff0d9541 .word 0x39a80171, 0x080cb3de, 0xd8b4e49c, 0x6456c190 .word 0x7bcb8461, 0xd532b670, 0x486c5c74, 0xd0b85742 @ Td4[256] .byte 0x52, 0x09, 0x6a, 0xd5, 0x30, 0x36, 0xa5, 0x38 .byte 0xbf, 0x40, 0xa3, 0x9e, 0x81, 0xf3, 0xd7, 0xfb .byte 0x7c, 0xe3, 0x39, 0x82, 0x9b, 0x2f, 0xff, 0x87 .byte 0x34, 0x8e, 0x43, 0x44, 0xc4, 0xde, 0xe9, 0xcb .byte 0x54, 0x7b, 0x94, 0x32, 0xa6, 0xc2, 0x23, 0x3d .byte 0xee, 0x4c, 0x95, 0x0b, 0x42, 0xfa, 0xc3, 0x4e .byte 0x08, 0x2e, 0xa1, 0x66, 0x28, 0xd9, 0x24, 0xb2 .byte 0x76, 0x5b, 0xa2, 0x49, 0x6d, 0x8b, 0xd1, 0x25 .byte 0x72, 0xf8, 0xf6, 0x64, 0x86, 0x68, 0x98, 0x16 .byte 0xd4, 0xa4, 0x5c, 0xcc, 0x5d, 0x65, 0xb6, 0x92 .byte 0x6c, 0x70, 0x48, 0x50, 0xfd, 0xed, 0xb9, 0xda .byte 0x5e, 0x15, 0x46, 0x57, 0xa7, 0x8d, 0x9d, 0x84 .byte 0x90, 0xd8, 0xab, 0x00, 0x8c, 0xbc, 0xd3, 0x0a .byte 0xf7, 0xe4, 0x58, 0x05, 0xb8, 0xb3, 0x45, 0x06 .byte 0xd0, 0x2c, 0x1e, 0x8f, 0xca, 0x3f, 0x0f, 0x02 .byte 0xc1, 0xaf, 0xbd, 0x03, 0x01, 0x13, 0x8a, 0x6b .byte 0x3a, 0x91, 0x11, 0x41, 0x4f, 0x67, 0xdc, 0xea .byte 0x97, 0xf2, 0xcf, 0xce, 0xf0, 0xb4, 0xe6, 0x73 .byte 0x96, 0xac, 0x74, 0x22, 0xe7, 0xad, 0x35, 0x85 .byte 0xe2, 0xf9, 0x37, 0xe8, 0x1c, 0x75, 0xdf, 0x6e .byte 0x47, 0xf1, 0x1a, 0x71, 0x1d, 0x29, 0xc5, 0x89 .byte 0x6f, 0xb7, 0x62, 0x0e, 0xaa, 0x18, 0xbe, 0x1b .byte 0xfc, 0x56, 0x3e, 0x4b, 0xc6, 0xd2, 0x79, 0x20 .byte 0x9a, 0xdb, 0xc0, 0xfe, 0x78, 0xcd, 0x5a, 0xf4 .byte 0x1f, 0xdd, 0xa8, 0x33, 0x88, 0x07, 0xc7, 0x31 .byte 0xb1, 0x12, 0x10, 0x59, 0x27, 0x80, 0xec, 0x5f .byte 0x60, 0x51, 0x7f, 0xa9, 0x19, 0xb5, 0x4a, 0x0d .byte 0x2d, 0xe5, 0x7a, 0x9f, 0x93, 0xc9, 0x9c, 0xef .byte 0xa0, 0xe0, 0x3b, 0x4d, 0xae, 0x2a, 0xf5, 0xb0 .byte 0xc8, 0xeb, 0xbb, 0x3c, 0x83, 0x53, 0x99, 0x61 .byte 0x17, 0x2b, 0x04, 0x7e, 0xba, 0x77, 0xd6, 0x26 .byte 0xe1, 0x69, 0x14, 0x63, 0x55, 0x21, 0x0c, 0x7d .size AES_Td,.-AES_Td @ void AES_decrypt(const unsigned char *in, unsigned char *out, @ const AES_KEY *key) { .globl AES_decrypt .type AES_decrypt,%function .align 5 AES_decrypt: #ifndef __thumb2__ sub r3,pc,#8 @ AES_decrypt #else adr r3,AES_decrypt #endif stmdb sp!,{r1,r4-r12,lr} #ifdef __APPLE__ adr r10,AES_Td #else sub r10,r3,#AES_decrypt-AES_Td @ Td #endif mov r12,r0 @ inp mov r11,r2 #if __ARM_ARCH__<7 ldrb r0,[r12,#3] @ load input data in endian-neutral ldrb r4,[r12,#2] @ manner... ldrb r5,[r12,#1] ldrb r6,[r12,#0] orr r0,r0,r4,lsl#8 ldrb r1,[r12,#7] orr r0,r0,r5,lsl#16 ldrb r4,[r12,#6] orr r0,r0,r6,lsl#24 ldrb r5,[r12,#5] ldrb r6,[r12,#4] orr r1,r1,r4,lsl#8 ldrb r2,[r12,#11] orr r1,r1,r5,lsl#16 ldrb r4,[r12,#10] orr r1,r1,r6,lsl#24 ldrb r5,[r12,#9] ldrb r6,[r12,#8] orr r2,r2,r4,lsl#8 ldrb r3,[r12,#15] orr r2,r2,r5,lsl#16 ldrb r4,[r12,#14] orr r2,r2,r6,lsl#24 ldrb r5,[r12,#13] ldrb r6,[r12,#12] orr r3,r3,r4,lsl#8 orr r3,r3,r5,lsl#16 orr r3,r3,r6,lsl#24 #else ldr r0,[r12,#0] ldr r1,[r12,#4] ldr r2,[r12,#8] ldr r3,[r12,#12] #ifdef __ARMEL__ rev r0,r0 rev r1,r1 rev r2,r2 rev r3,r3 #endif #endif bl _armv4_AES_decrypt ldr r12,[sp],#4 @ pop out #if __ARM_ARCH__>=7 #ifdef __ARMEL__ rev r0,r0 rev r1,r1 rev r2,r2 rev r3,r3 #endif str r0,[r12,#0] str r1,[r12,#4] str r2,[r12,#8] str r3,[r12,#12] #else mov r4,r0,lsr#24 @ write output in endian-neutral mov r5,r0,lsr#16 @ manner... mov r6,r0,lsr#8 strb r4,[r12,#0] strb r5,[r12,#1] mov r4,r1,lsr#24 strb r6,[r12,#2] mov r5,r1,lsr#16 strb r0,[r12,#3] mov r6,r1,lsr#8 strb r4,[r12,#4] strb r5,[r12,#5] mov r4,r2,lsr#24 strb r6,[r12,#6] mov r5,r2,lsr#16 strb r1,[r12,#7] mov r6,r2,lsr#8 strb r4,[r12,#8] strb r5,[r12,#9] mov r4,r3,lsr#24 strb r6,[r12,#10] mov r5,r3,lsr#16 strb r2,[r12,#11] mov r6,r3,lsr#8 strb r4,[r12,#12] strb r5,[r12,#13] strb r6,[r12,#14] strb r3,[r12,#15] #endif #if __ARM_ARCH__>=5 ldmia sp!,{r4,r5,r6,r7,r8,r9,r10,r11,r12,pc} #else ldmia sp!,{r4,r5,r6,r7,r8,r9,r10,r11,r12,lr} tst lr,#1 moveq pc,lr @ be binary compatible with V4, yet .word 0xe12fff1e @ interoperable with Thumb ISA:-) #endif .size AES_decrypt,.-AES_decrypt .type _armv4_AES_decrypt,%function .align 2 _armv4_AES_decrypt: str lr,[sp,#-4]! @ push lr ldmia r11!,{r4,r5,r6,r7} eor r0,r0,r4 ldr r12,[r11,#240-16] eor r1,r1,r5 eor r2,r2,r6 eor r3,r3,r7 sub r12,r12,#1 mov lr,#255 and r7,lr,r0,lsr#16 and r8,lr,r0,lsr#8 and r9,lr,r0 mov r0,r0,lsr#24 .Ldec_loop: ldr r4,[r10,r7,lsl#2] @ Td1[s0>>16] and r7,lr,r1 @ i0 ldr r5,[r10,r8,lsl#2] @ Td2[s0>>8] and r8,lr,r1,lsr#16 ldr r6,[r10,r9,lsl#2] @ Td3[s0>>0] and r9,lr,r1,lsr#8 ldr r0,[r10,r0,lsl#2] @ Td0[s0>>24] mov r1,r1,lsr#24 ldr r7,[r10,r7,lsl#2] @ Td3[s1>>0] ldr r8,[r10,r8,lsl#2] @ Td1[s1>>16] ldr r9,[r10,r9,lsl#2] @ Td2[s1>>8] eor r0,r0,r7,ror#24 ldr r1,[r10,r1,lsl#2] @ Td0[s1>>24] and r7,lr,r2,lsr#8 @ i0 eor r5,r8,r5,ror#8 and r8,lr,r2 @ i1 eor r6,r9,r6,ror#8 and r9,lr,r2,lsr#16 ldr r7,[r10,r7,lsl#2] @ Td2[s2>>8] eor r1,r1,r4,ror#8 ldr r8,[r10,r8,lsl#2] @ Td3[s2>>0] mov r2,r2,lsr#24 ldr r9,[r10,r9,lsl#2] @ Td1[s2>>16] eor r0,r0,r7,ror#16 ldr r2,[r10,r2,lsl#2] @ Td0[s2>>24] and r7,lr,r3,lsr#16 @ i0 eor r1,r1,r8,ror#24 and r8,lr,r3,lsr#8 @ i1 eor r6,r9,r6,ror#8 and r9,lr,r3 @ i2 ldr r7,[r10,r7,lsl#2] @ Td1[s3>>16] eor r2,r2,r5,ror#8 ldr r8,[r10,r8,lsl#2] @ Td2[s3>>8] mov r3,r3,lsr#24 ldr r9,[r10,r9,lsl#2] @ Td3[s3>>0] eor r0,r0,r7,ror#8 ldr r7,[r11],#16 eor r1,r1,r8,ror#16 ldr r3,[r10,r3,lsl#2] @ Td0[s3>>24] eor r2,r2,r9,ror#24 ldr r4,[r11,#-12] eor r0,r0,r7 ldr r5,[r11,#-8] eor r3,r3,r6,ror#8 ldr r6,[r11,#-4] and r7,lr,r0,lsr#16 eor r1,r1,r4 and r8,lr,r0,lsr#8 eor r2,r2,r5 and r9,lr,r0 eor r3,r3,r6 mov r0,r0,lsr#24 subs r12,r12,#1 bne .Ldec_loop add r10,r10,#1024 ldr r5,[r10,#0] @ prefetch Td4 ldr r6,[r10,#32] ldr r4,[r10,#64] ldr r5,[r10,#96] ldr r6,[r10,#128] ldr r4,[r10,#160] ldr r5,[r10,#192] ldr r6,[r10,#224] ldrb r0,[r10,r0] @ Td4[s0>>24] ldrb r4,[r10,r7] @ Td4[s0>>16] and r7,lr,r1 @ i0 ldrb r5,[r10,r8] @ Td4[s0>>8] and r8,lr,r1,lsr#16 ldrb r6,[r10,r9] @ Td4[s0>>0] and r9,lr,r1,lsr#8 add r1,r10,r1,lsr#24 ldrb r7,[r10,r7] @ Td4[s1>>0] ldrb r1,[r1] @ Td4[s1>>24] ldrb r8,[r10,r8] @ Td4[s1>>16] eor r0,r7,r0,lsl#24 ldrb r9,[r10,r9] @ Td4[s1>>8] eor r1,r4,r1,lsl#8 and r7,lr,r2,lsr#8 @ i0 eor r5,r5,r8,lsl#8 and r8,lr,r2 @ i1 ldrb r7,[r10,r7] @ Td4[s2>>8] eor r6,r6,r9,lsl#8 ldrb r8,[r10,r8] @ Td4[s2>>0] and r9,lr,r2,lsr#16 add r2,r10,r2,lsr#24 ldrb r2,[r2] @ Td4[s2>>24] eor r0,r0,r7,lsl#8 ldrb r9,[r10,r9] @ Td4[s2>>16] eor r1,r8,r1,lsl#16 and r7,lr,r3,lsr#16 @ i0 eor r2,r5,r2,lsl#16 and r8,lr,r3,lsr#8 @ i1 ldrb r7,[r10,r7] @ Td4[s3>>16] eor r6,r6,r9,lsl#16 ldrb r8,[r10,r8] @ Td4[s3>>8] and r9,lr,r3 @ i2 add r3,r10,r3,lsr#24 ldrb r9,[r10,r9] @ Td4[s3>>0] ldrb r3,[r3] @ Td4[s3>>24] eor r0,r0,r7,lsl#16 ldr r7,[r11,#0] eor r1,r1,r8,lsl#8 ldr r4,[r11,#4] eor r2,r9,r2,lsl#8 ldr r5,[r11,#8] eor r3,r6,r3,lsl#24 ldr r6,[r11,#12] eor r0,r0,r7 eor r1,r1,r4 eor r2,r2,r5 eor r3,r3,r6 sub r10,r10,#1024 ldr pc,[sp],#4 @ pop and return .size _armv4_AES_decrypt,.-_armv4_AES_decrypt .byte 65,69,83,32,102,111,114,32,65,82,77,118,52,44,32,67,82,89,80,84,79,71,65,77,83,32,98,121,32,60,97,112,112,114,111,64,111,112,101,110,115,115,108,46,111,114,103,62,0 .align 2 .align 2 gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_THREADS -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/local/ssl\"" -DENGINESDIR="\"/usr/local/lib/engines\"" -pthread -Wall -O3 -march=armv7-a -Wa,--noexecstack -Iinclude -I. -Icrypto/include -MM -MF crypto/aes/aes-armv4.d -MQ crypto/aes/aes-armv4 crypto/aes/aes-armv4.S crypto/aes/aes-armv4.S:1:22: fatal error: arm_arch.h: No such file or directory #include "arm_arch.h" ^ compilation terminated. Makefile:656: recipe for target 'crypto/aes/aes-armv4.d' failed make: *** [crypto/aes/aes-armv4.d] Error 1 -------------- next part -------------- A non-text attachment was scrubbed... Name: aes-armv4.pl.patch Type: text/x-patch Size: 1114 bytes Desc: not available URL: From sander at temme.net Sat Feb 20 20:40:38 2016 From: sander at temme.net (Sander Temme) Date: Sat, 20 Feb 2016 12:40:38 -0800 Subject: [openssl-dev] Ubsec and Chil engines In-Reply-To: <56C6FCFA.4040602@openssl.org> References: <56C6FCFA.4040602@openssl.org> Message-ID: <5B8F45EA-5867-4832-916A-6B31A323A59C@temme.net> > On Feb 19, 2016, at 3:31 AM, Matt Caswell wrote: OK that made our support lines blow up so yes there is interest. Disclaimer: I work for Thales but do not speak for Thales. > So it seems that for chil there may possibly be some rare use (but even > the most recent evidence is 4 years old). However the OpenSSL dev team > do not have access to this hardware to maintain the engine and (as noted > above) this is currently not building in 1.1.0. I think (again, personal impression) that this is one of those sleeper integrations that a lot of people use but doesn?t get on the radar a whole lot. Using openssl is by far the easiest way to get the nShield HSM to do something with protected keys? as long as those are RSA keys. Pair that with existing application integrations like Apache, OpenSSH, etc. I know of a number of customers and partners, none of whom I am at liberty to discuss (although they might speak up for themselves), who use OpenSSL with nShield for various applications. So it?s not dead. What it does, it does very well. If anything, the lack of visible activity may indicate how easy CHIL is to use and support. > In both cases I would like to remove these engines from 1.1.0. I'd like > to hear from the community if there is any active use of these. One > option if there is found to be some small scale use is to spin out the > engine into a separately managed repo (as has happened recently with the > GOST engine). > > If I don't hear from anyone I will remove these. Ehm. Let?s talk about this. As I noted above, a lot of our valued customers may depend on this even thought they might not know or may have forgotten about it. From your October 28 commit (29e7a56d), it seems that what broke us was when the bn structure went opaque? I see only two lines in e_chil.c that depend on the internal structure of bn so that should be addressable. We?d like to do some more things to this Engine, like more key types and, yes, those dynamic locks should go away, which requires some surgery to the stuff underneath but nothing major. All the platforms we run on now have good locking. And, Rich, I indeed have had those locks on my guilty conscience for all this time but not found any round tuits. However, I?m intrigued by the notion of a PKCS#11 Engine in OpenSSL: it?s a standard (an OASIS standard now); it?s fairly fully featured; everyone in the industry supports it including Thales; and you can build a program that calls it without needing a vendor SDK, because there are standard headers and a well defined way to get to the entry points. If we can come up with a way to pick a PKCS#11 slot and log into it that makes sense (e.g. not by poking PINs into a system wide config file etc.) then I think we?d have a winner. What I would like to see though is for such a PKCS#11 Engine to be part of OpenSSL proper, so that our customers and everyone else?s don?t have to go hunt hither and yon for bits and bobs of software in order to make their hardware kit work with OpenSSL. How would OpenSSL obtain a PKCS#11 Engine to include in its distribution? Thanks, S. -- sander at temme.net http://www.temme.net/sander/ PGP FP: BCD1 6D2C 8906 C48A 540E 253E 94D3 36A3 6D15 930A -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 235 bytes Desc: Message signed with OpenPGP using GPGMail URL: From levitte at openssl.org Sat Feb 20 21:55:41 2016 From: levitte at openssl.org (Richard Levitte) Date: Sat, 20 Feb 2016 22:55:41 +0100 (CET) Subject: [openssl-dev] Ubsec and Chil engines In-Reply-To: <5B8F45EA-5867-4832-916A-6B31A323A59C@temme.net> References: <56C6FCFA.4040602@openssl.org> <5B8F45EA-5867-4832-916A-6B31A323A59C@temme.net> Message-ID: <20160220.225541.1585601945103016062.levitte@openssl.org> In message <5B8F45EA-5867-4832-916A-6B31A323A59C at temme.net> on Sat, 20 Feb 2016 12:40:38 -0800, Sander Temme said: sander> sander> > On Feb 19, 2016, at 3:31 AM, Matt Caswell wrote: sander> sander> OK that made our support lines blow up so yes there is interest. sander> sander> Disclaimer: I work for Thales but do not speak for Thales. sander> sander> > So it seems that for chil there may possibly be some rare use (but even sander> > the most recent evidence is 4 years old). However the OpenSSL dev team sander> > do not have access to this hardware to maintain the engine and (as noted sander> > above) this is currently not building in 1.1.0. sander> sander> I think (again, personal impression) that this is one of those sander> sleeper integrations that a lot of people use but doesn?t get sander> on the radar a whole lot. Using openssl is by far the easiest sander> way to get the nShield HSM to do something with protected sander> keys? as long as those are RSA keys. Pair that with existing sander> application integrations like Apache, OpenSSH, etc. I know of sander> a number of customers and partners, none of whom I am at sander> liberty to discuss (although they might speak up for sander> themselves), who use OpenSSL with nShield for various sander> applications. Oh, nShield? Back when I was playing with e_chil.c, it was nCipher. But, no matter really... sander> So it?s not dead. What it does, it does very well. If sander> anything, the lack of visible activity may indicate how easy sander> CHIL is to use and support. The trouble is that we can't verify that. We don't have the hardware or the expertise. Even the few of us that got to play with a nCipher box 15+ years ago don't have that around any more. So there's that pile of code that no one dares to touch because we have no idea what the effects might be and have no way of testing that. With all that in mind, I've a question back to you... wouldn't it be more productive if Thales let an OpenSSL engine, built as a DSO, accompany the hardware? Considering you are much closer to the hardware and the expertise, it seems a bit more appropriate, doesn't it? sander> What I would like to see though is for such a PKCS#11 Engine sander> to be part of OpenSSL proper, so that our customers and sander> everyone else?s don?t have to go hunt hither and yon for bits sander> and bobs of software in order to make their hardware kit work sander> with OpenSSL. How would OpenSSL obtain a PKCS#11 Engine to sander> include in its distribution? I'm not sure if this is a problem specifically for OpenSSL to solve, or if it is a packager problem. Sometimes, the border between the two might be blurry, but... If OpenSSL is to "obtain" a PKCS#11 engine, it would probably be by writing one. It would be far easier, though, if someone would package the already existing engine_pkcs11 with OpenSSL (that packaging doesn't have to be done by the OpenSSL team), *or* with hardware distributions. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From jaroslav.imrich at gmail.com Sat Feb 20 22:34:10 2016 From: jaroslav.imrich at gmail.com (Jaroslav Imrich) Date: Sat, 20 Feb 2016 23:34:10 +0100 Subject: [openssl-dev] Ubsec and Chil engines In-Reply-To: <5B8F45EA-5867-4832-916A-6B31A323A59C@temme.net> References: <56C6FCFA.4040602@openssl.org> <5B8F45EA-5867-4832-916A-6B31A323A59C@temme.net> Message-ID: On 20 February 2016 at 21:40, Sander Temme wrote: > However, I?m intrigued by the notion of a PKCS#11 Engine in OpenSSL: it?s > a standard (an OASIS standard now); it?s fairly fully featured; everyone in > the industry supports it including Thales; and you can build a program that > calls it without needing a vendor SDK, because there are standard headers > and a well defined way to get to the entry points. If we can come up with > a way to pick a PKCS#11 slot and log into it that makes sense (e.g. not by > poking PINs into a system wide config file etc.) then I think we?d have a > winner. > Let's not forget that CHIL provides one very unique feature - forked process keeps the authentication state of its parent and can access HSM keys if its parent was authenticated. PKCS#11 specification prohibits such behavior (PKCS#11 v2.20 chapter 6.6.1) and because of that PKCS#11 based engine couldn't fully replace CHIL engine. Regards, Jaroslav -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Sun Feb 21 00:35:06 2016 From: rt at openssl.org (noloader@gmail.com via RT) Date: Sun, 21 Feb 2016 00:35:06 +0000 Subject: [openssl-dev] [openssl.org #4326] Failed to configure for Cygwin-x64 In-Reply-To: References: Message-ID: After configuring on Windows 8.1/Core i5 4th gen machine, make'ing depend produces the following errors: $ make depend making depend in crypto... make[1]: Entering directory '/home/Test_User/openssl-1.0.2f/crypto' cc1: error: CPU you selected does not support x86-64 instruction set cc1: error: CPU you selected does not support x86-64 instruction set cc1: error: CPU you selected does not support x86-64 instruction set cc1: error: CPU you selected does not support x86-64 instruction set cc1: error: CPU you selected does not support x86-64 instruction set cc1: error: CPU you selected does not support x86-64 instruction set cc1: error: CPU you selected does not support x86-64 instruction set cc1: error: CPU you selected does not support x86-64 instruction set cc1: error: CPU you selected does not support x86-64 instruction set cc1: error: CPU you selected does not support x86-64 instruction set cc1: error: CPU you selected does not support x86-64 instruction set cc1: error: CPU you selected does not support x86-64 instruction set cc1: error: CPU you selected does not support x86-64 instruction set cc1: error: CPU you selected does not support x86-64 instruction set cc1: error: CPU you selected does not support x86-64 instruction set cc1: error: CPU you selected does not support x86-64 instruction set cc1: error: CPU you selected does not support x86-64 instruction set cc1: error: CPU you selected does not support x86-64 instruction set cc1: error: CPU you selected does not support x86-64 instruction set cc1: error: CPU you selected does not support x86-64 instruction set cc1: error: CPU you selected does not support x86-64 instruction set cc1: error: CPU you selected does not support x86-64 instruction set cc1: error: CPU you selected does not support x86-64 instruction set cc1: error: CPU you selected does not support x86-64 instruction set cc1: error: CPU you selected does not support x86-64 instruction set cc1: error: CPU you selected does not support x86-64 instruction set cc1: error: CPU you selected does not support x86-64 instruction set cc1: error: CPU you selected does not support x86-64 instruction set cc1: error: CPU you selected does not support x86-64 instruction set cc1: error: CPU you selected does not support x86-64 instruction set Makefile:136: recipe for target 'local_depend' failed make[1]: *** [local_depend] Error 1 make[1]: Leaving directory '/home/Test_User/openssl-1.0.2f/crypto' Makefile:471: recipe for target 'depend' failed make: *** [depend] Error 1 ====================== $ ./config shared no-ssl2 no-ssl3 --openssldir="$HOME/ssl" Operating system: x86_64-whatever-cygwin Configuring for Cygwin Configuring for Cygwin no-ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128 (skip dir) no-gmp [default] OPENSSL_NO_GMP (skip dir) no-jpake [experimental] OPENSSL_NO_JPAKE (skip dir) no-krb5 [krb5-flavor not specified] OPENSSL_NO_KRB5 no-libunbound [experimental] OPENSSL_NO_LIBUNBOUND (skip dir) no-md2 [default] OPENSSL_NO_MD2 (skip dir) no-rc5 [default] OPENSSL_NO_RC5 (skip dir) no-rfc3779 [default] OPENSSL_NO_RFC3779 (skip dir) no-sctp [default] OPENSSL_NO_SCTP (skip dir) no-ssl-trace [default] OPENSSL_NO_SSL_TRACE (skip dir) no-ssl2 [option] OPENSSL_NO_SSL2 (skip dir) no-ssl3 [option] OPENSSL_NO_SSL3 (skip dir) no-store [experimental] OPENSSL_NO_STORE (skip dir) no-unit-test [default] OPENSSL_NO_UNIT_TEST (skip dir) no-zlib [default] no-zlib-dynamic [default] IsMK1MF=0 CC =gcc CFLAG =-D_WINDLL -DOPENSSL_PIC -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H -DTERMIOS -DL_ENDIAN -fomit-frame-pointer -O3 -march=i486 -Wall -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM EX_LIBS = CPUID_OBJ =x86cpuid.o BN_ASM =bn-586.o co-586.o x86-mont.o x86-gf2m.o EC_ASM = DES_ENC =des-586.o crypt586.o AES_ENC =aes-586.o vpaes-x86.o aesni-x86.o BF_ENC =bf-586.o CAST_ENC =c_enc.o RC4_ENC =rc4-586.o RC5_ENC =rc5-586.o MD5_OBJ_ASM =md5-586.o SHA1_OBJ_ASM =sha1-586.o sha256-586.o sha512-586.o RMD160_OBJ_ASM=rmd-586.o CMLL_ENC =cmll-x86.o MODES_OBJ =ghash-x86.o ENGINES_OBJ = PROCESSOR = RANLIB =/usr/bin/ranlib.exe ARFLAGS = PERL =/usr/bin/perl.exe THIRTY_TWO_BIT mode DES_PTR used DES_RISC1 used DES_UNROLL used BN_LLONG mode RC4_INDEX mode RC4_CHUNK is undefined e_os2.h => include/openssl/e_os2.h making links in crypto... make[1]: Entering directory '/home/Test_User/openssl-1.0.2f/crypto' crypto.h => ../include/openssl/crypto.h opensslv.h => ../include/openssl/opensslv.h opensslconf.h => ../include/openssl/opensslconf.h ebcdic.h => ../include/openssl/ebcdic.h symhacks.h => ../include/openssl/symhacks.h ossl_typ.h => ../include/openssl/ossl_typ.h constant_time_test.c => ../test/constant_time_test.c making links in crypto/objects... make[2]: Entering directory '/home/Test_User/openssl-1.0.2f/crypto/objects' objects.h => ../../include/openssl/objects.h obj_mac.h => ../../include/openssl/obj_mac.h make[2]: Leaving directory '/home/Test_User/openssl-1.0.2f/crypto/objects' making links in crypto/md4... make[2]: Entering directory '/home/Test_User/openssl-1.0.2f/crypto/md4' md4.h => ../../include/openssl/md4.h md4test.c => ../../test/md4test.c md4.c => ../../apps/md4.c make[2]: Leaving directory '/home/Test_User/openssl-1.0.2f/crypto/md4' making links in crypto/md5... make[2]: Entering directory '/home/Test_User/openssl-1.0.2f/crypto/md5' md5.h => ../../include/openssl/md5.h md5test.c => ../../test/md5test.c make[2]: Leaving directory '/home/Test_User/openssl-1.0.2f/crypto/md5' making links in crypto/sha... make[2]: Entering directory '/home/Test_User/openssl-1.0.2f/crypto/sha' sha.h => ../../include/openssl/sha.h shatest.c => ../../test/shatest.c sha1test.c => ../../test/sha1test.c sha256t.c => ../../test/sha256t.c sha512t.c => ../../test/sha512t.c make[2]: Leaving directory '/home/Test_User/openssl-1.0.2f/crypto/sha' making links in crypto/mdc2... make[2]: Entering directory '/home/Test_User/openssl-1.0.2f/crypto/mdc2' mdc2.h => ../../include/openssl/mdc2.h mdc2test.c => ../../test/mdc2test.c make[2]: Leaving directory '/home/Test_User/openssl-1.0.2f/crypto/mdc2' making links in crypto/hmac... make[2]: Entering directory '/home/Test_User/openssl-1.0.2f/crypto/hmac' hmac.h => ../../include/openssl/hmac.h hmactest.c => ../../test/hmactest.c make[2]: Leaving directory '/home/Test_User/openssl-1.0.2f/crypto/hmac' making links in crypto/ripemd... make[2]: Entering directory '/home/Test_User/openssl-1.0.2f/crypto/ripemd' ripemd.h => ../../include/openssl/ripemd.h rmdtest.c => ../../test/rmdtest.c make[2]: Leaving directory '/home/Test_User/openssl-1.0.2f/crypto/ripemd' making links in crypto/whrlpool... make[2]: Entering directory '/home/Test_User/openssl-1.0.2f/crypto/whrlpool' whrlpool.h => ../../include/openssl/whrlpool.h wp_test.c => ../../test/wp_test.c make[2]: Leaving directory '/home/Test_User/openssl-1.0.2f/crypto/whrlpool' making links in crypto/des... make[2]: Entering directory '/home/Test_User/openssl-1.0.2f/crypto/des' des.h => ../../include/openssl/des.h des_old.h => ../../include/openssl/des_old.h destest.c => ../../test/destest.c make[2]: Leaving directory '/home/Test_User/openssl-1.0.2f/crypto/des' making links in crypto/aes... make[2]: Entering directory '/home/Test_User/openssl-1.0.2f/crypto/aes' aes.h => ../../include/openssl/aes.h make[2]: Leaving directory '/home/Test_User/openssl-1.0.2f/crypto/aes' making links in crypto/rc2... make[2]: Entering directory '/home/Test_User/openssl-1.0.2f/crypto/rc2' rc2.h => ../../include/openssl/rc2.h rc2test.c => ../../test/rc2test.c make[2]: Leaving directory '/home/Test_User/openssl-1.0.2f/crypto/rc2' making links in crypto/rc4... make[2]: Entering directory '/home/Test_User/openssl-1.0.2f/crypto/rc4' rc4.h => ../../include/openssl/rc4.h rc4test.c => ../../test/rc4test.c make[2]: Leaving directory '/home/Test_User/openssl-1.0.2f/crypto/rc4' making links in crypto/idea... make[2]: Entering directory '/home/Test_User/openssl-1.0.2f/crypto/idea' idea.h => ../../include/openssl/idea.h ideatest.c => ../../test/ideatest.c make[2]: Leaving directory '/home/Test_User/openssl-1.0.2f/crypto/idea' making links in crypto/bf... make[2]: Entering directory '/home/Test_User/openssl-1.0.2f/crypto/bf' blowfish.h => ../../include/openssl/blowfish.h bftest.c => ../../test/bftest.c make[2]: Leaving directory '/home/Test_User/openssl-1.0.2f/crypto/bf' making links in crypto/cast... make[2]: Entering directory '/home/Test_User/openssl-1.0.2f/crypto/cast' cast.h => ../../include/openssl/cast.h casttest.c => ../../test/casttest.c make[2]: Leaving directory '/home/Test_User/openssl-1.0.2f/crypto/cast' making links in crypto/camellia... make[2]: Entering directory '/home/Test_User/openssl-1.0.2f/crypto/camellia' camellia.h => ../../include/openssl/camellia.h make[2]: Leaving directory '/home/Test_User/openssl-1.0.2f/crypto/camellia' making links in crypto/seed... make[2]: Entering directory '/home/Test_User/openssl-1.0.2f/crypto/seed' seed.h => ../../include/openssl/seed.h make[2]: Leaving directory '/home/Test_User/openssl-1.0.2f/crypto/seed' making links in crypto/modes... make[2]: Entering directory '/home/Test_User/openssl-1.0.2f/crypto/modes' modes.h => ../../include/openssl/modes.h make[2]: Leaving directory '/home/Test_User/openssl-1.0.2f/crypto/modes' making links in crypto/bn... make[2]: Entering directory '/home/Test_User/openssl-1.0.2f/crypto/bn' bn.h => ../../include/openssl/bn.h bntest.c => ../../test/bntest.c exptest.c => ../../test/exptest.c make[2]: Leaving directory '/home/Test_User/openssl-1.0.2f/crypto/bn' making links in crypto/ec... make[2]: Entering directory '/home/Test_User/openssl-1.0.2f/crypto/ec' ec.h => ../../include/openssl/ec.h ectest.c => ../../test/ectest.c make[2]: Leaving directory '/home/Test_User/openssl-1.0.2f/crypto/ec' making links in crypto/rsa... make[2]: Entering directory '/home/Test_User/openssl-1.0.2f/crypto/rsa' rsa.h => ../../include/openssl/rsa.h rsa_test.c => ../../test/rsa_test.c make[2]: Leaving directory '/home/Test_User/openssl-1.0.2f/crypto/rsa' making links in crypto/dsa... make[2]: Entering directory '/home/Test_User/openssl-1.0.2f/crypto/dsa' dsa.h => ../../include/openssl/dsa.h dsatest.c => ../../test/dsatest.c make[2]: Leaving directory '/home/Test_User/openssl-1.0.2f/crypto/dsa' making links in crypto/ecdsa... make[2]: Entering directory '/home/Test_User/openssl-1.0.2f/crypto/ecdsa' ecdsa.h => ../../include/openssl/ecdsa.h ecdsatest.c => ../../test/ecdsatest.c make[2]: Leaving directory '/home/Test_User/openssl-1.0.2f/crypto/ecdsa' making links in crypto/dh... make[2]: Entering directory '/home/Test_User/openssl-1.0.2f/crypto/dh' dh.h => ../../include/openssl/dh.h dhtest.c => ../../test/dhtest.c make[2]: Leaving directory '/home/Test_User/openssl-1.0.2f/crypto/dh' making links in crypto/ecdh... make[2]: Entering directory '/home/Test_User/openssl-1.0.2f/crypto/ecdh' ecdh.h => ../../include/openssl/ecdh.h ecdhtest.c => ../../test/ecdhtest.c make[2]: Leaving directory '/home/Test_User/openssl-1.0.2f/crypto/ecdh' making links in crypto/dso... make[2]: Entering directory '/home/Test_User/openssl-1.0.2f/crypto/dso' dso.h => ../../include/openssl/dso.h make[2]: Leaving directory '/home/Test_User/openssl-1.0.2f/crypto/dso' making links in crypto/engine... make[2]: Entering directory '/home/Test_User/openssl-1.0.2f/crypto/engine' engine.h => ../../include/openssl/engine.h enginetest.c => ../../test/enginetest.c make[2]: Leaving directory '/home/Test_User/openssl-1.0.2f/crypto/engine' making links in crypto/buffer... make[2]: Entering directory '/home/Test_User/openssl-1.0.2f/crypto/buffer' buffer.h => ../../include/openssl/buffer.h make[2]: Leaving directory '/home/Test_User/openssl-1.0.2f/crypto/buffer' making links in crypto/bio... make[2]: Entering directory '/home/Test_User/openssl-1.0.2f/crypto/bio' bio.h => ../../include/openssl/bio.h make[2]: Leaving directory '/home/Test_User/openssl-1.0.2f/crypto/bio' making links in crypto/stack... make[2]: Entering directory '/home/Test_User/openssl-1.0.2f/crypto/stack' stack.h => ../../include/openssl/stack.h safestack.h => ../../include/openssl/safestack.h make[2]: Leaving directory '/home/Test_User/openssl-1.0.2f/crypto/stack' making links in crypto/lhash... make[2]: Entering directory '/home/Test_User/openssl-1.0.2f/crypto/lhash' lhash.h => ../../include/openssl/lhash.h make[2]: Leaving directory '/home/Test_User/openssl-1.0.2f/crypto/lhash' making links in crypto/rand... make[2]: Entering directory '/home/Test_User/openssl-1.0.2f/crypto/rand' rand.h => ../../include/openssl/rand.h randtest.c => ../../test/randtest.c make[2]: Leaving directory '/home/Test_User/openssl-1.0.2f/crypto/rand' making links in crypto/err... make[2]: Entering directory '/home/Test_User/openssl-1.0.2f/crypto/err' err.h => ../../include/openssl/err.h make[2]: Leaving directory '/home/Test_User/openssl-1.0.2f/crypto/err' making links in crypto/evp... make[2]: Entering directory '/home/Test_User/openssl-1.0.2f/crypto/evp' evp.h => ../../include/openssl/evp.h evp_test.c => ../../test/evp_test.c evp_extra_test.c => ../../test/evp_extra_test.c evptests.txt -> ../../test/evptests.txt make[2]: Leaving directory '/home/Test_User/openssl-1.0.2f/crypto/evp' making links in crypto/asn1... make[2]: Entering directory '/home/Test_User/openssl-1.0.2f/crypto/asn1' asn1.h => ../../include/openssl/asn1.h asn1_mac.h => ../../include/openssl/asn1_mac.h asn1t.h => ../../include/openssl/asn1t.h make[2]: Leaving directory '/home/Test_User/openssl-1.0.2f/crypto/asn1' making links in crypto/pem... make[2]: Entering directory '/home/Test_User/openssl-1.0.2f/crypto/pem' pem.h => ../../include/openssl/pem.h pem2.h => ../../include/openssl/pem2.h make[2]: Leaving directory '/home/Test_User/openssl-1.0.2f/crypto/pem' making links in crypto/x509... make[2]: Entering directory '/home/Test_User/openssl-1.0.2f/crypto/x509' x509.h => ../../include/openssl/x509.h x509_vfy.h => ../../include/openssl/x509_vfy.h verify_extra_test.c => ../../test/verify_extra_test.c make[2]: Leaving directory '/home/Test_User/openssl-1.0.2f/crypto/x509' making links in crypto/x509v3... make[2]: Entering directory '/home/Test_User/openssl-1.0.2f/crypto/x509v3' x509v3.h => ../../include/openssl/x509v3.h v3nametest.c => ../../test/v3nametest.c make[2]: Leaving directory '/home/Test_User/openssl-1.0.2f/crypto/x509v3' making links in crypto/conf... make[2]: Entering directory '/home/Test_User/openssl-1.0.2f/crypto/conf' conf.h => ../../include/openssl/conf.h conf_api.h => ../../include/openssl/conf_api.h make[2]: Leaving directory '/home/Test_User/openssl-1.0.2f/crypto/conf' making links in crypto/txt_db... make[2]: Entering directory '/home/Test_User/openssl-1.0.2f/crypto/txt_db' txt_db.h => ../../include/openssl/txt_db.h make[2]: Leaving directory '/home/Test_User/openssl-1.0.2f/crypto/txt_db' making links in crypto/pkcs7... make[2]: Entering directory '/home/Test_User/openssl-1.0.2f/crypto/pkcs7' pkcs7.h => ../../include/openssl/pkcs7.h make[2]: Leaving directory '/home/Test_User/openssl-1.0.2f/crypto/pkcs7' making links in crypto/pkcs12... make[2]: Entering directory '/home/Test_User/openssl-1.0.2f/crypto/pkcs12' pkcs12.h => ../../include/openssl/pkcs12.h make[2]: Leaving directory '/home/Test_User/openssl-1.0.2f/crypto/pkcs12' making links in crypto/comp... make[2]: Entering directory '/home/Test_User/openssl-1.0.2f/crypto/comp' comp.h => ../../include/openssl/comp.h make[2]: Leaving directory '/home/Test_User/openssl-1.0.2f/crypto/comp' making links in crypto/ocsp... make[2]: Entering directory '/home/Test_User/openssl-1.0.2f/crypto/ocsp' ocsp.h => ../../include/openssl/ocsp.h make[2]: Leaving directory '/home/Test_User/openssl-1.0.2f/crypto/ocsp' making links in crypto/ui... make[2]: Entering directory '/home/Test_User/openssl-1.0.2f/crypto/ui' ui.h => ../../include/openssl/ui.h ui_compat.h => ../../include/openssl/ui_compat.h make[2]: Leaving directory '/home/Test_User/openssl-1.0.2f/crypto/ui' making links in crypto/krb5... make[2]: Entering directory '/home/Test_User/openssl-1.0.2f/crypto/krb5' krb5_asn.h => ../../include/openssl/krb5_asn.h make[2]: Leaving directory '/home/Test_User/openssl-1.0.2f/crypto/krb5' making links in crypto/cms... make[2]: Entering directory '/home/Test_User/openssl-1.0.2f/crypto/cms' cms.h => ../../include/openssl/cms.h make[2]: Leaving directory '/home/Test_User/openssl-1.0.2f/crypto/cms' making links in crypto/pqueue... make[2]: Entering directory '/home/Test_User/openssl-1.0.2f/crypto/pqueue' pqueue.h => ../../include/openssl/pqueue.h make[2]: Leaving directory '/home/Test_User/openssl-1.0.2f/crypto/pqueue' making links in crypto/ts... make[2]: Entering directory '/home/Test_User/openssl-1.0.2f/crypto/ts' ts.h => ../../include/openssl/ts.h make[2]: Leaving directory '/home/Test_User/openssl-1.0.2f/crypto/ts' making links in crypto/srp... make[2]: Entering directory '/home/Test_User/openssl-1.0.2f/crypto/srp' srp.h => ../../include/openssl/srp.h srptest.c => ../../test/srptest.c make[2]: Leaving directory '/home/Test_User/openssl-1.0.2f/crypto/srp' making links in crypto/cmac... make[2]: Entering directory '/home/Test_User/openssl-1.0.2f/crypto/cmac' cmac.h => ../../include/openssl/cmac.h make[2]: Leaving directory '/home/Test_User/openssl-1.0.2f/crypto/cmac' make[1]: Leaving directory '/home/Test_User/openssl-1.0.2f/crypto' making links in ssl... make[1]: Entering directory '/home/Test_User/openssl-1.0.2f/ssl' ssl.h => ../include/openssl/ssl.h ssl2.h => ../include/openssl/ssl2.h ssl3.h => ../include/openssl/ssl3.h ssl23.h => ../include/openssl/ssl23.h tls1.h => ../include/openssl/tls1.h dtls1.h => ../include/openssl/dtls1.h kssl.h => ../include/openssl/kssl.h srtp.h => ../include/openssl/srtp.h ssltest.c => ../test/ssltest.c heartbeat_test.c => ../test/heartbeat_test.c clienthellotest.c => ../test/clienthellotest.c make[1]: Leaving directory '/home/Test_User/openssl-1.0.2f/ssl' making links in engines... make[1]: Entering directory '/home/Test_User/openssl-1.0.2f/engines' making links in engines/ccgost... make[2]: Entering directory '/home/Test_User/openssl-1.0.2f/engines/ccgost' make[2]: Nothing to be done for 'links'. make[2]: Leaving directory '/home/Test_User/openssl-1.0.2f/engines/ccgost' make[1]: Leaving directory '/home/Test_User/openssl-1.0.2f/engines' making links in apps... make[1]: Entering directory '/home/Test_User/openssl-1.0.2f/apps' make[1]: Nothing to be done for 'links'. make[1]: Leaving directory '/home/Test_User/openssl-1.0.2f/apps' making links in test... make[1]: Entering directory '/home/Test_User/openssl-1.0.2f/test' make[1]: Nothing to be done for 'links'. make[1]: Leaving directory '/home/Test_User/openssl-1.0.2f/test' making links in tools... make[1]: Entering directory '/home/Test_User/openssl-1.0.2f/tools' make[1]: Nothing to be done for 'links'. make[1]: Leaving directory '/home/Test_User/openssl-1.0.2f/tools' generating dummy tests (if needed)... make[1]: Entering directory '/home/Test_User/openssl-1.0.2f/test' make[1]: Nothing to be done for 'generate'. make[1]: Leaving directory '/home/Test_User/openssl-1.0.2f/test' Configured for Cygwin. *** Because of configuration changes, you MUST do the following before *** building: make depend -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4326 Please log in as guest with password guest if prompted From rt at openssl.org Sun Feb 21 03:12:01 2016 From: rt at openssl.org (TJ Saunders via RT) Date: Sun, 21 Feb 2016 03:12:01 +0000 Subject: [openssl-dev] [openssl.org #4327] SSL_CTX_use_serverinfo_file() causes issues for SSL_CTX with multiple certs In-Reply-To: <1456021434.3968602.527141410.3B7F15DE@webmail.messagingengine.com> References: <1456021434.3968602.527141410.3B7F15DE@webmail.messagingengine.com> Message-ID: When the SSL_CTX_use_serverinfo_file() function is used to configure custom TLS extension data (e.g. for SCT data), AND the SSL_CTX in question is configured for multiple server certificates, the SSL/TLS handshake can fail unexpectedly, and will not return the configured TLS extension data properly. See: https://github.com/openssl/openssl/issues/719 Cheers, TJ -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4327 Please log in as guest with password guest if prompted From rt at openssl.org Sun Feb 21 04:33:17 2016 From: rt at openssl.org (noloader@gmail.com via RT) Date: Sun, 21 Feb 2016 04:33:17 +0000 Subject: [openssl-dev] [openssl.org #4326] AutoReply: Failed to configure for Cygwin-x64 In-Reply-To: References: Message-ID: Also see Issue 3110 (http://rt.openssl.org/Ticket/Display.html?id=3110) and "Adding support for x86_64 Cygwin" (http://openssl.6102.n7.nabble.com/openssl-org-3110-Adding-support-for-x86-64-Cygwin-td46131.html). The 3110 issue was closed in May 2015, but it looks like something is a bit amiss. > After configuring on Windows 8.1/Core i5 4th gen machine, make'ing > depend produces the following errors: > > $ make depend > making depend in crypto... > make[1]: Entering directory '/home/Test_User/openssl-1.0.2f/crypto' > cc1: error: CPU you selected does not support x86-64 instruction set > cc1: error: CPU you selected does not support x86-64 instruction set > cc1: error: CPU you selected does not support x86-64 instruction set > cc1: error: CPU you selected does not support x86-64 instruction set > cc1: error: CPU you selected does not support x86-64 instruction set > cc1: error: CPU you selected does not support x86-64 instruction set > cc1: error: CPU you selected does not support x86-64 instruction set > cc1: error: CPU you selected does not support x86-64 instruction set > cc1: error: CPU you selected does not support x86-64 instruction set > cc1: error: CPU you selected does not support x86-64 instruction set > cc1: error: CPU you selected does not support x86-64 instruction set > cc1: error: CPU you selected does not support x86-64 instruction set > cc1: error: CPU you selected does not support x86-64 instruction set > cc1: error: CPU you selected does not support x86-64 instruction set > cc1: error: CPU you selected does not support x86-64 instruction set > cc1: error: CPU you selected does not support x86-64 instruction set > cc1: error: CPU you selected does not support x86-64 instruction set > cc1: error: CPU you selected does not support x86-64 instruction set > cc1: error: CPU you selected does not support x86-64 instruction set > cc1: error: CPU you selected does not support x86-64 instruction set > cc1: error: CPU you selected does not support x86-64 instruction set > cc1: error: CPU you selected does not support x86-64 instruction set > cc1: error: CPU you selected does not support x86-64 instruction set > cc1: error: CPU you selected does not support x86-64 instruction set > cc1: error: CPU you selected does not support x86-64 instruction set > cc1: error: CPU you selected does not support x86-64 instruction set > cc1: error: CPU you selected does not support x86-64 instruction set > cc1: error: CPU you selected does not support x86-64 instruction set > cc1: error: CPU you selected does not support x86-64 instruction set > cc1: error: CPU you selected does not support x86-64 instruction set > Makefile:136: recipe for target 'local_depend' failed > make[1]: *** [local_depend] Error 1 > make[1]: Leaving directory '/home/Test_User/openssl-1.0.2f/crypto' > Makefile:471: recipe for target 'depend' failed > make: *** [depend] Error 1 > > ====================== > > $ ./config shared no-ssl2 no-ssl3 --openssldir="$HOME/ssl" > Operating system: x86_64-whatever-cygwin > Configuring for Cygwin > Configuring for Cygwin > no-ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128 (skip dir) > no-gmp [default] OPENSSL_NO_GMP (skip dir) > no-jpake [experimental] OPENSSL_NO_JPAKE (skip dir) > no-krb5 [krb5-flavor not specified] OPENSSL_NO_KRB5 > no-libunbound [experimental] OPENSSL_NO_LIBUNBOUND (skip dir) > no-md2 [default] OPENSSL_NO_MD2 (skip dir) > no-rc5 [default] OPENSSL_NO_RC5 (skip dir) > no-rfc3779 [default] OPENSSL_NO_RFC3779 (skip dir) > no-sctp [default] OPENSSL_NO_SCTP (skip dir) > no-ssl-trace [default] OPENSSL_NO_SSL_TRACE (skip dir) > no-ssl2 [option] OPENSSL_NO_SSL2 (skip dir) > no-ssl3 [option] OPENSSL_NO_SSL3 (skip dir) > no-store [experimental] OPENSSL_NO_STORE (skip dir) > no-unit-test [default] OPENSSL_NO_UNIT_TEST (skip dir) > no-zlib [default] > no-zlib-dynamic [default] > IsMK1MF=0 > CC =gcc > CFLAG =-D_WINDLL -DOPENSSL_PIC -DOPENSSL_THREADS -DDSO_DLFCN > -DHAVE_DLFCN_H -DTERMIOS -DL_ENDIAN -fomit-frame-pointer -O3 > -march=i486 -Wall -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 > -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM > -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM > -DWHIRLPOOL_ASM -DGHASH_ASM > EX_LIBS = > CPUID_OBJ =x86cpuid.o > BN_ASM =bn-586.o co-586.o x86-mont.o x86-gf2m.o > EC_ASM = > DES_ENC =des-586.o crypt586.o > AES_ENC =aes-586.o vpaes-x86.o aesni-x86.o > BF_ENC =bf-586.o > CAST_ENC =c_enc.o > RC4_ENC =rc4-586.o > RC5_ENC =rc5-586.o > MD5_OBJ_ASM =md5-586.o > SHA1_OBJ_ASM =sha1-586.o sha256-586.o sha512-586.o > RMD160_OBJ_ASM=rmd-586.o > CMLL_ENC =cmll-x86.o > MODES_OBJ =ghash-x86.o > ENGINES_OBJ = > PROCESSOR = > RANLIB =/usr/bin/ranlib.exe > ARFLAGS = > PERL =/usr/bin/perl.exe > THIRTY_TWO_BIT mode > DES_PTR used > DES_RISC1 used > DES_UNROLL used > BN_LLONG mode > RC4_INDEX mode > RC4_CHUNK is undefined > e_os2.h => include/openssl/e_os2.h > making links in crypto... > make[1]: Entering directory '/home/Test_User/openssl-1.0.2f/crypto' > ... -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4326 Please log in as guest with password guest if prompted From rt at openssl.org Sun Feb 21 05:25:30 2016 From: rt at openssl.org (noloader@gmail.com via RT) Date: Sun, 21 Feb 2016 05:25:30 +0000 Subject: [openssl-dev] [openssl.org #4328] Cygwin, self test and "./bctest: line 35: bc: command not found" In-Reply-To: References: Message-ID: Working on Windows under Cygwin-64: $ make test ... running bc ./bctest: line 35: bc: command not found bc does not work properly ('SunOStest' failed). Looking for another bc ... No working bc found. Consider installing GNU bc. 0 tests passed I'm reporting it because of the reference to "'SunOStest". It appears there's some logic involved that identifies the platform. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4328 Please log in as guest with password guest if prompted From rt at openssl.org Sun Feb 21 06:27:18 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Sun, 21 Feb 2016 06:27:18 +0000 Subject: [openssl-dev] [openssl.org #4326] Failed to configure for Cygwin-x64 In-Reply-To: References: Message-ID: I believe that the auto-detecting script, ./config, is lacking detection of architecture for Cygwin. Does one preferably recognise a x86_64 Cygwin from `uname -m` or is there something in `uname -s` that should be used as an indicator? Cheers, Richard Vid Sun, 21 Feb 2016 kl. 04.33.17, skrev noloader at gmail.com: > Also see Issue 3110 > (http://rt.openssl.org/Ticket/Display.html?id=3110) and "Adding > support for x86_64 Cygwin" > (http://openssl.6102.n7.nabble.com/openssl-org-3110-Adding-support- > for-x86-64-Cygwin-td46131.html). > > The 3110 issue was closed in May 2015, but it looks like something is > a bit amiss. > > > After configuring on Windows 8.1/Core i5 4th gen machine, make'ing > > depend produces the following errors: > > > > $ make depend > > making depend in crypto... > > make[1]: Entering directory '/home/Test_User/openssl-1.0.2f/crypto' > > cc1: error: CPU you selected does not support x86-64 instruction set > > cc1: error: CPU you selected does not support x86-64 instruction set > > cc1: error: CPU you selected does not support x86-64 instruction set > > cc1: error: CPU you selected does not support x86-64 instruction set > > cc1: error: CPU you selected does not support x86-64 instruction set > > cc1: error: CPU you selected does not support x86-64 instruction set > > cc1: error: CPU you selected does not support x86-64 instruction set > > cc1: error: CPU you selected does not support x86-64 instruction set > > cc1: error: CPU you selected does not support x86-64 instruction set > > cc1: error: CPU you selected does not support x86-64 instruction set > > cc1: error: CPU you selected does not support x86-64 instruction set > > cc1: error: CPU you selected does not support x86-64 instruction set > > cc1: error: CPU you selected does not support x86-64 instruction set > > cc1: error: CPU you selected does not support x86-64 instruction set > > cc1: error: CPU you selected does not support x86-64 instruction set > > cc1: error: CPU you selected does not support x86-64 instruction set > > cc1: error: CPU you selected does not support x86-64 instruction set > > cc1: error: CPU you selected does not support x86-64 instruction set > > cc1: error: CPU you selected does not support x86-64 instruction set > > cc1: error: CPU you selected does not support x86-64 instruction set > > cc1: error: CPU you selected does not support x86-64 instruction set > > cc1: error: CPU you selected does not support x86-64 instruction set > > cc1: error: CPU you selected does not support x86-64 instruction set > > cc1: error: CPU you selected does not support x86-64 instruction set > > cc1: error: CPU you selected does not support x86-64 instruction set > > cc1: error: CPU you selected does not support x86-64 instruction set > > cc1: error: CPU you selected does not support x86-64 instruction set > > cc1: error: CPU you selected does not support x86-64 instruction set > > cc1: error: CPU you selected does not support x86-64 instruction set > > cc1: error: CPU you selected does not support x86-64 instruction set > > Makefile:136: recipe for target 'local_depend' failed > > make[1]: *** [local_depend] Error 1 > > make[1]: Leaving directory '/home/Test_User/openssl-1.0.2f/crypto' > > Makefile:471: recipe for target 'depend' failed > > make: *** [depend] Error 1 > > > > ====================== > > > > $ ./config shared no-ssl2 no-ssl3 --openssldir="$HOME/ssl" > > Operating system: x86_64-whatever-cygwin > > Configuring for Cygwin > > Configuring for Cygwin > > no-ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128 > > (skip dir) > > no-gmp [default] OPENSSL_NO_GMP (skip dir) > > no-jpake [experimental] OPENSSL_NO_JPAKE (skip dir) > > no-krb5 [krb5-flavor not specified] OPENSSL_NO_KRB5 > > no-libunbound [experimental] OPENSSL_NO_LIBUNBOUND (skip dir) > > no-md2 [default] OPENSSL_NO_MD2 (skip dir) > > no-rc5 [default] OPENSSL_NO_RC5 (skip dir) > > no-rfc3779 [default] OPENSSL_NO_RFC3779 (skip dir) > > no-sctp [default] OPENSSL_NO_SCTP (skip dir) > > no-ssl-trace [default] OPENSSL_NO_SSL_TRACE (skip dir) > > no-ssl2 [option] OPENSSL_NO_SSL2 (skip dir) > > no-ssl3 [option] OPENSSL_NO_SSL3 (skip dir) > > no-store [experimental] OPENSSL_NO_STORE (skip dir) > > no-unit-test [default] OPENSSL_NO_UNIT_TEST (skip dir) > > no-zlib [default] > > no-zlib-dynamic [default] > > IsMK1MF=0 > > CC =gcc > > CFLAG =-D_WINDLL -DOPENSSL_PIC -DOPENSSL_THREADS -DDSO_DLFCN > > -DHAVE_DLFCN_H -DTERMIOS -DL_ENDIAN -fomit-frame-pointer -O3 > > -march=i486 -Wall -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 > > -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM > > -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM > > -DWHIRLPOOL_ASM -DGHASH_ASM > > EX_LIBS = > > CPUID_OBJ =x86cpuid.o > > BN_ASM =bn-586.o co-586.o x86-mont.o x86-gf2m.o > > EC_ASM = > > DES_ENC =des-586.o crypt586.o > > AES_ENC =aes-586.o vpaes-x86.o aesni-x86.o > > BF_ENC =bf-586.o > > CAST_ENC =c_enc.o > > RC4_ENC =rc4-586.o > > RC5_ENC =rc5-586.o > > MD5_OBJ_ASM =md5-586.o > > SHA1_OBJ_ASM =sha1-586.o sha256-586.o sha512-586.o > > RMD160_OBJ_ASM=rmd-586.o > > CMLL_ENC =cmll-x86.o > > MODES_OBJ =ghash-x86.o > > ENGINES_OBJ = > > PROCESSOR = > > RANLIB =/usr/bin/ranlib.exe > > ARFLAGS = > > PERL =/usr/bin/perl.exe > > THIRTY_TWO_BIT mode > > DES_PTR used > > DES_RISC1 used > > DES_UNROLL used > > BN_LLONG mode > > RC4_INDEX mode > > RC4_CHUNK is undefined > > e_os2.h => include/openssl/e_os2.h > > making links in crypto... > > make[1]: Entering directory '/home/Test_User/openssl-1.0.2f/crypto' > > ... -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4326 Please log in as guest with password guest if prompted From rt at openssl.org Sun Feb 21 06:33:54 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Sun, 21 Feb 2016 06:33:54 +0000 Subject: [openssl-dev] [openssl.org #4328] Cygwin, self test and "./bctest: line 35: bc: command not found" In-Reply-To: References: Message-ID: Truth is, the logic is a bit flawed, and it's not about those platform specific tests (which it shouldn't try on that first run). The correct conclusion right now is that you need to install 'bc' to be able to run the BIGNUM test Vid Sun, 21 Feb 2016 kl. 05.25.30, skrev noloader at gmail.com: > Working on Windows under Cygwin-64: > > $ make test > ... running bc > ./bctest: line 35: bc: command not found > bc does not work properly ('SunOStest' failed). Looking for another bc ... > No working bc found. Consider installing GNU bc. > 0 tests passed > > I'm reporting it because of the reference to "'SunOStest". It appears > there's some logic involved that identifies the platform. > -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4328 Please log in as guest with password guest if prompted From rt at openssl.org Sun Feb 21 06:50:35 2016 From: rt at openssl.org (noloader@gmail.com via RT) Date: Sun, 21 Feb 2016 06:50:35 +0000 Subject: [openssl-dev] [openssl.org #4326] Failed to configure for Cygwin-x64 In-Reply-To: References: Message-ID: On Sun, Feb 21, 2016 at 1:27 AM, Richard Levitte via RT wrote: > I believe that the auto-detecting script, ./config, is lacking detection of > architecture for Cygwin. Does one preferably recognise a x86_64 Cygwin from > `uname -m` or is there something in `uname -s` that should be used as an > indicator? Yes, that seems to be the issue at hand for OpenSSL 1.0.2. Using the following works: $ export KERNEL_BITS=64 $ ./Configure Cygwin-x86_64 ... KERNEL_BITS=64 may not be needed. Its old habit for OS X, where config wants to select 32-bit builds for modern 64-bit machines. Uname (for x86_64 installation): $ uname -m x86_64 $ uname -a CYGWIN_NT-6.3 asus-windows8 2.4.1(0.293/5/3) 2016-01-24 11:26 x86_64 Cygwin $ uname -s CYGWIN_NT-6.3 You can also go to the preprocessor, if interested (for x86_64 installation): $ cpp -dM - References: Message-ID: > I believe that the auto-detecting script, ./config, is lacking detection of > architecture for Cygwin. Does one preferably recognise a x86_64 Cygwin from > `uname -m` or is there something in `uname -s` that should be used as an > indicator? Yes, that seems to be the issue at hand for OpenSSL 1.0.2. Using the following works: $ export KERNEL_BITS=64 $ ./Configure Cygwin-x86_64 ... KERNEL_BITS=64 may not be needed. Its old habit for OS X, where config wants to select 32-bit builds for modern 64-bit machines. Uname (for x86_64 installation): $ uname -m x86_64 $ uname -a CYGWIN_NT-6.3 asus-windows8 2.4.1(0.293/5/3) 2016-01-24 11:26 x86_64 Cygwin $ uname -s CYGWIN_NT-6.3 You can also go to the preprocessor, if interested (for x86_64 installation): $ cpp -dM - References: Message-ID: > I believe that the auto-detecting script, ./config, is lacking detection of > architecture for Cygwin. Does one preferably recognise a x86_64 Cygwin from > `uname -m` or is there something in `uname -s` that should be used as an > indicator? Yes, that seems to be the issue at hand for OpenSSL 1.0.2. Using the following works: $ export KERNEL_BITS=64 $ ./Configure Cygwin-x86_64 ... KERNEL_BITS=64 may not be needed. Its old habit for OS X, where config wants to select 32-bit builds for modern 64-bit machines. Uname (for x86_64 installation): $ uname -m x86_64 $ uname -a CYGWIN_NT-6.3 asus-windows8 2.4.1(0.293/5/3) 2016-01-24 11:26 x86_64 Cygwin $ uname -s CYGWIN_NT-6.3 You can also go to the preprocessor, if interested (for x86_64 installation): $ cpp -dM - References: Message-ID: Would you try the attached patch, please? -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4326 Please log in as guest with password guest if prompted -------------- next part -------------- A non-text attachment was scrubbed... Name: config.diff Type: text/x-patch Size: 402 bytes Desc: not available URL: From noloader at gmail.com Sun Feb 21 08:21:58 2016 From: noloader at gmail.com (Jeffrey Walton) Date: Sun, 21 Feb 2016 03:21:58 -0500 Subject: [openssl-dev] [openssl.org #4326] Failed to configure for Cygwin-x64 In-Reply-To: References: Message-ID: On Sun, Feb 21, 2016 at 2:50 AM, Richard Levitte via RT wrote: > Would you try the attached patch, please? > Looks good for both 1.0.2 and Master. Its also nice to see CHACHA_ENC and POLY1305_OBJ in the list below. ===== openssl-git $ ./config Operating system: x86_64-pc-cygwin Configuring for Cygwin-x86_64 Configuring OpenSSL version 1.1.0-pre4-dev (0x0x10100004L) no-crypto-mdebug [default] OPENSSL_NO_CRYPTO_MDEBUG (skip dir) no-crypto-mdebug-backtrace [forced] OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE (skip dir) no-ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128 (skip dir) no-egd [default] OPENSSL_NO_EGD (skip dir) no-heartbeats [default] OPENSSL_NO_HEARTBEATS (skip dir) no-md2 [default] OPENSSL_NO_MD2 (skip dir) no-rc5 [default] OPENSSL_NO_RC5 (skip dir) no-sctp [default] OPENSSL_NO_SCTP (skip dir) no-shared [default] no-ssl-trace [default] OPENSSL_NO_SSL_TRACE (skip dir) no-static-engine [default] no-unit-test [default] OPENSSL_NO_UNIT_TEST (skip dir) no-zlib [default] no-zlib-dynamic [forced] Configuring for Cygwin-x86_64 IsMK1MF =no CC =gcc CFLAG = -DTERMIOS -DL_ENDIAN -Wall -O3 DEFINES =DSO_DLFCN HAVE_DLFCN_H OPENSSL_THREADS OPENSSL_NO_STATIC_ENGINE OPENSSL_IA32_SSE2 OPENSSL_BN_ASM_MONT OPENSSL_BN_ASM_MONT5 OPENSSL_BN_ASM_GF2m SHA1_ASM SHA256_ASM SHA512_ASM MD5_ASM AES_ASM VPAES_ASM BSAES_ASM GHASH_ASM ECP_NISTZ256_ASM POLY1305_ASM LFLAG = PLIB_LFLAG = EX_LIBS = CPUID_OBJ =x86_64cpuid.o BN_ASM =asm/x86_64-gcc.o x86_64-mont.o x86_64-mont5.o x86_64-gf2m.o rsaz_exp.o rsaz-x86_64.o rsaz-avx2.o EC_ASM =ecp_nistz256.o ecp_nistz256-x86_64.o DES_ENC =des_enc.o fcrypt_b.o AES_ENC =aes-x86_64.o vpaes-x86_64.o bsaes-x86_64.o aesni-x86_64.o aesni-sha1-x86_64.o aesni-sha256-x86_64.o aesni-mb-x86_64.o BF_ENC =bf_enc.o CAST_ENC =c_enc.o RC4_ENC =rc4-x86_64.o rc4-md5-x86_64.o RC5_ENC =rc5_enc.o MD5_OBJ_ASM =md5-x86_64.o SHA1_OBJ_ASM =sha1-x86_64.o sha256-x86_64.o sha512-x86_64.o sha1-mb-x86_64.o sha256-mb-x86_64.o RMD160_OBJ_ASM= CMLL_ENC =cmll-x86_64.o cmll_misc.o MODES_OBJ =ghash-x86_64.o aesni-gcm-x86_64.o PADLOCK_OBJ =e_padlock-x86_64.o CHACHA_ENC =chacha-x86_64.o POLY1305_OBJ =poly1305-x86_64.o PROCESSOR = RANLIB =/usr/bin/ranlib.exe ARFLAGS = PERL =/usr/bin/perl.exe SIXTY_FOUR_BIT_LONG mode Configured for Cygwin-x86_64. From rt at openssl.org Sun Feb 21 08:22:02 2016 From: rt at openssl.org (noloader@gmail.com via RT) Date: Sun, 21 Feb 2016 08:22:02 +0000 Subject: [openssl-dev] [openssl.org #4326] Failed to configure for Cygwin-x64 In-Reply-To: References: Message-ID: On Sun, Feb 21, 2016 at 2:50 AM, Richard Levitte via RT wrote: > Would you try the attached patch, please? > Looks good for both 1.0.2 and Master. Its also nice to see CHACHA_ENC and POLY1305_OBJ in the list below. ===== openssl-git $ ./config Operating system: x86_64-pc-cygwin Configuring for Cygwin-x86_64 Configuring OpenSSL version 1.1.0-pre4-dev (0x0x10100004L) no-crypto-mdebug [default] OPENSSL_NO_CRYPTO_MDEBUG (skip dir) no-crypto-mdebug-backtrace [forced] OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE (skip dir) no-ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128 (skip dir) no-egd [default] OPENSSL_NO_EGD (skip dir) no-heartbeats [default] OPENSSL_NO_HEARTBEATS (skip dir) no-md2 [default] OPENSSL_NO_MD2 (skip dir) no-rc5 [default] OPENSSL_NO_RC5 (skip dir) no-sctp [default] OPENSSL_NO_SCTP (skip dir) no-shared [default] no-ssl-trace [default] OPENSSL_NO_SSL_TRACE (skip dir) no-static-engine [default] no-unit-test [default] OPENSSL_NO_UNIT_TEST (skip dir) no-zlib [default] no-zlib-dynamic [forced] Configuring for Cygwin-x86_64 IsMK1MF =no CC =gcc CFLAG = -DTERMIOS -DL_ENDIAN -Wall -O3 DEFINES =DSO_DLFCN HAVE_DLFCN_H OPENSSL_THREADS OPENSSL_NO_STATIC_ENGINE OPENSSL_IA32_SSE2 OPENSSL_BN_ASM_MONT OPENSSL_BN_ASM_MONT5 OPENSSL_BN_ASM_GF2m SHA1_ASM SHA256_ASM SHA512_ASM MD5_ASM AES_ASM VPAES_ASM BSAES_ASM GHASH_ASM ECP_NISTZ256_ASM POLY1305_ASM LFLAG = PLIB_LFLAG = EX_LIBS = CPUID_OBJ =x86_64cpuid.o BN_ASM =asm/x86_64-gcc.o x86_64-mont.o x86_64-mont5.o x86_64-gf2m.o rsaz_exp.o rsaz-x86_64.o rsaz-avx2.o EC_ASM =ecp_nistz256.o ecp_nistz256-x86_64.o DES_ENC =des_enc.o fcrypt_b.o AES_ENC =aes-x86_64.o vpaes-x86_64.o bsaes-x86_64.o aesni-x86_64.o aesni-sha1-x86_64.o aesni-sha256-x86_64.o aesni-mb-x86_64.o BF_ENC =bf_enc.o CAST_ENC =c_enc.o RC4_ENC =rc4-x86_64.o rc4-md5-x86_64.o RC5_ENC =rc5_enc.o MD5_OBJ_ASM =md5-x86_64.o SHA1_OBJ_ASM =sha1-x86_64.o sha256-x86_64.o sha512-x86_64.o sha1-mb-x86_64.o sha256-mb-x86_64.o RMD160_OBJ_ASM= CMLL_ENC =cmll-x86_64.o cmll_misc.o MODES_OBJ =ghash-x86_64.o aesni-gcm-x86_64.o PADLOCK_OBJ =e_padlock-x86_64.o CHACHA_ENC =chacha-x86_64.o POLY1305_OBJ =poly1305-x86_64.o PROCESSOR = RANLIB =/usr/bin/ranlib.exe ARFLAGS = PERL =/usr/bin/perl.exe SIXTY_FOUR_BIT_LONG mode Configured for Cygwin-x86_64. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4326 Please log in as guest with password guest if prompted From rt at openssl.org Sun Feb 21 13:55:35 2016 From: rt at openssl.org (Rainer Jung via RT) Date: Sun, 21 Feb 2016 13:55:35 +0000 Subject: [openssl-dev] [openssl.org #4329] OpenSSL 1.1.0 pre3: internal error in tls_post_process_client_key_exchange during reneg In-Reply-To: <56C9C1CC.50406@kippdata.de> References: <56C9C1CC.50406@kippdata.de> Message-ID: Running the Apache test suite for Apache 2.4 with OpenSSL 1.1.0 adjustments, I get error:14180044:SSL routines:tls_post_process_client_key_exchange:internal error The error is triggered in tls_post_process_client_key_exchange() file ssl/statem/statem_srvr.c which checks s->s3->handshake_buffer against NULL: 2631 if (!s->s3->handshake_buffer) { 2632 SSLerr(SSL_F_TLS_POST_PROCESS_CLIENT_KEY_EXCHANGE, 2633 ERR_R_INTERNAL_ERROR); 2634 ossl_statem_set_error(s); 2635 return WORK_ERROR; 2636 } Running the test, the handshake_buffer gets set in ssl3_init_finished_mac(), then cleared in tls_post_process_client_hello() which calls ssl3_digest_cached_records() with "keep" equals 0. This resets the handshake_buffer to NULL. Then later tls1_generate_master_secret() again calls ssl3_digest_cached_records() with keep set to 1 (but the handshake_buffer is already NULL and stays like that) and finally tls_post_process_client_key_exchange() throws the error because the handshake_buffer is NULL. The message sequence was: server Loop: SSLv3/TLS write hello request client Loop: SSLv3/TLS write client hello server Loop: SSLv3/TLS read client hello server Loop: SSLv3/TLS write server hello server Loop: SSLv3/TLS write certificate server Loop: SSLv3/TLS write key exchange server Loop: SSLv3/TLS write server done client Loop: SSLv3/TLS write client hello client Loop: SSLv3/TLS read server hello client Loop: SSLv3/TLS read server certificate client Loop: SSLv3/TLS read server key exchange client Loop: SSLv3/TLS read server done client Loop: SSLv3/TLS write client certificate client Loop: SSLv3/TLS write client key exchange client Loop: SSLv3/TLS write certificate verify client Loop: SSLv3/TLS write change cipher spec client Loop: SSLv3/TLS write finished server Loop: SSLv3/TLS write server done server Loop: SSLv3/TLS read client certificate server error:14180044:SSL routines:tls_post_process_client_key_exchange:internal error Regards, Rainer -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4329 Please log in as guest with password guest if prompted From rt at openssl.org Sun Feb 21 17:06:58 2016 From: rt at openssl.org (noloader@gmail.com via RT) Date: Sun, 21 Feb 2016 17:06:58 +0000 Subject: [openssl-dev] [openssl.org #4330] Unsupported options: no-ssl2 In-Reply-To: References: Message-ID: I think its great that SSLv2 is disabled by default or removed. However, this might cause some UI pain: $ ./config shared no-ssl2 no-ssl3 Operating system: x86_64-whatever-linux2 Configuring for linux-x86_64 Configuring OpenSSL version 1.1.0-pre4-dev (0x0x10100004L) ***** Unsupported options: no-ssl2 For years we have been pounding into people's heads: "configure with no-ssl2 no-ssl3". SSLv2 and SSLv3 are insecure. See, for example, http://www.owasp.org/index.php/C-Based_Toolchain_Hardening#Integration. Changing the behavior now such that 'no-ssl2' is an error creates additional rules that users should not have to worry about. User might accidentally omit 'no-ssl2' on OpenSSL 1.0.1 and below due to the new conditioning. I think it would be good for users to (1) disable or omit SSLv2 (as the library is doing), and (2) honor or ignore 'no-ssl2' (both achieve the same goal). -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4330 Please log in as guest with password guest if prompted From rt at openssl.org Sun Feb 21 20:27:50 2016 From: rt at openssl.org (Andy Polyakov via RT) Date: Sun, 21 Feb 2016 20:27:50 +0000 Subject: [openssl-dev] [openssl.org #4323] chacha-armv4.pl bugs In-Reply-To: <56CA1DC3.1070501@openssl.org> References: <56CA1DC3.1070501@openssl.org> Message-ID: Hi, > The partial-block tail code in chacha-armv4.pl also seems to have problems. > My colleague Steven and I made an attempt to debug it, but we're not > familiar enough with ARM to fix it. > > From playing with it in a debugger, it doesn't look like @t[3] contains the > length. We suspect something is going wrong with the condition flags on > loading or updating length. > https://git.openssl.org/gitweb/?p=openssl.git;a=blob;f=crypto/chacha/asm/chacha-armv4.pl;h=55ebc9e586475a35e313b74483eb4b8d5b6f2b03;hb=HEAD#l585 Attached is patch for chacha-armv4.pl (please verify) and a test snippet I've put together. > It may be worth going back and testing these cases on all of the > implementations as well. Besides armv4 only s390x module was failing. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4323 Please log in as guest with password guest if prompted -------------- next part -------------- diff --git a/crypto/chacha/asm/chacha-armv4.pl b/crypto/chacha/asm/chacha-armv4.pl index 55ebc9e..6c20755 100755 --- a/crypto/chacha/asm/chacha-armv4.pl +++ b/crypto/chacha/asm/chacha-armv4.pl @@ -440,9 +440,9 @@ $code.=<<___; eorhs @x[4], at x[4], at t[0] eorhs @x[5], at x[5], at t[1] # ifdef __thumb2__ - it hi + it ne # endif - ldrhi @t[0],[sp,#4*(32+2)] @ re-load len + ldrne @t[0],[sp,#4*(32+2)] @ re-load len # ifdef __thumb2__ itt hs # endif @@ -584,9 +584,9 @@ ___ } $code.=<<___; # ifdef __thumb2__ - it hi + it ne # endif - ldrhi @t[0],[sp,#4*(32+2)] @ re-load len + ldrne @t[0],[sp,#4*(32+2)] @ re-load len # ifdef __thumb2__ it hs # endif @@ -598,15 +598,15 @@ $code.=<<___; .Ltail: ldr r12,[sp,#4*(32+1)] @ load inp - add @t[2],sp,#4*(0) + add @t[1],sp,#4*(0) ldr r14,[sp,#4*(32+0)] @ load out .Loop_tail: - ldrb @t[0],[@t[2]],#1 @ read buffer on stack - ldrb @t[1],[r12],#1 @ read input - subs @t[3], at t[3],#1 - eor @t[0], at t[0], at t[1] - strb @t[0],[r14],#1 @ store output + ldrb @t[2],[@t[1]],#1 @ read buffer on stack + ldrb @t[3],[r12],#1 @ read input + subs @t[0], at t[0],#1 + eor @t[3], at t[3], at t[2] + strb @t[3],[r14],#1 @ store output bne .Loop_tail .Ldone: @@ -1120,7 +1120,7 @@ $code.=<<___; # endif stmia @t[0],{@x[0]- at x[7]} add @t[2],sp,#4*(0) - sub @t[3], at t[0],#64*3 @ len-=64*3 + sub @t[3], at t[3],#64*3 @ len-=64*3 .Loop_tail_neon: ldrb @t[0],[@t[2]],#1 @ read buffer on stack -------------- next part -------------- A non-text attachment was scrubbed... Name: chacha_test.c Type: text/x-csrc Size: 4835 bytes Desc: not available URL: From rt at openssl.org Mon Feb 22 04:34:21 2016 From: rt at openssl.org (Rainer M. Canavan via RT) Date: Mon, 22 Feb 2016 04:34:21 +0000 Subject: [openssl-dev] [openssl.org #4332] openssl-1.1.0pre3 on IRIX: "Something wrong with" config --unified In-Reply-To: <201602211932.u1LJW5Mm024635@tezro.nonet> References: <201602211932.u1LJW5Mm024635@tezro.nonet> Message-ID: I'm trying to build openssl 1.1.0pre3 on IRIX 6.5 with the new unified building system using perl 5.8.9. This fails with the error message below. Building without --unified works as expected. Any hints how to debug this or extract better logs would be appreciated. $ perl ../openssl-1.1.0-pre3/config --unified Operating system: mips4-sgi-irix64 WARNING! If you wish to build 64-bit library, then you have to invoke '../openssl-1.1.0-pre3/Configure irix64-mips4-cc' *manually*. You have about 5 seconds to press Ctrl-C to abort. Configuring for irix-mips3-cc Configuring OpenSSL version 1.1.0-pre3 (0x0x10100003L) no-crypto-mdebug [default] OPENSSL_NO_CRYPTO_MDEBUG (skip dir) no-crypto-mdebug-backtrace [forced] OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE (skip dir) no-ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128 (skip dir) no-egd [default] OPENSSL_NO_EGD (skip dir) no-heartbeats [default] OPENSSL_NO_HEARTBEATS (skip dir) no-jpake [experimental] OPENSSL_NO_JPAKE (skip dir) no-md2 [default] OPENSSL_NO_MD2 (skip dir) no-rc5 [default] OPENSSL_NO_RC5 (skip dir) no-sctp [default] OPENSSL_NO_SCTP (skip dir) no-shared [default] no-ssl-trace [default] OPENSSL_NO_SSL_TRACE (skip dir) no-unit-test [default] OPENSSL_NO_UNIT_TEST (skip dir) no-zlib [default] no-zlib-dynamic [forced] Configuring for irix-mips3-cc Something wrong with this line: SOURCE[../libcrypto]= cryptlib.c mem.c mem_dbg.c cversion.c ex_data.c cpt_err.c ebcdic.c uid.c o_time.c o_str.c o_dir.c thr_id.c lock.c o_init.c o_fips.c mem_sec.c init.c mem_clr.c at /usr/people/canavan/src/openssl/openssl-1.1.0-pre3/crypto/build.info at ../openssl-1.1.0-pre3/Configure line 1368. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4332 Please log in as guest with password guest if prompted From rt at openssl.org Mon Feb 22 04:34:21 2016 From: rt at openssl.org (Rainer M. Canavan via RT) Date: Mon, 22 Feb 2016 04:34:21 +0000 Subject: [openssl-dev] [openssl.org #4331] openssl-1.1.0pre3 on IRIX: struct timeval is undefined In-Reply-To: <201602211919.u1LJJooK024142@tezro.nonet> References: <201602211919.u1LJJooK024142@tezro.nonet> Message-ID: Building openssl-1.1.0pre3 for irix-mips3-cc fails because struct timeval is undefined: cc-1070 cc: ERROR File = s_server.c, Line = 2092 The indicated type is incomplete. struct timeval timeout; With the patch below, openssl builds, and aside from a few possibly spurious errors in make test, appears to work. However, I assume that the added include statement may have to be protected by a suitable #ifdef. rainer diff -ur ../clean/openssl-1.1.0-pre3/apps/ocsp.c ./apps/ocsp.c --- ../clean/openssl-1.1.0-pre3/apps/ocsp.c 2016-02-15 19:08:07.000000000 +0100 +++ ./apps/ocsp.c 2016-02-21 20:04:23.832906441 +0100 @@ -68,6 +68,7 @@ # include # include # include +# include # include # include "apps.h" /* needs to be included before the openssl * headers! */ diff -ur ../clean/openssl-1.1.0-pre3/apps/s_client.c ./apps/s_client.c --- ../clean/openssl-1.1.0-pre3/apps/s_client.c 2016-02-15 19:08:07.000000000 +0100 +++ ./apps/s_client.c 2016-02-21 20:04:21.896880487 +0100 @@ -167,6 +167,7 @@ #endif #include "s_apps.h" #include "timeouts.h" +#include "sys/time.h" #if (defined(OPENSSL_SYS_VMS) && __VMS_VER < 70000000) /* FIONBIO used as a switch to enable ioctl, and that isn't in VMS < 7.0 */ diff -ur ../clean/openssl-1.1.0-pre3/apps/s_server.c ./apps/s_server.c --- ../clean/openssl-1.1.0-pre3/apps/s_server.c 2016-02-15 19:08:07.000000000 +0100 +++ ./apps/s_server.c 2016-02-21 20:04:19.767906666 +0100 @@ -184,6 +184,7 @@ #endif #include "s_apps.h" #include "timeouts.h" +#include "sys/time.h" #if (defined(OPENSSL_SYS_VMS) && __VMS_VER < 70000000) /* FIONBIO used as a switch to enable ioctl, and that isn't in VMS < 7.0 */ diff -ur ../clean/openssl-1.1.0-pre3/ssl/ssl_locl.h ./ssl/ssl_locl.h --- ../clean/openssl-1.1.0-pre3/ssl/ssl_locl.h 2016-02-15 19:08:07.000000000 +0100 +++ ./ssl/ssl_locl.h 2016-02-21 20:04:25.679106539 +0100 @@ -143,6 +143,7 @@ # define HEADER_SSL_LOCL_H # include # include +#include # include # include -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4331 Please log in as guest with password guest if prompted From rt at openssl.org Mon Feb 22 04:34:22 2016 From: rt at openssl.org (Rainer M. Canavan via RT) Date: Mon, 22 Feb 2016 04:34:22 +0000 Subject: [openssl-dev] [openssl.org #4333] openssl-1.1.0pre3 on IRIX: make test: Unrecognized escape \R passed through In-Reply-To: <201602212021.u1LKL2mh065389@tezro.nonet> References: <201602212021.u1LKL2mh065389@tezro.nonet> Message-ID: make test fails on IRIX 6.5 with perl 5.8.9 when building for irix-mips3-cc and irix64-mips4-cc (the only platforms I've tried so far). TOP=.. PERL=/usr/nekoware/bin/perl /usr/nekoware/bin/perl run_tests.pl alltests ../test/recipes/01-test_ordinals.t ........ ok ../test/recipes/05-test_bf.t .............. ok ../test/recipes/05-test_cast.t ............ ok ../test/recipes/05-test_des.t ............. ok ../test/recipes/05-test_hmac.t ............ ok ../test/recipes/05-test_idea.t ............ ok ../test/recipes/05-test_md2.t ............. skipped: md2 is not supported by this OpenSSL build ../test/recipes/05-test_md4.t ............. ok ../test/recipes/05-test_md5.t ............. ok ../test/recipes/05-test_mdc2.t ............ ok ../test/recipes/05-test_rand.t ............ ok ../test/recipes/05-test_rc2.t ............. ok ../test/recipes/05-test_rc4.t ............. ok ../test/recipes/05-test_rc5.t ............. skipped: rc5 is not supported by this OpenSSL build ../test/recipes/05-test_rmd.t ............. ok ../test/recipes/05-test_sha1.t ............ ok ../test/recipes/05-test_sha256.t .......... ok ../test/recipes/05-test_sha512.t .......... ok ../test/recipes/05-test_wp.t .............. ok ../test/recipes/10-test_bn.t .............. Unrecognized escape \R passed through at ../test/recipes/10-test_bn.t line 28. ../test/recipes/10-test_bn.t .............. ok ../test/recipes/10-test_exp.t ............. ok ../test/recipes/15-test_dh.t .............. ok ../test/recipes/15-test_dsa.t ............. Unrecognized escape \R passed through at ../test/recipes/tconversion.pl line 92. Unrecognized escape \R passed through at ../test/recipes/tconversion.pl line 93. ../test/recipes/15-test_dsa.t ............. ok ../test/recipes/15-test_ec.t .............. Unrecognized escape \R passed through at ../test/recipes/tconversion.pl line 92. Unrecognized escape \R passed through at ../test/recipes/tconversion.pl line 93. ../test/recipes/15-test_ec.t .............. ok ../test/recipes/15-test_ecdh.t ............ ok ../test/recipes/15-test_ecdsa.t ........... ok ../test/recipes/15-test_rsa.t ............. Unrecognized escape \R passed through at ../test/recipes/tconversion.pl line 92. Unrecognized escape \R passed through at ../test/recipes/tconversion.pl line 93. ../test/recipes/15-test_rsa.t ............. ok ../test/recipes/20-test_enc.t ............. ok ../test/recipes/25-test_crl.t ............. Unrecognized escape \R passed through at ../test/recipes/tconversion.pl line 92. Unrecognized escape \R passed through at ../test/recipes/tconversion.pl line 93. ../test/recipes/25-test_crl.t ............. ok ../test/recipes/25-test_gen.t ............. ok ../test/recipes/25-test_pkcs7.t ........... Unrecognized escape \R passed through at ../test/recipes/tconversion.pl line 92. Unrecognized escape \R passed through at ../test/recipes/tconversion.pl line 93. ../test/recipes/25-test_pkcs7.t ........... ok ../test/recipes/25-test_req.t ............. Unrecognized escape \R passed through at ../test/recipes/25-test_req.t line 34. ../test/recipes/25-test_req.t ............. 1/3 Unrecognized escape \R passed through at ../test/recipes/tconversion.pl line 92. Unrecognized escape \R passed through at ../test/recipes/tconversion.pl line 93. ../test/recipes/25-test_req.t ............. ok ../test/recipes/25-test_sid.t ............. Unrecognized escape \R passed through at ../test/recipes/tconversion.pl line 92. Unrecognized escape \R passed through at ../test/recipes/tconversion.pl line 93. ../test/recipes/25-test_sid.t ............. ok ../test/recipes/25-test_verify.t .......... ok ../test/recipes/25-test_x509.t ............ Unrecognized escape \R passed through at ../test/recipes/tconversion.pl line 92. Unrecognized escape \R passed through at ../test/recipes/tconversion.pl line 93. ../test/recipes/25-test_x509.t ............ ok ../test/recipes/30-test_engine.t .......... ok ../test/recipes/30-test_evp.t ............. ok ../test/recipes/30-test_evp_extra.t ....... ok ../test/recipes/30-test_pbelu.t ........... ok ../test/recipes/40-test_rehash.t .......... ok ../test/recipes/70-test_clienthello.t ..... ok ../test/recipes/70-test_packet.t .......... ok ../test/recipes/70-test_sslcertstatus.t ... skipped: test_sslcertstatus can only be performed with OpenSSL configured shared ../test/recipes/70-test_sslextension.t .... skipped: test_sslextension can only be performed with OpenSSL configured shared ../test/recipes/70-test_sslsessiontick.t .. skipped: test_sslsessiontick can only be performed with OpenSSL configured shared ../test/recipes/70-test_sslskewith0p.t .... skipped: test_sslskewith0p can only be performed with OpenSSL configured shared ../test/recipes/70-test_sslvertol.t ....... skipped: test_sslextension can only be performed with OpenSSL configured shared ../test/recipes/70-test_tlsextms.t ........ skipped: test_tlsextms can only be performed with OpenSSL configured shared ../test/recipes/70-test_verify_extra.t .... ok ../test/recipes/80-test_ca.t .............. ok ../test/recipes/80-test_cms.t ............. ok ../test/recipes/80-test_dane.t ............ ok ../test/recipes/80-test_dtlsv1listen.t .... ok ../test/recipes/80-test_ocsp.t ............ ok ../test/recipes/80-test_ssl.t ............. Unrecognized escape \R passed through at ../test/recipes/80-test_ssl.t line 483. ../test/recipes/80-test_ssl.t ............. 3/44 # Failed test 'Testing ECDHE-SA-AES256-GCM-SHA384' # at ../test/recipes/80-test_ssl.t line 497. # Failed test 'Testing ECDHE-SA-AES256-SHA384' # at ../test/recipes/80-test_ssl.t line 497. # Failed test 'Testing DHE-SA-AES256-CCM8' # at ../test/recipes/80-test_ssl.t line 497. # Failed test 'Testing DHE-SA-AES256-CCM' # at ../test/recipes/80-test_ssl.t line 497. # Failed test 'Testing DHE-SA-AES256-GCM-SHA384' # at ../test/recipes/80-test_ssl.t line 497. # Failed test 'Testing DHE-SA-AES256-SHA256' # at ../test/recipes/80-test_ssl.t line 497. # Failed test 'Testing ECDHE-SA-CHACHA20-POLY1305' # at ../test/recipes/80-test_ssl.t line 497. # Failed test 'Testing ECDHE-SA-CAMELLIA256-SHA384' # at ../test/recipes/80-test_ssl.t line 497. # Failed test 'Testing DHE-SA-CHACHA20-POLY1305' # at ../test/recipes/80-test_ssl.t line 497. # Failed test 'Testing DHE-SA-CAMELLIA256-SHA256' # at ../test/recipes/80-test_ssl.t line 497. # Failed test 'Testing ECDHE-SA-AES128-GCM-SHA256' # at ../test/recipes/80-test_ssl.t line 497. # Failed test 'Testing ECDHE-SA-AES128-SHA256' # at ../test/recipes/80-test_ssl.t line 497. # Failed test 'Testing DHE-SA-AES128-CCM8' # at ../test/recipes/80-test_ssl.t line 497. # Failed test 'Testing DHE-SA-AES128-CCM' # at ../test/recipes/80-test_ssl.t line 497. # Failed test 'Testing DHE-SA-AES128-GCM-SHA256' # at ../test/recipes/80-test_ssl.t line 497. # Failed test 'Testing DHE-SA-AES128-SHA256' # at ../test/recipes/80-test_ssl.t line 497. # Failed test 'Testing ECDHE-SA-CAMELLIA128-SHA256' # at ../test/recipes/80-test_ssl.t line 497. # Failed test 'Testing DHE-SA-CAMELLIA128-SHA256' # at ../test/recipes/80-test_ssl.t line 497. # Failed test 'Testing NULL-SHA256 # ' # at ../test/recipes/80-test_ssl.t line 497. # Failed test 'Testing ECDHE-SA-AES256-SHA' # at ../test/recipes/80-test_ssl.t line 497. # Failed test 'Testing DHE-SA-AES256-SHA' # at ../test/recipes/80-test_ssl.t line 497. # Failed test 'Testing DHE-SA-CAMELLIA256-SHA' # at ../test/recipes/80-test_ssl.t line 497. # Failed test 'Testing ECDHE-SA-AES128-SHA' # at ../test/recipes/80-test_ssl.t line 497. # Failed test 'Testing DHE-SA-AES128-SHA' # at ../test/recipes/80-test_ssl.t line 497. # Failed test 'Testing DHE-SA-SEED-SHA' # at ../test/recipes/80-test_ssl.t line 497. # Failed test 'Testing DHE-SA-CAMELLIA128-SHA' # at ../test/recipes/80-test_ssl.t line 497. # Failed test 'Testing ECDHE-SA-RC4-SHA' # at ../test/recipes/80-test_ssl.t line 497. # Failed test 'Testing ECDHE-ECDSA-C4-SHA' # at ../test/recipes/80-test_ssl.t line 497. # Failed test 'Testing AECDH-C4-SHA' # at ../test/recipes/80-test_ssl.t line 497. # Failed test 'Testing ADH-C4-MD5' # at ../test/recipes/80-test_ssl.t line 497. # Failed test 'Testing C4-SHA' # at ../test/recipes/80-test_ssl.t line 497. # Failed test 'Testing C4-MD5' # at ../test/recipes/80-test_ssl.t line 497. # Failed test 'Testing ECDHE-SA-DES-CBC3-SHA' # at ../test/recipes/80-test_ssl.t line 497. # Failed test 'Testing DHE-SA-DES-CBC3-SHA' # at ../test/recipes/80-test_ssl.t line 497. # Failed test 'Testing ECDHE-SA-NULL-SHA' # at ../test/recipes/80-test_ssl.t line 497. # Failed test 'Testing NULL-MD5 # ' # at ../test/recipes/80-test_ssl.t line 497. ../test/recipes/80-test_ssl.t ............. 4/44 # Looks like you failed 36 tests of 99. # Failed test 'Testing ciphersuites' # at ../test/recipes/80-test_ssl.t line 508. ../test/recipes/80-test_ssl.t ............. 32/44 # Looks like you failed 1 test of 44. ../test/recipes/80-test_ssl.t ............. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/44 subtests ../test/recipes/80-test_tsa.t ............. ok ../test/recipes/90-test_async.t ........... ok ../test/recipes/90-test_constant_time.t ... ok ../test/recipes/90-test_gmdiff.t .......... ok ../test/recipes/90-test_heartbeat.t ....... skipped: heartbeats is not supported by this OpenSSL build ../test/recipes/90-test_ige.t ............. ok ../test/recipes/90-test_jpake.t ........... skipped: jpake is not supported by this OpenSSL build ../test/recipes/90-test_memleak.t ......... ok ../test/recipes/90-test_networking.t ...... skipped: test_networking can only be performed with OpenSSL configured shared ../test/recipes/90-test_np.t .............. ok ../test/recipes/90-test_p5_crpt2.t ........ ok ../test/recipes/90-test_secmem.t .......... ok ../test/recipes/90-test_srp.t ............. ok ../test/recipes/90-test_v3name.t .......... ok Test Summary Report ------------------- ../test/recipes/80-test_ssl.t (Wstat: 256 Tests: 44 Failed: 1) Failed test: 4 Non-zero exit status: 1 Files=69, Tests=361, 256 wallclock secs ( 1.98 usr 0.39 sys + 217.26 cusr 33.35 csys = 252.98 CPU) Result: FAIL Failed 1/69 test programs. 1/361 subtests failed. gmake[1]: *** [tests] Error 255 gmake[1]: Leaving directory `/usr/people/canavan/src/openssl/openssl-1.1.0-pre3/test' gmake: *** [tests] Error 2 -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4333 Please log in as guest with password guest if prompted From rt at openssl.org Mon Feb 22 09:49:05 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Mon, 22 Feb 2016 09:49:05 +0000 Subject: [openssl-dev] [openssl.org #4330] Unsupported options: no-ssl2 In-Reply-To: References: Message-ID: Does the attached patch work for you? Vid Sun, 21 Feb 2016 kl. 17.06.58, skrev noloader at gmail.com: > I think its great that SSLv2 is disabled by default or removed. > However, this might cause some UI pain: > > $ ./config shared no-ssl2 no-ssl3 > Operating system: x86_64-whatever-linux2 > Configuring for linux-x86_64 > Configuring OpenSSL version 1.1.0-pre4-dev (0x0x10100004L) > ***** Unsupported options: no-ssl2 > > For years we have been pounding into people's heads: "configure with > no-ssl2 no-ssl3". SSLv2 and SSLv3 are insecure. See, for example, > http://www.owasp.org/index.php/C-Based_Toolchain_Hardening#Integration. > > Changing the behavior now such that 'no-ssl2' is an error creates > additional rules that users should not have to worry about. User might > accidentally omit 'no-ssl2' on OpenSSL 1.0.1 and below due to the new > conditioning. > > I think it would be good for users to (1) disable or omit SSLv2 (as > the library is doing), and (2) honor or ignore 'no-ssl2' (both achieve > the same goal). > -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4330 Please log in as guest with password guest if prompted -------------- next part -------------- A non-text attachment was scrubbed... Name: Configure.diff Type: text/x-patch Size: 1696 bytes Desc: not available URL: From rt at openssl.org Mon Feb 22 10:01:20 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Mon, 22 Feb 2016 10:01:20 +0000 Subject: [openssl-dev] [openssl.org #4326] Failed to configure for Cygwin-x64 In-Reply-To: References: Message-ID: Actually, master already had a patch, which is even better. I'll apply one reminding of that. Vid Sun, 21 Feb 2016 kl. 08.22.02, skrev noloader at gmail.com: > On Sun, Feb 21, 2016 at 2:50 AM, Richard Levitte via RT > wrote: > > Would you try the attached patch, please? > > > > Looks good for both 1.0.2 and Master. > > Its also nice to see CHACHA_ENC and POLY1305_OBJ in the list below. > > ===== > > openssl-git $ ./config > Operating system: x86_64-pc-cygwin > Configuring for Cygwin-x86_64 > Configuring OpenSSL version 1.1.0-pre4-dev (0x0x10100004L) > no-crypto-mdebug [default] OPENSSL_NO_CRYPTO_MDEBUG (skip dir) > no-crypto-mdebug-backtrace [forced] > OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE (skip dir) > no-ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128 > (skip dir) > no-egd [default] OPENSSL_NO_EGD (skip dir) > no-heartbeats [default] OPENSSL_NO_HEARTBEATS (skip dir) > no-md2 [default] OPENSSL_NO_MD2 (skip dir) > no-rc5 [default] OPENSSL_NO_RC5 (skip dir) > no-sctp [default] OPENSSL_NO_SCTP (skip dir) > no-shared [default] > no-ssl-trace [default] OPENSSL_NO_SSL_TRACE (skip dir) > no-static-engine [default] > no-unit-test [default] OPENSSL_NO_UNIT_TEST (skip dir) > no-zlib [default] > no-zlib-dynamic [forced] > Configuring for Cygwin-x86_64 > IsMK1MF =no > CC =gcc > CFLAG = -DTERMIOS -DL_ENDIAN -Wall -O3 > DEFINES =DSO_DLFCN HAVE_DLFCN_H OPENSSL_THREADS > OPENSSL_NO_STATIC_ENGINE OPENSSL_IA32_SSE2 OPENSSL_BN_ASM_MONT > OPENSSL_BN_ASM_MONT5 OPENSSL_BN_ASM_GF2m SHA1_ASM SHA256_ASM > SHA512_ASM MD5_ASM AES_ASM VPAES_ASM BSAES_ASM GHASH_ASM > ECP_NISTZ256_ASM POLY1305_ASM > LFLAG = > PLIB_LFLAG = > EX_LIBS = > CPUID_OBJ =x86_64cpuid.o > BN_ASM =asm/x86_64-gcc.o x86_64-mont.o x86_64-mont5.o > x86_64-gf2m.o rsaz_exp.o rsaz-x86_64.o rsaz-avx2.o > EC_ASM =ecp_nistz256.o ecp_nistz256-x86_64.o > DES_ENC =des_enc.o fcrypt_b.o > AES_ENC =aes-x86_64.o vpaes-x86_64.o bsaes-x86_64.o > aesni-x86_64.o aesni-sha1-x86_64.o aesni-sha256-x86_64.o > aesni-mb-x86_64.o > BF_ENC =bf_enc.o > CAST_ENC =c_enc.o > RC4_ENC =rc4-x86_64.o rc4-md5-x86_64.o > RC5_ENC =rc5_enc.o > MD5_OBJ_ASM =md5-x86_64.o > SHA1_OBJ_ASM =sha1-x86_64.o sha256-x86_64.o sha512-x86_64.o > sha1-mb-x86_64.o sha256-mb-x86_64.o > RMD160_OBJ_ASM= > CMLL_ENC =cmll-x86_64.o cmll_misc.o > MODES_OBJ =ghash-x86_64.o aesni-gcm-x86_64.o > PADLOCK_OBJ =e_padlock-x86_64.o > CHACHA_ENC =chacha-x86_64.o > POLY1305_OBJ =poly1305-x86_64.o > PROCESSOR = > RANLIB =/usr/bin/ranlib.exe > ARFLAGS = > PERL =/usr/bin/perl.exe > SIXTY_FOUR_BIT_LONG mode > Configured for Cygwin-x86_64. -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4326 Please log in as guest with password guest if prompted From nmav at redhat.com Mon Feb 22 10:16:36 2016 From: nmav at redhat.com (Nikos Mavrogiannopoulos) Date: Mon, 22 Feb 2016 11:16:36 +0100 Subject: [openssl-dev] Ubsec and Chil engines In-Reply-To: References: <56C6FCFA.4040602@openssl.org> <5B8F45EA-5867-4832-916A-6B31A323A59C@temme.net> Message-ID: <1456136196.3289.26.camel@redhat.com> On Sat, 2016-02-20 at 23:34 +0100, Jaroslav Imrich wrote: > On 20 February 2016 at 21:40, Sander Temme wrote: > > ?However, I?m intrigued by the notion of a PKCS#11 Engine in > > OpenSSL: it?s a standard (an OASIS standard now); it?s fairly fully > > featured; everyone in the industry supports it including Thales; > > and you can build a program that calls it without needing a vendor > > SDK, because there are standard headers and a well defined way to > > get to the entry points.? If we can come up with a way to pick a > > PKCS#11 slot and log into it that makes sense (e.g. not by poking > > PINs into a system wide config file etc.) then I think we?d have a > > winner. > Let's not forget that CHIL provides one very unique feature - forked > process keeps the authentication state of its parent and can access > HSM keys if its parent was authenticated. PKCS#11 specification > prohibits such behavior (PKCS#11 v2.20 chapter 6.6.1) and because of > that PKCS#11 based engine couldn't fully replace CHIL engine. That's an implementation detail. As far as I know engine_pkcs11 does not require re-authentication after fork. It handles the pkcs11 peculiarities internally. regards, Nikos From dwmw2 at infradead.org Mon Feb 22 11:12:12 2016 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 22 Feb 2016 11:12:12 +0000 Subject: [openssl-dev] Ubsec and Chil engines In-Reply-To: <1455893619.3919.62.camel@redhat.com> References: <56C6FCFA.4040602@openssl.org> <1455887024.912.17.camel@redhat.com> <56C714BC.3060307@openssl.org> <1455893619.3919.62.camel@redhat.com> Message-ID: <1456139532.4735.266.camel@infradead.org> On Fri, 2016-02-19 at 15:53 +0100, Nikos Mavrogiannopoulos wrote: > On Fri, 2016-02-19 at 13:12 +0000, Matt Caswell wrote: > > > As far as I know there are some customers using the Chil engine > > > with > > > RHEL (openssl-1.0.1).? > > > > How do you feel about the engine being spun out into a separate > > repo? > > That of course assumes that a volunteer can be found to maintain it > > (I > > don't believe anyone on the dev team wishes to do so). > > > > If no such volunteer can be found how big a deal is it to remove it > > from > > 1.1.0 without a replacement? Obviously it won't be taken out of > > 1.0.1/1.0.2. Of course there's no reason, even if we take it out > > now, > > that if someone needs it badly enough in the future that they > > couldn't forward port the 1.0.2 version to 1.1.0 and maintain it > > themselves at that point. > > It may even be better, instead of pushing for different engines for > different hardware, to make PKCS#11 the only API used to talk to > hardware. There is a quite functional (and active as project) pkcs11 > engine for openssl [0]. Agreed. With the caveat that I *really* want libp11 and engine_pkcs11 to die, and be replaced by native code in openssl/crypto/pkcs11/ That way we can integrate it *properly*, with various SSL certificate handling functions just naturally taking PKCS#11 URIs alongside filenames. Integrating libp11 itself would require relicensing it, which might be non-trivial but perhaps still achievable. Or maybe we should reimplement it, basing the new version around p11-kit. It would be an *optional* thing, of course. Windows builds might default to no-pkcs11. But p11-kit ought to exist fairly much everywhere *else*. Apart from UEFI :) -- David Woodhouse Open Source Technology Centre David.Woodhouse at intel.com Intel Corporation -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5691 bytes Desc: not available URL: From dwmw2 at infradead.org Mon Feb 22 11:32:21 2016 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 22 Feb 2016 11:32:21 +0000 Subject: [openssl-dev] Ubsec and Chil engines In-Reply-To: <20160220.225541.1585601945103016062.levitte@openssl.org> References: <56C6FCFA.4040602@openssl.org> <5B8F45EA-5867-4832-916A-6B31A323A59C@temme.net> <20160220.225541.1585601945103016062.levitte@openssl.org> Message-ID: <1456140741.4735.272.camel@infradead.org> On Sat, 2016-02-20 at 22:55 +0100, Richard Levitte wrote: > > sander> What I would like to see though is for such a PKCS#11 Engine > sander> to be part of OpenSSL proper, so that our customers and > sander> everyone else?s don?t have to go hunt hither and yon for bits > sander> and bobs of software in order to make their hardware kit work > sander> with OpenSSL.? How would OpenSSL obtain a PKCS#11 Engine to > sander> include in its distribution? > > I'm not sure if this is a problem specifically for OpenSSL to solve, > or if it is a packager problem.? I touched on this in a message a few minutes ago, but I *definitely* think it's the former. If we integrate the support natively into OpenSSL, then PKCS#11 URIs (see RFC7512) can be first-class citizens throughout the crypto and SSL APIs. Any function which takes a filename for a cert or key should also accept? a PKCS#11 URI. Then we can also use PKCS#11 for the trust database, which allows us to properly handle the trusted *purposes* in ways that a flat file doesn't. And that flat file is now *exported* from the p11-kit-trust token purely for the benefit of OpenSSL, which it would be nice to stop doing. I am happy to work on this. -- David Woodhouse Open Source Technology Centre David.Woodhouse at intel.com Intel Corporation ? Or "have a parallel function which takes"... but seriously, how often is a string which starts "pkcs11:" going to have been intended as a an actual *filename*? :) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5691 bytes Desc: not available URL: From levitte at openssl.org Mon Feb 22 11:52:36 2016 From: levitte at openssl.org (Richard Levitte) Date: Mon, 22 Feb 2016 12:52:36 +0100 (CET) Subject: [openssl-dev] Ubsec and Chil engines In-Reply-To: <1456140741.4735.272.camel@infradead.org> References: <5B8F45EA-5867-4832-916A-6B31A323A59C@temme.net> <20160220.225541.1585601945103016062.levitte@openssl.org> <1456140741.4735.272.camel@infradead.org> Message-ID: <20160222.125236.1263663358704085081.levitte@openssl.org> In message <1456140741.4735.272.camel at infradead.org> on Mon, 22 Feb 2016 11:32:21 +0000, David Woodhouse said: dwmw2> On Sat, 2016-02-20 at 22:55 +0100, Richard Levitte wrote: dwmw2> > dwmw2> > sander> What I would like to see though is for such a PKCS#11 Engine dwmw2> > sander> to be part of OpenSSL proper, so that our customers and dwmw2> > sander> everyone else?s don?t have to go hunt hither and yon for bits dwmw2> > sander> and bobs of software in order to make their hardware kit work dwmw2> > sander> with OpenSSL.? How would OpenSSL obtain a PKCS#11 Engine to dwmw2> > sander> include in its distribution? dwmw2> > dwmw2> > I'm not sure if this is a problem specifically for OpenSSL to solve, dwmw2> > or if it is a packager problem.? dwmw2> dwmw2> I touched on this in a message a few minutes ago, but I *definitely* dwmw2> think it's the former. dwmw2> dwmw2> If we integrate the support natively into OpenSSL, then PKCS#11 URIs dwmw2> (see RFC7512) can be first-class citizens throughout the crypto and SSL dwmw2> APIs. Any function which takes a filename for a cert or key should also dwmw2> accept? a PKCS#11 URI. dwmw2> dwmw2> Then we can also use PKCS#11 for the trust database, which allows us to dwmw2> properly handle the trusted *purposes* in ways that a flat file dwmw2> doesn't. And that flat file is now *exported* from the p11-kit-trust dwmw2> token purely for the benefit of OpenSSL, which it would be nice to stop dwmw2> doing. dwmw2> dwmw2> I am happy to work on this. That takes me back to crypto/store, which is currently removed in master but which I have a rework of in a branch, which is meant to solve this exact problem, but without being exclusively tied to PKCS#11. The design is to have it work with engine backends, and a PKCS#11 engine that's part of OpenSSL would fit that bill, so to say. Shall we talk? -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From dwmw2 at infradead.org Mon Feb 22 12:21:55 2016 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 22 Feb 2016 12:21:55 +0000 Subject: [openssl-dev] Ubsec and Chil engines In-Reply-To: <20160222.125236.1263663358704085081.levitte@openssl.org> References: <5B8F45EA-5867-4832-916A-6B31A323A59C@temme.net> <20160220.225541.1585601945103016062.levitte@openssl.org> <1456140741.4735.272.camel@infradead.org> <20160222.125236.1263663358704085081.levitte@openssl.org> Message-ID: <1456143715.4735.291.camel@infradead.org> On Mon, 2016-02-22 at 12:52 +0100, Richard Levitte wrote: > > That takes me back to crypto/store, which is currently removed in > master but which I have a rework of in a branch, which is meant to > solve this exact problem, but without being exclusively tied to > PKCS#11.? The design is to have it work with engine backends, and a > PKCS#11 engine that's part of OpenSSL would fit that bill, so to say. That seems ideal. The TPM ENGINE could benefit from it too. I'd really like to look at this from the *application* developer's point of view. Please clear your mind of any internal OpenSSL knowledge and context, and take a look at the OpenConnect VPN client, and the various hoops it has to jump through to load a certificate: http://git.infradead.org/users/dwmw2/openconnect.git/blob/v7.06:/openssl.c#l261 through to the main load_certificate() function which ends at line 916.? (You can ignore the entire contents of openssl-pkcs11.c for now.) Even if you discount the TPM and PKCS#11 parts, it's bad enough for just loading certificates from a file. We force the *application* to inspect the file that the user asked it to use, and work out what kind of file it is. And then even the handling of the *passphrase* is different according to what kind of file it is ? PKCS#12 functions need the password handed in, while PEM functions are given a callback function instead. And don't even *talk* to me about the horridness with the TPM's UI having no way to pass through any opaque data to the callback, and the need for that 'static struct openconnect_info *ui_vpninfo' at line 276. Actually, do talk to me about that. Let's fix it before 1.1? We desperately need to provide applications with a function that silently Does The Right Thing, when given a filename or a PKCS#11 URI or whatever other string a user might put reasonably put into a config file to specify a certificate/key. > Shall we talk? Absolutely :) -- David Woodhouse Open Source Technology Centre David.Woodhouse at intel.com Intel Corporation -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5691 bytes Desc: not available URL: From jaroslav.imrich at gmail.com Mon Feb 22 14:08:16 2016 From: jaroslav.imrich at gmail.com (Jaroslav Imrich) Date: Mon, 22 Feb 2016 15:08:16 +0100 Subject: [openssl-dev] Ubsec and Chil engines In-Reply-To: <1456136196.3289.26.camel@redhat.com> References: <56C6FCFA.4040602@openssl.org> <5B8F45EA-5867-4832-916A-6B31A323A59C@temme.net> <1456136196.3289.26.camel@redhat.com> Message-ID: On 22 February 2016 at 11:16, Nikos Mavrogiannopoulos wrote: > That's an implementation detail. As far as I know engine_pkcs11 does > not require re-authentication after fork. It handles the pkcs11 > peculiarities internally. > AFAIK this works by caching the PIN in engine_pkcs11 internally and is OK for most of the use cases with smartcards. However HSMs usually use more complex authentication schemes where this approach does not work i.e. in order to login there must be N of M physical tokens/cards with passwords presented in a sequence (requires vendor specific extensions when used via PKCS#11). CHIL engine already handles such schemes very well and does not need to reauthenticate after fork. Regards, Jaroslav -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Mon Feb 22 14:46:28 2016 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 22 Feb 2016 14:46:28 +0000 Subject: [openssl-dev] Ubsec and Chil engines In-Reply-To: <1456140741.4735.272.camel@infradead.org> References: <56C6FCFA.4040602@openssl.org> <5B8F45EA-5867-4832-916A-6B31A323A59C@temme.net> <20160220.225541.1585601945103016062.levitte@openssl.org> <1456140741.4735.272.camel@infradead.org> Message-ID: <347004c001fd430aadadceac908e68a2@ustx2ex-dag1mb1.msg.corp.akamai.com> > If we integrate the support natively into OpenSSL, then PKCS#11 URIs (see > RFC7512) can be first-class citizens throughout the crypto and SSL APIs. Any > function which takes a filename for a cert or key should also accept? a > PKCS#11 URI. It'd be great to see a crypto/pkcs11 directory with full native support (as much as possible). But really doubtful to happen in 1.1 as the API freeze is in a month. From rt at openssl.org Mon Feb 22 14:46:53 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Mon, 22 Feb 2016 14:46:53 +0000 Subject: [openssl-dev] [openssl.org #4326] Failed to configure for Cygwin-x64 In-Reply-To: References: Message-ID: Issue fixed in commit e80381e1a3309f5d4a783bcaa508a90187a48882 -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4326 Please log in as guest with password guest if prompted From rt at openssl.org Mon Feb 22 14:48:02 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Mon, 22 Feb 2016 14:48:02 +0000 Subject: [openssl-dev] [openssl.org #4330] Unsupported options: no-ssl2 In-Reply-To: References: Message-ID: Issue fixed in commit e80381e1a3309f5d4a783bcaa508a90187a48882 -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4330 Please log in as guest with password guest if prompted From rt at openssl.org Mon Feb 22 14:48:55 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Mon, 22 Feb 2016 14:48:55 +0000 Subject: [openssl-dev] [openssl.org #4326] Failed to configure for Cygwin-x64 In-Reply-To: References: Message-ID: Sorry, wrong commit cited here, the correct one is 5c57fbb8ca991e8db7ce23174613898a27ca3fcb Vid Mon, 22 Feb 2016 kl. 14.46.52, skrev levitte: > Issue fixed in commit e80381e1a3309f5d4a783bcaa508a90187a48882 > > -- > Richard Levitte > levitte at openssl.org -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4326 Please log in as guest with password guest if prompted From levitte at openssl.org Mon Feb 22 15:00:34 2016 From: levitte at openssl.org (Richard Levitte) Date: Mon, 22 Feb 2016 16:00:34 +0100 (CET) Subject: [openssl-dev] Ubsec and Chil engines In-Reply-To: <347004c001fd430aadadceac908e68a2@ustx2ex-dag1mb1.msg.corp.akamai.com> References: <20160220.225541.1585601945103016062.levitte@openssl.org> <1456140741.4735.272.camel@infradead.org> <347004c001fd430aadadceac908e68a2@ustx2ex-dag1mb1.msg.corp.akamai.com> Message-ID: <20160222.160034.1279367000656813396.levitte@openssl.org> In message <347004c001fd430aadadceac908e68a2 at ustx2ex-dag1mb1.msg.corp.akamai.com> on Mon, 22 Feb 2016 14:46:28 +0000, "Salz, Rich" said: rsalz> > If we integrate the support natively into OpenSSL, then PKCS#11 URIs (see rsalz> > RFC7512) can be first-class citizens throughout the crypto and SSL APIs. Any rsalz> > function which takes a filename for a cert or key should also accept? a rsalz> > PKCS#11 URI. rsalz> rsalz> It'd be great to see a crypto/pkcs11 directory with full native support (as much as possible). rsalz> rsalz> But really doubtful to happen in 1.1 as the API freeze is in a month. Yeah, 1.1 is unrealistic, I'm sorry to say. -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From uri at ll.mit.edu Mon Feb 22 15:54:25 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Mon, 22 Feb 2016 15:54:25 +0000 Subject: [openssl-dev] openssl-1.1 started looking for engines using wrong names Message-ID: In short, after commits done in the last few days, openssl-1.1 stopped looking for lib.so, and started looking for .so. I think it?s an introduced bug that needs to be fixed: $ ~/src/openssl-1.1/bin/openssl engine pkcs11 -t 140735268914000:error:25066067:DSO support routines:dlfcn_load:could not load the shared library:crypto/dso/dso_dlfcn.c:172:filename(/Users/ur20980/src/openssl-1.1/l ib/engines/pkcs11.dylib): dlopen(/Users/ur20980/src/openssl-1.1/lib/engines/pkcs11.dylib, 2): image not found 140735268914000:error:25070067:DSO support routines:DSO_load:could not load the shared library:crypto/dso/dso_lib.c:220: 140735268914000:error:260B6084:engine routines:dynamic_load:dso not found:crypto/engine/eng_dyn.c:456: 140735268914000:error:2606A074:engine routines:ENGINE_by_id:no such engine:crypto/engine/eng_list.c:372:id=pkcs11 $ ln -s /Users/ur20980/src/openssl-1.1/lib/engines/libpkcs11.dylib /Users/ur20980/src/openssl-1.1/lib/engines/pkcs11.dylib $ ~/src/openssl-1.1/bin/openssl engine pkcs11 -t (pkcs11) pkcs11 engine [ available ] $ This issue has been reported on Github: https://github.com/openssl/openssl/issues/727 -- Regards, Uri Blumenthal -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4324 bytes Desc: not available URL: From ju-hyoung.lee at hpe.com Mon Feb 22 15:50:21 2016 From: ju-hyoung.lee at hpe.com (Lee, Ju (Converged Systems)) Date: Mon, 22 Feb 2016 15:50:21 +0000 Subject: [openssl-dev] [openssl.org #4326] Failed to configure for Cygwin-x64 In-Reply-To: References: Message-ID: <5976CEC235DEAB42ACDF49B92E1FCF360CF36F@G9W0727.americas.hpqcorp.net> It failed to 'make test' at d784bcffa3dcd7ac4a0c77bfac4e686dcb771bd9 this morning. Test Summary Report ------------------- ../../openssl/test/recipes/70-test_sslcertstatus.t (Wstat: 28416 Tests: 0 Failed: 0) Non-zero exit status: 111 Parse errors: Bad plan. You planned 1 tests but ran 0. Files=68, Tests=386, 23 wallclock secs ( 0.41 usr 0.07 sys + 14.88 cusr 0.66 csys = 16.02 CPU) Result: FAIL Failed 1/68 test programs. 0/386 subtests failed. Makefile:118: recipe for target 'test' failed make: *** [test] Error 255 user at washinro1:~/_openssl-build_linux-x86_64$ BTW, 'make test' passed like below. Somehow the make rule in test fails. user at washinro1:~/openssl$ cat testlog OpenSSL self-test report: OpenSSL version: 1.1.0-pre4-dev Last change: Configuration change; it's now possible to build dynami... Options: -Wa,--noexecstack no-crypto-mdebug no-crypto-mdebug-backtrace no-ec_nistp_64_gcc_128 no-egd no-heartbeats no-md2 no-rc5 no-sctp no-shared no-ssl-trace no-static-engine no-unit-test no-zlib no-zlib-dynamic OS (uname): Linux washinro1 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u3 (2016-01-17) x86_64 GNU/Linux OS (config): x86_64-whatever-linux2 Target (default): linux-x86_64 Target: linux-x86_64 Compiler: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.2-10' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.9 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.9.2 (Debian 4.9.2-10) Test passed. user at washinro1:~/openssl$ Ju -----Original Message----- From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Richard Levitte via RT Sent: Monday, February 22, 2016 8:49 AM To: noloader at gmail.com Cc: openssl-dev at openssl.org Subject: [openssl-dev] [openssl.org #4326] Failed to configure for Cygwin-x64 Sorry, wrong commit cited here, the correct one is 5c57fbb8ca991e8db7ce23174613898a27ca3fcb Vid Mon, 22 Feb 2016 kl. 14.46.52, skrev levitte: > Issue fixed in commit e80381e1a3309f5d4a783bcaa508a90187a48882 > > -- > Richard Levitte > levitte at openssl.org -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4326 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From rt at openssl.org Mon Feb 22 15:56:55 2016 From: rt at openssl.org (Lee, Ju via RT) Date: Mon, 22 Feb 2016 15:56:55 +0000 Subject: [openssl-dev] [openssl.org #4326] Failed to configure for Cygwin-x64 In-Reply-To: <5976CEC235DEAB42ACDF49B92E1FCF360CF36F@G9W0727.americas.hpqcorp.net> References: <5976CEC235DEAB42ACDF49B92E1FCF360CF36F@G9W0727.americas.hpqcorp.net> Message-ID: It failed to 'make test' at d784bcffa3dcd7ac4a0c77bfac4e686dcb771bd9 this morning. Test Summary Report ------------------- ../../openssl/test/recipes/70-test_sslcertstatus.t (Wstat: 28416 Tests: 0 Failed: 0) Non-zero exit status: 111 Parse errors: Bad plan. You planned 1 tests but ran 0. Files=68, Tests=386, 23 wallclock secs ( 0.41 usr 0.07 sys + 14.88 cusr 0.66 csys = 16.02 CPU) Result: FAIL Failed 1/68 test programs. 0/386 subtests failed. Makefile:118: recipe for target 'test' failed make: *** [test] Error 255 user at washinro1:~/_openssl-build_linux-x86_64$ BTW, 'make test' passed like below. Somehow the make rule in test fails. user at washinro1:~/openssl$ cat testlog OpenSSL self-test report: OpenSSL version: 1.1.0-pre4-dev Last change: Configuration change; it's now possible to build dynami... Options: -Wa,--noexecstack no-crypto-mdebug no-crypto-mdebug-backtrace no-ec_nistp_64_gcc_128 no-egd no-heartbeats no-md2 no-rc5 no-sctp no-shared no-ssl-trace no-static-engine no-unit-test no-zlib no-zlib-dynamic OS (uname): Linux washinro1 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u3 (2016-01-17) x86_64 GNU/Linux OS (config): x86_64-whatever-linux2 Target (default): linux-x86_64 Target: linux-x86_64 Compiler: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.2-10' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.9 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.9.2 (Debian 4.9.2-10) Test passed. user at washinro1:~/openssl$ Ju -----Original Message----- From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Richard Levitte via RT Sent: Monday, February 22, 2016 8:49 AM To: noloader at gmail.com Cc: openssl-dev at openssl.org Subject: [openssl-dev] [openssl.org #4326] Failed to configure for Cygwin-x64 Sorry, wrong commit cited here, the correct one is 5c57fbb8ca991e8db7ce23174613898a27ca3fcb Vid Mon, 22 Feb 2016 kl. 14.46.52, skrev levitte: > Issue fixed in commit e80381e1a3309f5d4a783bcaa508a90187a48882 > > -- > Richard Levitte > levitte at openssl.org -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4326 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4326 Please log in as guest with password guest if prompted From uri at ll.mit.edu Mon Feb 22 15:59:18 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Mon, 22 Feb 2016 15:59:18 +0000 Subject: [openssl-dev] Ubsec and Chil engines In-Reply-To: <1456139532.4735.266.camel@infradead.org> References: <56C6FCFA.4040602@openssl.org> <1455887024.912.17.camel@redhat.com> <56C714BC.3060307@openssl.org> <1455893619.3919.62.camel@redhat.com> <1456139532.4735.266.camel@infradead.org> Message-ID: On 2/22/16, 6:12 , "openssl-dev on behalf of David Woodhouse" wrote: >>It may even be better, instead of pushing for different engines for >> different hardware, to make PKCS#11 the only API used to talk to >> hardware. There is a quite functional (and active as project) pkcs11 >> engine for openssl [0]. > >Agreed. With the caveat that I *really* want libp11 and engine_pkcs11 >to die, and be replaced by native code in openssl/crypto/pkcs11/ Would you mind explaining what you mean by ?native code? that presumably could replace the current libp11, and who in your opinion would support it? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4324 bytes Desc: not available URL: From swall at redcom.com Mon Feb 22 16:01:02 2016 From: swall at redcom.com (Wall, Stephen) Date: Mon, 22 Feb 2016 11:01:02 -0500 Subject: [openssl-dev] OpenSSL 1.1.0 and FIPS Message-ID: <401084E5E73F4241A44F3C9E6FD79428036870CEDA@exch-01> I wonder if I could get the thoughts of some of you developers on how difficult it would be to build an engine for OpenSSL 1.1.0 that makes use of the current (2.0.11?) fipscanister.o. Also, opinions on if this would be a legitimate way to get FIPS in 1.1.0. Thanks, spw From rt at openssl.org Mon Feb 22 16:28:08 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 22 Feb 2016 16:28:08 +0000 Subject: [openssl-dev] [openssl.org #4320] [Patch] OpenSSL 1.1.0-pre3: "unable to load Key" error in PEM_get_EVP_CIPHER_INFO() In-Reply-To: <56C4BA0E.7090603@kippdata.de> References: <56C4BA0E.7090603@kippdata.de> Message-ID: fixed in commit 985c3146967633707f7c165df82bb0fd8f279758 thanks for the report! -- Rich Salz, OpenSSL dev team; rsalz at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4320 Please log in as guest with password guest if prompted From ju-hyoung.lee at hpe.com Mon Feb 22 16:30:04 2016 From: ju-hyoung.lee at hpe.com (Lee, Ju (Converged Systems)) Date: Mon, 22 Feb 2016 16:30:04 +0000 Subject: [openssl-dev] [openssl.org #4326] Failed to configure for Cygwin-x64 In-Reply-To: References: <5976CEC235DEAB42ACDF49B92E1FCF360CF36F@G9W0727.americas.hpqcorp.net> Message-ID: <5976CEC235DEAB42ACDF49B92E1FCF360CF471@G9W0727.americas.hpqcorp.net> 9e04edf2f309e7edc3f4c9a09d444b2fd23a1e46 fixed -----Original Message----- From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Lee, Ju via RT Sent: Monday, February 22, 2016 9:57 AM To: noloader at gmail.com Cc: openssl-dev at openssl.org Subject: Re: [openssl-dev] [openssl.org #4326] Failed to configure for Cygwin-x64 It failed to 'make test' at d784bcffa3dcd7ac4a0c77bfac4e686dcb771bd9 this morning. Test Summary Report ------------------- ../../openssl/test/recipes/70-test_sslcertstatus.t (Wstat: 28416 Tests: 0 Failed: 0) Non-zero exit status: 111 Parse errors: Bad plan. You planned 1 tests but ran 0. Files=68, Tests=386, 23 wallclock secs ( 0.41 usr 0.07 sys + 14.88 cusr 0.66 csys = 16.02 CPU) Result: FAIL Failed 1/68 test programs. 0/386 subtests failed. Makefile:118: recipe for target 'test' failed make: *** [test] Error 255 user at washinro1:~/_openssl-build_linux-x86_64$ BTW, 'make test' passed like below. Somehow the make rule in test fails. user at washinro1:~/openssl$ cat testlog OpenSSL self-test report: OpenSSL version: 1.1.0-pre4-dev Last change: Configuration change; it's now possible to build dynami... Options: -Wa,--noexecstack no-crypto-mdebug no-crypto-mdebug-backtrace no-ec_nistp_64_gcc_128 no-egd no-heartbeats no-md2 no-rc5 no-sctp no-shared no-ssl-trace no-static-engine no-unit-test no-zlib no-zlib-dynamic OS (uname): Linux washinro1 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u3 (2016-01-17) x86_64 GNU/Linux OS (config): x86_64-whatever-linux2 Target (default): linux-x86_64 Target: linux-x86_64 Compiler: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.2-10' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.9 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.9.2 (Debian 4.9.2-10) Test passed. user at washinro1:~/openssl$ Ju -----Original Message----- From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Richard Levitte via RT Sent: Monday, February 22, 2016 8:49 AM To: noloader at gmail.com Cc: openssl-dev at openssl.org Subject: [openssl-dev] [openssl.org #4326] Failed to configure for Cygwin-x64 Sorry, wrong commit cited here, the correct one is 5c57fbb8ca991e8db7ce23174613898a27ca3fcb Vid Mon, 22 Feb 2016 kl. 14.46.52, skrev levitte: > Issue fixed in commit e80381e1a3309f5d4a783bcaa508a90187a48882 > > -- > Richard Levitte > levitte at openssl.org -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4326 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4326 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From rt at openssl.org Mon Feb 22 16:30:16 2016 From: rt at openssl.org (Lee, Ju via RT) Date: Mon, 22 Feb 2016 16:30:16 +0000 Subject: [openssl-dev] [openssl.org #4326] Failed to configure for Cygwin-x64 In-Reply-To: <5976CEC235DEAB42ACDF49B92E1FCF360CF471@G9W0727.americas.hpqcorp.net> References: <5976CEC235DEAB42ACDF49B92E1FCF360CF36F@G9W0727.americas.hpqcorp.net> <5976CEC235DEAB42ACDF49B92E1FCF360CF471@G9W0727.americas.hpqcorp.net> Message-ID: 9e04edf2f309e7edc3f4c9a09d444b2fd23a1e46 fixed -----Original Message----- From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Lee, Ju via RT Sent: Monday, February 22, 2016 9:57 AM To: noloader at gmail.com Cc: openssl-dev at openssl.org Subject: Re: [openssl-dev] [openssl.org #4326] Failed to configure for Cygwin-x64 It failed to 'make test' at d784bcffa3dcd7ac4a0c77bfac4e686dcb771bd9 this morning. Test Summary Report ------------------- ../../openssl/test/recipes/70-test_sslcertstatus.t (Wstat: 28416 Tests: 0 Failed: 0) Non-zero exit status: 111 Parse errors: Bad plan. You planned 1 tests but ran 0. Files=68, Tests=386, 23 wallclock secs ( 0.41 usr 0.07 sys + 14.88 cusr 0.66 csys = 16.02 CPU) Result: FAIL Failed 1/68 test programs. 0/386 subtests failed. Makefile:118: recipe for target 'test' failed make: *** [test] Error 255 user at washinro1:~/_openssl-build_linux-x86_64$ BTW, 'make test' passed like below. Somehow the make rule in test fails. user at washinro1:~/openssl$ cat testlog OpenSSL self-test report: OpenSSL version: 1.1.0-pre4-dev Last change: Configuration change; it's now possible to build dynami... Options: -Wa,--noexecstack no-crypto-mdebug no-crypto-mdebug-backtrace no-ec_nistp_64_gcc_128 no-egd no-heartbeats no-md2 no-rc5 no-sctp no-shared no-ssl-trace no-static-engine no-unit-test no-zlib no-zlib-dynamic OS (uname): Linux washinro1 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u3 (2016-01-17) x86_64 GNU/Linux OS (config): x86_64-whatever-linux2 Target (default): linux-x86_64 Target: linux-x86_64 Compiler: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.2-10' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.9 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.9.2 (Debian 4.9.2-10) Test passed. user at washinro1:~/openssl$ Ju -----Original Message----- From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Richard Levitte via RT Sent: Monday, February 22, 2016 8:49 AM To: noloader at gmail.com Cc: openssl-dev at openssl.org Subject: [openssl-dev] [openssl.org #4326] Failed to configure for Cygwin-x64 Sorry, wrong commit cited here, the correct one is 5c57fbb8ca991e8db7ce23174613898a27ca3fcb Vid Mon, 22 Feb 2016 kl. 14.46.52, skrev levitte: > Issue fixed in commit e80381e1a3309f5d4a783bcaa508a90187a48882 > > -- > Richard Levitte > levitte at openssl.org -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4326 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4326 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4326 Please log in as guest with password guest if prompted From rt at openssl.org Mon Feb 22 16:32:31 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 22 Feb 2016 16:32:31 +0000 Subject: [openssl-dev] [openssl.org #4309] [PATCH] Fix UEFI/EDK2 build error by defining PRIu64 In-Reply-To: <1455634716.4832.128.camel@infradead.org> References: <1455634716.4832.128.camel@infradead.org> Message-ID: pushed in commit d99d0d9 thanks! -- Rich Salz, OpenSSL dev team; rsalz at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4309 Please log in as guest with password guest if prompted From foleyj at cisco.com Mon Feb 22 16:33:01 2016 From: foleyj at cisco.com (John Foley) Date: Mon, 22 Feb 2016 11:33:01 -0500 Subject: [openssl-dev] OpenSSL 1.1.0 and FIPS In-Reply-To: <401084E5E73F4241A44F3C9E6FD79428036870CEDA@exch-01> References: <401084E5E73F4241A44F3C9E6FD79428036870CEDA@exch-01> Message-ID: <56CB383D.8070208@cisco.com> One of the challenges with this will be symbol collision (in a Linux environment). I would think that doing this as a static engine would not be possible. The reason is your new engine that's using the 2.0.11 canister would contain symbols that exist in OpenSSL. But maybe the fipssyms.h trickery could be used to get past this. Doing this as a dynamic engine may be a challenge as well. Your dynamic engine, implemented as a .so, would have symbol overlap as well. But these would be resolved by the loader. Depending on whether libcrypto.so or your .so was loaded first by the loader, the wrong implementation for a symbol could be used. On 02/22/2016 11:01 AM, Wall, Stephen wrote: > I wonder if I could get the thoughts of some of you developers on how difficult it would be to build an engine for OpenSSL 1.1.0 that makes use of the current (2.0.11?) fipscanister.o. Also, opinions on if this would be a legitimate way to get FIPS in 1.1.0. > > Thanks, > spw > From uri at ll.mit.edu Mon Feb 22 16:42:46 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Mon, 22 Feb 2016 16:42:46 +0000 Subject: [openssl-dev] [openssl.org #4290] HMAC_Init_ex() return bug In-Reply-To: References: <9901de91e2a14612a1155d04cd74be30@ustx2ex-dag1mb1.msg.corp.akamai.com> Message-ID: If somebody (Mik, Felipe, you hear? :) cares to send me a *simple* *short* code that exposes this problem, I?ll be willing to test it on Linux and Mac OS X, with OpenSSL-1.0.2f, OpenSSL-1.0.2-stable, and 1.1-pre. -- Regards, Uri Blumenthal On 2/20/16, 9:10 , "openssl-dev on behalf of Salz, Rich via RT" wrote: >Still waiting to see from anyone else if it's a non-mac issue. > > >-- >Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4290 >Please log in as guest with password guest if prompted > >-- >openssl-dev mailing list >To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4324 bytes Desc: not available URL: From marquess at openssl.com Mon Feb 22 16:47:17 2016 From: marquess at openssl.com (Steve Marquess) Date: Mon, 22 Feb 2016 11:47:17 -0500 Subject: [openssl-dev] OpenSSL 1.1.0 and FIPS In-Reply-To: <401084E5E73F4241A44F3C9E6FD79428036870CEDA@exch-01> References: <401084E5E73F4241A44F3C9E6FD79428036870CEDA@exch-01> Message-ID: <56CB3B95.2040506@openssl.com> On 02/22/2016 11:01 AM, Wall, Stephen wrote: > I wonder if I could get the thoughts of some of you developers on how > difficult it would be to build an engine for OpenSSL 1.1.0 that makes > use of the current (2.0.11?) fipscanister.o. Also, opinions on if > this would be a legitimate way to get FIPS in 1.1.0. > > Thanks, spw > Re-use of the current 2.0 module was debated in detail, with the conclusion that too many distortions to the new OpenSSL code would be required. We're trying hard to get away from messy, ugly, fragile code and reluctantly concluded that only a new FIPS module designed for a clean interface with OpenSSL 1.1 was feasible. We are not happy with the loss of FIPS support for 1.1; we know many users require it. But, we're not willing to compromise sound software engineering judgment to kludge together an abomination (and frankly the current FIPS module with OpenSSL 1.0.N is pretty ugly already). What we need is a new FIPS module, which we're willing to develop given the opportunity. The main problem there is the formal validation process. A FIPS 140-2 validation is challenging enough for conventional proprietary close-source binary code; open source based validations are enormously more difficult. Those have only been done five times, and my assessment of the current regulatory environment is that it would be far too risky for us to attempt a sixth such attempt (at least not without sponsor(s) willing to absorb most of that risk). If and when a new FIPS module for 1.1 is developed, it almost certainly will take the form of a new "engine" style modular component. -Steve M. -- Steve Marquess OpenSSL Validation Services, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From rt at openssl.org Mon Feb 22 16:58:40 2016 From: rt at openssl.org (David Woodhouse via RT) Date: Mon, 22 Feb 2016 16:58:40 +0000 Subject: [openssl-dev] [openssl.org #4334] Check for UEFI before __STDC_VERSION__ for In-Reply-To: <1456160308.4735.301.camel@infradead.org> References: <1456160308.4735.301.camel@infradead.org> Message-ID: Adding -nostdinc to the EDK2 showed that we were including for some UEFI builds, because the check for __STDC_VERSION__ happens before the check for OPENSSL_SYS_UEFI. Fix that. --- ?include/openssl/e_os2.h | 12 ++++++------ ?1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/include/openssl/e_os2.h b/include/openssl/e_os2.h index b66b1cc..ba3345a 100644 --- a/include/openssl/e_os2.h +++ b/include/openssl/e_os2.h @@ -286,11 +286,7 @@ extern "C" { ?# endif ? ?/* Standard integer types */ -# if (defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L) || \ -?????defined(__osf__) || defined(__sgi) || defined(__hpux) || \ -?????defined(OPENSSL_SYS_VMS) -#??include -# elif defined(OPENSSL_SYS_UEFI) +# if defined(OPENSSL_SYS_UEFI) ?typedef INT8 int8_t; ?typedef UINT8 uint8_t; ?typedef INT16 int16_t; @@ -299,7 +295,11 @@ typedef INT32 int32_t; ?typedef UINT32 uint32_t; ?typedef INT64 int64_t; ?typedef UINT64 uint64_t; -#define PRIu64 "%Lu" +#??define PRIu64 "%Lu" +# elif (defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L) || \ +?????defined(__osf__) || defined(__sgi) || defined(__hpux) || \ +?????defined(OPENSSL_SYS_VMS) +#??include ?# elif defined(_MSC_VER) && _MSC_VER<=1500 ?/* ? * minimally required typdefs for systems not supporting inttypes.h or --? 2.5.0 -- David Woodhouse Open Source Technology Centre David.Woodhouse at intel.com Intel Corporation -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4334 Please log in as guest with password guest if prompted -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5691 bytes Desc: not available URL: From rt at openssl.org Mon Feb 22 17:04:01 2016 From: rt at openssl.org (David Woodhouse via RT) Date: Mon, 22 Feb 2016 17:04:01 +0000 Subject: [openssl-dev] [openssl.org #4335] ix 'assignment from incompatible type' warning in OBJ_NAME_new_index() In-Reply-To: <1456160635.4735.302.camel@infradead.org> References: <1456160635.4735.302.camel@infradead.org> Message-ID: We are using OPENSSL_strcmp() as the cmp_func, where cmp_func takes a pair of (void *) pointers, not (char *). Which is fine; we know we're going to pass it strings in this case. So explicitly cast it to avoid the resulting compiler warning. --- ?crypto/objects/o_names.c | 2 +- ?1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/crypto/objects/o_names.c b/crypto/objects/o_names.c index 0a07379..1f9f10a 100644 --- a/crypto/objects/o_names.c +++ b/crypto/objects/o_names.c @@ -83,7 +83,7 @@ int OBJ_NAME_new_index(unsigned long (*hash_func) (const char *), ?????????????return (0); ?????????} ?????????name_funcs->hash_func = lh_strhash; -????????name_funcs->cmp_func = OPENSSL_strcmp; +????????name_funcs->cmp_func = (void *)OPENSSL_strcmp; ?????????CRYPTO_mem_ctrl(CRYPTO_MEM_CHECK_DISABLE); ?????????sk_NAME_FUNCS_push(name_funcs_stack, name_funcs); ?????????CRYPTO_mem_ctrl(CRYPTO_MEM_CHECK_ENABLE); --? 2.5.0 -- David Woodhouse Open Source Technology Centre David.Woodhouse at intel.com Intel Corporation -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4335 Please log in as guest with password guest if prompted -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5691 bytes Desc: not available URL: From rt at openssl.org Mon Feb 22 17:15:51 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 22 Feb 2016 17:15:51 +0000 Subject: [openssl-dev] [openssl.org #4334] Check for UEFI before __STDC_VERSION__ for In-Reply-To: <1456160308.4735.301.camel@infradead.org> References: <1456160308.4735.301.camel@infradead.org> Message-ID: fixed in commit a2d0baa thanks! -- Rich Salz, OpenSSL dev team; rsalz at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4334 Please log in as guest with password guest if prompted From vinschen at redhat.com Mon Feb 22 17:34:04 2016 From: vinschen at redhat.com (Corinna Vinschen) Date: Mon, 22 Feb 2016 18:34:04 +0100 Subject: [openssl-dev] [openssl.org #4326] Failed to configure for Cygwin-x64 In-Reply-To: References: Message-ID: <20160222173404.GB11853@calimero.vinschen.de> On Feb 21 06:27, Richard Levitte via RT wrote: > I believe that the auto-detecting script, ./config, is lacking detection of > architecture for Cygwin. Does one preferably recognise a x86_64 Cygwin from > `uname -m` or is there something in `uname -s` that should be used as an > indicator? Uh oh, is there a chance that the configury for 1.0.2 is NOT changed anymore? We have a set of local patches in the Cygwin distro which works around the missing pieces in 1.0.2 in a certain way, and changing the 1.0.2 branch now would break the build scripts for the Cygwin distro. I would very much prefer if people interested in OpenSSL 1.0.2 for Cygwin would use the openssl-1.0.2 source archive, which cotains all patches required for Cygwin, as well as the cygport build script to build openssl exactly the same way as in the Cygwin distro. Please let's not break that and stick to the master branch for the build system changes. Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From levitte at openssl.org Mon Feb 22 17:43:38 2016 From: levitte at openssl.org (Richard Levitte) Date: Mon, 22 Feb 2016 18:43:38 +0100 (CET) Subject: [openssl-dev] [openssl.org #4326] Failed to configure for Cygwin-x64 In-Reply-To: <20160222173404.GB11853@calimero.vinschen.de> References: <20160222173404.GB11853@calimero.vinschen.de> Message-ID: <20160222.184338.2013463692174692308.levitte@openssl.org> In message <20160222173404.GB11853 at calimero.vinschen.de> on Mon, 22 Feb 2016 18:34:04 +0100, Corinna Vinschen said: vinschen> On Feb 21 06:27, Richard Levitte via RT wrote: vinschen> > I believe that the auto-detecting script, ./config, is lacking detection of vinschen> > architecture for Cygwin. Does one preferably recognise a x86_64 Cygwin from vinschen> > `uname -m` or is there something in `uname -s` that should be used as an vinschen> > indicator? vinschen> vinschen> Uh oh, is there a chance that the configury for 1.0.2 is NOT changed vinschen> anymore? We have a set of local patches in the Cygwin distro which vinschen> works around the missing pieces in 1.0.2 in a certain way, and changing vinschen> the 1.0.2 branch now would break the build scripts for the Cygwin distro. A patch that fixes ./config was merged to the 1.0.2 branch earlier today. Commit 5c57fbb8ca991e8db7ce23174613898a27ca3fcb. It's a backport of the corresponding patch in master. It's a very small change, I'd be surprised if you can't edit that particular one from your scripts. 1.0.2 is on long term support, see http://openssl.org/policies/releasestrat.html. That means that reasonable fixes might very well go in. Sorry if that becomes a bother. -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From vinschen at redhat.com Mon Feb 22 18:00:08 2016 From: vinschen at redhat.com (Corinna Vinschen) Date: Mon, 22 Feb 2016 19:00:08 +0100 Subject: [openssl-dev] [openssl.org #4326] Failed to configure for Cygwin-x64 In-Reply-To: <20160222.184338.2013463692174692308.levitte@openssl.org> References: <20160222173404.GB11853@calimero.vinschen.de> <20160222.184338.2013463692174692308.levitte@openssl.org> Message-ID: <20160222180008.GA31724@calimero.vinschen.de> On Feb 22 18:43, Richard Levitte wrote: > In message <20160222173404.GB11853 at calimero.vinschen.de> on Mon, 22 Feb 2016 18:34:04 +0100, Corinna Vinschen said: > > vinschen> On Feb 21 06:27, Richard Levitte via RT wrote: > vinschen> > I believe that the auto-detecting script, ./config, is lacking detection of > vinschen> > architecture for Cygwin. Does one preferably recognise a x86_64 Cygwin from > vinschen> > `uname -m` or is there something in `uname -s` that should be used as an > vinschen> > indicator? > vinschen> > vinschen> Uh oh, is there a chance that the configury for 1.0.2 is NOT changed > vinschen> anymore? We have a set of local patches in the Cygwin distro which > vinschen> works around the missing pieces in 1.0.2 in a certain way, and changing > vinschen> the 1.0.2 branch now would break the build scripts for the Cygwin distro. > > A patch that fixes ./config was merged to the 1.0.2 branch earlier > today. Commit 5c57fbb8ca991e8db7ce23174613898a27ca3fcb. It's a > backport of the corresponding patch in master. It's a very small > change, I'd be surprised if you can't edit that particular one from > your scripts. This one's no problem since the build script runs ./Configure directly. > 1.0.2 is on long term support, see > http://openssl.org/policies/releasestrat.html. That means that > reasonable fixes might very well go in. Sorry if that becomes a > bother. It's not a bother per se, only changes in the build system are potentially disruptive, that's why I really dread them for the branch. OTOH, is it much of a problem to apply the patches used for the Cygwin distro into the 1.0.2 branch so we can get rid of them entirely? That would be extremly cool. I attached them for your review. Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat -------------- next part -------------- --- origsrc/openssl-1.0.2a/Configure 2015-03-19 16:08:33.952761607 +0100 +++ src/openssl-1.0.2a/Configure 2015-03-19 16:14:46.061816093 +0100 @@ -588,8 +588,8 @@ my %table=( "UWIN", "cc:-DTERMIOS -DL_ENDIAN -O -Wall:::UWIN::BN_LLONG ${x86_gcc_des} ${x86_gcc_opts}:${no_asm}:win32", # Cygwin -"Cygwin", "gcc:-DTERMIOS -DL_ENDIAN -fomit-frame-pointer -O3 -march=i486 -Wall:::CYGWIN::BN_LLONG ${x86_gcc_des} ${x86_gcc_opts}:${x86_asm}:coff:dlfcn:cygwin-shared:-D_WINDLL:-shared:.dll.a", -"Cygwin-x86_64", "gcc:-DTERMIOS -DL_ENDIAN -O3 -Wall:::CYGWIN::SIXTY_FOUR_BIT_LONG RC4_CHUNK DES_INT DES_UNROLL:${x86_64_asm}:mingw64:dlfcn:cygwin-shared:-D_WINDLL:-shared:.dll.a", +"Cygwin", "gcc:\$(OPT_CFLAGS) -DTERMIOS -DL_ENDIAN -fomit-frame-pointer -O3 -march=i686 -Wall:::CYGWIN::BN_LLONG ${x86_gcc_des} ${x86_gcc_opts}:${x86_asm}:coff:dlfcn:cygwin-shared:-D_WINDLL:-shared:.dll.a", +"Cygwin-x86_64", "gcc:\$(OPT_CFLAGS) -DTERMIOS -DL_ENDIAN -O3 -Wall:::CYGWIN::SIXTY_FOUR_BIT_LONG RC4_CHUNK DES_INT DES_UNROLL:${x86_64_asm}:mingw64:dlfcn:cygwin-shared:-D_WINDLL:-shared:.dll.a", # NetWare from David Ward (dsward at novell.com) # requires either MetroWerks NLM development tools, or gcc / nlmconv --- origsrc/openssl-1.0.2a/Makefile.shared 2015-03-19 16:14:57.245727560 +0100 +++ src/openssl-1.0.2a/Makefile.shared 2015-03-19 16:15:45.514345456 +0100 @@ -272,7 +272,7 @@ link_o.cygwin: SHLIB_SOVER=${LIBVERSION:+"-$(LIBVERSION)"}; \ ALLSYMSFLAGS='-Wl,--whole-archive'; \ NOALLSYMSFLAGS='-Wl,--no-whole-archive'; \ - SHAREDFLAGS="$(CFLAGS) $(SHARED_LDFLAGS) -shared $$base $$deffile -Wl,-s,-Bsymbolic"; \ + SHAREDFLAGS="$(CFLAGS) $(SHARED_LDFLAGS) -shared $$base $$deffile -Wl,-Bsymbolic"; \ $(LINK_SO_O) #for mingw target if def-file is in use dll-name should match library-name link_a.cygwin: @@ -297,7 +297,7 @@ link_a.cygwin: extras="$$extras rc.o"; \ ALLSYMSFLAGS='-Wl,--whole-archive'; \ NOALLSYMSFLAGS='-Wl,--no-whole-archive'; \ - SHAREDFLAGS="$(CFLAGS) $(SHARED_LDFLAGS) -shared $$base -Wl,-s,-Bsymbolic -Wl,--out-implib,lib$(LIBNAME).dll.a $$extras"; \ + SHAREDFLAGS="$(CFLAGS) $(SHARED_LDFLAGS) -shared $$base -Wl,-Bsymbolic -Wl,--out-implib,lib$(LIBNAME).dll.a $$extras"; \ [ -f apps/$$dll_name ] && rm apps/$$dll_name; \ [ -f test/$$dll_name ] && rm test/$$dll_name; \ $(LINK_SO_A) || exit 1; \ -------------- next part -------------- diff -up openssl-1.0.2a/Configure.enginesdir openssl-1.0.2a/Configure --- openssl-1.0.2a/Configure.enginesdir 2015-04-20 14:37:58.137392222 +0200 +++ openssl-1.0.2a/Configure 2015-04-20 14:37:58.140392292 +0200 @@ -702,6 +702,7 @@ my $idx_multilib = $idx++; my $prefix=""; my $libdir=""; my $openssldir=""; +my $enginesdir=""; my $exe_ext=""; my $install_prefix= "$ENV{'INSTALL_PREFIX'}"; my $cross_compile_prefix=""; @@ -929,6 +930,10 @@ PROCESS_ARGS: { $openssldir=$1; } + elsif (/^--enginesdir=(.*)$/) + { + $enginesdir=$1; + } elsif (/^--install.prefix=(.*)$/) { $install_prefix=$1; @@ -1185,7 +1190,7 @@ chop $prefix if $prefix =~ /.\/$/; $openssldir=$prefix . "/ssl" if $openssldir eq ""; $openssldir=$prefix . "/" . $openssldir if $openssldir !~ /(^\/|^[a-zA-Z]:[\\\/])/; - +$enginesdir="$prefix/lib/engines" if $enginesdir eq ""; print "IsMK1MF=$IsMK1MF\n"; @@ -1871,7 +1876,7 @@ while () } elsif (/^#define\s+ENGINESDIR/) { - my $foo = "$prefix/$libdir/engines"; + my $foo = "$enginesdir"; $foo =~ s/\\/\\\\/g; print OUT "#define ENGINESDIR \"$foo\"\n"; } diff -up openssl-1.0.2a/engines/Makefile.enginesdir openssl-1.0.2a/engines/Makefile --- openssl-1.0.2a/engines/Makefile.enginesdir 2015-04-20 14:37:58.140392292 +0200 +++ openssl-1.0.2a/engines/Makefile 2015-04-20 14:40:15.570598383 +0200 @@ -124,7 +124,7 @@ install: esac; \ cp $$pfx$$l$$sfx $(INSTALL_PREFIX)$(INSTALLTOP)/$(LIBDIR)/engines/$$pfx$$l$$sfx.new; \ fi; \ - chmod 555 $(INSTALL_PREFIX)$(INSTALLTOP)/$(LIBDIR)/engines/$$pfx$$l$$sfx.new; \ + chmod 755 $(INSTALL_PREFIX)$(INSTALLTOP)/$(LIBDIR)/engines/$$pfx$$l$$sfx.new; \ mv -f $(INSTALL_PREFIX)$(INSTALLTOP)/$(LIBDIR)/engines/$$pfx$$l$$sfx.new $(INSTALL_PREFIX)$(INSTALLTOP)/$(LIBDIR)/engines/$$pfx$$l$$sfx ); \ done; \ fi -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From levitte at openssl.org Mon Feb 22 18:01:58 2016 From: levitte at openssl.org (Richard Levitte) Date: Mon, 22 Feb 2016 19:01:58 +0100 (CET) Subject: [openssl-dev] [openssl.org #4326] Failed to configure for Cygwin-x64 In-Reply-To: <20160222180008.GA31724@calimero.vinschen.de> References: <20160222173404.GB11853@calimero.vinschen.de> <20160222.184338.2013463692174692308.levitte@openssl.org> <20160222180008.GA31724@calimero.vinschen.de> Message-ID: <20160222.190158.920273727508356313.levitte@openssl.org> In message <20160222180008.GA31724 at calimero.vinschen.de> on Mon, 22 Feb 2016 19:00:08 +0100, Corinna Vinschen said: vinschen> OTOH, is it much of a problem to apply the patches used for the Cygwin vinschen> distro into the 1.0.2 branch so we can get rid of them entirely? That vinschen> would be extremly cool. I attached them for your review. I can at least look at them and make a judgement. -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From steve at openssl.org Mon Feb 22 18:58:29 2016 From: steve at openssl.org (Dr. Stephen Henson) Date: Mon, 22 Feb 2016 18:58:29 +0000 Subject: [openssl-dev] OpenSSL 1.1.0 and FIPS In-Reply-To: <401084E5E73F4241A44F3C9E6FD79428036870CEDA@exch-01> References: <401084E5E73F4241A44F3C9E6FD79428036870CEDA@exch-01> Message-ID: <20160222185829.GA19490@openssl.org> On Mon, Feb 22, 2016, Wall, Stephen wrote: > I wonder if I could get the thoughts of some of you developers on how > difficult it would be to build an engine for OpenSSL 1.1.0 that makes use of > the current (2.0.11?) fipscanister.o. Also, opinions on if this would be a > legitimate way to get FIPS in 1.1.0. > Just to add a few thoughts to this. It would be very tricky and rather messy. The 2.0.x module uses various shortcuts (which were pretty much essential given the time pressure on its development) such as keeping structure compatible with OpenSSL. For 1.1.0 many structures have changed considerably and many are opaque so this wont work. Add to that that it isn't just a case of having an external ENGINE. There needs to be some extensive glue code in OpenSSL itself to (for example) ensure that the correct imeplementation is used and to block unapproved APIs and algorithms. So while I think it is theoretically possible I think handling this as part of a new validation effort would be the best approach. We could then incorporate some of the new FIPS 140-2 requirements and add some new algorithms. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From levitte at openssl.org Mon Feb 22 19:18:53 2016 From: levitte at openssl.org (Richard Levitte) Date: Mon, 22 Feb 2016 20:18:53 +0100 (CET) Subject: [openssl-dev] OpenSSL 1.1.0 and FIPS In-Reply-To: <20160222185829.GA19490@openssl.org> References: <401084E5E73F4241A44F3C9E6FD79428036870CEDA@exch-01> <20160222185829.GA19490@openssl.org> Message-ID: <20160222.201853.66734063985503887.levitte@openssl.org> In message <20160222185829.GA19490 at openssl.org> on Mon, 22 Feb 2016 18:58:29 +0000, "Dr. Stephen Henson" said: steve> On Mon, Feb 22, 2016, Wall, Stephen wrote: steve> steve> > I wonder if I could get the thoughts of some of you developers on how steve> > difficult it would be to build an engine for OpenSSL 1.1.0 that makes use of steve> > the current (2.0.11?) fipscanister.o. Also, opinions on if this would be a steve> > legitimate way to get FIPS in 1.1.0. steve> > steve> steve> Just to add a few thoughts to this. steve> steve> It would be very tricky and rather messy. The 2.0.x module uses various steve> shortcuts (which were pretty much essential given the time pressure on its steve> development) such as keeping structure compatible with OpenSSL. For 1.1.0 many steve> structures have changed considerably and many are opaque so this wont work. steve> steve> Add to that that it isn't just a case of having an external ENGINE. There steve> needs to be some extensive glue code in OpenSSL itself to (for example) ensure steve> that the correct imeplementation is used and to block unapproved APIs and steve> algorithms. steve> steve> So while I think it is theoretically possible I think handling this as part of steve> a new validation effort would be the best approach. We could then incorporate steve> some of the new FIPS 140-2 requirements and add some new algorithms. This is where I go dreamy eyed with a desire to make all our built in algorithm into an engine, loadable like any other engine. The current retrofit we do because we want to support having the low level functions as dispatchers into a loaded engine still gives me the heeby jeebies. With that kind of setup, wouldn't it be incredibly easy to have the approved FIPS 140-2 engine? (if this ever happens, it's in the far future, folks) -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From tshort at akamai.com Mon Feb 22 20:07:52 2016 From: tshort at akamai.com (Short, Todd) Date: Mon, 22 Feb 2016 20:07:52 +0000 Subject: [openssl-dev] RT4265 no-srtp still broken Message-ID: <8EEA10E8-1631-4884-8B91-F657AAD945D0@akamai.com> Configuring the master branch with no-srtp is still broken. This PR: https://github.com/openssl/openssl/pull/582 fixes it. Its a bit out of date, but there shouldn?t be any conflicts. -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." -------------- next part -------------- An HTML attachment was scrubbed... URL: From marquess at openssl.com Mon Feb 22 20:22:36 2016 From: marquess at openssl.com (Steve Marquess) Date: Mon, 22 Feb 2016 15:22:36 -0500 Subject: [openssl-dev] OpenSSL 1.1.0 and FIPS In-Reply-To: <20160222185829.GA19490@openssl.org> References: <401084E5E73F4241A44F3C9E6FD79428036870CEDA@exch-01> <20160222185829.GA19490@openssl.org> Message-ID: <56CB6E0C.3000004@openssl.com> On 02/22/2016 01:58 PM, Dr. Stephen Henson wrote: > On Mon, Feb 22, 2016, Wall, Stephen wrote: > >> I wonder if I could get the thoughts of some of you developers on how >> difficult it would be to build an engine for OpenSSL 1.1.0 that makes use of >> the current (2.0.11?) fipscanister.o. Also, opinions on if this would be a >> legitimate way to get FIPS in 1.1.0. >> > > Just to add a few thoughts to this. > > It would be very tricky and rather messy. The 2.0.x module uses various > shortcuts (which were pretty much essential given the time pressure on its > development) such as keeping structure compatible with OpenSSL. For 1.1.0 many > structures have changed considerably and many are opaque so this wont work. > > Add to that that it isn't just a case of having an external ENGINE. There > needs to be some extensive glue code in OpenSSL itself to (for example) ensure > that the correct imeplementation is used and to block unapproved APIs and > algorithms. > ... This last point is worth emphasizing. While the formal FIPS validation is more or less done in a vacuum (or perhaps I should say "reality independent context"), it has to be used in a real world setting with application code (probably legacy code developed to use stock OpenSSL). That means a) using it with OpenSSL, because the FIPS module alone is too impoverished an API for direct use, and b) making sure your application does only FIPS allowed cryptography while FIPS mode is enabled. That latter step is a lot harder than it looks. While some vendors won't care as long as they have some minimal level of buzzword compliance, some do. With the "FIPS enabled" OpenSSL converting your existing application for FIPS 140-2 can be as simple as throwing in a FIPS_mode_set() call. With a stock OpenSSL and hand-jammed FIPS module you'd need to manually vet all application code; the stock OpenSSL won't let you know when your application uses non-allowed cryptography. -Steve M. -- Steve Marquess OpenSSL Validation Services, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From rt at openssl.org Mon Feb 22 20:51:49 2016 From: rt at openssl.org (Roumen Petrov via RT) Date: Mon, 22 Feb 2016 20:51:49 +0000 Subject: [openssl-dev] [openssl.org #4320] [Patch] OpenSSL 1.1.0-pre3: "unable to load Key" error in PEM_get_EVP_CIPHER_INFO() In-Reply-To: <56CB74DB.1000401@roumenpetrov.info> References: <56C4BA0E.7090603@kippdata.de> <56CB74DB.1000401@roumenpetrov.info> Message-ID: Hi Rich, Rich Salz via RT wrote: > fixed in commit 985c3146967633707f7c165df82bb0fd8f279758 thanks for the report! From initial patch is missing line with header += 9. Please could you review parsing with ENCRYPTED Roumen -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4320 Please log in as guest with password guest if prompted -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-4320-OpenSSL-1.1.0-pre3-unable-to-load-Key-error-in-.patch Type: text/x-diff Size: 1181 bytes Desc: not available URL: From jaroslav.imrich at gmail.com Mon Feb 22 21:02:03 2016 From: jaroslav.imrich at gmail.com (Jaroslav Imrich) Date: Mon, 22 Feb 2016 22:02:03 +0100 Subject: [openssl-dev] OpenSSL 1.1.0 and FIPS In-Reply-To: <20160222.201853.66734063985503887.levitte@openssl.org> References: <401084E5E73F4241A44F3C9E6FD79428036870CEDA@exch-01> <20160222185829.GA19490@openssl.org> <20160222.201853.66734063985503887.levitte@openssl.org> Message-ID: On 22 February 2016 at 20:18, Richard Levitte wrote: > > This is where I go dreamy eyed with a desire to make all our built in > algorithm into an engine, loadable like any other engine. I have never tried such setup but this sounds like SoftHSM2 [0] with OpenSSL crypto backend loaded by OpenSSL via engine_pkcs11 [1]. [0] https://github.com/opendnssec/SoftHSMv2 [1] https://github.com/OpenSC/engine_pkcs11 Regards, Jaroslav -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Mon Feb 22 21:21:14 2016 From: rt at openssl.org (Kaduk, Ben via RT) Date: Mon, 22 Feb 2016 21:21:14 +0000 Subject: [openssl-dev] [openssl.org #4335] ix 'assignment from incompatible type' warning in OBJ_NAME_new_index() In-Reply-To: <56CB7BC7.1080103@akamai.com> References: <1456160635.4735.302.camel@infradead.org> <56CB7BC7.1080103@akamai.com> Message-ID: On 02/22/2016 11:04 AM, David Woodhouse via RT wrote: > We are using OPENSSL_strcmp() as the cmp_func, where cmp_func takes > a pair of (void *) pointers, not (char *). Which is fine; we know we're > going to pass it strings in this case. So explicitly cast it to avoid > the resulting compiler warning. > --- > crypto/objects/o_names.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/crypto/objects/o_names.c b/crypto/objects/o_names.c > index 0a07379..1f9f10a 100644 > --- a/crypto/objects/o_names.c > +++ b/crypto/objects/o_names.c > @@ -83,7 +83,7 @@ int OBJ_NAME_new_index(unsigned long (*hash_func) (const char *), > return (0); > } > name_funcs->hash_func = lh_strhash; > - name_funcs->cmp_func = OPENSSL_strcmp; > + name_funcs->cmp_func = (void *)OPENSSL_strcmp; > CRYPTO_mem_ctrl(CRYPTO_MEM_CHECK_DISABLE); > sk_NAME_FUNCS_push(name_funcs_stack, name_funcs); > CRYPTO_mem_ctrl(CRYPTO_MEM_CHECK_ENABLE); > Er, where is the cmp_func that is supposed to take void* pointers? In master:crypto/objects/o_names.c I see the name_funcs_st with a member "int (*cmp_func) (const char *a, const char *b);" (Also, strict C forbids inter-casting between function pointers and void*, so a cast of (int (*)(void *,void *)) would seem more appropriate for the stated goal.) -Ben -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4335 Please log in as guest with password guest if prompted From rt at openssl.org Mon Feb 22 22:26:56 2016 From: rt at openssl.org (David Benjamin via RT) Date: Mon, 22 Feb 2016 22:26:56 +0000 Subject: [openssl-dev] [openssl.org #4323] chacha-armv4.pl bugs In-Reply-To: References: <56CA1DC3.1070501@openssl.org> Message-ID: On Sun, Feb 21, 2016 at 3:27 PM Andy Polyakov via RT wrote: > Hi, > > > The partial-block tail code in chacha-armv4.pl also seems to have > problems. > > My colleague Steven and I made an attempt to debug it, but we're not > > familiar enough with ARM to fix it. > > > > From playing with it in a debugger, it doesn't look like @t[3] contains > the > > length. We suspect something is going wrong with the condition flags on > > loading or updating length. > > > https://git.openssl.org/gitweb/?p=openssl.git;a=blob;f=crypto/chacha/asm/chacha-armv4.pl;h=55ebc9e586475a35e313b74483eb4b8d5b6f2b03;hb=HEAD#l585 > > Attached is patch for chacha-armv4.pl (please verify) and a test snippet > I've put together. > The fix seems to work. And it's a decent bit faster than our current NEON code too. :-) Thanks! > > It may be worth going back and testing these cases on all of the > > implementations as well. > > Besides armv4 only s390x module was failing. > Can confirm that the armv8 code is fine. David -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4323 Please log in as guest with password guest if prompted From rt at openssl.org Mon Feb 22 22:39:44 2016 From: rt at openssl.org (Andy Polyakov via RT) Date: Mon, 22 Feb 2016 22:39:44 +0000 Subject: [openssl-dev] [openssl.org #4323] chacha-armv4.pl bugs In-Reply-To: <56CB8E30.5060105@openssl.org> References: <56CA1DC3.1070501@openssl.org> <56CB8E30.5060105@openssl.org> Message-ID: > The fix seems to work. On related note, a problem was reported with poly1305-armv4 module, which was traced down to assembler (different versions disagree about how to treat #-1 as argument to vmov.i64). If you run into problem, don't panic, fix is upcoming... -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4323 Please log in as guest with password guest if prompted From bill at thebiermans.org Tue Feb 23 00:19:15 2016 From: bill at thebiermans.org (Bill Bierman) Date: Mon, 22 Feb 2016 14:19:15 -1000 Subject: [openssl-dev] MSVC 2015 internal compiler error Message-ID: Hello. I'm sorry I cannot reply to the thread. I only just now have subscribed to the list. I can confirm that this problem exists with Visual Studio 2015 on HEAD. I spoke to a friend of mine who works at MS who relayed this to the compiler team. A senior dev there is aware of the issue and they are working on a fix. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at thebiermans.org Tue Feb 23 01:55:12 2016 From: bill at thebiermans.org (Bill Bierman) Date: Mon, 22 Feb 2016 15:55:12 -1000 Subject: [openssl-dev] MSVC 2015 internal compiler error In-Reply-To: References: Message-ID: The Microsoft compiler team has suggested removing the include of ssl.h from srtp.h as it creates a circular reference which is likely confusing the compiler. On Mon, Feb 22, 2016 at 2:19 PM, Bill Bierman wrote: > Hello. I'm sorry I cannot reply to the thread. I only just now have > subscribed to the list. > > I can confirm that this problem exists with Visual Studio 2015 on HEAD. > > I spoke to a friend of mine who works at MS who relayed this to the > compiler team. A senior dev there is aware of the issue and they are > working on a fix. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Tue Feb 23 02:13:57 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 23 Feb 2016 02:13:57 +0000 Subject: [openssl-dev] MSVC 2015 internal compiler error In-Reply-To: References: Message-ID: <20160223021357.GJ12869@mournblade.imrryr.org> On Mon, Feb 22, 2016 at 03:55:12PM -1000, Bill Bierman wrote: > The Microsoft compiler team has suggested removing the include of ssl.h > from srtp.h as it creates a circular reference which is likely confusing > the compiler. Could you test the patch below. It tries to avoid incompatible loss of the implicit inclusion, by making it conditional: -- Viktor. diff --git a/include/openssl/ssl.h b/include/openssl/ssl.h index 9709103..ee61451 100644 --- a/include/openssl/ssl.h +++ b/include/openssl/ssl.h @@ -901,7 +901,9 @@ __owur int SSL_extension_supported(unsigned int ext_type); # include # include /* This is mostly sslv3 with a few tweaks */ # include /* Datagram TLS */ -# include /* Support for the use_srtp extension */ +# ifndef HEADER_D1_SRTP_H +# include /* Support for the use_srtp extension */ +# endif #ifdef __cplusplus extern "C" { From gvanem at yahoo.no Tue Feb 23 09:12:03 2016 From: gvanem at yahoo.no (Gisle Vanem) Date: Tue, 23 Feb 2016 10:12:03 +0100 Subject: [openssl-dev] MSVC 2015 internal compiler error In-Reply-To: <20160223021357.GJ12869@mournblade.imrryr.org> References: <20160223021357.GJ12869@mournblade.imrryr.org> Message-ID: <56CC2263.9040409@yahoo.no> Viktor Dukhovni wrote: > On Mon, Feb 22, 2016 at 03:55:12PM -1000, Bill Bierman wrote: > >> The Microsoft compiler team has suggested removing the include of ssl.h >> from srtp.h as it creates a circular reference which is likely confusing >> the compiler. > > Could you test the patch below. It tries to avoid incompatible > loss of the implicit inclusion, by making it conditional: Nice try, but your patch doesn't help here: F:\MingW32\src\inet\Crypto\OpenSSL\ssl\s3_lib.c : fatal error C1001: An internal error has occurred in the compiler. (compiler file 'f:\dd\vctools\compiler\utc\src\p2\main.c', line 246) To work around this problem, try simplifying or changing the program near the locations listed above. Please choose the Technical Support command on the Visual C++ Help menu, or open the Technical Support help file for more information INTERNAL COMPILER ERROR in 'f:\gv\VC_2015\bin\cl.exe' Please choose the Technical Support command on the Visual C++ Help menu, or open the Technical Support help file for more information ------------ BTW1, using '-DOPENSSL_NO_SRTP' doesn't fix this. One of the .h-files seems to trigger this fault (no option I've tried so far has prevent it). BTW2, I get a lot of these warnings: include\openssl/lhash.h(270): warning C4090: 'function': different 'const' qualifiers which seems related to include/openssl/lhash.h: typedef const char *OPENSSL_CSTRING; or one of the hideous lhash.h/safestack.h macros (?!) And I'm still using this cl: Microsoft (R) C/C++ Optimizing Compiler Version 19.00.23506 for x86 on Win-10. -- --gv From nmav at redhat.com Tue Feb 23 10:15:23 2016 From: nmav at redhat.com (Nikos Mavrogiannopoulos) Date: Tue, 23 Feb 2016 11:15:23 +0100 Subject: [openssl-dev] Ubsec and Chil engines In-Reply-To: References: <56C6FCFA.4040602@openssl.org> <5B8F45EA-5867-4832-916A-6B31A323A59C@temme.net> <1456136196.3289.26.camel@redhat.com> Message-ID: <1456222523.11980.8.camel@redhat.com> On Mon, 2016-02-22 at 15:08 +0100, Jaroslav Imrich wrote: > On 22 February 2016 at 11:16, Nikos Mavrogiannopoulos m> wrote: > > ?That's an implementation detail. As far as I know engine_pkcs11 > > does not require re-authentication after fork. It handles the > > pkcs11 peculiarities internally. > AFAIK this works by caching the PIN in engine_pkcs11 internally and > is OK for most of the use cases with smartcards. However HSMs usually > use more complex authentication schemes where this approach does not > work i.e. in order to login there must be N of M physical > tokens/cards with passwords presented in a sequence (requires vendor > specific extensions when used via PKCS#11). CHIL engine already > handles such schemes very well and does not need to reauthenticate > after fork. I find that discussion more suitable to the PKCS #11 working group than here. It cannot be solved by openssl devevlopers. In any case, I don't find the solution to any problem in a standardized API is "let's make our own better API". Why not work towards fixing the PKCS #11 spec? In any case, there _are_ PKCS #11 modules which continue working after fork (opendnssec's softhsm for example). So the issue is not something that cannot be addressed within PKCS #11. regards, Nikos From noloader at gmail.com Tue Feb 23 11:28:20 2016 From: noloader at gmail.com (Jeffrey Walton) Date: Tue, 23 Feb 2016 06:28:20 -0500 Subject: [openssl-dev] MSVC 2015 internal compiler error In-Reply-To: <56CC2263.9040409@yahoo.no> References: <20160223021357.GJ12869@mournblade.imrryr.org> <56CC2263.9040409@yahoo.no> Message-ID: > ... > F:\MingW32\src\inet\Crypto\OpenSSL\ssl\s3_lib.c : > fatal error C1001: An internal error has occurred in the compiler. > (compiler file 'f:\dd\vctools\compiler\utc\src\p2\main.c', line 246) > To work around this problem, try simplifying or changing the program near the locations listed above. > Please choose the Technical Support command on the Visual C++ > Help menu, or open the Technical Support help file for more information > > INTERNAL COMPILER ERROR in 'f:\gv\VC_2015\bin\cl.exe' > Please choose the Technical Support command on the Visual C++ > Help menu, or open the Technical Support help file for more information I've seen these mystery breaks quite a few times under the VS compilers. Mostly it was the old days of VC++ 5.0 and 6.0, but they crop up on occasion. As crazy as it sounds, you might try re-ordering functions in the headers and source files. That is, if the order is: void fn1(...) { ... } void fn2(...) { ... } void fn3(...) { ... } Then try: void fn3(...) { ... } void fn1(...) { ... } void fn2(...) { ... } I don't know why it works on occasion. Jeff From dwmw2 at infradead.org Tue Feb 23 12:13:57 2016 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 23 Feb 2016 12:13:57 +0000 Subject: [openssl-dev] Ubsec and Chil engines In-Reply-To: <347004c001fd430aadadceac908e68a2@ustx2ex-dag1mb1.msg.corp.akamai.com> References: <56C6FCFA.4040602@openssl.org> <5B8F45EA-5867-4832-916A-6B31A323A59C@temme.net> <20160220.225541.1585601945103016062.levitte@openssl.org> <1456140741.4735.272.camel@infradead.org> <347004c001fd430aadadceac908e68a2@ustx2ex-dag1mb1.msg.corp.akamai.com> Message-ID: <1456229637.4735.382.camel@infradead.org> On Mon, 2016-02-22 at 14:46 +0000, Salz, Rich wrote: > > If we integrate the support natively into OpenSSL, then PKCS#11 URIs (see > > RFC7512) can be first-class citizens throughout the crypto and SSL APIs. Any > > function which takes a filename for a cert or key should also accept? a > > PKCS#11 URI. > > It'd be great to see a crypto/pkcs11 directory with full native support (as much as possible). > > But really doubtful to happen in 1.1 as the API freeze is in a month. Sure, it'd be insane to target 1.1.... well, except that libp11 is basically *designed* to be dropped into crypto/pkcs11 except for being under the LGPL. And its original author has already agreed to relicense it more sensibly. But yeah ? realistically speaking, we are talking about 1.2 (or whatever comes next). We have libp11+engine_pkcs11 for now. I absolutely don't want to waste the effort though, so seeing you say things like "it'd be great to have" is actually really useful. So let me outline the plan a little bit and see if you still think it's a good idea... I was intending to use libp11-kit for the basic PKCS#11 module enumeration and handling. On the *nix platforms where PKCS#11 is most important, p11-kit is fairly much ubiquitous. Obviously the code would be designed such that if someone really wants to eliminate that requirement, they could reimplement all the things that libp11-kit gives us and make it a build-time option. But seriously, why would you? I'd start by throwing together the code to implement the various EVP_PKEY types work based on PKCS#11 calls, and then look at Richard's STORE code and how we'd want to tie that in with the use of PKCS#11 URIs to identify objects. If other libp11 contributors are happy to relicense, that means I can lift big chunks of code from there. Otherwise I get to reinvent the wheel. -- David Woodhouse Open Source Technology Centre David.Woodhouse at intel.com Intel Corporation -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5691 bytes Desc: not available URL: From dwmw2 at infradead.org Tue Feb 23 12:54:28 2016 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 23 Feb 2016 12:54:28 +0000 Subject: [openssl-dev] Ubsec and Chil engines In-Reply-To: References: <56C6FCFA.4040602@openssl.org> <1455887024.912.17.camel@redhat.com> <56C714BC.3060307@openssl.org> <1455893619.3919.62.camel@redhat.com> <1456139532.4735.266.camel@infradead.org> Message-ID: <1456232068.4735.397.camel@infradead.org> On Mon, 2016-02-22 at 15:59 +0000, Blumenthal, Uri - 0553 - MITLL wrote: > On 2/22/16, 6:12 , "openssl-dev on behalf of David Woodhouse" > wrote: > > > > It may even be better, instead of pushing for different engines for > > > different hardware, to make PKCS#11 the only API used to talk to > > > hardware. There is a quite functional (and active as project) pkcs11 > > > engine for openssl [0]. > > > > Agreed. With the caveat that I *really* want libp11 and engine_pkcs11 > > to die, and be replaced by native code in openssl/crypto/pkcs11/ > > Would you mind explaining what you mean by ?native code? that presumably > could replace the current libp11, and who in your opinion would support it? Really, I mean "code within OpenSSL itself". In an ideal world, that might actually *be* libp11, which is basically written as if it resides in openssl/crypto/pkcs11/ already ? except for its licence (qv). So "die and be replaced by" would be the wrong wording for me to have used. I want libp11 to stop being a *separate* project. In particular ? if I pick some random OpenSSL-using application, like wpa_supplicant, and pass it a PKCs#11 URI instead of a filename as the certificate/key, then I want it to Just Work? through the normal OpenSSL APIs, without the application author having to jump through additional hoops to *make* it work. (Note: the first part of that, "shall accept PKCS#11 URI in place of filename" is part of the Fedora packaging guidelines these days. It is expected that software packaged for Fedora SHOULD work that way. The second part, with normal OpenSSL APIs actually facilitating that improvement, is what we're talking about here.) As for who would work work on it... well, it would be part of an OpenSSL (1.2?) release, so the OpenSSL team would have a certain amount of responsibility for it. But I expect that anyone who has had an interest in libp11 in the days *before* OpenSSL 1.2 would continue to have contributions for crypto/pkcs11/ in OpenSSL 1.2 onwards. As well as *more* interest especially from the Linux distribution side, once we make it possible to have coherent CA trust settings across the distribution by having the trust database in PKCS#11, etc. In fact, libp11 wasn't seeing a huge amount of development work before people started adding EC support to it, was it? Other than keeping it up to date with OpenSSL releases, of course... I don't anticipate that it would be a large maintenance burden. -- David Woodhouse Open Source Technology Centre David.Woodhouse at intel.com Intel Corporation -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5691 bytes Desc: not available URL: From swall at redcom.com Tue Feb 23 13:16:04 2016 From: swall at redcom.com (Wall, Stephen) Date: Tue, 23 Feb 2016 08:16:04 -0500 Subject: [openssl-dev] OpenSSL 1.1.0 and FIPS In-Reply-To: <56CB6E0C.3000004@openssl.com> References: <401084E5E73F4241A44F3C9E6FD79428036870CEDA@exch-01> <20160222185829.GA19490@openssl.org> <56CB6E0C.3000004@openssl.com> Message-ID: <401084E5E73F4241A44F3C9E6FD79428036870D131@exch-01> Thanks for the feedback, I was deliberately ignoring the issue of not running non-FIPS algos, there are actually instances where it's desirable to have access to them in FIPS mode (RADIUS, eg). A generic way to handle that (aside from Richards dream proposal) would be to have a NO_INTERNAL_ALGORITHMS setting somewhere in the API. Possibly split into NO_INTERNAL_SYMMETRIC_ALGOS, ASYMMETRIC, HASHES, etc, for finer grained control. Or even a bit per specific algo to go to the extreme. Probably too late to get something like that in for a 1.1.0 release...? As far as structure incompatibility, translation could be handled internally to the engine (though that would require a lot of near-duplicate structures). Feasible, maybe not practical. From rt at openssl.org Tue Feb 23 13:51:40 2016 From: rt at openssl.org (Hannes Magnusson via RT) Date: Tue, 23 Feb 2016 13:51:40 +0000 Subject: [openssl-dev] [openssl.org #4336] SSL_CTX_set_cipher_list man page links to 404 In-Reply-To: References: Message-ID: There is a link to "ciphers" from https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_set_cipher_list.html that leads to 404 page: https://www.openssl.org/docs/manmaster/ssl/ciphers.html This is linked twice from the page, once in the "see also", and once in the description "The format of the string is described in ciphers -Hannes -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4336 Please log in as guest with password guest if prompted From swall at redcom.com Tue Feb 23 13:55:00 2016 From: swall at redcom.com (Wall, Stephen) Date: Tue, 23 Feb 2016 08:55:00 -0500 Subject: [openssl-dev] OpenSSL 1.1.0 and FIPS In-Reply-To: <401084E5E73F4241A44F3C9E6FD79428036870D131@exch-01> References: <401084E5E73F4241A44F3C9E6FD79428036870CEDA@exch-01> <20160222185829.GA19490@openssl.org> <56CB6E0C.3000004@openssl.com> <401084E5E73F4241A44F3C9E6FD79428036870D131@exch-01> Message-ID: <401084E5E73F4241A44F3C9E6FD79428036870D17E@exch-01> > A generic > way to handle that (aside from Richards dream proposal) would be to > have a NO_INTERNAL_ALGORITHMS setting somewhere in the API. Possibly > split into NO_INTERNAL_SYMMETRIC_ALGOS, ASYMMETRIC, HASHES, etc, for > finer grained control. Replying to my own post, a second idea: what if the engine claims it can do all possible algorithms, but returns EVP_R_DISABLED_FOR_FIPS for the ones that FIPS does not allow? Would that be sufficient to prevent the core from trying to run any algorithms, or would the failure prompt a fallback to the internal code? From marquess at openssl.com Tue Feb 23 14:11:17 2016 From: marquess at openssl.com (Steve Marquess) Date: Tue, 23 Feb 2016 09:11:17 -0500 Subject: [openssl-dev] OpenSSL 1.1.0 and FIPS In-Reply-To: <401084E5E73F4241A44F3C9E6FD79428036870D131@exch-01> References: <401084E5E73F4241A44F3C9E6FD79428036870CEDA@exch-01> <20160222185829.GA19490@openssl.org> <56CB6E0C.3000004@openssl.com> <401084E5E73F4241A44F3C9E6FD79428036870D131@exch-01> Message-ID: <56CC6885.5010306@openssl.com> On 02/23/2016 08:16 AM, Wall, Stephen wrote: > Thanks for the feedback, I was deliberately ignoring the issue of not > running non-FIPS algos, there are actually instances where it's > desirable to have access to them in FIPS mode (RADIUS, eg). A > generic way to handle that (aside from Richards dream proposal) would > be to have a NO_INTERNAL_ALGORITHMS setting somewhere in the API. > Possibly split into NO_INTERNAL_SYMMETRIC_ALGOS, ASYMMETRIC, HASHES, > etc, for finer grained control. Or even a bit per specific algo to > go to the extreme. Probably too late to get something like that in > for a 1.1.0 release...? > > As far as structure incompatibility, translation could be handled > internally to the engine (though that would require a lot of > near-duplicate structures). Feasible, maybe not practical. Sufficient desperation and sufficiently deep pockets set the boundaries of "feasible". FIPS 140-2 isn't practical to begin with. I know of several commercial vendors planning to hand-jamb some variant of the current FIPS module into OpenSSL 1.1 (what they see as their least bad option). The result is going to be horrible, though, and will still require validation. It will leave them with a maintenance tail that will haunt them for years to come. I wish them luck, and understand that FIPS 140-2 is important enough to their business that they have no choice. But here at the OpenSSL project we've made the conscious decision to not allow FIPS 140-2 to distort and pervert OpenSSL even more than has already been the case. We'll do a (relatively) clean and sane implementation for 1.1 if and when we can, and nothing otherwise. -Steve M. -- Steve Marquess OpenSSL Validation Services, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From rt at openssl.org Tue Feb 23 14:45:04 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Tue, 23 Feb 2016 14:45:04 +0000 Subject: [openssl-dev] [openssl.org #4337] SEGV Fault in the DES_fcrypt In-Reply-To: References: Message-ID: From: Rafa? Buczko [mailto:rafal.buczko92 at gmail.com] Sent: Monday, February 22, 2016 8:45 PM To: openssl-security at openssl.org Subject: [openssl-security] SEGV Fault in the DES_fcrypt Hi :), There is a segmentation fault, in function DES_fcrypt (file: openssl/fcrypt.c:120) x = ret[0] = ((salt[0] == '\0') ? 'A' : salt[0]); Eswap0 = con_salt[x] << 2; x = ret[1] = ((salt[1] == '\0') ? 'A' : salt[1]); Eswap1 = con_salt[x] << 6; , which happens to happend when salt input string contains some unusual chars like ?, ? ... (char values from 128 to 255) OS: Ubuntu 15.10 x86_64 Code: #include int main() { char ret_buff[14]; //char *DES_fcrypt(const char *buf, const char *salt, char *ret) DES_fcrypt("bca76;23", "??", ret_buff); return 0; } This is my first report, so please be understanding about any incomprehension. Best Regards Rafal :). -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4337 Please log in as guest with password guest if prompted From rt at openssl.org Tue Feb 23 14:53:55 2016 From: rt at openssl.org (J Mohan Rao Arisankala via RT) Date: Tue, 23 Feb 2016 14:53:55 +0000 Subject: [openssl-dev] [openssl.org #4338] master: allocating memory for an unused variable in tls1_export_keying_material In-Reply-To: References: Message-ID: Hi, In tls1_export_keying_material(), memory was getting allocated for an unused variable. I have removed this unused code in the below pull request, please have a look. https://github.com/openssl/openssl/pull/735 Thanks, Mohan -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4338 Please log in as guest with password guest if prompted From rt at openssl.org Tue Feb 23 15:08:02 2016 From: rt at openssl.org (David Woodhouse via RT) Date: Tue, 23 Feb 2016 15:08:02 +0000 Subject: [openssl-dev] [openssl.org #4339] [PATCH] Fix handling of in UEFI build In-Reply-To: <1456240073.4735.411.camel@infradead.org> References: <1456240073.4735.411.camel@infradead.org> Message-ID: The entire contents of are unwanted in the UEFI build because we have to do it differently there. To support building for both 32-bit and 64-bit platforms without re-running the OpenSSL Configure script, the EDK2 environment defines THIRTY_TWO_BIT or SIXTY_FOUR_BIT for itself according to the target platform. The current setup is broken, though. It checks for OPENSSL_SYS_UEFI but before it's actually defined, since opensslconf.h hasn't yet been included. Let's fix that by including opensslconf.h. And also let's move the bn_conf.h doesn't even need to *exist* in the UEFI build environment. --- ?crypto/bn/bn_lcl.h???????????????????| 6 ++++++ ?crypto/include/internal/bn_conf.h.in | 5 +++-- ?2 files changed, 9 insertions(+), 2 deletions(-) diff --git a/crypto/bn/bn_lcl.h b/crypto/bn/bn_lcl.h index 0f3205c..a0a857b 100644 --- a/crypto/bn/bn_lcl.h +++ b/crypto/bn/bn_lcl.h @@ -111,7 +111,13 @@ ?#ifndef HEADER_BN_LCL_H ?# define HEADER_BN_LCL_H ? +/* The EDK2 build sets these externally since it doesn't re-run our + * own Configure script and needs to support both 32-bit and 64-bit */ +#include + +# if !defined(OPENSSL_SYS_UEFI) ?# include "internal/bn_conf.h" +# endif ?# include "internal/bn_int.h" ? ?#ifdef??__cplusplus diff --git a/crypto/include/internal/bn_conf.h.in b/crypto/include/internal/bn_conf.h.in index 5ebd55d..ceb4cba 100644 --- a/crypto/include/internal/bn_conf.h.in +++ b/crypto/include/internal/bn_conf.h.in @@ -56,7 +56,9 @@ ?#ifndef HEADER_BN_CONF_H ?# define HEADER_BN_CONF_H ? -# if !defined(OPENSSL_SYS_UEFI) +/* The contents of this file are not used in the UEFI build, as + * both 32-bit and 64-bit builds are supported from a single run + * of the Configure script. */ ? ?/* Should we define BN_DIV2W here? */ ? @@ -64,6 +66,5 @@ ?{- $config{b64l} ? "#define" : "#undef" -} SIXTY_FOUR_BIT_LONG ?{- $config{b64}??? "#define" : "#undef" -} SIXTY_FOUR_BIT ?{- $config{b32}??? "#define" : "#undef" -} THIRTY_TWO_BIT -# endif ? ?#endif --? 2.5.0 -- David Woodhouse Open Source Technology Centre David.Woodhouse at intel.com Intel Corporation -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4339 Please log in as guest with password guest if prompted -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5691 bytes Desc: not available URL: From matt at openssl.org Tue Feb 23 15:59:55 2016 From: matt at openssl.org (Matt Caswell) Date: Tue, 23 Feb 2016 15:59:55 +0000 Subject: [openssl-dev] MSVC 2015 internal compiler error In-Reply-To: References: Message-ID: <56CC81FB.2000107@openssl.org> On 23/02/16 01:55, Bill Bierman wrote: > The Microsoft compiler team has suggested removing the include of ssl.h > from srtp.h as it creates a circular reference which is likely confusing > the compiler. > > On Mon, Feb 22, 2016 at 2:19 PM, Bill Bierman > wrote: > > Hello. I'm sorry I cannot reply to the thread. I only just now > have subscribed to the list. > > I can confirm that this problem exists with Visual Studio 2015 on HEAD. > > I spoke to a friend of mine who works at MS who relayed this to the > compiler team. A senior dev there is aware of the issue and they > are working on a fix. The attached seems to avoid the problem - but then for reasons I cannot understand link errors result later on in the build. Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: vs2015-bug.patch Type: text/x-patch Size: 1435 bytes Desc: not available URL: From matt at openssl.org Tue Feb 23 16:21:30 2016 From: matt at openssl.org (Matt Caswell) Date: Tue, 23 Feb 2016 16:21:30 +0000 Subject: [openssl-dev] MSVC 2015 internal compiler error In-Reply-To: <56CC81FB.2000107@openssl.org> References: <56CC81FB.2000107@openssl.org> Message-ID: <56CC870A.60003@openssl.org> On 23/02/16 15:59, Matt Caswell wrote: > > > On 23/02/16 01:55, Bill Bierman wrote: >> The Microsoft compiler team has suggested removing the include of ssl.h >> from srtp.h as it creates a circular reference which is likely confusing >> the compiler. >> >> On Mon, Feb 22, 2016 at 2:19 PM, Bill Bierman > > wrote: >> >> Hello. I'm sorry I cannot reply to the thread. I only just now >> have subscribed to the list. >> >> I can confirm that this problem exists with Visual Studio 2015 on HEAD. >> >> I spoke to a friend of mine who works at MS who relayed this to the >> compiler team. A senior dev there is aware of the issue and they >> are working on a fix. > > > The attached seems to avoid the problem - but then for reasons I cannot > understand link errors result later on in the build. Ahhh, mkdef.pl had fallen over...fix coming up. Matt From sander at temme.net Tue Feb 23 16:38:41 2016 From: sander at temme.net (Sander Temme) Date: Tue, 23 Feb 2016 11:38:41 -0500 Subject: [openssl-dev] Ubsec and Chil engines In-Reply-To: <20160222.160034.1279367000656813396.levitte@openssl.org> References: <20160220.225541.1585601945103016062.levitte@openssl.org> <1456140741.4735.272.camel@infradead.org> <347004c001fd430aadadceac908e68a2@ustx2ex-dag1mb1.msg.corp.akamai.com> <20160222.160034.1279367000656813396.levitte@openssl.org> Message-ID: All, I toyed over the weekend with resurrecting CHIL: intermediate result here https://github.com/sctemme/openssl/tree/rescue-chil and I AM NOT PROUD OF THIS but have no cycles to clean it up for at least a couple of days to come. It builds now but doesn't work: my privkey loading routine doesn't get called and that may be an API change I missed. Can we resurrect CHIL for 1.1 along these lines? Then I'd be delighted to join the discussion about p11 for down the road. S. Sent from my iPhone > On Feb 22, 2016, at 10:00 AM, Richard Levitte wrote: > > In message <347004c001fd430aadadceac908e68a2 at ustx2ex-dag1mb1.msg.corp.akamai.com> on Mon, 22 Feb 2016 14:46:28 +0000, "Salz, Rich" said: > > rsalz> > If we integrate the support natively into OpenSSL, then PKCS#11 URIs (see > rsalz> > RFC7512) can be first-class citizens throughout the crypto and SSL APIs. Any > rsalz> > function which takes a filename for a cert or key should also accept? a > rsalz> > PKCS#11 URI. > rsalz> > rsalz> It'd be great to see a crypto/pkcs11 directory with full native support (as much as possible). > rsalz> > rsalz> But really doubtful to happen in 1.1 as the API freeze is in a month. > > Yeah, 1.1 is unrealistic, I'm sorry to say. > > -- > Richard Levitte levitte at openssl.org > OpenSSL Project http://www.openssl.org/~levitte/ From doctor at doctor.nl2k.ab.ca Tue Feb 23 17:00:44 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Tue, 23 Feb 2016 10:00:44 -0700 Subject: [openssl-dev] OPenssl-SNAP-20160223 issue test/recipes/70-test_sslcertstatus.t Message-ID: <20160223170044.GB14945@doctor.nl2k.ab.ca> Thank you for getting the libssl.so.1.1 issue corrected! I found this ../test/recipes/70-test_packet.t .......... 1..1 test_PACKET_buf_init() failed not ok 1 - running packettest # Failed test 'running packettest' # at ../test/testlib/OpenSSL/Test/Simple.pm line 70. # Looks like you failed 1 test of 1. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/70-test_sslcertstatus.t ... 1..1 Proxy started on port 4453 engine "ossltest" set. engine "ossltest" set. 136617832:error:20087002:BIO routines:BIO_lookup:system lib:b_addr.c:711:Invali d value for ai_flags connect:errno=2 Using default temp DH parameters ACCEPT 136617832:error:20087002:BIO routines:BIO_lookup:system lib:b_addr.c:711:Invali d value for ai_flags 0 items in the session cache 0 client connects (SSL_connect()) 0 client renegotiates (SSL_connect()) 0 client connects that finished 0 server accepts (SSL_accept()) 0 server renegotiates (SSL_accept()) 0 server accepts that finished 0 session cache hits 0 session cache misses 0 session cache timeouts 0 callback cache hits 0 cache full overflows (128 allowed) Also each morning I do have to edit b_addr.c so that LOCALHOSt is defined This is what I do to compensate #include #include And the above error is from # ifdef AI_ADDRCONFIG hints.ai_flags = AI_ADDRCONFIG; # endif hints.ai_family = family; hints.ai_socktype = socktype; if (lookup_type == BIO_LOOKUP_SERVER) hints.ai_flags |= AI_PASSIVE; /* Note that |res| SHOULD be a 'struct addrinfo **' thanks to * macro magic in bio_lcl.h */ switch ((gai_ret = getaddrinfo(host, service, &hints, res))) { # ifdef EAI_SYSTEM case EAI_SYSTEM: SYSerr(SYS_F_GETADDRINFO, get_last_socket_error()); BIOerr(BIO_F_BIO_LOOKUP, ERR_R_SYS_LIB); break; # endif case 0: ret = 1; /* Success */ break; default: BIOerr(BIO_F_BIO_LOOKUP, ERR_R_SYS_LIB); ERR_add_error_data(1, gai_strerror(gai_ret)); break; } } else { line 711 is line 710 in your case. Please fix -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Broadcasting the truth for 25 years From rt at openssl.org Tue Feb 23 17:11:15 2016 From: rt at openssl.org (J Mohan Rao Arisankala via RT) Date: Tue, 23 Feb 2016 17:11:15 +0000 Subject: [openssl-dev] [openssl.org #4340] ASN1_item_sign_ctx(): method check before access and release ctx in error paths In-Reply-To: References: Message-ID: - In error paths, EVP_MD_CTX allocated by the callee is not released (master) - Checking method before access (in master and earlier versions) Pull request with these changes (on master) are as below, please have a look. https://github.com/openssl/openssl/pull/737 Thanks, Mohan -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4340 Please log in as guest with password guest if prompted From levitte at openssl.org Tue Feb 23 17:35:20 2016 From: levitte at openssl.org (Richard Levitte) Date: Tue, 23 Feb 2016 18:35:20 +0100 (CET) Subject: [openssl-dev] OPenssl-SNAP-20160223 issue test/recipes/70-test_sslcertstatus.t In-Reply-To: <20160223170044.GB14945@doctor.nl2k.ab.ca> References: <20160223170044.GB14945@doctor.nl2k.ab.ca> Message-ID: <20160223.183520.60223467499466451.levitte@openssl.org> Before anything else, mind reminding us what platform this is on? In message <20160223170044.GB14945 at doctor.nl2k.ab.ca> on Tue, 23 Feb 2016 10:00:44 -0700, The Doctor said: doctor> I found this doctor> doctor> ../test/recipes/70-test_packet.t .......... doctor> 1..1 doctor> test_PACKET_buf_init() failed doctor> not ok 1 - running packettest doctor> doctor> # Failed test 'running packettest' doctor> # at ../test/testlib/OpenSSL/Test/Simple.pm line 70. doctor> # Looks like you failed 1 test of 1. doctor> Dubious, test returned 1 (wstat 256, 0x100) doctor> Failed 1/1 subtests doctor> ../test/recipes/70-test_sslcertstatus.t ... doctor> 1..1 doctor> Proxy started on port 4453 doctor> engine "ossltest" set. doctor> engine "ossltest" set. doctor> 136617832:error:20087002:BIO routines:BIO_lookup:system lib:b_addr.c:711:Invali doctor> d value for ai_flags doctor> connect:errno=2 doctor> Using default temp DH parameters doctor> ACCEPT doctor> 136617832:error:20087002:BIO routines:BIO_lookup:system lib:b_addr.c:711:Invali doctor> d value for ai_flags doctor> 0 items in the session cache doctor> 0 client connects (SSL_connect()) doctor> 0 client renegotiates (SSL_connect()) doctor> 0 client connects that finished doctor> 0 server accepts (SSL_accept()) doctor> 0 server renegotiates (SSL_accept()) doctor> 0 server accepts that finished doctor> 0 session cache hits doctor> 0 session cache misses doctor> 0 session cache timeouts doctor> 0 callback cache hits doctor> 0 cache full overflows (128 allowed) doctor> doctor> Also each morning I do have to edit b_addr.c so that LOCALHOSt is doctor> defined I have no idea what that means. "so that LOCALHOST is defined"? doctor> doctor> This is what I do to compensate doctor> doctor> #include doctor> #include Mind reminding us what goes wrong if isn't included? doctor> And the above error is from doctor> doctor> # ifdef AI_ADDRCONFIG doctor> hints.ai_flags = AI_ADDRCONFIG; doctor> # endif doctor> hints.ai_family = family; doctor> hints.ai_socktype = socktype; doctor> doctor> if (lookup_type == BIO_LOOKUP_SERVER) doctor> hints.ai_flags |= AI_PASSIVE; So either it doesn't like AI_ADDRCONFIG or AI_PASSIVE. We can survive without AI_ADDRCONFIG (though not happily), but it's strange considering it's only set if the macro is defined... Living without AI_PASSIVE, on the other hand, would suck quite hard. doctor> Please fix Please help us figure this out ;-) -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From kurt at roeckx.be Tue Feb 23 17:51:56 2016 From: kurt at roeckx.be (Kurt Roeckx) Date: Tue, 23 Feb 2016 18:51:56 +0100 Subject: [openssl-dev] OPenssl-SNAP-20160223 issue test/recipes/70-test_sslcertstatus.t In-Reply-To: <20160223170044.GB14945@doctor.nl2k.ab.ca> References: <20160223170044.GB14945@doctor.nl2k.ab.ca> Message-ID: <20160223175156.GA2092@roeckx.be> On Tue, Feb 23, 2016 at 10:00:44AM -0700, The Doctor wrote: > 136617832:error:20087002:BIO routines:BIO_lookup:system lib:b_addr.c:711:Invali > d value for ai_flags Do you have any idea which flag it is that is causing problems? I find it rather strange that it knows about the flag, but then says it's an invalid one. What OS is that? Do the headers you have actually match the libc you use? > Also each morning I do have to edit b_addr.c so that LOCALHOSt is > defined > > This is what I do to compensate > > #include > #include Do you mean INADDR_LOOPBACK maybe? What about including netinet/in.h instead? Kurt From levitte at openssl.org Tue Feb 23 18:04:10 2016 From: levitte at openssl.org (Richard Levitte) Date: Tue, 23 Feb 2016 19:04:10 +0100 (CET) Subject: [openssl-dev] OPenssl-SNAP-20160223 issue test/recipes/70-test_sslcertstatus.t In-Reply-To: <20160223175156.GA2092@roeckx.be> References: <20160223170044.GB14945@doctor.nl2k.ab.ca> <20160223175156.GA2092@roeckx.be> Message-ID: <20160223.190410.442629674129020658.levitte@openssl.org> In message <20160223175156.GA2092 at roeckx.be> on Tue, 23 Feb 2016 18:51:56 +0100, Kurt Roeckx said: kurt> > Also each morning I do have to edit b_addr.c so that LOCALHOSt is kurt> > defined kurt> > kurt> > This is what I do to compensate kurt> > kurt> > #include kurt> > #include kurt> kurt> Do you mean INADDR_LOOPBACK maybe? kurt> What about including netinet/in.h instead? That should be added somewhere in e_os.h in that case -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From rt at openssl.org Tue Feb 23 18:20:06 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 23 Feb 2016 18:20:06 +0000 Subject: [openssl-dev] [openssl.org #4339] [PATCH] Fix handling of in UEFI build In-Reply-To: <1456240073.4735.411.camel@infradead.org> References: <1456240073.4735.411.camel@infradead.org> Message-ID: commit 78c8307 pushed, thanks! (also is GH PR 736) -- Rich Salz, OpenSSL dev team; rsalz at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4339 Please log in as guest with password guest if prompted From rt at openssl.org Tue Feb 23 18:47:46 2016 From: rt at openssl.org (David Benjamin via RT) Date: Tue, 23 Feb 2016 18:47:46 +0000 Subject: [openssl-dev] [openssl.org #4341] [PATCH] Consistently use arm_arch.h constants in armcap assembly code. In-Reply-To: References: Message-ID: Patch attached. This is just a little cleanup change to fix not everything using the OPENSSL_armcap constants. (Existing ones already are using them, so I'm assuming this is okay.) David -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4341 Please log in as guest with password guest if prompted -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Consistently-use-arm_arch.h-constants-in-armcap-asse.patch Type: text/x-patch Size: 2160 bytes Desc: not available URL: From doctor at doctor.nl2k.ab.ca Tue Feb 23 18:48:00 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Tue, 23 Feb 2016 11:48:00 -0700 Subject: [openssl-dev] OPenssl-SNAP-20160223 issue test/recipes/70-test_sslcertstatus.t In-Reply-To: <20160223.183520.60223467499466451.levitte@openssl.org> References: <20160223170044.GB14945@doctor.nl2k.ab.ca> <20160223.183520.60223467499466451.levitte@openssl.org> Message-ID: <20160223184759.GC6063@doctor.nl2k.ab.ca> On Tue, Feb 23, 2016 at 06:35:20PM +0100, Richard Levitte wrote: > Before anything else, mind reminding us what platform this is on? > > In message <20160223170044.GB14945 at doctor.nl2k.ab.ca> on Tue, 23 Feb 2016 10:00:44 -0700, The Doctor said: > > doctor> I found this > doctor> > doctor> ../test/recipes/70-test_packet.t .......... > doctor> 1..1 > doctor> test_PACKET_buf_init() failed > doctor> not ok 1 - running packettest > doctor> > doctor> # Failed test 'running packettest' > doctor> # at ../test/testlib/OpenSSL/Test/Simple.pm line 70. > doctor> # Looks like you failed 1 test of 1. > doctor> Dubious, test returned 1 (wstat 256, 0x100) > doctor> Failed 1/1 subtests > doctor> ../test/recipes/70-test_sslcertstatus.t ... > doctor> 1..1 > doctor> Proxy started on port 4453 > doctor> engine "ossltest" set. > doctor> engine "ossltest" set. > doctor> 136617832:error:20087002:BIO routines:BIO_lookup:system lib:b_addr.c:711:Invali > doctor> d value for ai_flags > doctor> connect:errno=2 > doctor> Using default temp DH parameters > doctor> ACCEPT > doctor> 136617832:error:20087002:BIO routines:BIO_lookup:system lib:b_addr.c:711:Invali > doctor> d value for ai_flags > doctor> 0 items in the session cache > doctor> 0 client connects (SSL_connect()) > doctor> 0 client renegotiates (SSL_connect()) > doctor> 0 client connects that finished > doctor> 0 server accepts (SSL_accept()) > doctor> 0 server renegotiates (SSL_accept()) > doctor> 0 server accepts that finished > doctor> 0 session cache hits > doctor> 0 session cache misses > doctor> 0 session cache timeouts > doctor> 0 callback cache hits > doctor> 0 cache full overflows (128 allowed) > doctor> > doctor> Also each morning I do have to edit b_addr.c so that LOCALHOSt is > doctor> defined > > I have no idea what that means. "so that LOCALHOST is defined"? > > doctor> > doctor> This is what I do to compensate > doctor> > doctor> #include > doctor> #include > > Mind reminding us what goes wrong if isn't included? > > doctor> And the above error is from > doctor> > doctor> # ifdef AI_ADDRCONFIG > doctor> hints.ai_flags = AI_ADDRCONFIG; > doctor> # endif > doctor> hints.ai_family = family; > doctor> hints.ai_socktype = socktype; > doctor> > doctor> if (lookup_type == BIO_LOOKUP_SERVER) > doctor> hints.ai_flags |= AI_PASSIVE; > > So either it doesn't like AI_ADDRCONFIG or AI_PASSIVE. We can survive > without AI_ADDRCONFIG (though not happily), but it's strange > considering it's only set if the macro is defined... Living without > AI_PASSIVE, on the other hand, would suck quite hard. > > doctor> Please fix > > Please help us figure this out ;-) AI_ADDRCONFIG is the issue. In Clamav/clamd/tcpserver.c I have to comment that out for clamd to work properly. > > -- > Richard Levitte levitte at openssl.org > OpenSSL Project http://www.openssl.org/~levitte/ > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Broadcasting the truth for 25 years From doctor at doctor.nl2k.ab.ca Tue Feb 23 18:43:53 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Tue, 23 Feb 2016 11:43:53 -0700 Subject: [openssl-dev] OPenssl-SNAP-20160223 issue test/recipes/70-test_sslcertstatus.t In-Reply-To: <20160223170044.GB14945@doctor.nl2k.ab.ca> References: <20160223170044.GB14945@doctor.nl2k.ab.ca> Message-ID: <20160223184353.GA6063@doctor.nl2k.ab.ca> On Tue, Feb 23, 2016 at 10:00:44AM -0700, The Doctor wrote: > Thank you for getting the libssl.so.1.1 issue corrected! > > > I found this > > ../test/recipes/70-test_packet.t .......... > 1..1 > test_PACKET_buf_init() failed > not ok 1 - running packettest > > # Failed test 'running packettest' > # at ../test/testlib/OpenSSL/Test/Simple.pm line 70. > # Looks like you failed 1 test of 1. > Dubious, test returned 1 (wstat 256, 0x100) > Failed 1/1 subtests > ../test/recipes/70-test_sslcertstatus.t ... > 1..1 > Proxy started on port 4453 > engine "ossltest" set. > engine "ossltest" set. > 136617832:error:20087002:BIO routines:BIO_lookup:system lib:b_addr.c:711:Invali > d value for ai_flags > connect:errno=2 > Using default temp DH parameters > ACCEPT > 136617832:error:20087002:BIO routines:BIO_lookup:system lib:b_addr.c:711:Invali > d value for ai_flags > 0 items in the session cache > 0 client connects (SSL_connect()) > 0 client renegotiates (SSL_connect()) > 0 client connects that finished > 0 server accepts (SSL_accept()) > 0 server renegotiates (SSL_accept()) > 0 server accepts that finished > 0 session cache hits > 0 session cache misses > 0 session cache timeouts > 0 callback cache hits > 0 cache full overflows (128 allowed) > > Also each morning I do have to edit b_addr.c so that LOCALHOSt is > defined > > This is what I do to compensate > > #include > #include > > And the above error is from > > # ifdef AI_ADDRCONFIG > hints.ai_flags = AI_ADDRCONFIG; > # endif The above 3 lines are the issue. In clamav/clamd/tcpserver.c for me to get calmd to work properly I need to do #ifdef AI_ADDRCONFIG /* hints.ai_flags |= AI_ADDRCONFIG; */ #endif > hints.ai_family = family; > hints.ai_socktype = socktype; > > if (lookup_type == BIO_LOOKUP_SERVER) > hints.ai_flags |= AI_PASSIVE; > > /* Note that |res| SHOULD be a 'struct addrinfo **' thanks to > * macro magic in bio_lcl.h > */ > switch ((gai_ret = getaddrinfo(host, service, &hints, res))) { > # ifdef EAI_SYSTEM > case EAI_SYSTEM: > SYSerr(SYS_F_GETADDRINFO, get_last_socket_error()); > BIOerr(BIO_F_BIO_LOOKUP, ERR_R_SYS_LIB); > break; > # endif > case 0: > ret = 1; /* Success */ > break; > default: > BIOerr(BIO_F_BIO_LOOKUP, ERR_R_SYS_LIB); > ERR_add_error_data(1, gai_strerror(gai_ret)); > break; > } > } else { > > line 711 is line 710 in your case. > > Please fix > > -- > Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca > God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! > http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism > Broadcasting the truth for 25 years > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Broadcasting the truth for 25 years From doctor at doctor.nl2k.ab.ca Tue Feb 23 19:17:27 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Tue, 23 Feb 2016 12:17:27 -0700 Subject: [openssl-dev] OPenssl-SNAP-20160223 issue test/recipes/70-test_sslcertstatus.t In-Reply-To: <20160223.190410.442629674129020658.levitte@openssl.org> References: <20160223170044.GB14945@doctor.nl2k.ab.ca> <20160223175156.GA2092@roeckx.be> <20160223.190410.442629674129020658.levitte@openssl.org> Message-ID: <20160223191727.GB8292@doctor.nl2k.ab.ca> On Tue, Feb 23, 2016 at 07:04:10PM +0100, Richard Levitte wrote: > In message <20160223175156.GA2092 at roeckx.be> on Tue, 23 Feb 2016 18:51:56 +0100, Kurt Roeckx said: > > kurt> > Also each morning I do have to edit b_addr.c so that LOCALHOSt is > kurt> > defined > kurt> > > kurt> > This is what I do to compensate > kurt> > > kurt> > #include > kurt> > #include > kurt> > kurt> Do you mean INADDR_LOOPBACK maybe? > kurt> What about including netinet/in.h instead? > > That should be added somewhere in e_os.h in that case > Suppose this line works? #define INADDR_LOOPBACK (u_long)0x7F000001 in e_os.h ? > -- > Richard Levitte levitte at openssl.org > OpenSSL Project http://www.openssl.org/~levitte/ > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Broadcasting the truth for 25 years From doctor at doctor.nl2k.ab.ca Tue Feb 23 19:16:24 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Tue, 23 Feb 2016 12:16:24 -0700 Subject: [openssl-dev] OPenssl-SNAP-20160223 issue test/recipes/70-test_sslcertstatus.t In-Reply-To: <20160223175156.GA2092@roeckx.be> References: <20160223170044.GB14945@doctor.nl2k.ab.ca> <20160223175156.GA2092@roeckx.be> Message-ID: <20160223191623.GA8292@doctor.nl2k.ab.ca> On Tue, Feb 23, 2016 at 06:51:56PM +0100, Kurt Roeckx wrote: > On Tue, Feb 23, 2016 at 10:00:44AM -0700, The Doctor wrote: > > 136617832:error:20087002:BIO routines:BIO_lookup:system lib:b_addr.c:711:Invali > > d value for ai_flags > > Do you have any idea which flag it is that is causing problems? I > find it rather strange that it knows about the flag, but then says > it's an invalid one. > > What OS is that? > > Do the headers you have actually match the libc you use? > > > Also each morning I do have to edit b_addr.c so that LOCALHOSt is > > defined > > > > This is what I do to compensate > > > > #include > > #include > > Do you mean INADDR_LOOPBACK maybe? > What about including netinet/in.h instead? > Not in netinet/in.h a quick solution would be to include the following line in b_addr.c #define INADDR_LOOPBACK (u_long)0x7F000001 > > Kurt > > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Broadcasting the truth for 25 years From levitte at openssl.org Tue Feb 23 19:33:44 2016 From: levitte at openssl.org (Richard Levitte) Date: Tue, 23 Feb 2016 20:33:44 +0100 (CET) Subject: [openssl-dev] OPenssl-SNAP-20160223 issue test/recipes/70-test_sslcertstatus.t In-Reply-To: <20160223191623.GA8292@doctor.nl2k.ab.ca> <20160223184353.GA6063@doctor.nl2k.ab.ca> References: <20160223170044.GB14945@doctor.nl2k.ab.ca> <20160223175156.GA2092@roeckx.be> <20160223191623.GA8292@doctor.nl2k.ab.ca> Message-ID: <20160223.203344.1204167871752593102.levitte@openssl.org> In message <20160223184353.GA6063 at doctor.nl2k.ab.ca> on Tue, 23 Feb 2016 11:43:53 -0700, The Doctor said: doctor> On Tue, Feb 23, 2016 at 10:00:44AM -0700, The Doctor wrote: doctor> > # ifdef AI_ADDRCONFIG doctor> > hints.ai_flags = AI_ADDRCONFIG; doctor> > # endif doctor> doctor> The above 3 lines are the issue. doctor> doctor> In clamav/clamd/tcpserver.c for me to get calmd to work properly doctor> I need to do doctor> doctor> #ifdef AI_ADDRCONFIG /* doctor> hints.ai_flags |= AI_ADDRCONFIG; */ doctor> #endif That's... interesting. One might wonder why AI_ADDRCONFIG is defined. I'm still interested in knowing what platform this is on. In message <20160223191623.GA8292 at doctor.nl2k.ab.ca> on Tue, 23 Feb 2016 12:16:24 -0700, The Doctor said: doctor> On Tue, Feb 23, 2016 at 06:51:56PM +0100, Kurt Roeckx wrote: doctor> > Do you mean INADDR_LOOPBACK maybe? doctor> > What about including netinet/in.h instead? doctor> > doctor> doctor> Not in netinet/in.h Is INADDR_LOOPBACK defined anywhere? doctor> a quick solution would be to include the following line in b_addr.c doctor> doctor> #define INADDR_LOOPBACK (u_long)0x7F000001 In the end, I think a correct solution would be preferable to the quick hack. If it is defined anywhere, it would be nice to know how to get it. And oh, what platform is this on? Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From openssl at roumenpetrov.info Tue Feb 23 19:48:30 2016 From: openssl at roumenpetrov.info (Roumen Petrov) Date: Tue, 23 Feb 2016 21:48:30 +0200 Subject: [openssl-dev] shared build, master, 2016-02-23 Message-ID: <56CCB78E.6060605@roumenpetrov.info> Hello, The current master branch does not create shared libraries. Attached patch restore build with gnu tools. Regards, Roumen Petrov -------------- next part -------------- A non-text attachment was scrubbed... Name: 0013-correct-name-of-GNU-shared-libraries.patch Type: text/x-diff Size: 674 bytes Desc: not available URL: From doctor at doctor.nl2k.ab.ca Tue Feb 23 19:59:46 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Tue, 23 Feb 2016 12:59:46 -0700 Subject: [openssl-dev] OPenssl-SNAP-20160223 issue test/recipes/70-test_sslcertstatus.t In-Reply-To: <20160223.203344.1204167871752593102.levitte@openssl.org> References: <20160223170044.GB14945@doctor.nl2k.ab.ca> <20160223175156.GA2092@roeckx.be> <20160223191623.GA8292@doctor.nl2k.ab.ca> <20160223.203344.1204167871752593102.levitte@openssl.org> Message-ID: <20160223195945.GA23039@doctor.nl2k.ab.ca> On Tue, Feb 23, 2016 at 08:33:44PM +0100, Richard Levitte wrote: > In message <20160223184353.GA6063 at doctor.nl2k.ab.ca> on Tue, 23 Feb 2016 11:43:53 -0700, The Doctor said: > > doctor> On Tue, Feb 23, 2016 at 10:00:44AM -0700, The Doctor wrote: > doctor> > # ifdef AI_ADDRCONFIG > doctor> > hints.ai_flags = AI_ADDRCONFIG; > doctor> > # endif > doctor> > doctor> The above 3 lines are the issue. > doctor> > doctor> In clamav/clamd/tcpserver.c for me to get calmd to work properly > doctor> I need to do > doctor> > doctor> #ifdef AI_ADDRCONFIG /* > doctor> hints.ai_flags |= AI_ADDRCONFIG; */ > doctor> #endif > > That's... interesting. One might wonder why AI_ADDRCONFIG is > defined. > > I'm still interested in knowing what platform this is on. > BSDI 4.3 > In message <20160223191623.GA8292 at doctor.nl2k.ab.ca> on Tue, 23 Feb 2016 12:16:24 -0700, The Doctor said: > > doctor> On Tue, Feb 23, 2016 at 06:51:56PM +0100, Kurt Roeckx wrote: > doctor> > Do you mean INADDR_LOOPBACK maybe? > doctor> > What about including netinet/in.h instead? > doctor> > > doctor> > doctor> Not in netinet/in.h > > Is INADDR_LOOPBACK defined anywhere? > > doctor> a quick solution would be to include the following line in b_addr.c > doctor> > doctor> #define INADDR_LOOPBACK (u_long)0x7F000001 > > In the end, I think a correct solution would be preferable to the > quick hack. If it is defined anywhere, it would be nice to know how > to get it. > > And oh, what platform is this on? I just told you. BTW, the results of changes are in ../test/recipes/01-test_ordinals.t ........ ok ../test/recipes/05-test_bf.t .............. ok ../test/recipes/05-test_cast.t ............ ok ../test/recipes/05-test_des.t ............. ok ../test/recipes/05-test_hmac.t ............ ok ../test/recipes/05-test_idea.t ............ ok ../test/recipes/05-test_md2.t ............. skipped: md2 is not supported by this OpenSSL build ../test/recipes/05-test_md4.t ............. ok ../test/recipes/05-test_md5.t ............. ok ../test/recipes/05-test_mdc2.t ............ ok ../test/recipes/05-test_rand.t ............ ok ../test/recipes/05-test_rc2.t ............. ok ../test/recipes/05-test_rc4.t ............. ok ../test/recipes/05-test_rc5.t ............. ok ../test/recipes/05-test_rmd.t ............. ok ../test/recipes/05-test_sha1.t ............ ok ../test/recipes/05-test_sha256.t .......... ok ../test/recipes/05-test_sha512.t .......... ok ../test/recipes/05-test_wp.t .............. ok ../test/recipes/10-test_bn.t .............. ok ../test/recipes/10-test_exp.t ............. ok ../test/recipes/15-test_dh.t .............. ok ../test/recipes/15-test_dsa.t ............. ok ../test/recipes/15-test_ec.t .............. ok ../test/recipes/15-test_ecdh.t ............ ok ../test/recipes/15-test_ecdsa.t ........... ok ../test/recipes/15-test_rsa.t ............. ok ../test/recipes/20-test_enc.t ............. ok ../test/recipes/25-test_crl.t ............. ok ../test/recipes/25-test_gen.t ............. ok ../test/recipes/25-test_pkcs7.t ........... ok ../test/recipes/25-test_req.t ............. ok ../test/recipes/25-test_sid.t ............. ok ../test/recipes/25-test_verify.t .......... ok ../test/recipes/25-test_x509.t ............ ok ../test/recipes/30-test_engine.t .......... ok ../test/recipes/30-test_evp.t ............. 1/1 # Failed test 'running evp_test evptests.txt' # at ../test/recipes/30-test_evp.t line 11. # Looks like you failed 1 test of 1. ../test/recipes/30-test_evp.t ............. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/30-test_evp_extra.t ....... ok ../test/recipes/30-test_pbelu.t ........... ok ../test/recipes/40-test_rehash.t .......... 2/5 # Failed test 'Testing that we aren't running as a priviledged user, such as root' # at ../test/recipes/40-test_rehash.t line 41. # Looks like you failed 1 test of 5. ../test/recipes/40-test_rehash.t .......... Dubious, test returned 1 (wstat 256, 0x100) Failed 1/5 subtests (less 1 skipped subtest: 3 okay) ../test/recipes/70-test_clienthello.t ..... ok ../test/recipes/70-test_packet.t .......... 1/1 # Failed test 'running packettest' # at ../test/testlib/OpenSSL/Test/Simple.pm line 70. # Looks like you failed 1 test of 1. ../test/recipes/70-test_packet.t .......... Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/70-test_sslcertstatus.t ... ok ../test/recipes/70-test_sslextension.t .... ok ../test/recipes/70-test_sslsessiontick.t .. ok ../test/recipes/70-test_sslskewith0p.t .... ok ../test/recipes/70-test_sslvertol.t ....... ok ../test/recipes/70-test_tlsextms.t ........ ok ../test/recipes/70-test_verify_extra.t .... ok ../test/recipes/80-test_ca.t .............. ok ../test/recipes/80-test_cms.t ............. ok ../test/recipes/80-test_dane.t ............ ok ../test/recipes/80-test_dtlsv1listen.t .... ok ../test/recipes/80-test_ocsp.t ............ ok ../test/recipes/80-test_ssl.t ............. ok ../test/recipes/80-test_tsa.t ............. ok ../test/recipes/90-test_async.t ........... ok ../test/recipes/90-test_constant_time.t ... ok ../test/recipes/90-test_gmdiff.t .......... ok ../test/recipes/90-test_heartbeat.t ....... skipped: heartbeats is not supported by this OpenSSL build ../test/recipes/90-test_ige.t ............. ok ../test/recipes/90-test_memleak.t ......... ok ../test/recipes/90-test_networking.t ...... ok ../test/recipes/90-test_np.t .............. ok ../test/recipes/90-test_p5_crpt2.t ........ ok ../test/recipes/90-test_secmem.t .......... ok ../test/recipes/90-test_srp.t ............. ok ../test/recipes/90-test_v3name.t .......... ok Test Summary Report ------------------- ../test/recipes/30-test_evp.t (Wstat: 256 Tests: 1 Failed: 1) Failed test: 1 Non-zero exit status: 1 ../test/recipes/40-test_rehash.t (Wstat: 256 Tests: 5 Failed: 1) Failed test: 4 Non-zero exit status: 1 ../test/recipes/70-test_packet.t (Wstat: 256 Tests: 1 Failed: 1) Failed test: 1 Non-zero exit status: 1 Files=68, Tests=400, 473 wallclock secs ( 3.70 usr 2.68 sys + 301.70 cusr 83.35 csys = 391.43 CPU) Result: FAIL Failed 3/68 test programs. 3/400 subtests failed. *** Error code 255 Stop. *** Error code 1 Stop. That looks better. Anyone else testing on BSD for this iteration of OpenSSL. > > Cheers, > Richard > > -- > Richard Levitte levitte at openssl.org > OpenSSL Project http://www.openssl.org/~levitte/ > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Broadcasting the truth for 25 years From levitte at openssl.org Tue Feb 23 20:23:40 2016 From: levitte at openssl.org (Richard Levitte) Date: Tue, 23 Feb 2016 21:23:40 +0100 (CET) Subject: [openssl-dev] OPenssl-SNAP-20160223 issue test/recipes/70-test_sslcertstatus.t In-Reply-To: <20160223195945.GA23039@doctor.nl2k.ab.ca> References: <20160223191623.GA8292@doctor.nl2k.ab.ca> <20160223.203344.1204167871752593102.levitte@openssl.org> <20160223195945.GA23039@doctor.nl2k.ab.ca> Message-ID: <20160223.212340.1831208234993432808.levitte@openssl.org> In message <20160223195945.GA23039 at doctor.nl2k.ab.ca> on Tue, 23 Feb 2016 12:59:46 -0700, The Doctor said: doctor> On Tue, Feb 23, 2016 at 08:33:44PM +0100, Richard Levitte wrote: doctor> > I'm still interested in knowing what platform this is on. doctor> doctor> BSDI 4.3 Thank you. doctor> Anyone else testing on BSD for this iteration of OpenSSL. Actually, yes. FreeBSD is getting frequently tested, and I think NetBSD gets a run through a little now and then. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From openssl at roumenpetrov.info Tue Feb 23 20:25:27 2016 From: openssl at roumenpetrov.info (Roumen Petrov) Date: Tue, 23 Feb 2016 22:25:27 +0200 Subject: [openssl-dev] OPENSSL_cleanup additional Message-ID: <56CCC037.5040403@roumenpetrov.info> Hello, I just finish tests with new initialization methods. Memory detection tool report a number of memory leaks. Startup code is: OPENSSL_init_crypto( OPENSSL_INIT_ENGINE_ALL_BUILTIN | OPENSSL_INIT_ADD_ALL_CIPHERS | OPENSSL_INIT_ADD_ALL_DIGESTS | OPENSSL_INIT_LOAD_CONFIG, NULL); Default configuration describes a cryptographic module : ------------------ #[ default ] openssl_conf = config [ config ] engines = engine_section [ engine_section ] engine1 = engine_conf1 [ engine_conf1 ] engine_id = foo ... ------------------ At exit OPENSSL_cleanup is not enough. It seems to me call of ENGINE_cleanup() and CONF_modules_unload(1) before cleanup suppress memory warnings. Another point - why OPENSSL_config duplicate name of configuration file? Regards, Roumen From rsalz at akamai.com Tue Feb 23 20:30:36 2016 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 23 Feb 2016 20:30:36 +0000 Subject: [openssl-dev] OPENSSL_cleanup additional In-Reply-To: <56CCC037.5040403@roumenpetrov.info> References: <56CCC037.5040403@roumenpetrov.info> Message-ID: > Another point - why OPENSSL_config duplicate name of configuration file? Because that's the only way we can know that we have to free() it. From doctor at doctor.nl2k.ab.ca Tue Feb 23 20:41:13 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Tue, 23 Feb 2016 13:41:13 -0700 Subject: [openssl-dev] OPenssl-SNAP-20160223 issue test/recipes/70-test_sslcertstatus.t In-Reply-To: <20160223.212340.1831208234993432808.levitte@openssl.org> References: <20160223191623.GA8292@doctor.nl2k.ab.ca> <20160223.203344.1204167871752593102.levitte@openssl.org> <20160223195945.GA23039@doctor.nl2k.ab.ca> <20160223.212340.1831208234993432808.levitte@openssl.org> Message-ID: <20160223204113.GA5389@doctor.nl2k.ab.ca> On Tue, Feb 23, 2016 at 09:23:40PM +0100, Richard Levitte wrote: > In message <20160223195945.GA23039 at doctor.nl2k.ab.ca> on Tue, 23 Feb 2016 12:59:46 -0700, The Doctor said: > > doctor> On Tue, Feb 23, 2016 at 08:33:44PM +0100, Richard Levitte wrote: > doctor> > I'm still interested in knowing what platform this is on. > doctor> > doctor> BSDI 4.3 > > Thank you. > > doctor> Anyone else testing on BSD for this iteration of OpenSSL. > > Actually, yes. FreeBSD is getting frequently tested, and I think > NetBSD gets a run through a little now and then. > > Cheers, > Richard > FreeBSD 10.X uses clang / cannot speak for NetBSD. Also Dragonfly? > -- > Richard Levitte levitte at openssl.org > OpenSSL Project http://www.openssl.org/~levitte/ > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Broadcasting the truth for 25 years From levitte at openssl.org Tue Feb 23 22:16:38 2016 From: levitte at openssl.org (Richard Levitte) Date: Tue, 23 Feb 2016 23:16:38 +0100 (CET) Subject: [openssl-dev] shared build, master, 2016-02-23 In-Reply-To: <56CCB78E.6060605@roumenpetrov.info> References: <56CCB78E.6060605@roumenpetrov.info> Message-ID: <20160223.231638.526233065366937419.levitte@openssl.org> In message <56CCB78E.6060605 at roumenpetrov.info> on Tue, 23 Feb 2016 21:48:30 +0200, Roumen Petrov said: openssl> Hello, openssl> openssl> The current master branch does not create shared libraries. Attached openssl> patch restore build with gnu tools. Hi, Your patch got applied, commit 1cb7757ee7fde0ca19f64fd6f1886d4b41397b9c Thank you! -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From erik at efca.com Wed Feb 24 00:36:34 2016 From: erik at efca.com (Erik Forsberg) Date: Tue, 23 Feb 2016 16:36:34 -0800 Subject: [openssl-dev] DSO's on Soalris Message-ID: after the recent changes that build engines like foo.so, I suppose it was forgotten to update Makefile.shared for Solaris platforms. link_dso.solaris: @ if $(DETECT_GNU_LD); then \ $(DO_GNU_DSO); \ else \ $(CALC_VERSIONS); \ SHLIB=lib$(LIBNAME).so; \ SHLIB_SUFFIX=; \ ALLSYMSFLAGS=""; \ NOALLSYMSFLAGS=""; \ SHAREDFLAGS="$(CFLAGS) $(SHARED_LDFLAGS) -h $$SHLIB$$SHLIB_SOVER$$SHLIB_SUFFIX -Wl,-Bsymbolic"; \ fi; \ $(LINK_SO_DSO) I removed the lib prefix from SHLIB in order to pass all the tests that tries to load the ossltest engine. I assume that was the decision, right ? From levitte at openssl.org Wed Feb 24 00:44:40 2016 From: levitte at openssl.org (Richard Levitte) Date: Wed, 24 Feb 2016 01:44:40 +0100 (CET) Subject: [openssl-dev] DSO's on Soalris In-Reply-To: References: Message-ID: <20160224.014440.387815358987889546.levitte@openssl.org> In message on Tue, 23 Feb 2016 16:36:34 -0800, "Erik Forsberg" said: erik> erik> after the recent changes that build engines like foo.so, I suppose erik> it was forgotten to update Makefile.shared for Solaris platforms. erik> erik> link_dso.solaris: erik> @ if $(DETECT_GNU_LD); then \ erik> $(DO_GNU_DSO); \ erik> else \ erik> $(CALC_VERSIONS); \ erik> SHLIB=lib$(LIBNAME).so; \ erik> SHLIB_SUFFIX=; \ erik> ALLSYMSFLAGS=""; \ erik> NOALLSYMSFLAGS=""; \ erik> SHAREDFLAGS="$(CFLAGS) $(SHARED_LDFLAGS) -h $$SHLIB$$SHLIB_SOVER$$SHLIB_SUFFIX -Wl,-Bsymbolic"; \ erik> fi; \ erik> $(LINK_SO_DSO) erik> erik> I removed the lib prefix from SHLIB in order to pass all the tests erik> that tries to load the ossltest engine. erik> erik> I assume that was the decision, right ? Yes, that's exactly the idea. This commit message explains the reasoning (I hope): commit 9ee0ed3de66678a15db126d10b3e4226e835b8f5 Author: Richard Levitte Date: Mon Feb 15 18:29:09 2016 +0100 Big rename fest of engine DSO names, from libFOO.so to FOO.so The engine DSOs were named as if they were shared libraries, and could end up having all sorts of fancy names: Cygwin: cygFOO.dll Mingw: FOOeay32.dll Unix: libFOO.so / libFOO.sl / libFOO.dylib / ... This may be confusing, since they look like libraries one should link with at link time, when they're just DSOs. It's therefore time to rename them, and do it consistently on all platforms: Cygwin & Mingw: FOO.dll Unix: FOO.{so,sl,dylib,...} Interestingly enough, the MSVC and VMS builds always did it this way. Reviewed-by: Andy Polyakov Thanks for notifying! Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From nmav at redhat.com Wed Feb 24 08:00:21 2016 From: nmav at redhat.com (Nikos Mavrogiannopoulos) Date: Wed, 24 Feb 2016 09:00:21 +0100 Subject: [openssl-dev] Ubsec and Chil engines In-Reply-To: <1456222523.11980.8.camel@redhat.com> References: <56C6FCFA.4040602@openssl.org> <5B8F45EA-5867-4832-916A-6B31A323A59C@temme.net> <1456136196.3289.26.camel@redhat.com> <1456222523.11980.8.camel@redhat.com> Message-ID: <1456300821.2889.6.camel@redhat.com> -------- Forwarded Message -------- From: Robert Relyea To: Nikos Mavrogiannopoulos Cc: openssl-dev at openss l.org Subject: Re: [openssl-dev] Ubsec and Chil engines Date: Tue, 23 Feb 2016 12:28:25 -0500 (EST) ----- Nikos Mavrogiannopoulos wrote: > On Mon, 2016-02-22 at 15:08 +0100, Jaroslav Imrich wrote: > > On 22 February 2016 at 11:16, Nikos Mavrogiannopoulos > co > > m> wrote: > > >??That's an implementation detail. As far as I know engine_pkcs11 > > > does not require re-authentication after fork. It handles the > > > pkcs11 peculiarities internally. > > AFAIK this works by caching the PIN in engine_pkcs11 internally and > > is OK for most of the use cases with smartcards. However HSMs > > usually > > use more complex authentication schemes where this approach does > > not > > work i.e. in order to login there must be N of M physical > > tokens/cards with passwords presented in a sequence (requires > > vendor > > specific extensions when used via PKCS#11). CHIL engine already > > handles such schemes very well and does not need to reauthenticate > > after fork. >? > I find that discussion more suitable to the PKCS #11 working group > than > here. It cannot be solved by openssl devevlopers. In any case, I > don't > find the solution to any problem in a standardized API is "let's make > our own better API". Why not work towards fixing the PKCS #11 spec? >? > In any case, there _are_ PKCS #11 modules which continue working > after fork (opendnssec's softhsm for example). So the issue is not > something that cannot be addressed within PKCS #11. The osasis pkcs 11 group is already planning on updating the semantic in a future pkcs 11 release. You can track the technicial committee work here https://www.oasis-open.org/apps/org/workgroup/pkcs11? If you have fully formed proposals for PKCS 11 let me know and we can look at adding it to the spec.? Bob From gvanem at yahoo.no Wed Feb 24 10:29:13 2016 From: gvanem at yahoo.no (Gisle Vanem) Date: Wed, 24 Feb 2016 11:29:13 +0100 Subject: [openssl-dev] MSVC 2015 internal compiler error In-Reply-To: <56CC81FB.2000107@openssl.org> References: <56CC81FB.2000107@openssl.org> Message-ID: <56CD85F9.6050307@yahoo.no> Matt Caswell wrote: > The attached seems to avoid the problem - but then for reasons I cannot > understand link errors result later on in the build. I too can confirm that your patch fixes MSVC-2105 compilation. Thanks a million! But as you wrote, the link fails. Due to util/mkdef.pl needs an update? I looked at this .pl-file, but I'm a n00b when it comes to Perl. So I fail to see how it now should define all needed .def symbols. As it's now, ssleay32.dll export only these: BIO_f_ssl BIO_new_ssl BIO_ssl_copy_session_id BIO_ssl_shutdown BIO_new_buffer_ssl_connect BIO_new_ssl_connect But is building with -DOPENSSL_OPT_WINDLL (i.e. __declspec(dllimport) while using the OpenSSL .DLLs) still supported? If so, what is the .def-files good for then? -- --gv From matt at openssl.org Wed Feb 24 10:35:26 2016 From: matt at openssl.org (Matt Caswell) Date: Wed, 24 Feb 2016 10:35:26 +0000 Subject: [openssl-dev] MSVC 2015 internal compiler error In-Reply-To: <56CD85F9.6050307@yahoo.no> References: <56CC81FB.2000107@openssl.org> <56CD85F9.6050307@yahoo.no> Message-ID: <56CD876E.7020404@openssl.org> On 24/02/16 10:29, Gisle Vanem wrote: > Matt Caswell wrote: > >> The attached seems to avoid the problem - but then for reasons I cannot >> understand link errors result later on in the build. > > I too can confirm that your patch fixes MSVC-2105 compilation. > Thanks a million! > > But as you wrote, the link fails. Due to util/mkdef.pl needs > an update? I looked at this .pl-file, but I'm a n00b when it > comes to Perl. So I fail to see how it now should define all > needed .def symbols. > > As it's now, ssleay32.dll export only these: > BIO_f_ssl > BIO_new_ssl > BIO_ssl_copy_session_id > BIO_ssl_shutdown > BIO_new_buffer_ssl_connect > BIO_new_ssl_connect > > But is building with -DOPENSSL_OPT_WINDLL (i.e. __declspec(dllimport) > while using the OpenSSL .DLLs) still supported? If so, what is the > .def-files good for then? > The complete patch is attached. This is currently going through review, and solves the link issue. Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: vs2015-bug.patch Type: text/x-patch Size: 2011 bytes Desc: not available URL: From rt at openssl.org Wed Feb 24 12:04:02 2016 From: rt at openssl.org (J Mohan Rao Arisankala via RT) Date: Wed, 24 Feb 2016 12:04:02 +0000 Subject: [openssl-dev] [openssl.org #4342] few missing malloc return checks and free in error paths In-Reply-To: References: Message-ID: Hi, I have the below mentioned changes in the PR: https://github.com/openssl/openssl/pull/740, please have a look. BIO_ADDR_new, ossl_hmac_init, b64_new, ok_new, pkey_hmac_init: - added missing checks for malloc return value. EC_KEY_new_method, ossl_hmac_copy, dane_ctx_enable: - releasing memory in few missing error paths EVP_DigestInit_ex: - remove additional check for ?type? and doing clear free instead of free ossl_hmac_cleanup, pkey_hmac_cleanup: - allow to invoke with NULL data - using EVP_PKEY_CTX_[get|set]_data Thanks, Mohan -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4342 Please log in as guest with password guest if prompted From rt at openssl.org Wed Feb 24 12:07:05 2016 From: rt at openssl.org (J Mohan Rao Arisankala via RT) Date: Wed, 24 Feb 2016 12:07:05 +0000 Subject: [openssl-dev] [openssl.org #4343] master: EC_KEY_priv2buf (): check parameter sanity In-Reply-To: References: Message-ID: Hi, I have PR https://github.com/openssl/openssl/pull/739 with the below changes, please have a look. - In EC_KEY_priv2buf(), check for pbuf sanity. - If invoked with NULL, gracefully returns the key length. Thanks, Mohan -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4343 Please log in as guest with password guest if prompted From doctor at doctor.nl2k.ab.ca Wed Feb 24 15:50:25 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Wed, 24 Feb 2016 08:50:25 -0700 Subject: [openssl-dev] SSL_library_init Message-ID: <20160224155025.GA16088@doctor.nl2k.ab.ca> As of 2106-20-24 SSL_librbary_init may not be avialable in the libssl.so . Is their a workaround for this? -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Broadcasting the truth for 25 years From gvanem at yahoo.no Wed Feb 24 16:48:59 2016 From: gvanem at yahoo.no (Gisle Vanem) Date: Wed, 24 Feb 2016 17:48:59 +0100 Subject: [openssl-dev] MSVC 2015 internal compiler error In-Reply-To: <56CD876E.7020404@openssl.org> References: <56CC81FB.2000107@openssl.org> <56CD85F9.6050307@yahoo.no> <56CD876E.7020404@openssl.org> Message-ID: <56CDDEFB.4020504@yahoo.no> Matt Caswell wrote: > The complete patch is attached. This is currently going through review, > and solves the link issue. That brought MSVC-2015 back on track. Thanks! -- --gv From datta.pm at gmail.com Wed Feb 24 17:09:49 2016 From: datta.pm at gmail.com (Datta Prabhu Maddikunta) Date: Wed, 24 Feb 2016 09:09:49 -0800 Subject: [openssl-dev] Fwd: Assembly code errors while building openssl-1.0.2f on Ubuntu 14.04 In-Reply-To: References: Message-ID: Reposting on openssl-dev for some solution. ---------- Forwarded message ---------- From: Datta Prabhu Maddikunta Date: Tue, Feb 23, 2016 at 5:06 PM Subject: Re: Assembly code errors while building openssl-1.0.2f on Ubuntu 14.04 To: openssl-users at openssl.org Hi Team, > > I am trying to build 'openssl-1.0.2f' on my Ubuntu 14.04 and I end up > seeing the " > Error: no such instruction: `vpclmulqdq $0,%xmm6,%xmm14,%xmm0'" errors on > my machine(Please see the complete error at the end of this mail.). > > The o/p of uname is as below: > > ----------- > $ uname -a > Linux 3.13.0-74-generic #118-Ubuntu SMP Thu Dec 17 22:52:10 > UTC 2015 x86_64 x86_64 x86_64 GNU/Linux > ----------- > My GNU assembler version is as below: > ================ $gcc -Wa,-v -c -o /dev/null -x assembler /dev/null GNU assembler version 2.24 (x86_64-linux-gnu) using BFD version (GNU Binutils for Ubuntu) 2.24 ================= > I can provide any further information required . > > Can anyone guess the reason why this error is being thrown on my machine? > > Any inputs would be appreciated ., > > Thanks., > Datta M > > > ============================================= > ...... > /usr/bin/perl asm/ghash-x86_64.pl elf > ghash-x86_64.s > /bin/gcc -I.. -I../.. -I../modes -I../asn1 -I../evp > -I../../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT > -DDSO_DLFCN -DHAVE_DLFCN_H -DSSL_ALLOW_ADH -m64 -DL_ENDIAN -O3 -Wall > -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 > -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM > -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM > -DECP_NISTZ256_ASM -c -o ghash-x86_64.o ghash-x86_64.s > /bin/as: Execution > of /bin/compat-as/as failed with error code 0 > ghash-x86_64.s: Assembler messages: > `vpclmulqdq $17,%xmm2,%xmm0,%xmm1' > ghash-x86_64.s:1282: Error: no such instruction: `vpclmulqdq > $0,%xmm2,%xmm0,%xmm0' > ghash-x86_64.s:1283: Error: no such instruction: `vpclmulqdq > $0,%xmm6,%xmm3,%xmm3' > ghash-x86_64.s:1312: Error: no such instruction: `vpclmulqdq > $17,%xmm2,%xmm0,%xmm1' > ghash-x86_64.s:1313: Error: no such instruction: `vpclmulqdq > $0,%xmm2,%xmm0,%xmm0' > ghash-x86_64.s:1314: Error: no such instruction: `vpclmulqdq > $0,%xmm6,%xmm3,%xmm3' > ghash-x86_64.s:1383: Error: no such instruction: `vpclmulqdq > $0,%xmm6,%xmm14,%xmm0' > ghash-x86_64.s:1386: Error: no such instruction: `vpclmulqdq > $17,%xmm6,%xmm14,%xmm1' > ghash-x86_64.s:1390: Error: no such instruction: `vpclmulqdq > $0,%xmm7,%xmm9,%xmm2' > ghash-x86_64.s:1394: Error: no such instruction: `vpclmulqdq > $0,%xmm6,%xmm15,%xmm3' > ghash-x86_64.s:1396: Error: no such instruction: `vpclmulqdq > $17,%xmm6,%xmm15,%xmm4' > ghash-x86_64.s:1400: Error: no such instruction: `vpclmulqdq > $16,%xmm7,%xmm8,%xmm5' > ghash-x86_64.s:1405: Error: no such instruction: `vpclmulqdq > $0,%xmm6,%xmm14,%xmm0' > ghash-x86_64.s:1408: Error: no such instruction: `vpclmulqdq > $17,%xmm6,%xmm14,%xmm1' > ghash-x86_64.s:1411: Error: no such instruction: `vpclmulqdq > $0,%xmm7,%xmm9,%xmm2' > ghash-x86_64.s:1416: Error: no such instruction: `vpclmulqdq > $0,%xmm6,%xmm15,%xmm3' > ghash-x86_64.s:1419: Error: no such instruction: `vpclmulqdq > $17,%xmm6,%xmm15,%xmm4' > ghash-x86_64.s:1423: Error: no such instruction: `vpclmulqdq > $16,%xmm7,%xmm8,%xmm5' > ghash-x86_64.s:1429: Error: no such instruction: `vpclmulqdq > $0,%xmm6,%xmm14,%xmm0' > ghash-x86_64.s:1432: Error: no such instruction: `vpclmulqdq > $17,%xmm6,%xmm14,%xmm1' > ghash-x86_64.s:1436: Error: no such instruction: `vpclmulqdq > $0,%xmm7,%xmm9,%xmm2' > ghash-x86_64.s:1441: Error: no such instruction: `vpclmulqdq > $0,%xmm6,%xmm15,%xmm3' > ghash-x86_64.s:1444: Error: no such instruction: `vpclmulqdq > $17,%xmm6,%xmm15,%xmm4' > ghash-x86_64.s:1448: Error: no such instruction: `vpclmulqdq > $16,%xmm7,%xmm8,%xmm5' > ghash-x86_64.s:1454: Error: no such instruction: `vpclmulqdq > $0,%xmm6,%xmm14,%xmm0' > ghash-x86_64.s:1457: Error: no such instruction: `vpclmulqdq > $17,%xmm6,%xmm14,%xmm1' > ghash-x86_64.s:1460: Error: no such instruction: `vpclmulqdq > $16,%xmm7,%xmm9,%xmm2' > ghash-x86_64.s:1476: Error: no such instruction: `vpclmulqdq > $0,%xmm6,%xmm15,%xmm10' > ghash-x86_64.s:1479: Error: no such instruction: `vpclmulqdq > $17,%xmm6,%xmm15,%xmm11' > ghash-x86_64.s:1483: Error: no such instruction: `vpclmulqdq > $0,%xmm7,%xmm8,%xmm12' > ghash-x86_64.s:1488: Error: no such instruction: `vpclmulqdq > $0,%xmm6,%xmm14,%xmm0' > ghash-x86_64.s:1491: Error: no such instruction: `vpclmulqdq > $17,%xmm6,%xmm14,%xmm1' > ghash-x86_64.s:1495: Error: no such instruction: `vpclmulqdq > $0,%xmm7,%xmm9,%xmm2' > ghash-x86_64.s:1501: Error: no such instruction: `vpclmulqdq > $0,%xmm6,%xmm15,%xmm3' > ghash-x86_64.s:1505: Error: no such instruction: `vpclmulqdq > $17,%xmm6,%xmm15,%xmm4' > ghash-x86_64.s:1513: Error: no such instruction: `vpclmulqdq > $16,%xmm7,%xmm8,%xmm5' > ghash-x86_64.s:1520: Error: no such instruction: `vpclmulqdq > $0,%xmm6,%xmm14,%xmm0' > ghash-x86_64.s:1523: Error: no such instruction: `vpclmulqdq > $17,%xmm6,%xmm14,%xmm1' > ghash-x86_64.s:1527: Error: no such instruction: `vpclmulqdq > $0,%xmm7,%xmm9,%xmm2' > ghash-x86_64.s:1532: Error: no such instruction: `vpclmulqdq > $16,(%r10),%xmm10,%xmm10' > ghash-x86_64.s:1533: Error: no such instruction: `vpclmulqdq > $0,%xmm6,%xmm15,%xmm3' > ghash-x86_64.s:1536: Error: no such instruction: `vpclmulqdq > $17,%xmm6,%xmm15,%xmm4' > ghash-x86_64.s:1540: Error: no such instruction: `vpclmulqdq > $16,%xmm7,%xmm8,%xmm5' > ghash-x86_64.s:1546: Error: no such instruction: `vpclmulqdq > $0,%xmm6,%xmm14,%xmm0' > ghash-x86_64.s:1549: Error: no such instruction: `vpclmulqdq > $17,%xmm6,%xmm14,%xmm1' > ghash-x86_64.s:1553: Error: no such instruction: `vpclmulqdq > $0,%xmm7,%xmm9,%xmm2' > ghash-x86_64.s:1560: Error: no such instruction: `vpclmulqdq > $0,%xmm6,%xmm15,%xmm3' > ghash-x86_64.s:1563: Error: no such instruction: `vpclmulqdq > $17,%xmm6,%xmm15,%xmm4' > ghash-x86_64.s:1565: Error: no such instruction: `vpclmulqdq > $16,(%r10),%xmm10,%xmm10' > ghash-x86_64.s:1569: Error: no such instruction: `vpclmulqdq > $16,%xmm7,%xmm8,%xmm5' > ghash-x86_64.s:1575: Error: no such instruction: `vpclmulqdq > $0,%xmm6,%xmm14,%xmm0' > ghash-x86_64.s:1577: Error: no such instruction: `vpclmulqdq > $17,%xmm6,%xmm14,%xmm1' > ghash-x86_64.s:1580: Error: no such instruction: `vpclmulqdq > $16,%xmm7,%xmm9,%xmm2' > ghash-x86_64.s:1606: Error: no such instruction: `vpclmulqdq > $0,%xmm6,%xmm15,%xmm0' > ghash-x86_64.s:1610: Error: no such instruction: `vpclmulqdq > $17,%xmm6,%xmm15,%xmm1' > ghash-x86_64.s:1614: Error: no such instruction: `vpclmulqdq > $0,%xmm7,%xmm8,%xmm2' > ghash-x86_64.s:1621: Error: no such instruction: `vpclmulqdq > $0,%xmm6,%xmm15,%xmm0' > ghash-x86_64.s:1625: Error: no such instruction: `vpclmulqdq > $17,%xmm6,%xmm15,%xmm1' > ghash-x86_64.s:1629: Error: no such instruction: `vpclmulqdq > $0,%xmm7,%xmm8,%xmm2' > ghash-x86_64.s:1636: Error: no such instruction: `vpclmulqdq > $0,%xmm6,%xmm15,%xmm0' > ghash-x86_64.s:1640: Error: no such instruction: `vpclmulqdq > $17,%xmm6,%xmm15,%xmm1' > ghash-x86_64.s:1644: Error: no such instruction: `vpclmulqdq > $0,%xmm7,%xmm8,%xmm2' > ghash-x86_64.s:1651: Error: no such instruction: `vpclmulqdq > $0,%xmm6,%xmm15,%xmm0' > ghash-x86_64.s:1655: Error: no such instruction: `vpclmulqdq > $17,%xmm6,%xmm15,%xmm1' > ghash-x86_64.s:1659: Error: no such instruction: `vpclmulqdq > $0,%xmm7,%xmm8,%xmm2' > ghash-x86_64.s:1666: Error: no such instruction: `vpclmulqdq > $0,%xmm6,%xmm15,%xmm0' > ghash-x86_64.s:1670: Error: no such instruction: `vpclmulqdq > $17,%xmm6,%xmm15,%xmm1' > ghash-x86_64.s:1674: Error: no such instruction: `vpclmulqdq > $0,%xmm7,%xmm8,%xmm2' > ghash-x86_64.s:1681: Error: no such instruction: `vpclmulqdq > $0,%xmm6,%xmm15,%xmm0' > ghash-x86_64.s:1685: Error: no such instruction: `vpclmulqdq > $17,%xmm6,%xmm15,%xmm1' > ghash-x86_64.s:1689: Error: no such instruction: `vpclmulqdq > $0,%xmm7,%xmm8,%xmm2' > ghash-x86_64.s:1700: Error: no such instruction: `vpclmulqdq > $0,%xmm6,%xmm15,%xmm0' > ghash-x86_64.s:1703: Error: no such instruction: `vpclmulqdq > $17,%xmm6,%xmm15,%xmm1' > ghash-x86_64.s:1705: Error: no such instruction: `vpclmulqdq > $0,%xmm7,%xmm8,%xmm2' > ghash-x86_64.s:1720: Error: no such instruction: `vpclmulqdq > $16,%xmm12,%xmm10,%xmm9' > ghash-x86_64.s:1724: Error: no such instruction: `vpclmulqdq > $16,%xmm12,%xmm10,%xmm9' > make[2]: *** [ghash-x86_64.o] Error 1 > make[2]: Leaving directory `/openssl/openssl-1.0.2e/crypto/modes' > make[1]: *** [subdirs] Error 1 > make[1]: Leaving directory /openssl/openssl-1.0.2e/crypto' > make: *** [build_crypto] Error 1 > scons: *** Error 2 > scons: *** [/openssl/.build] Error 2 > scons: building terminated because of errors. > > ============================================= > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hyc at highlandsun.com Wed Feb 24 17:19:40 2016 From: hyc at highlandsun.com (Howard Chu) Date: Wed, 24 Feb 2016 17:19:40 +0000 Subject: [openssl-dev] SSL_library_init In-Reply-To: <20160224155025.GA16088@doctor.nl2k.ab.ca> References: <20160224155025.GA16088@doctor.nl2k.ab.ca> Message-ID: <56CDE62C.4000006@highlandsun.com> The Doctor wrote: > As of 2106-20-24 SSL_librbary_init may not be avialable in the libssl.so . Wow, did you really come back 90 years in your TARDIS just to tell us this? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ From rt at openssl.org Wed Feb 24 17:33:29 2016 From: rt at openssl.org (Dmitry Belyavsky via RT) Date: Wed, 24 Feb 2016 17:33:29 +0000 Subject: [openssl-dev] [openssl.org #4344] Re: Missing accessor to the EVP_CIPHER_CTX member oiv In-Reply-To: References: Message-ID: Dear Richard, The patch you suggested seems not to break at least self-compatibility for the smime -enc command. Is this enough or should I do some more tests? Thank you! On Fri, Feb 19, 2016 at 12:40 AM, Dmitry Belyavsky wrote: > Dear Richard, > > Sorry for the delay. I am out of office now so I will check it some days > later. > > > On Thursday, February 18, 2016, Richard Levitte via RT > wrote: > >> Did that help, can we close this ticket now? >> >> Vid Ons, 17 Feb 2016 kl. 11.25.26, skrev levitte: >> > May I suggest that you use EVP_CIPHER_set_asn1_iv() and/or >> > EVP_CIPHER_get_asn1_iv()? With a temporary ASN1_TYPE to which you >> > assign >> > gcp->iv, that should be perfectly possible, no? >> > >> > Cheers, >> > Richard >> > >> > Vid Ons, 17 Feb 2016 kl. 09.53.04, skrev beldmit at gmail.com: >> > > Dear Richard, >> > > >> > > I am not sure it will not break the compatibility. >> > > Both implementations of the GOST ciphers require access to this >> > > field. >> > > >> > > On Wed, Feb 17, 2016 at 12:42 PM, Richard Levitte via RT >> > > >> > > wrote: >> > > >> > > > Hi, >> > > > >> > > > I'm sorry, the oiv field is EVP private. Sure, it's been accessible >> > > > (and >> > > > thoroughly misused in some cases) when EVP_CIPHER_CTX was open, but >> > > > in >> > > > essence, >> > > > it's a EVP private store of the IV that was given at >> > > > EVP_CipherInit(). >> > > > >> > > > If you want to retain a copy of the original IV, I suggest you have >> > > > one in >> > > > GOSTs structure and take a copy of the IV given to the init() >> > > > function. >> > > > >> > > > Thank you for the reminder, I meant to deal with this further. oiv >> > > > should >> > > > really not be publically accessible at all, not even as a constant. >> > > > >> > > > Cheers, >> > > > Richard >> > > > >> > > > Vid Sat, 23 Jan 2016 kl. 09.40.19, skrev beldmit at gmail.com: >> > > > > Hello, >> > > > > >> > > > > After making the EVP_CIPHER_CTX struct opaque I found that there >> > > > > is a >> > > > > missing non-const accessor to the oiv member. It is used in GOST >> > > > > engine >> > > > > when we set the cipher parameters from the ASN1 parameters. >> > > > > >> > > > > Thank you! >> > > > > >> > > > >> > > > >> > > > -- >> > > > Richard Levitte >> > > > levitte at openssl.org >> > > > >> > > > -- >> > > > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4267 >> > > > Please log in as guest with password guest if prompted >> > > > >> > > > >> > > >> > > >> > >> > >> > -- >> > Richard Levitte >> > levitte at openssl.org >> >> >> -- >> Richard Levitte >> levitte at openssl.org >> >> -- >> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4267 >> Please log in as guest with password guest if prompted >> >> > > -- > SY, Dmitry Belyavsky > -- SY, Dmitry Belyavsky -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4344 Please log in as guest with password guest if prompted From rt at openssl.org Wed Feb 24 17:47:27 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Wed, 24 Feb 2016 17:47:27 +0000 Subject: [openssl-dev] [openssl.org #4267] Missing accessor to the EVP_CIPHER_CTX member oiv In-Reply-To: References: Message-ID: If you're happy, I'm happy; it's that easy. If you think it's good, then it's time to close this ticket. You decide. Cheers, Richard Vid Ons, 24 Feb 2016 kl. 17.33.29, skrev beldmit at gmail.com: > Dear Richard, > > The patch you suggested seems not to break at least self-compatibility for > the smime -enc command. > Is this enough or should I do some more tests? > > Thank you! > > On Fri, Feb 19, 2016 at 12:40 AM, Dmitry Belyavsky > wrote: > > > Dear Richard, > > > > Sorry for the delay. I am out of office now so I will check it some days > > later. > > > > > > On Thursday, February 18, 2016, Richard Levitte via RT > > wrote: > > > >> Did that help, can we close this ticket now? > >> > >> Vid Ons, 17 Feb 2016 kl. 11.25.26, skrev levitte: > >> > May I suggest that you use EVP_CIPHER_set_asn1_iv() and/or > >> > EVP_CIPHER_get_asn1_iv()? With a temporary ASN1_TYPE to which you > >> > assign > >> > gcp->iv, that should be perfectly possible, no? > >> > > >> > Cheers, > >> > Richard > >> > > >> > Vid Ons, 17 Feb 2016 kl. 09.53.04, skrev beldmit at gmail.com: > >> > > Dear Richard, > >> > > > >> > > I am not sure it will not break the compatibility. > >> > > Both implementations of the GOST ciphers require access to this > >> > > field. > >> > > > >> > > On Wed, Feb 17, 2016 at 12:42 PM, Richard Levitte via RT > >> > > > >> > > wrote: > >> > > > >> > > > Hi, > >> > > > > >> > > > I'm sorry, the oiv field is EVP private. Sure, it's been accessible > >> > > > (and > >> > > > thoroughly misused in some cases) when EVP_CIPHER_CTX was open, but > >> > > > in > >> > > > essence, > >> > > > it's a EVP private store of the IV that was given at > >> > > > EVP_CipherInit(). > >> > > > > >> > > > If you want to retain a copy of the original IV, I suggest you have > >> > > > one in > >> > > > GOSTs structure and take a copy of the IV given to the init() > >> > > > function. > >> > > > > >> > > > Thank you for the reminder, I meant to deal with this further. oiv > >> > > > should > >> > > > really not be publically accessible at all, not even as a constant. > >> > > > > >> > > > Cheers, > >> > > > Richard > >> > > > > >> > > > Vid Sat, 23 Jan 2016 kl. 09.40.19, skrev beldmit at gmail.com: > >> > > > > Hello, > >> > > > > > >> > > > > After making the EVP_CIPHER_CTX struct opaque I found that there > >> > > > > is a > >> > > > > missing non-const accessor to the oiv member. It is used in GOST > >> > > > > engine > >> > > > > when we set the cipher parameters from the ASN1 parameters. > >> > > > > > >> > > > > Thank you! > >> > > > > > >> > > > > >> > > > > >> > > > -- > >> > > > Richard Levitte > >> > > > levitte at openssl.org > >> > > > > >> > > > -- > >> > > > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4267 > >> > > > Please log in as guest with password guest if prompted > >> > > > > >> > > > > >> > > > >> > > > >> > > >> > > >> > -- > >> > Richard Levitte > >> > levitte at openssl.org > >> > >> > >> -- > >> Richard Levitte > >> levitte at openssl.org > >> > >> -- > >> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4267 > >> Please log in as guest with password guest if prompted > >> > >> > > > > -- > > SY, Dmitry Belyavsky > > > > > -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4267 Please log in as guest with password guest if prompted From beldmit at gmail.com Wed Feb 24 17:49:01 2016 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Wed, 24 Feb 2016 20:49:01 +0300 Subject: [openssl-dev] [openssl.org #4267] Missing accessor to the EVP_CIPHER_CTX member oiv In-Reply-To: References: Message-ID: Well, I think the ticket may be closed. Thank you! On Wed, Feb 24, 2016 at 8:47 PM, Richard Levitte via RT wrote: > If you're happy, I'm happy; it's that easy. If you think it's good, then > it's > time to close this ticket. You decide. > > Cheers, > Richard > > Vid Ons, 24 Feb 2016 kl. 17.33.29, skrev beldmit at gmail.com: > > Dear Richard, > > > > The patch you suggested seems not to break at least self-compatibility > for > > the smime -enc command. > > Is this enough or should I do some more tests? > > > > Thank you! > > > > On Fri, Feb 19, 2016 at 12:40 AM, Dmitry Belyavsky > > wrote: > > > > > Dear Richard, > > > > > > Sorry for the delay. I am out of office now so I will check it some > days > > > later. > > > > > > > > > On Thursday, February 18, 2016, Richard Levitte via RT > > > > wrote: > > > > > >> Did that help, can we close this ticket now? > > >> > > >> Vid Ons, 17 Feb 2016 kl. 11.25.26, skrev levitte: > > >> > May I suggest that you use EVP_CIPHER_set_asn1_iv() and/or > > >> > EVP_CIPHER_get_asn1_iv()? With a temporary ASN1_TYPE to which you > > >> > assign > > >> > gcp->iv, that should be perfectly possible, no? > > >> > > > >> > Cheers, > > >> > Richard > > >> > > > >> > Vid Ons, 17 Feb 2016 kl. 09.53.04, skrev beldmit at gmail.com: > > >> > > Dear Richard, > > >> > > > > >> > > I am not sure it will not break the compatibility. > > >> > > Both implementations of the GOST ciphers require access to this > > >> > > field. > > >> > > > > >> > > On Wed, Feb 17, 2016 at 12:42 PM, Richard Levitte via RT > > >> > > > > >> > > wrote: > > >> > > > > >> > > > Hi, > > >> > > > > > >> > > > I'm sorry, the oiv field is EVP private. Sure, it's been > accessible > > >> > > > (and > > >> > > > thoroughly misused in some cases) when EVP_CIPHER_CTX was open, > but > > >> > > > in > > >> > > > essence, > > >> > > > it's a EVP private store of the IV that was given at > > >> > > > EVP_CipherInit(). > > >> > > > > > >> > > > If you want to retain a copy of the original IV, I suggest you > have > > >> > > > one in > > >> > > > GOSTs structure and take a copy of the IV given to the init() > > >> > > > function. > > >> > > > > > >> > > > Thank you for the reminder, I meant to deal with this further. > oiv > > >> > > > should > > >> > > > really not be publically accessible at all, not even as a > constant. > > >> > > > > > >> > > > Cheers, > > >> > > > Richard > > >> > > > > > >> > > > Vid Sat, 23 Jan 2016 kl. 09.40.19, skrev beldmit at gmail.com: > > >> > > > > Hello, > > >> > > > > > > >> > > > > After making the EVP_CIPHER_CTX struct opaque I found that > there > > >> > > > > is a > > >> > > > > missing non-const accessor to the oiv member. It is used in > GOST > > >> > > > > engine > > >> > > > > when we set the cipher parameters from the ASN1 parameters. > > >> > > > > > > >> > > > > Thank you! > > >> > > > > > > >> > > > > > >> > > > > > >> > > > -- > > >> > > > Richard Levitte > > >> > > > levitte at openssl.org > > >> > > > > > >> > > > -- > > >> > > > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4267 > > >> > > > Please log in as guest with password guest if prompted > > >> > > > > > >> > > > > > >> > > > > >> > > > > >> > > > >> > > > >> > -- > > >> > Richard Levitte > > >> > levitte at openssl.org > > >> > > >> > > >> -- > > >> Richard Levitte > > >> levitte at openssl.org > > >> > > >> -- > > >> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4267 > > >> Please log in as guest with password guest if prompted > > >> > > >> > > > > > > -- > > > SY, Dmitry Belyavsky > > > > > > > > > > > > -- > Richard Levitte > levitte at openssl.org > > -- > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4267 > Please log in as guest with password guest if prompted > > -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Wed Feb 24 17:49:09 2016 From: rt at openssl.org (Dmitry Belyavsky via RT) Date: Wed, 24 Feb 2016 17:49:09 +0000 Subject: [openssl-dev] [openssl.org #4267] Missing accessor to the EVP_CIPHER_CTX member oiv In-Reply-To: References: Message-ID: Well, I think the ticket may be closed. Thank you! On Wed, Feb 24, 2016 at 8:47 PM, Richard Levitte via RT wrote: > If you're happy, I'm happy; it's that easy. If you think it's good, then > it's > time to close this ticket. You decide. > > Cheers, > Richard > > Vid Ons, 24 Feb 2016 kl. 17.33.29, skrev beldmit at gmail.com: > > Dear Richard, > > > > The patch you suggested seems not to break at least self-compatibility > for > > the smime -enc command. > > Is this enough or should I do some more tests? > > > > Thank you! > > > > On Fri, Feb 19, 2016 at 12:40 AM, Dmitry Belyavsky > > wrote: > > > > > Dear Richard, > > > > > > Sorry for the delay. I am out of office now so I will check it some > days > > > later. > > > > > > > > > On Thursday, February 18, 2016, Richard Levitte via RT > > > > wrote: > > > > > >> Did that help, can we close this ticket now? > > >> > > >> Vid Ons, 17 Feb 2016 kl. 11.25.26, skrev levitte: > > >> > May I suggest that you use EVP_CIPHER_set_asn1_iv() and/or > > >> > EVP_CIPHER_get_asn1_iv()? With a temporary ASN1_TYPE to which you > > >> > assign > > >> > gcp->iv, that should be perfectly possible, no? > > >> > > > >> > Cheers, > > >> > Richard > > >> > > > >> > Vid Ons, 17 Feb 2016 kl. 09.53.04, skrev beldmit at gmail.com: > > >> > > Dear Richard, > > >> > > > > >> > > I am not sure it will not break the compatibility. > > >> > > Both implementations of the GOST ciphers require access to this > > >> > > field. > > >> > > > > >> > > On Wed, Feb 17, 2016 at 12:42 PM, Richard Levitte via RT > > >> > > > > >> > > wrote: > > >> > > > > >> > > > Hi, > > >> > > > > > >> > > > I'm sorry, the oiv field is EVP private. Sure, it's been > accessible > > >> > > > (and > > >> > > > thoroughly misused in some cases) when EVP_CIPHER_CTX was open, > but > > >> > > > in > > >> > > > essence, > > >> > > > it's a EVP private store of the IV that was given at > > >> > > > EVP_CipherInit(). > > >> > > > > > >> > > > If you want to retain a copy of the original IV, I suggest you > have > > >> > > > one in > > >> > > > GOSTs structure and take a copy of the IV given to the init() > > >> > > > function. > > >> > > > > > >> > > > Thank you for the reminder, I meant to deal with this further. > oiv > > >> > > > should > > >> > > > really not be publically accessible at all, not even as a > constant. > > >> > > > > > >> > > > Cheers, > > >> > > > Richard > > >> > > > > > >> > > > Vid Sat, 23 Jan 2016 kl. 09.40.19, skrev beldmit at gmail.com: > > >> > > > > Hello, > > >> > > > > > > >> > > > > After making the EVP_CIPHER_CTX struct opaque I found that > there > > >> > > > > is a > > >> > > > > missing non-const accessor to the oiv member. It is used in > GOST > > >> > > > > engine > > >> > > > > when we set the cipher parameters from the ASN1 parameters. > > >> > > > > > > >> > > > > Thank you! > > >> > > > > > > >> > > > > > >> > > > > > >> > > > -- > > >> > > > Richard Levitte > > >> > > > levitte at openssl.org > > >> > > > > > >> > > > -- > > >> > > > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4267 > > >> > > > Please log in as guest with password guest if prompted > > >> > > > > > >> > > > > > >> > > > > >> > > > > >> > > > >> > > > >> > -- > > >> > Richard Levitte > > >> > levitte at openssl.org > > >> > > >> > > >> -- > > >> Richard Levitte > > >> levitte at openssl.org > > >> > > >> -- > > >> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4267 > > >> Please log in as guest with password guest if prompted > > >> > > >> > > > > > > -- > > > SY, Dmitry Belyavsky > > > > > > > > > > > > -- > Richard Levitte > levitte at openssl.org > > -- > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4267 > Please log in as guest with password guest if prompted > > -- SY, Dmitry Belyavsky -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4267 Please log in as guest with password guest if prompted From rt at openssl.org Wed Feb 24 18:14:25 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Wed, 24 Feb 2016 18:14:25 +0000 Subject: [openssl-dev] [openssl.org #4267] Missing accessor to the EVP_CIPHER_CTX member oiv In-Reply-To: References: Message-ID: Great! Closing now. Thank you. Vid Ons, 24 Feb 2016 kl. 17.47.26, skrev levitte: > If you're happy, I'm happy; it's that easy. If you think it's good, > then it's > time to close this ticket. You decide. > > Cheers, > Richard > > Vid Ons, 24 Feb 2016 kl. 17.33.29, skrev beldmit at gmail.com: > > Dear Richard, > > > > The patch you suggested seems not to break at least self- > > compatibility for > > the smime -enc command. > > Is this enough or should I do some more tests? > > > > Thank you! > > > > On Fri, Feb 19, 2016 at 12:40 AM, Dmitry Belyavsky > > > > wrote: > > > > > Dear Richard, > > > > > > Sorry for the delay. I am out of office now so I will check it some > > > days > > > later. > > > > > > > > > On Thursday, February 18, 2016, Richard Levitte via RT > > > > > > wrote: > > > > > >> Did that help, can we close this ticket now? > > >> > > >> Vid Ons, 17 Feb 2016 kl. 11.25.26, skrev levitte: > > >> > May I suggest that you use EVP_CIPHER_set_asn1_iv() and/or > > >> > EVP_CIPHER_get_asn1_iv()? With a temporary ASN1_TYPE to which > > >> > you > > >> > assign > > >> > gcp->iv, that should be perfectly possible, no? > > >> > > > >> > Cheers, > > >> > Richard > > >> > > > >> > Vid Ons, 17 Feb 2016 kl. 09.53.04, skrev beldmit at gmail.com: > > >> > > Dear Richard, > > >> > > > > >> > > I am not sure it will not break the compatibility. > > >> > > Both implementations of the GOST ciphers require access to > > >> > > this > > >> > > field. > > >> > > > > >> > > On Wed, Feb 17, 2016 at 12:42 PM, Richard Levitte via RT > > >> > > > > >> > > wrote: > > >> > > > > >> > > > Hi, > > >> > > > > > >> > > > I'm sorry, the oiv field is EVP private. Sure, it's been > > >> > > > accessible > > >> > > > (and > > >> > > > thoroughly misused in some cases) when EVP_CIPHER_CTX was > > >> > > > open, but > > >> > > > in > > >> > > > essence, > > >> > > > it's a EVP private store of the IV that was given at > > >> > > > EVP_CipherInit(). > > >> > > > > > >> > > > If you want to retain a copy of the original IV, I suggest > > >> > > > you have > > >> > > > one in > > >> > > > GOSTs structure and take a copy of the IV given to the > > >> > > > init() > > >> > > > function. > > >> > > > > > >> > > > Thank you for the reminder, I meant to deal with this > > >> > > > further. oiv > > >> > > > should > > >> > > > really not be publically accessible at all, not even as a > > >> > > > constant. > > >> > > > > > >> > > > Cheers, > > >> > > > Richard > > >> > > > > > >> > > > Vid Sat, 23 Jan 2016 kl. 09.40.19, skrev beldmit at gmail.com: > > >> > > > > Hello, > > >> > > > > > > >> > > > > After making the EVP_CIPHER_CTX struct opaque I found that > > >> > > > > there > > >> > > > > is a > > >> > > > > missing non-const accessor to the oiv member. It is used > > >> > > > > in GOST > > >> > > > > engine > > >> > > > > when we set the cipher parameters from the ASN1 > > >> > > > > parameters. > > >> > > > > > > >> > > > > Thank you! > > >> > > > > > > >> > > > > > >> > > > > > >> > > > -- > > >> > > > Richard Levitte > > >> > > > levitte at openssl.org > > >> > > > > > >> > > > -- > > >> > > > Ticket here: > > >> > > > http://rt.openssl.org/Ticket/Display.html?id=4267 > > >> > > > Please log in as guest with password guest if prompted > > >> > > > > > >> > > > > > >> > > > > >> > > > > >> > > > >> > > > >> > -- > > >> > Richard Levitte > > >> > levitte at openssl.org > > >> > > >> > > >> -- > > >> Richard Levitte > > >> levitte at openssl.org > > >> > > >> -- > > >> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4267 > > >> Please log in as guest with password guest if prompted > > >> > > >> > > > > > > -- > > > SY, Dmitry Belyavsky > > > > > > > > > > > > -- > Richard Levitte > levitte at openssl.org -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4267 Please log in as guest with password guest if prompted From kurt at roeckx.be Wed Feb 24 20:48:21 2016 From: kurt at roeckx.be (Kurt Roeckx) Date: Wed, 24 Feb 2016 21:48:21 +0100 Subject: [openssl-dev] Fwd: Assembly code errors while building openssl-1.0.2f on Ubuntu 14.04 In-Reply-To: References: Message-ID: <20160224204820.GA29538@roeckx.be> On Wed, Feb 24, 2016 at 09:09:49AM -0800, Datta Prabhu Maddikunta wrote: > > /bin/as: Execution > > of /bin/compat-as/as failed with error code 0 You're trying to cross compile? What is th target? How did you call Configure? Kurt From appro at openssl.org Wed Feb 24 20:58:09 2016 From: appro at openssl.org (Andy Polyakov) Date: Wed, 24 Feb 2016 21:58:09 +0100 Subject: [openssl-dev] Fwd: Assembly code errors while building openssl-1.0.2f on Ubuntu 14.04 In-Reply-To: <20160224204820.GA29538@roeckx.be> References: <20160224204820.GA29538@roeckx.be> Message-ID: <56CE1961.1010801@openssl.org> >>> /bin/as: Execution >>> of /bin/compat-as/as failed with error code 0 > > You're trying to cross compile? What is th target? > > How did you call Configure? On related note, similar problem was reported earlier, see for example https://mta.openssl.org/pipermail/openssl-dev/2015-June/001768.html, but fix was not applied at that time. It will be this time. Key question is not what does gcc -Wa,-v ...' print, but /bin/gcc. From rt at openssl.org Wed Feb 24 21:12:35 2016 From: rt at openssl.org (Rich Salz via RT) Date: Wed, 24 Feb 2016 21:12:35 +0000 Subject: [openssl-dev] [openssl.org #4137] [PATCH] In-Reply-To: References: Message-ID: fixed with commit b5292f7 Thank you! -- Rich Salz, OpenSSL dev team; rsalz at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4137 Please log in as guest with password guest if prompted From doctor at doctor.nl2k.ab.ca Wed Feb 24 23:40:34 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Wed, 24 Feb 2016 16:40:34 -0700 Subject: [openssl-dev] SSL_library_init In-Reply-To: <56CE19B5.3080100@trigofacile.com> References: <20160224155025.GA16088@doctor.nl2k.ab.ca> <56CE19B5.3080100@trigofacile.com> Message-ID: <20160224234034.GA21348@doctor.nl2k.ab.ca> On Wed, Feb 24, 2016 at 09:59:33PM +0100, Julien ?LIE wrote: > Hi The Doctor, > > >As of 2016-02-24 SSL_library_init may not be available in the libssl.so . > > > >Is there a workaround for this? > > Did you try OPENSSL_init_ssl()? > According to the documentation > https://www.openssl.org/docs/manmaster/ssl/SSL_library_init.html > > "The SSL_library_init() and OpenSSL_add_ssl_algorithms() functions were > deprecated in OpenSSL 1.1.0 by OPENSSL_init_ssl()." That should work, however we are going to need to distinguish between Openssl < 1.1 and Openssl >= 1.1 duing the configuration run. > > -- > Julien ?LIE > > ? ? Ils s'arr?taient tous les jours ? 5 heures, pour boire de > l'eau chaude? > ? Je prendrai un nuage de lait, je vous prie. ? (Ast?rix) > _______________________________________________ > inn-workers mailing list > inn-workers at lists.isc.org > https://lists.isc.org/mailman/listinfo/inn-workers -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Broadcasting the truth for 25 years From rsalz at akamai.com Thu Feb 25 00:55:38 2016 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 25 Feb 2016 00:55:38 +0000 Subject: [openssl-dev] SSL_library_init In-Reply-To: <20160224234034.GA21348@doctor.nl2k.ab.ca> References: <20160224155025.GA16088@doctor.nl2k.ab.ca> <56CE19B5.3080100@trigofacile.com> <20160224234034.GA21348@doctor.nl2k.ab.ca> Message-ID: > That should work, however we are going to need to distinguish between > > Openssl < 1.1 and > > Openssl >= 1.1 duing the configuration run. Looking at openssl/opensslv.h will let you figure it out and then have the right #ifdef's. From matt at openssl.org Thu Feb 25 09:24:02 2016 From: matt at openssl.org (Matt Caswell) Date: Thu, 25 Feb 2016 09:24:02 +0000 Subject: [openssl-dev] SSL_library_init In-Reply-To: <20160224155025.GA16088@doctor.nl2k.ab.ca> References: <20160224155025.GA16088@doctor.nl2k.ab.ca> Message-ID: <56CEC832.5000305@openssl.org> On 24/02/16 15:50, The Doctor wrote: > As of 2106-20-24 SSL_librbary_init may not be avialable in the libssl.so . > > Is their a workaround for this? > SSL_library_init is still available in ssl.h as a compatibility macro: #if OPENSSL_API_COMPAT < 0x10100000L # define SSL_library_init() OPENSSL_init_ssl(0, NULL) #endif Matt From mark at openssl.org Thu Feb 25 09:29:25 2016 From: mark at openssl.org (Mark J Cox) Date: Thu, 25 Feb 2016 09:29:25 +0000 Subject: [openssl-dev] Forthcoming OpenSSL releases Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Forthcoming OpenSSL releases ============================ The OpenSSL project team would like to announce the forthcoming release of OpenSSL versions 1.0.2g, 1.0.1s. These releases will be made available on 1st March 2016 between approximately 1300-1700 UTC. They will fix several security defects with maximum severity "high". Please see the following page for further details of severity levels: https://www.openssl.org/policies/secpolicy.html Please also note that, as per our previous announcements, support for 1.0.1 will end on 31st December 2016. Yours The OpenSSL Project Team -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJWzsjbAAoJEAEKUEB8TIy9ukoH/A+KQh0TPuC5CulMeFd4OiGy 7HV9bX/nCe4sKmW5IGYt6GDPFRnhup9WR9Dvz0C/sBjwttsnF+UZOUUfYbDw2liO YG46kiS95zbeU4yYFQwHr9Sf01o89ogEGrxCIlKQiA4aXSZwn9liI0a51y7izWUC xdj2GEgQ/fnVnlN/AyToVmoQxlrphXJx9FigLxTuXi1X6nvSNdEYB1VtOuqjanRu 8sR4UDCWYRZNT0L3as0IEU49X7ncwm5a85NR02SkVimevdbJw0mBT1ru4Zjddo88 oO5xpgSKy2a56xC8yQXURkVPvuFqUpfvyojLwOULUnWHCpnDhzn+ygdko2Pii3o= =XURc -----END PGP SIGNATURE----- From rt at openssl.org Thu Feb 25 13:13:41 2016 From: rt at openssl.org (yancm via RT) Date: Thu, 25 Feb 2016 13:13:41 +0000 Subject: [openssl-dev] [openssl.org #4345] Bug - Cannot build openssl-1.1.0-pre4-dev on NetBSD 6_Stable In-Reply-To: <4c16b2491b878e183f594c75f801f5bf.squirrel@wm.sdf.org> References: <4c16b2491b878e183f594c75f801f5bf.squirrel@wm.sdf.org> Message-ID: The first parts of this report are the actual build bug I think I am encountering, but also, at the end, I am asking for additional help with enabling the crypto-mdebug and crypto-mdebug-backtrace as I am trying to to diagnose a compatibility issue between tor and the openssl 1.1.0_dev branch. config and output: *****Config command and output***** # ./config --unified --debug --api=1.1.0 no-shared Operating system: i686-whatever-netbsd Configuring for BSD-x86-elf Configuring OpenSSL version 1.1.0-pre4-dev (0x0x10100004L) no-crypto-mdebug [default] OPENSSL_NO_CRYPTO_MDEBUG (skip dir) no-crypto-mdebug-backtrace [forced] OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE (skip dir) no-ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128 (skip dir) no-egd [default] OPENSSL_NO_EGD (skip dir) no-heartbeats [default] OPENSSL_NO_HEARTBEATS (skip dir) no-md2 [default] OPENSSL_NO_MD2 (skip dir) no-rc5 [default] OPENSSL_NO_RC5 (skip dir) no-sctp [default] OPENSSL_NO_SCTP (skip dir) no-shared [option] no-ssl-trace [default] OPENSSL_NO_SSL_TRACE (skip dir) no-static-engine [default] OPENSSL_NO_STATIC_ENGINE (skip dir) no-unit-test [default] OPENSSL_NO_UNIT_TEST (skip dir) no-zlib [default] no-zlib-dynamic [forced] Configuring for BSD-x86-elf IsMK1MF =no CC =cc CFLAG = -pthread -D_THREAD_SAFE -D_REENTRANT -DL_ENDIAN -Wall -O0 -g -DWHIRLPOOL_ASM -Wa,--noexecstack DEFINES =DSO_DLFCN HAVE_DLFCN_H OPENSSL_THREADS OPENSSL_NO_STATIC_ENGINE OPENSSL_PIC OPENSSL_BN_ASM_PART_WORDS OPENSSL_IA32_SSE2 OPENSSL_BN_ASM_MONT OPENSSL_BN_ASM_GF2m SHA1_ASM SHA256_ASM SHA512_ASM MD5_ASM RMD160_ASM AES_ASM VPAES_ASM GHASH_ASM ECP_NISTZ256_ASM POLY1305_ASM OPENSSL_API_COMPAT=0x10100000L LFLAG = PLIB_LFLAG = EX_LIBS = CPUID_OBJ =x86cpuid.o BN_ASM =bn-586.o co-586.o x86-mont.o x86-gf2m.o EC_ASM =ecp_nistz256.o ecp_nistz256-x86.o DES_ENC =des-586.o crypt586.o AES_ENC =aes-586.o vpaes-x86.o aesni-x86.o BF_ENC =bf-586.o CAST_ENC =c_enc.o RC4_ENC =rc4-586.o RC5_ENC =rc5-586.o MD5_OBJ_ASM =md5-586.o SHA1_OBJ_ASM =sha1-586.o sha256-586.o sha512-586.o RMD160_OBJ_ASM=rmd-586.o CMLL_ENC =cmll-x86.o MODES_OBJ =ghash-x86.o PADLOCK_OBJ =e_padlock-x86.o CHACHA_ENC =chacha-x86.o POLY1305_OBJ =poly1305-x86.o PROCESSOR = RANLIB =/usr/bin/ranlib ARFLAGS = PERL =/usr/pkg/bin/perl THIRTY_TWO_BIT mode BN_LLONG mode Configured for BSD-x86-elf. *************************************** if I gmake at the top level, the build proceeds for a while and appears to exit cleanly, but if I run gmake again, I get the following message: # gmake gmake: *** No rule to make target 'usr/include/stdio.husr/include/sys/cdefs.h', needed by 'apps/openssl'. Stop. *************************************** I have problems even if I turn off debug. I really want debug AND I think I need to enable crypto-mdebug and crypto-mdebug-backtrace so I can determine the calling line from tor that is crashing in openssl. The tor dev's think they have coded for compatibility with openssl 1.1.0_dev, but I cannot confirm this on my builds. I built tor with debug symbols, but so far, even if I set breakpoints at main() in tor, running tor in gdb appears to crash in openssl somewhere but I cannot execute a backtrace to see what line in tor is calling the openssl function that is failing. At the moment I cannot even build openssl. I've had this issue for a week or two... -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4345 Please log in as guest with password guest if prompted From rt at openssl.org Thu Feb 25 14:36:30 2016 From: rt at openssl.org (Kiyoshi KANAZAWA via RT) Date: Thu, 25 Feb 2016 14:36:30 +0000 Subject: [openssl-dev] [openssl.org #4324] openssl-1.1.0-pre3 with solaris-x86-cc & solaris64-x86_64-cc make fails In-Reply-To: <845222.20757.qm@web101214.mail.kks.yahoo.co.jp> References: <521557.3312.qm@web101212.mail.kks.yahoo.co.jp> <845222.20757.qm@web101214.mail.kks.yahoo.co.jp> Message-ID: With the following patch, % ./Configure --unified solaris-x86-cc % make % make test passed. % ./Configure --unifiedsolaris64-x86_64-cc; make; make test also passed. This patch was written comparing to openssl-1.0.2f. It has side effect for other configurations. Please add some conditions. diff -cr ../openssl-1.1.0-pre3.orig/Makefile.shared ./Makefile.shared *** ../openssl-1.1.0-pre3.orig/Makefile.shared? 2016-02-16 03:08:07.000000000 +0900 --- ./Makefile.shared?? 2016-02-25 22:57:23.347187336 +0900 *************** *** 398,409 **** ??????? ($(CC) -v 2>&1 | grep gcc) > /dev/null && MINUSZ='-Wl,-z,'; \ ??????? SHLIB=lib$(LIBNAME).so; \ ??????? SHLIB_SUFFIX=;\ !?????? if [ $(LIBNAME) != "crypto" -a $(LIBNAME) != "ssl" ]; then \ ??????????? ALLSYMSFLAGS="$${MINUSZ}allextract"; \ !?????? else \ !?????????? $(PERL) $(SRCDIR)/util/mkdef.pl $(LIBNAME) linux >$(LIBNAME).map; \ !?????????? ALLSYMSFLAGS="$${MINUSZ}allextract,-M,$(LIBNAME).map"; \ !?????? fi; \ ??????? NOALLSYMSFLAGS="$${MINUSZ}defaultextract"; \ ??????? SHAREDFLAGS="$(CFLAGS) $(SHARED_LDFLAGS) -h $$SHLIB$$SHLIB_SOVER$$SHLIB_SUFFIX -Wl,-Bsymbolic"; \ ??? fi; \ --- 398,409 ---- ??????? ($(CC) -v 2>&1 | grep gcc) > /dev/null && MINUSZ='-Wl,-z,'; \ ??????? SHLIB=lib$(LIBNAME).so; \ ??????? SHLIB_SUFFIX=;\ ! #???? if [ $(LIBNAME) != "crypto" -a $(LIBNAME) != "ssl" ]; then \ ??????????? ALLSYMSFLAGS="$${MINUSZ}allextract"; \ ! #???? else \ ! #???????? $(PERL) $(SRCDIR)/util/mkdef.pl $(LIBNAME) linux >$(LIBNAME).map; \ ! #???????? ALLSYMSFLAGS="$${MINUSZ}allextract,-M,$(LIBNAME).map"; \ ! #???? fi; \ ??????? NOALLSYMSFLAGS="$${MINUSZ}defaultextract"; \ ??????? SHAREDFLAGS="$(CFLAGS) $(SHARED_LDFLAGS) -h $$SHLIB$$SHLIB_SOVER$$SHLIB_SUFFIX -Wl,-Bsymbolic"; \ ??? fi; \ -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4324 Please log in as guest with password guest if prompted From rt at openssl.org Thu Feb 25 15:05:25 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 25 Feb 2016 15:05:25 +0000 Subject: [openssl-dev] [openssl.org #4116] [PATCH] Reimplement non-asm OPENSSL_cleanse() In-Reply-To: <20151031130526.GA11805@kronk.local> References: <20151031130526.GA11805@kronk.local> Message-ID: closed with commit 104ce8a thanks. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4116 Please log in as guest with password guest if prompted From rt at openssl.org Thu Feb 25 23:16:29 2016 From: rt at openssl.org (David Benjamin via RT) Date: Thu, 25 Feb 2016 23:16:29 +0000 Subject: [openssl-dev] [openssl.org #4346] poly1305-x86.pl's AVX2 code In-Reply-To: References: Message-ID: There seems to be a bug in the AVX2 codepath in poly1305-x86.pl. I have not attempted to debug this, but I have attached a test file which produces different output in normal and AVX2 codepaths. Our existing poly1305 implementation agrees with the former. $ OPENSSL_ia32cap=0 ./poly1305_test PASS $ ./poly1305_test Poly1305 test failed. got: 2e65f0054e36505687d937ff5e8ed112 expected: 69d28f73dd09d39a92aa179da354b7ea You may wish to generalize that Poly1305_Update pattern into your own tests. This is what I did to catch this: https://boringssl-review.googlesource.com/#/c/7223/ >From looking at valgrind, this pattern seems to give good coverage. I used valgrind --tool=callgrind --dump-instr=yes --collect-jumps=yes and then kcachegrind to inspect the output. (kcachegrind is a bit heavy for this. I'm hoping I can find or write a better annotator here. Something which looks like, say, LCOV would be ideal.) By the way, this assembly code is quite complicated. I wasn't able to find problems in the others (I tested armv4, armv8, x86, and x86_64), but I'm far from confident I've covered all the cases. With the caveat that I'm no assembly programmer, much of the complexity seems to come the SIMD code needing a multiple of 2 or 4 blocks and the implementation converting internal state back and forth from base 2^26 and 2^64 and handling excess blocks slightly differently in different cases. (I counted nine distinct codepaths to test in the x86_64 AVX codepath alone.) The C code already buffers up to 16-byte blocks. Did you consider buffering up to 32 or 64 bytes in C when the SIMD code called for it? I think it could be simpler. You'd only need to handle excess blocks at the end. This would also simplify the SIMD upgrade on long inputs, so long as the buffer exceeds the cutoff. (You'll never process input before the upgrade.) I haven't tried this, so perhaps the performance costs are prohibitive, but if the costs are modest, the simplifications may be worth it. David -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4346 Please log in as guest with password guest if prompted -------------- next part -------------- A non-text attachment was scrubbed... Name: poly1305_test.c Type: text/x-csrc Size: 7376 bytes Desc: not available URL: From rt at openssl.org Thu Feb 25 23:28:21 2016 From: rt at openssl.org (David Woodhouse via RT) Date: Thu, 25 Feb 2016 23:28:21 +0000 Subject: [openssl-dev] [openssl.org #4347] Fix GCC unused-value warnings with HOST_c2l() In-Reply-To: <1456442886.4666.120.camel@infradead.org> References: <1456442886.4666.120.camel@infradead.org> Message-ID: The HOST_c2l() macro assigns the value to the specified variable, but also evaluates to the same value. Which we ignore, triggering a warning. To fix this, just cast it to void ? like we did in commit 08e553644 ("Fix some clang warnings.") for a bunch of other instances. --- ?crypto/md5/md5_dgst.c | 32 ++++++++++++++++---------------- ?crypto/sha/sha256.c???| 34 +++++++++++++++++----------------- ?crypto/sha/sha_locl.h |??2 +- ?3 files changed, 34 insertions(+), 34 deletions(-) diff --git a/crypto/md5/md5_dgst.c b/crypto/md5/md5_dgst.c index 18a3262..37b0d31 100644 --- a/crypto/md5/md5_dgst.c +++ b/crypto/md5/md5_dgst.c @@ -102,52 +102,52 @@ void md5_block_data_order(MD5_CTX *c, const void *data_, size_t num) ?????D = c->D; ? ?????for (; num--;) { -????????HOST_c2l(data, l); +????????(void)HOST_c2l(data, l); ?????????X(0) = l; -????????HOST_c2l(data, l); +????????(void)HOST_c2l(data, l); ?????????X(1) = l; ?????????/* Round 0 */ ?????????R0(A, B, C, D, X(0), 7, 0xd76aa478L); -????????HOST_c2l(data, l); +????????(void)HOST_c2l(data, l); ?????????X(2) = l; ?????????R0(D, A, B, C, X(1), 12, 0xe8c7b756L); -????????HOST_c2l(data, l); +????????(void)HOST_c2l(data, l); ?????????X(3) = l; ?????????R0(C, D, A, B, X(2), 17, 0x242070dbL); -????????HOST_c2l(data, l); +????????(void)HOST_c2l(data, l); ?????????X(4) = l; ?????????R0(B, C, D, A, X(3), 22, 0xc1bdceeeL); -????????HOST_c2l(data, l); +????????(void)HOST_c2l(data, l); ?????????X(5) = l; ?????????R0(A, B, C, D, X(4), 7, 0xf57c0fafL); -????????HOST_c2l(data, l); +????????(void)HOST_c2l(data, l); ?????????X(6) = l; ?????????R0(D, A, B, C, X(5), 12, 0x4787c62aL); -????????HOST_c2l(data, l); +????????(void)HOST_c2l(data, l); ?????????X(7) = l; ?????????R0(C, D, A, B, X(6), 17, 0xa8304613L); -????????HOST_c2l(data, l); +????????(void)HOST_c2l(data, l); ?????????X(8) = l; ?????????R0(B, C, D, A, X(7), 22, 0xfd469501L); -????????HOST_c2l(data, l); +????????(void)HOST_c2l(data, l); ?????????X(9) = l; ?????????R0(A, B, C, D, X(8), 7, 0x698098d8L); -????????HOST_c2l(data, l); +????????(void)HOST_c2l(data, l); ?????????X(10) = l; ?????????R0(D, A, B, C, X(9), 12, 0x8b44f7afL); -????????HOST_c2l(data, l); +????????(void)HOST_c2l(data, l); ?????????X(11) = l; ?????????R0(C, D, A, B, X(10), 17, 0xffff5bb1L); -????????HOST_c2l(data, l); +????????(void)HOST_c2l(data, l); ?????????X(12) = l; ?????????R0(B, C, D, A, X(11), 22, 0x895cd7beL); -????????HOST_c2l(data, l); +????????(void)HOST_c2l(data, l); ?????????X(13) = l; ?????????R0(A, B, C, D, X(12), 7, 0x6b901122L); -????????HOST_c2l(data, l); +????????(void)HOST_c2l(data, l); ?????????X(14) = l; ?????????R0(D, A, B, C, X(13), 12, 0xfd987193L); -????????HOST_c2l(data, l); +????????(void)HOST_c2l(data, l); ?????????X(15) = l; ?????????R0(C, D, A, B, X(14), 17, 0xa679438eL); ?????????R0(B, C, D, A, X(15), 22, 0x49b40821L); diff --git a/crypto/sha/sha256.c b/crypto/sha/sha256.c index d7d33d5..53b6054 100644 --- a/crypto/sha/sha256.c +++ b/crypto/sha/sha256.c @@ -181,7 +181,7 @@ static void sha256_block_data_order(SHA256_CTX *ctx, const void *in, ?????????h = ctx->h[7]; ? ?????????for (i = 0; i < 16; i++) { -????????????HOST_c2l(data, l); +????????????(void)HOST_c2l(data, l); ?????????????T1 = X[i] = l; ?????????????T1 += h + Sigma1(e) + Ch(e, f, g) + K256[i]; ?????????????T2 = Sigma0(a) + Maj(a, b, c); @@ -305,52 +305,52 @@ static void sha256_block_data_order(SHA256_CTX *ctx, const void *in, ?????????} else { ?????????????SHA_LONG l; ? -????????????HOST_c2l(data, l); +????????????(void)HOST_c2l(data, l); ?????????????T1 = X[0] = l; ?????????????ROUND_00_15(0, a, b, c, d, e, f, g, h); -????????????HOST_c2l(data, l); +????????????(void)HOST_c2l(data, l); ?????????????T1 = X[1] = l; ?????????????ROUND_00_15(1, h, a, b, c, d, e, f, g); -????????????HOST_c2l(data, l); +????????????(void)HOST_c2l(data, l); ?????????????T1 = X[2] = l; ?????????????ROUND_00_15(2, g, h, a, b, c, d, e, f); -????????????HOST_c2l(data, l); +????????????(void)HOST_c2l(data, l); ?????????????T1 = X[3] = l; ?????????????ROUND_00_15(3, f, g, h, a, b, c, d, e); -????????????HOST_c2l(data, l); +????????????(void)HOST_c2l(data, l); ?????????????T1 = X[4] = l; ?????????????ROUND_00_15(4, e, f, g, h, a, b, c, d); -????????????HOST_c2l(data, l); +????????????(void)HOST_c2l(data, l); ?????????????T1 = X[5] = l; ?????????????ROUND_00_15(5, d, e, f, g, h, a, b, c); -????????????HOST_c2l(data, l); +????????????(void)HOST_c2l(data, l); ?????????????T1 = X[6] = l; ?????????????ROUND_00_15(6, c, d, e, f, g, h, a, b); -????????????HOST_c2l(data, l); +????????????(void)HOST_c2l(data, l); ?????????????T1 = X[7] = l; ?????????????ROUND_00_15(7, b, c, d, e, f, g, h, a); -????????????HOST_c2l(data, l); +????????????(void)HOST_c2l(data, l); ?????????????T1 = X[8] = l; ?????????????ROUND_00_15(8, a, b, c, d, e, f, g, h); -????????????HOST_c2l(data, l); +????????????(void)HOST_c2l(data, l); ?????????????T1 = X[9] = l; ?????????????ROUND_00_15(9, h, a, b, c, d, e, f, g); -????????????HOST_c2l(data, l); +????????????(void)HOST_c2l(data, l); ?????????????T1 = X[10] = l; ?????????????ROUND_00_15(10, g, h, a, b, c, d, e, f); -????????????HOST_c2l(data, l); +????????????(void)HOST_c2l(data, l); ?????????????T1 = X[11] = l; ?????????????ROUND_00_15(11, f, g, h, a, b, c, d, e); -????????????HOST_c2l(data, l); +????????????(void)HOST_c2l(data, l); ?????????????T1 = X[12] = l; ?????????????ROUND_00_15(12, e, f, g, h, a, b, c, d); -????????????HOST_c2l(data, l); +????????????(void)HOST_c2l(data, l); ?????????????T1 = X[13] = l; ?????????????ROUND_00_15(13, d, e, f, g, h, a, b, c); -????????????HOST_c2l(data, l); +????????????(void)HOST_c2l(data, l); ?????????????T1 = X[14] = l; ?????????????ROUND_00_15(14, c, d, e, f, g, h, a, b); -????????????HOST_c2l(data, l); +????????????(void)HOST_c2l(data, l); ?????????????T1 = X[15] = l; ?????????????ROUND_00_15(15, b, c, d, e, f, g, h, a); ?????????} diff --git a/crypto/sha/sha_locl.h b/crypto/sha/sha_locl.h index 87e69d8..649cded 100644 --- a/crypto/sha/sha_locl.h +++ b/crypto/sha/sha_locl.h @@ -430,7 +430,7 @@ static void HASH_BLOCK_DATA_ORDER(SHA_CTX *c, const void *p, size_t num) ? ?????for (;;) { ?????????for (i = 0; i < 16; i++) { -????????????HOST_c2l(data, l); +????????????(void)HOST_c2l(data, l); ?????????????X[i] = l; ?????????????BODY_00_15(X[i]); ?????????} --? 2.5.0 -- David Woodhouse Open Source Technology Centre David.Woodhouse at intel.com Intel Corporation -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4347 Please log in as guest with password guest if prompted -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5691 bytes Desc: not available URL: From rt at openssl.org Fri Feb 26 02:47:23 2016 From: rt at openssl.org (Bruce Drake via RT) Date: Fri, 26 Feb 2016 02:47:23 +0000 Subject: [openssl-dev] [openssl.org #4348] SSL3_GET_MESSAGE:excessive message size In-Reply-To: <56CF8C70.3070504@dataprocessors.com.au> References: <56CF8C70.3070504@dataprocessors.com.au> Message-ID: Hi I am getting the following error when trying to connect to stream-api.betfair.com:443 Error connecting with SSL. error:1408E098:SSL routines:SSL3_GET_MESSAGE:excessive message size using OpenSSL. However using code I wrote using SChannel it works fine. I looked around and it looks like this has happened before and there is something in the code that needs to be tweaked, I am using 1.0.1r which I have build myself, if someone could point me at the code that needs to change to fix this I would be happy to do so. Regards Bruce -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4348 Please log in as guest with password guest if prompted From doctor at doctor.nl2k.ab.ca Fri Feb 26 09:29:02 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Fri, 26 Feb 2016 02:29:02 -0700 Subject: [openssl-dev] openssl 1.0.2 SNAP 20160226 issues Message-ID: <20160226092902.GA20863@doctor.nl2k.ab.ca> Please have a look at Script started on Fri Feb 26 02:22:05 2016 doctor.nl2k.ab.ca//usr/source/openssl-1.0.2-stable-SNAP-20160226$ less /usr/cot nrib/bin/configopenssl /usr/cotnrib/bin/configopenssl: No such file or directory doctor.nl2k.ab.ca//usr/source/openssl-1.0.2-stable-SNAP-20160226$ ^tn^nt less /usr/contrib/bin/configopenssl [?1h= ./Configure 386 threads shared experimental-libunbound experimental-dane no-s se2 enable-srtp no-sctp experimental-jpake experimental-store enable-whrlpool enable-montasm enable-capieng enable-cms enable-seed enable-tlsext enable-ssl-t race enable-camellia enable-rfc3779 enable-gmp enable-mdc2 enable-md5 enable-rc 5 experimental-multiblock enable-unit-test zlib-dynamic --prefix=/usr/contrib - -openssldir=/usr/contrib debug-bsdi-x86-elf ; make update;make depend /usr/contrib/bin/configopenssl (END)[?1l>doctor.nl2k.ab.ca//usr/source/openssl-1.0.2-stable-SNAP-20160226$ ^cat^ sh: :s^cat^: substitution failed doctor.nl2k.ab.ca//usr/source/openssl-1.0.2-stable-SNAP-20160226$ ^less^ /usr/contrib/bin/configopenssl Configuring for debug-bsdi-x86-elf no-ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128 (skip dir) no-krb5 [krb5-flavor not specified] OPENSSL_NO_KRB5 no-md2 [default] OPENSSL_NO_MD2 (skip dir) no-sctp [option] OPENSSL_NO_SCTP (skip dir) no-sse2 [forced] IsMK1MF=0 CC =gcc3 CFLAG =-fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -pthread -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DPERL5 -DL_ENDIAN -DTERMIOS -fomit-frame-pointer -O2 -Wall -g -DOPENSSL_EXPERIMENTAL_JPAKE -DOPENSSL_EXPERIMENTAL_LIBUNBOUND -DOPENSSL_EXPERIMENTAL_STORE -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DGHASH_ASM EX_LIBS =-lgmp -ldl -lm -lc -lz CPUID_OBJ =mem_clr.o BN_ASM =bn-586.o co-586.o x86-mont.o x86-gf2m.o EC_ASM = DES_ENC =des-586.o crypt586.o AES_ENC =aes-586.o BF_ENC =bf-586.o CAST_ENC =c_enc.o RC4_ENC =rc4-586.o RC5_ENC =rc5-586.o MD5_OBJ_ASM =md5-586.o SHA1_OBJ_ASM =sha1-586.o sha256-586.o sha512-586.o RMD160_OBJ_ASM=rmd-586.o CMLL_ENC =cmll-x86.o MODES_OBJ =ghash-x86.o ENGINES_OBJ = PROCESSOR =386 RANLIB =/usr/bin/ranlib ARFLAGS = PERL =/usr/contrib/bin/perl5 THIRTY_TWO_BIT mode DES_PTR used DES_RISC1 used DES_UNROLL used BN_LLONG mode RC4_INDEX mode RC4_CHUNK is unsigned long e_os2.h => include/openssl/e_os2.h making links in crypto... make[1]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto' crypto.h => ../include/openssl/crypto.h opensslv.h => ../include/openssl/opensslv.h opensslconf.h => ../include/openssl/opensslconf.h ebcdic.h => ../include/openssl/ebcdic.h symhacks.h => ../include/openssl/symhacks.h ossl_typ.h => ../include/openssl/ossl_typ.h constant_time_test.c => ../test/constant_time_test.c making links in crypto/objects... make[2]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/objects' objects.h => ../../include/openssl/objects.h obj_mac.h => ../../include/openssl/obj_mac.h make[2]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/objects' making links in crypto/md4... make[2]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/md4' md4.h => ../../include/openssl/md4.h md4test.c => ../../test/md4test.c md4.c => ../../apps/md4.c make[2]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/md4' making links in crypto/md5... make[2]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/md5' md5.h => ../../include/openssl/md5.h md5test.c => ../../test/md5test.c make[2]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/md5' making links in crypto/sha... make[2]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/sha' sha.h => ../../include/openssl/sha.h shatest.c => ../../test/shatest.c sha1test.c => ../../test/sha1test.c sha256t.c => ../../test/sha256t.c sha512t.c => ../../test/sha512t.c make[2]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/sha' making links in crypto/mdc2... make[2]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/mdc2' mdc2.h => ../../include/openssl/mdc2.h mdc2test.c => ../../test/mdc2test.c make[2]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/mdc2' making links in crypto/hmac... make[2]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/hmac' hmac.h => ../../include/openssl/hmac.h hmactest.c => ../../test/hmactest.c make[2]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/hmac' making links in crypto/ripemd... make[2]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/ripemd' ripemd.h => ../../include/openssl/ripemd.h rmdtest.c => ../../test/rmdtest.c make[2]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/ripemd' making links in crypto/whrlpool... make[2]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/whrlpool' whrlpool.h => ../../include/openssl/whrlpool.h wp_test.c => ../../test/wp_test.c make[2]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/whrlpool' making links in crypto/des... make[2]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/des' des.h => ../../include/openssl/des.h des_old.h => ../../include/openssl/des_old.h destest.c => ../../test/destest.c make[2]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/des' making links in crypto/aes... make[2]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/aes' aes.h => ../../include/openssl/aes.h make[2]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/aes' making links in crypto/rc2... make[2]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/rc2' rc2.h => ../../include/openssl/rc2.h rc2test.c => ../../test/rc2test.c make[2]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/rc2' making links in crypto/rc4... make[2]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/rc4' rc4.h => ../../include/openssl/rc4.h rc4test.c => ../../test/rc4test.c make[2]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/rc4' making links in crypto/rc5... make[2]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/rc5' rc5.h => ../../include/openssl/rc5.h rc5test.c => ../../test/rc5test.c make[2]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/rc5' making links in crypto/idea... make[2]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/idea' idea.h => ../../include/openssl/idea.h ideatest.c => ../../test/ideatest.c make[2]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/idea' making links in crypto/bf... make[2]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/bf' blowfish.h => ../../include/openssl/blowfish.h bftest.c => ../../test/bftest.c make[2]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/bf' making links in crypto/cast... make[2]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/cast' cast.h => ../../include/openssl/cast.h casttest.c => ../../test/casttest.c make[2]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/cast' making links in crypto/camellia... make[2]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/camellia' camellia.h => ../../include/openssl/camellia.h make[2]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/camellia' making links in crypto/seed... make[2]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/seed' seed.h => ../../include/openssl/seed.h make[2]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/seed' making links in crypto/modes... make[2]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/modes' modes.h => ../../include/openssl/modes.h make[2]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/modes' making links in crypto/bn... make[2]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/bn' bn.h => ../../include/openssl/bn.h bntest.c => ../../test/bntest.c exptest.c => ../../test/exptest.c make[2]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/bn' making links in crypto/ec... make[2]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/ec' ec.h => ../../include/openssl/ec.h ectest.c => ../../test/ectest.c make[2]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/ec' making links in crypto/rsa... make[2]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/rsa' rsa.h => ../../include/openssl/rsa.h rsa_test.c => ../../test/rsa_test.c make[2]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/rsa' making links in crypto/dsa... make[2]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/dsa' dsa.h => ../../include/openssl/dsa.h dsatest.c => ../../test/dsatest.c make[2]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/dsa' making links in crypto/ecdsa... make[2]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/ecdsa' ecdsa.h => ../../include/openssl/ecdsa.h ecdsatest.c => ../../test/ecdsatest.c make[2]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/ecdsa' making links in crypto/dh... make[2]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/dh' dh.h => ../../include/openssl/dh.h dhtest.c => ../../test/dhtest.c make[2]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/dh' making links in crypto/ecdh... make[2]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/ecdh' ecdh.h => ../../include/openssl/ecdh.h ecdhtest.c => ../../test/ecdhtest.c make[2]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/ecdh' making links in crypto/dso... make[2]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/dso' dso.h => ../../include/openssl/dso.h make[2]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/dso' making links in crypto/engine... make[2]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/engine' engine.h => ../../include/openssl/engine.h enginetest.c => ../../test/enginetest.c make[2]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/engine' making links in crypto/buffer... make[2]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/buffer' buffer.h => ../../include/openssl/buffer.h make[2]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/buffer' making links in crypto/bio... make[2]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/bio' bio.h => ../../include/openssl/bio.h make[2]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/bio' making links in crypto/stack... make[2]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/stack' stack.h => ../../include/openssl/stack.h safestack.h => ../../include/openssl/safestack.h make[2]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/stack' making links in crypto/lhash... make[2]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/lhash' lhash.h => ../../include/openssl/lhash.h make[2]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/lhash' making links in crypto/rand... make[2]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/rand' rand.h => ../../include/openssl/rand.h randtest.c => ../../test/randtest.c make[2]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/rand' making links in crypto/err... make[2]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/err' err.h => ../../include/openssl/err.h make[2]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/err' making links in crypto/evp... make[2]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/evp' evp.h => ../../include/openssl/evp.h evp_test.c => ../../test/evp_test.c evp_extra_test.c => ../../test/evp_extra_test.c evptests.txt -> ../../test/evptests.txt make[2]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/evp' making links in crypto/asn1... make[2]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/asn1' asn1.h => ../../include/openssl/asn1.h asn1_mac.h => ../../include/openssl/asn1_mac.h asn1t.h => ../../include/openssl/asn1t.h make[2]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/asn1' making links in crypto/pem... make[2]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/pem' pem.h => ../../include/openssl/pem.h pem2.h => ../../include/openssl/pem2.h make[2]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/pem' making links in crypto/x509... make[2]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/x509' x509.h => ../../include/openssl/x509.h x509_vfy.h => ../../include/openssl/x509_vfy.h verify_extra_test.c => ../../test/verify_extra_test.c make[2]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/x509' making links in crypto/x509v3... make[2]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/x509v3' x509v3.h => ../../include/openssl/x509v3.h v3nametest.c => ../../test/v3nametest.c make[2]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/x509v3' making links in crypto/conf... make[2]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/conf' conf.h => ../../include/openssl/conf.h conf_api.h => ../../include/openssl/conf_api.h make[2]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/conf' making links in crypto/txt_db... make[2]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/txt_db' txt_db.h => ../../include/openssl/txt_db.h make[2]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/txt_db' making links in crypto/pkcs7... make[2]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/pkcs7' pkcs7.h => ../../include/openssl/pkcs7.h make[2]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/pkcs7' making links in crypto/pkcs12... make[2]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/pkcs12' pkcs12.h => ../../include/openssl/pkcs12.h make[2]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/pkcs12' making links in crypto/comp... make[2]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/comp' comp.h => ../../include/openssl/comp.h make[2]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/comp' making links in crypto/ocsp... make[2]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/ocsp' ocsp.h => ../../include/openssl/ocsp.h make[2]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/ocsp' making links in crypto/ui... make[2]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/ui' ui.h => ../../include/openssl/ui.h ui_compat.h => ../../include/openssl/ui_compat.h make[2]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/ui' making links in crypto/krb5... make[2]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/krb5' krb5_asn.h => ../../include/openssl/krb5_asn.h make[2]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/krb5' making links in crypto/cms... make[2]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/cms' cms.h => ../../include/openssl/cms.h make[2]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/cms' making links in crypto/pqueue... make[2]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/pqueue' pqueue.h => ../../include/openssl/pqueue.h make[2]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/pqueue' making links in crypto/ts... make[2]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/ts' ts.h => ../../include/openssl/ts.h make[2]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/ts' making links in crypto/jpake... make[2]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/jpake' jpake.h => ../../include/openssl/jpake.h jpaketest.c => ../../test/jpaketest.c make[2]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/jpake' making links in crypto/srp... make[2]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/srp' srp.h => ../../include/openssl/srp.h srptest.c => ../../test/srptest.c make[2]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/srp' making links in crypto/store... make[2]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/store' store.h => ../../include/openssl/store.h make[2]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/store' making links in crypto/cmac... make[2]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/cmac' cmac.h => ../../include/openssl/cmac.h make[2]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto/cmac' make[1]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto' making links in ssl... make[1]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/ssl' ssl.h => ../include/openssl/ssl.h ssl2.h => ../include/openssl/ssl2.h ssl3.h => ../include/openssl/ssl3.h ssl23.h => ../include/openssl/ssl23.h tls1.h => ../include/openssl/tls1.h dtls1.h => ../include/openssl/dtls1.h kssl.h => ../include/openssl/kssl.h srtp.h => ../include/openssl/srtp.h ssltest.c => ../test/ssltest.c heartbeat_test.c => ../test/heartbeat_test.c clienthellotest.c => ../test/clienthellotest.c make[1]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/ssl' making links in engines... make[1]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/engines' making links in engines/ccgost... make[2]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/engines/ccgost' make[2]: Nothing to be done for 'links'. make[2]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/engines/ccgost' make[1]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/engines' making links in apps... make[1]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/apps' make[1]: Nothing to be done for 'links'. make[1]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/apps' making links in test... make[1]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/test' make[1]: Nothing to be done for 'links'. make[1]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/test' making links in tools... make[1]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/tools' make[1]: Nothing to be done for 'links'. make[1]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/tools' generating dummy tests (if needed)... make[1]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/test' make[1]: Nothing to be done for 'generate'. make[1]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/test' Configured for debug-bsdi-x86-elf. *** Because of configuration changes, you MUST do the following before *** building: make depend /usr/contrib/bin/perl5 util/ck_errf.pl -strict */*.c */*/*.c /usr/contrib/bin/perl5 util/mkerr.pl -recurse -write TS: No new error codes DSO: No new error codes ENGINE: No new error codes OCSP: No new error codes EC: No new error codes BN: No new error codes UI: No new error codes DH: No new error codes HMAC: No new error codes CONF: No new error codes EVP: No new error codes SSL: No new error codes OBJ: No new error codes ECDH: No new error codes ECDSA: No new error codes X509V3: No new error codes BUF: No new error codes PKCS7: No new error codes ASN1: No new error codes STORE: No new error codes DSA: No new error codes X509: No new error codes CMS: No new error codes PEM: No new error codes COMP: No new error codes JPAKE: No new error codes CRYPTO: No new error codes RAND: No new error codes PKCS12: No new error codes RSA: No new error codes BIO: No new error codes (cd engines; make PERL=/usr/contrib/bin/perl5 errors) make[1]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/engines' set -e; for l in 4758cca aep atalla cswift gmp chil nuron sureware ubsec padlock capi; do \ /usr/contrib/bin/perl5 ../util/mkerr.pl -conf e_$l.ec \ -nostatic -staticloader -write e_$l.c; \ done CCA4758: No new error codes AEPHK: No new error codes ATALLA: No new error codes CSWIFT: No new error codes GMP: No new error codes HWCRHK: No new error codes NURON: No new error codes SUREWARE: No new error codes UBSEC: No new error codes PADLOCK: No new error codes CAPI: No new error codes (cd ccgost; make PERL=/usr/contrib/bin/perl5 errors) make[2]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/engines/ccgost' /usr/contrib/bin/perl5 ../../util/mkerr.pl -conf gost.ec -nostatic -write gost2001.c gost2001_keyx.c gost89.c gost94_keyx.c gost_ameth.c gost_asn1.c gost_crypt.c gost_ctl.c gost_eng.c gosthash.c gost_keywrap.c gost_md.c gost_params.c gost_pmeth.c gost_sign.c GOST: No new error codes make[2]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/engines/ccgost' make[1]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/engines' /usr/contrib/bin/perl5 util/mkstack.pl -write No changes to crypto/stack/safestack.h. /usr/contrib/bin/perl5 util/mkdef.pl crypto update Updating LIBEAY info No old symbols needed info update Rewriting LIBEAY Updating LIBEAY numbers No New symbols Added /usr/contrib/bin/perl5 util/mkdef.pl ssl update Updating SSLEAY info No old symbols needed info update Rewriting SSLEAY Updating SSLEAY numbers No New symbols Added making update in crypto... make[1]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto' makedepend: not found makedepend: not found mv: cannot stat `Makefile.new': No such file or directory Makefile:136: recipe for target 'local_depend' failed make[1]: *** [local_depend] Error 1 make[1]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto' Makefile:468: recipe for target 'update' failed make: *** [update] Error 1 making depend in crypto... make[1]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto' makedepend: not found makedepend: not found mv: cannot stat `Makefile.new': No such file or directory Makefile:136: recipe for target 'local_depend' failed make[1]: *** [local_depend] Error 1 make[1]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto' Makefile:471: recipe for target 'depend' failed make: *** [depend] Error 1 doctor.nl2k.ab.ca//usr/source/openssl-1.0.2-stable-SNAP-20160226$ exit exit Script done on Fri Feb 26 02:25:11 2016 make, make test, make install works , but still in the prep time some barking is occuring. Please have a look. -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Broadcasting the truth for 25 years From levitte at openssl.org Fri Feb 26 09:48:16 2016 From: levitte at openssl.org (Richard Levitte) Date: Fri, 26 Feb 2016 10:48:16 +0100 (CET) Subject: [openssl-dev] openssl 1.0.2 SNAP 20160226 issues In-Reply-To: <20160226092902.GA20863@doctor.nl2k.ab.ca> References: <20160226092902.GA20863@doctor.nl2k.ab.ca> Message-ID: <20160226.104816.1561735000710279669.levitte@openssl.org> In message <20160226092902.GA20863 at doctor.nl2k.ab.ca> on Fri, 26 Feb 2016 02:29:02 -0700, The Doctor said: doctor> Please have a look at ... doctor> making update in crypto... doctor> make[1]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto' doctor> makedepend: not found doctor> makedepend: not found doctor> mv: cannot stat `Makefile.new': No such file or directory doctor> Makefile:136: recipe for target 'local_depend' failed doctor> make[1]: *** [local_depend] Error 1 doctor> make[1]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto' doctor> Makefile:468: recipe for target 'update' failed doctor> make: *** [update] Error 1 ... Please install makedepend -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From matt at openssl.org Fri Feb 26 15:14:37 2016 From: matt at openssl.org (Matt Caswell) Date: Fri, 26 Feb 2016 15:14:37 +0000 Subject: [openssl-dev] Ubsec and Chil engines In-Reply-To: References: <20160220.225541.1585601945103016062.levitte@openssl.org> <1456140741.4735.272.camel@infradead.org> <347004c001fd430aadadceac908e68a2@ustx2ex-dag1mb1.msg.corp.akamai.com> <20160222.160034.1279367000656813396.levitte@openssl.org> Message-ID: <56D06BDD.7090405@openssl.org> On 23/02/16 16:38, Sander Temme wrote: > All, > > I toyed over the weekend with resurrecting CHIL: intermediate result > here https://github.com/sctemme/openssl/tree/rescue-chil and I AM NOT > PROUD OF THIS but have no cycles to clean it up for at least a couple > of days to come. It builds now but doesn't work: my privkey loading > routine doesn't get called and that may be an API change I missed. > > Can we resurrect CHIL for 1.1 along these lines? Then I'd be > delighted to join the discussion about p11 for down the road. I would prefer to move CHIL to an external repo (e.g. maybe Richard's engine corner??). As Richard said in another post, this code is unmaintainable by us because no-one on the team has access to the relevant hardware. BTW, no one has spoken up for Ubsec, which was the other engine mentioned in the original post, so I will be removing that one imminently. Matt From doctor at doctor.nl2k.ab.ca Fri Feb 26 15:26:02 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Fri, 26 Feb 2016 08:26:02 -0700 Subject: [openssl-dev] openssl 1.0.2 SNAP 20160226 issues In-Reply-To: <20160226.104816.1561735000710279669.levitte@openssl.org> References: <20160226092902.GA20863@doctor.nl2k.ab.ca> <20160226.104816.1561735000710279669.levitte@openssl.org> Message-ID: <20160226152601.GA16018@doctor.nl2k.ab.ca> On Fri, Feb 26, 2016 at 10:48:16AM +0100, Richard Levitte wrote: > In message <20160226092902.GA20863 at doctor.nl2k.ab.ca> on Fri, 26 Feb 2016 02:29:02 -0700, The Doctor said: > > doctor> Please have a look at > ... > doctor> making update in crypto... > doctor> make[1]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto' > doctor> makedepend: not found > doctor> makedepend: not found > doctor> mv: cannot stat `Makefile.new': No such file or directory > doctor> Makefile:136: recipe for target 'local_depend' failed > doctor> make[1]: *** [local_depend] Error 1 > doctor> make[1]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto' > doctor> Makefile:468: recipe for target 'update' failed > doctor> make: *** [update] Error 1 > ... > > Please install makedepend > Where do I find makedepend ? > -- > Richard Levitte levitte at openssl.org > OpenSSL Project http://www.openssl.org/~levitte/ -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Broadcasting the truth for 25 years From levitte at openssl.org Fri Feb 26 15:59:32 2016 From: levitte at openssl.org (Richard Levitte) Date: Fri, 26 Feb 2016 16:59:32 +0100 (CET) Subject: [openssl-dev] openssl 1.0.2 SNAP 20160226 issues In-Reply-To: <20160226152601.GA16018@doctor.nl2k.ab.ca> References: <20160226092902.GA20863@doctor.nl2k.ab.ca> <20160226.104816.1561735000710279669.levitte@openssl.org> <20160226152601.GA16018@doctor.nl2k.ab.ca> Message-ID: <20160226.165932.467834483695581959.levitte@openssl.org> In message <20160226152601.GA16018 at doctor.nl2k.ab.ca> on Fri, 26 Feb 2016 08:26:02 -0700, The Doctor said: doctor> On Fri, Feb 26, 2016 at 10:48:16AM +0100, Richard Levitte wrote: doctor> > In message <20160226092902.GA20863 at doctor.nl2k.ab.ca> on Fri, 26 Feb 2016 02:29:02 -0700, The Doctor said: doctor> > doctor> > doctor> Please have a look at doctor> > ... doctor> > doctor> making update in crypto... doctor> > doctor> make[1]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto' doctor> > doctor> makedepend: not found doctor> > doctor> makedepend: not found doctor> > doctor> mv: cannot stat `Makefile.new': No such file or directory doctor> > doctor> Makefile:136: recipe for target 'local_depend' failed doctor> > doctor> make[1]: *** [local_depend] Error 1 doctor> > doctor> make[1]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto' doctor> > doctor> Makefile:468: recipe for target 'update' failed doctor> > doctor> make: *** [update] Error 1 doctor> > ... doctor> > doctor> > Please install makedepend doctor> > doctor> doctor> Where do I find makedepend ? I don't know BSDi, so not sure how to answer that. I'm surprised it isn't there, though... however, it's a developper tool that originally came with X11 (or so the story tells *). There are tarballs here: http://xorg.freedesktop.org/releases/individual/util/ I'm surprised, though, as this is nothing new with 1.0.2... are you telling us that you've *never* run 'make depend' before? (*) https://en.wikipedia.org/wiki/Makedepend Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From rt at openssl.org Fri Feb 26 16:04:28 2016 From: rt at openssl.org (Rich Salz via RT) Date: Fri, 26 Feb 2016 16:04:28 +0000 Subject: [openssl-dev] [openssl.org #4335] ix 'assignment from incompatible type' warning in OBJ_NAME_new_index() In-Reply-To: <1456160635.4735.302.camel@infradead.org> References: <1456160635.4735.302.camel@infradead.org> Message-ID: commit 2d51c28 thanks! -- Rich Salz, OpenSSL dev team; rsalz at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4335 Please log in as guest with password guest if prompted From rt at openssl.org Fri Feb 26 16:17:50 2016 From: rt at openssl.org (Rich Salz via RT) Date: Fri, 26 Feb 2016 16:17:50 +0000 Subject: [openssl-dev] [openssl.org #4340] ASN1_item_sign_ctx(): method check before access and release ctx in error paths In-Reply-To: References: Message-ID: done, closing. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4340 Please log in as guest with password guest if prompted From rt at openssl.org Fri Feb 26 16:19:10 2016 From: rt at openssl.org (Rich Salz via RT) Date: Fri, 26 Feb 2016 16:19:10 +0000 Subject: [openssl-dev] [openssl.org #4343] master: EC_KEY_priv2buf (): check parameter sanity In-Reply-To: References: Message-ID: commit acae59b pushed, thanks! -- Rich Salz, OpenSSL dev team; rsalz at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4343 Please log in as guest with password guest if prompted From rt at openssl.org Fri Feb 26 16:33:01 2016 From: rt at openssl.org (Diego Aranha via RT) Date: Fri, 26 Feb 2016 16:33:01 +0000 Subject: [openssl-dev] [openssl.org #4349] Pull request for bilinear pairings In-Reply-To: References: Message-ID: Dear OpenSSL development team, Below you can find a pull request I just submitted containing a patch to implement bilinear pairings inside OpenSSL: https://github.com/openssl/openssl/pull/751 The implementation supports the so-called BN curves which are state-of-the-art in academic research and closer to standardization, as of [1,2]. [1] https://tools.ietf.org/html/draft-kasamatsu-bncurves [2] https://tools.ietf.org/html/draft-kato-optimal-ate-pairings Let me know if you have any questions. Thanks for your consideration! -- Diego de Freitas Aranha Institute of Computing - University of Campinas http://www.ic.unicamp.br/~dfaranha -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4349 Please log in as guest with password guest if prompted From rt at openssl.org Fri Feb 26 16:33:24 2016 From: rt at openssl.org (noloader@gmail.com via RT) Date: Fri, 26 Feb 2016 16:33:24 +0000 Subject: [openssl-dev] [openssl.org #4350] Failed self test 10-test_bn.t on 5th gen Core-i5 In-Reply-To: References: Message-ID: Results from a 5th gen Core-i5. I believe its a Broadwell processor with AVX2, RDSEED and friends. $ ./config ... $ make clean && make depend ... $ make && make test ... TOP=.. PERL=/usr/bin/perl /usr/bin/perl run_tests.pl alltests ../test/recipes/01-test_ordinals.t ........ ok ../test/recipes/05-test_bf.t .............. ok ../test/recipes/05-test_cast.t ............ ok ... ../test/recipes/10-test_bn.t .............. 1/3 # Failed test 'initialize' # at ../test/recipes/10-test_bn.t line 17. # Looks like you failed 1 test of 3. ../test/recipes/10-test_bn.t .............. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/3 subtests (less 1 skipped subtest: 1 okay) ... Test Summary Report ------------------- ../test/recipes/10-test_bn.t (Wstat: 256 Tests: 3 Failed: 1) Failed test: 2 Non-zero exit status: 1 Files=70, Tests=389, 22 wallclock secs ( 0.52 usr 0.06 sys + 14.82 cusr 0.89 csys = 16.29 CPU) Result: FAIL Failed 1/70 test programs. 1/389 subtests failed. make[1]: *** [tests] Error 255 -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4350 Please log in as guest with password guest if prompted From rt at openssl.org Fri Feb 26 16:50:27 2016 From: rt at openssl.org (Stephen Henson via RT) Date: Fri, 26 Feb 2016 16:50:27 +0000 Subject: [openssl-dev] [openssl.org #4343] master: EC_KEY_priv2buf (): check parameter sanity In-Reply-To: References: Message-ID: On Wed Feb 24 12:07:05 2016, mohan at computer.org wrote: > Hi, > > I have PR https://github.com/openssl/openssl/pull/739 with the below > changes, please have a look. > > - In EC_KEY_priv2buf(), check for pbuf sanity. > - If invoked with NULL, gracefully returns the key length. > If you're doing this you're probably using the wrong API. EC_KEY_priv2buf() allocates a buffer and returns its length. If you just want the length and/or want to allocate a buffer yourself you should be using EV_KEY_priv2oct() instead. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4343 Please log in as guest with password guest if prompted From openssl-users at dukhovni.org Fri Feb 26 17:04:43 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 26 Feb 2016 17:04:43 +0000 Subject: [openssl-dev] [openssl.org #4343] master: EC_KEY_priv2buf (): check parameter sanity In-Reply-To: References: Message-ID: <20160226170443.GW12869@mournblade.imrryr.org> On Fri, Feb 26, 2016 at 04:50:27PM +0000, Stephen Henson via RT wrote: > > I have PR https://github.com/openssl/openssl/pull/739 with the below > > changes, please have a look. > > > > - In EC_KEY_priv2buf(), check for pbuf sanity. > > - If invoked with NULL, gracefully returns the key length. > > > > If you're doing this you're probably using the wrong API. EC_KEY_priv2buf() > allocates a buffer and returns its length. If you just want the length and/or > want to allocate a buffer yourself you should be using EV_KEY_priv2oct() > instead. I'd like to propose a policy of no bug fixes to undocumented public interfaces. If the interface is useful enough to fix, it has to be documented. Anyone care to produce manpages for EC_KEY_priv2buf or EC_KEY_priv2oct? -- Viktor. From noloader at gmail.com Fri Feb 26 17:10:09 2016 From: noloader at gmail.com (Jeffrey Walton) Date: Fri, 26 Feb 2016 12:10:09 -0500 Subject: [openssl-dev] [openssl.org #4343] master: EC_KEY_priv2buf (): check parameter sanity In-Reply-To: <20160226170443.GW12869@mournblade.imrryr.org> References: <20160226170443.GW12869@mournblade.imrryr.org> Message-ID: >> > I have PR https://github.com/openssl/openssl/pull/739 with the below >> > changes, please have a look. >> > >> > - In EC_KEY_priv2buf(), check for pbuf sanity. >> > - If invoked with NULL, gracefully returns the key length. > ... > I'd like to propose a policy of no bug fixes to undocumented public > interfaces. If the interface is useful enough to fix, it has to be > documented. Anyone care to produce manpages for EC_KEY_priv2buf or > EC_KEY_priv2oct? > Correct me if I am wrong... API's that start with capitol letters are public. Private interfaces use lowercase letters. Documented/undocumented does not really factor things. If OpenSSL wants to make it private so that its should not be called and it won't be maintained, then the symbol should be changed to ec_key_priv2oct. Jeff From rsalz at akamai.com Fri Feb 26 17:10:42 2016 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 26 Feb 2016 17:10:42 +0000 Subject: [openssl-dev] [openssl.org #4343] master: EC_KEY_priv2buf (): check parameter sanity In-Reply-To: <20160226170443.GW12869@mournblade.imrryr.org> References: <20160226170443.GW12869@mournblade.imrryr.org> Message-ID: <26e72af80e074d579a6bdf39bb9250e9@usma1ex-dag1mb3.msg.corp.akamai.com> > I'd like to propose a policy of no bug fixes to undocumented public > interfaces. That seems extreme, given how much of the API is undocumented and how much external stuff depends on private things. I understand the goal. I just want to make sure you've thought about the proposal. (And heck I might even agree with it) From openssl-users at dukhovni.org Fri Feb 26 17:19:24 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 26 Feb 2016 17:19:24 +0000 Subject: [openssl-dev] [openssl.org #4343] master: EC_KEY_priv2buf (): check parameter sanity In-Reply-To: References: <20160226170443.GW12869@mournblade.imrryr.org> Message-ID: <20160226171924.GX12869@mournblade.imrryr.org> On Fri, Feb 26, 2016 at 12:10:09PM -0500, Jeffrey Walton wrote: > > I'd like to propose a policy of no bug fixes to undocumented public > > interfaces. If the interface is useful enough to fix, it has to be > > documented. Anyone care to produce manpages for EC_KEY_priv2buf or > > EC_KEY_priv2oct? > > > Correct me if I am wrong... API's that start with capitol letters are > public. Private interfaces use lowercase letters. > Documented/undocumented does not really factor things. You're wrong. Once OpenSSL's past sins are remediated, public interfaces are precisely those that are documented. For now, public interfaces are either macros or functions and global variables those whose symbols are exported by the libssl and libcrypto shared libraries. This is not a good place to be. > If OpenSSL wants to make it private so that its should not be called > and it won't be maintained, then the symbol should be changed to > ec_key_priv2oct. Undocumented functions have no public "contract", and should not be used. Sadly we're not quite there yet, but the way to get there is at least always update the documentation of any functions that are updated. We also have to document functions that are not updated, but that does not change the wisdom of the proposed policy. One reason to update the documentation, is that one will often find that documenting a function will make one think harder about how it is really supposed to behave, potentially improving the code and/or avoiding mistakes. -- Viktor. From standby24x7 at gmail.com Fri Feb 26 17:20:40 2016 From: standby24x7 at gmail.com (Masanari Iida) Date: Sat, 27 Feb 2016 02:20:40 +0900 Subject: [openssl-dev] [PATCH] Add missing semi colon in crypto/o_str.c Message-ID: <1456507240-16520-1-git-send-email-standby24x7@gmail.com> Missing semi colon cause following error. Wa,--noexecstack -fPIC -c -o o_str.o o_str.c o_str.c: In function 'CRYPTO_strndup': o_str.c:144:5: error: expected ';' before 'ret' ret = CRYPTO_malloc(maxlen + 1, file, line); ^ make[1]: *** [o_str.o] Error 1 make[1]: Leaving directory `/home/iida/Repo/openssl/crypto' make: *** [build_crypto] Error 1 Signed-off-by: Masanari Iida --- crypto/o_str.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/crypto/o_str.c b/crypto/o_str.c index b01128c..84005e6 100644 --- a/crypto/o_str.c +++ b/crypto/o_str.c @@ -139,7 +139,7 @@ char *CRYPTO_strndup(const char *str, size_t s, const char* file, int line) if (str == NULL) return NULL; - maxlen = OPENSSL_strnlen(str, s) + maxlen = OPENSSL_strnlen(str, s); ret = CRYPTO_malloc(maxlen + 1, file, line); if (ret) { -- 2.7.2.333.g70bd996 From rsalz at akamai.com Fri Feb 26 17:22:04 2016 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 26 Feb 2016 17:22:04 +0000 Subject: [openssl-dev] [PATCH] Add missing semi colon in crypto/o_str.c In-Reply-To: <1456507240-16520-1-git-send-email-standby24x7@gmail.com> References: <1456507240-16520-1-git-send-email-standby24x7@gmail.com> Message-ID: Yes already fixed, thanks. From uri at ll.mit.edu Fri Feb 26 17:22:10 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Fri, 26 Feb 2016 17:22:10 +0000 Subject: [openssl-dev] Ubsec and Chil engines In-Reply-To: <1456232068.4735.397.camel@infradead.org> References: <56C6FCFA.4040602@openssl.org> <1455887024.912.17.camel@redhat.com> <56C714BC.3060307@openssl.org> <1455893619.3919.62.camel@redhat.com> <1456139532.4735.266.camel@infradead.org> <1456232068.4735.397.camel@infradead.org> Message-ID: >>> Agreed. With the caveat that I *really* want libp11 and engine_pkcs11 >> > to die, and be replaced by native code in openssl/crypto/pkcs11/ >> >> Would you mind explaining what you mean by ?native code? that presumably >> could replace the current libp11, and who in your opinion would support >>it? > >Really, I mean "code within OpenSSL itself". In an ideal world, that >might actually *be* libp11, which is basically written as if it resides >in openssl/crypto/pkcs11/ already ? except for its licence (qv). Ah, I understand. Yes, we?re in complete agreement here. >So "die and be replaced by" would be the wrong wording for me to have >used. I want libp11 to stop being a *separate* project. :-) >In fact, libp11 wasn't seeing a huge amount of development work before >people started adding EC support to it, was it? Other than keeping it >up to date with OpenSSL releases, of course... Yep? >I don't anticipate that it would be a large maintenance burden. Michal would be the right person to comment on this, but I think I agree. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4324 bytes Desc: not available URL: From noloader at gmail.com Fri Feb 26 17:22:52 2016 From: noloader at gmail.com (Jeffrey Walton) Date: Fri, 26 Feb 2016 12:22:52 -0500 Subject: [openssl-dev] [openssl.org #4343] master: EC_KEY_priv2buf (): check parameter sanity In-Reply-To: <20160226171924.GX12869@mournblade.imrryr.org> References: <20160226170443.GW12869@mournblade.imrryr.org> <20160226171924.GX12869@mournblade.imrryr.org> Message-ID: >> > I'd like to propose a policy of no bug fixes to undocumented public >> > interfaces. If the interface is useful enough to fix, it has to be >> > documented. Anyone care to produce manpages for EC_KEY_priv2buf or >> > EC_KEY_priv2oct? >> > >> Correct me if I am wrong... API's that start with capitol letters are >> public. Private interfaces use lowercase letters. >> Documented/undocumented does not really factor things. > > You're wrong. Once OpenSSL's past sins are remediated, public > interfaces are precisely those that are documented. For now, public > interfaces are either macros or functions and global variables > those whose symbols are exported by the libssl and libcrypto shared > libraries. This is not a good place to be. > Thanks. Is that documented anywhere? (I'm still providing the old guidance, so it would be nice to cite the change and the documented policy). Jeff From openssl-users at dukhovni.org Fri Feb 26 17:24:46 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 26 Feb 2016 17:24:46 +0000 Subject: [openssl-dev] [openssl.org #4343] master: EC_KEY_priv2buf (): check parameter sanity In-Reply-To: <26e72af80e074d579a6bdf39bb9250e9@usma1ex-dag1mb3.msg.corp.akamai.com> References: <20160226170443.GW12869@mournblade.imrryr.org> <26e72af80e074d579a6bdf39bb9250e9@usma1ex-dag1mb3.msg.corp.akamai.com> Message-ID: <20160226172446.GY12869@mournblade.imrryr.org> On Fri, Feb 26, 2016 at 05:10:42PM +0000, Salz, Rich wrote: > > I'd like to propose a policy of no bug fixes to undocumented public > > interfaces. > > That seems extreme, given how much of the API is undocumented and how much > external stuff depends on private things. Not at all. You're well aware, for example, that the bulk of my changes for the upcoming security release are documentation; the code changes were easy enough. > I understand the goal. I just want to make sure you've thought about the > proposal. (And heck I might even agree with it) I've thought about it a great deal over the years. This policy has proved its worth over and over in other contexts and recently in OpenSSL as well. The code changes for 1.0.2g would not have been as complete, had I not reviewed and updated the documentation. -- Viktor. From rsalz at akamai.com Fri Feb 26 17:29:26 2016 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 26 Feb 2016 17:29:26 +0000 Subject: [openssl-dev] [openssl.org #4343] master: EC_KEY_priv2buf (): check parameter sanity In-Reply-To: <20160226172446.GY12869@mournblade.imrryr.org> References: <20160226170443.GW12869@mournblade.imrryr.org> <26e72af80e074d579a6bdf39bb9250e9@usma1ex-dag1mb3.msg.corp.akamai.com> <20160226172446.GY12869@mournblade.imrryr.org> Message-ID: As just about the only team member who trolls through RT and closes things with any quantity, I am not sure that I agree that fixing a bug requires documentation if the API isn't already documented. From openssl-users at dukhovni.org Fri Feb 26 17:34:14 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 26 Feb 2016 17:34:14 +0000 Subject: [openssl-dev] [openssl.org #4343] master: EC_KEY_priv2buf (): check parameter sanity In-Reply-To: References: <20160226170443.GW12869@mournblade.imrryr.org> <26e72af80e074d579a6bdf39bb9250e9@usma1ex-dag1mb3.msg.corp.akamai.com> <20160226172446.GY12869@mournblade.imrryr.org> Message-ID: <20160226173414.GA12869@mournblade.imrryr.org> On Fri, Feb 26, 2016 at 05:29:26PM +0000, Salz, Rich wrote: > As just about the only team member who trolls through RT and closes things > with any quantity, I am not sure that I agree that fixing a bug requires > documentation if the API isn't already documented. Focus on fixing bugs in documented interfaces first, and even then review the documentation, to make sure the fix comports with the documentation and that the latter is not stale. Once all the bugs in documented interfaces are fixed, I'm afraid we really must start documenting the code we're updating. Otherwise, there's no way to know we're doing it right, and we're digging the hole deeper. New code needs to be documented as it is written, old code also, but at a slower pace. -- Viktor. From openssl-users at dukhovni.org Fri Feb 26 17:37:11 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 26 Feb 2016 17:37:11 +0000 Subject: [openssl-dev] [openssl.org #4343] master: EC_KEY_priv2buf (): check parameter sanity In-Reply-To: References: <20160226170443.GW12869@mournblade.imrryr.org> <26e72af80e074d579a6bdf39bb9250e9@usma1ex-dag1mb3.msg.corp.akamai.com> <20160226172446.GY12869@mournblade.imrryr.org> Message-ID: <20160226173710.GB12869@mournblade.imrryr.org> On Fri, Feb 26, 2016 at 05:29:26PM +0000, Salz, Rich wrote: > As just about the only team member who trolls through RT and closes things > with any quantity, I am not sure that I agree that fixing a bug requires > documentation if the API isn't already documented. We should also get the word out that contributed patches (RT or Github) without documentation will take much longer to get adopted (will require someone else to find the time to create the documentation). Priority will go to patches with sufficiently complete documentation. -- Viktor. From noloader at gmail.com Fri Feb 26 17:37:22 2016 From: noloader at gmail.com (Jeffrey Walton) Date: Fri, 26 Feb 2016 12:37:22 -0500 Subject: [openssl-dev] [openssl.org #4343] master: EC_KEY_priv2buf (): check parameter sanity In-Reply-To: References: <20160226170443.GW12869@mournblade.imrryr.org> <26e72af80e074d579a6bdf39bb9250e9@usma1ex-dag1mb3.msg.corp.akamai.com> <20160226172446.GY12869@mournblade.imrryr.org> Message-ID: On Fri, Feb 26, 2016 at 12:29 PM, Salz, Rich wrote: > As just about the only team member who trolls through RT and closes things with any quantity, I am not sure that I agree that fixing a bug requires documentation if the API isn't already documented. +1. Concepts seem to be cross-pollinating. It seems like (to me) the the most direct way to mark a function as private is to add a comment in the source code stating such. That will avoid pain points for public but undocumented functions. it also seems like (to me) that tying bug fixes to documentation is a bad idea. Jeff From doctor at doctor.nl2k.ab.ca Fri Feb 26 17:33:01 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Fri, 26 Feb 2016 10:33:01 -0700 Subject: [openssl-dev] openssl 1.0.2 SNAP 20160226 issues In-Reply-To: <20160226.165932.467834483695581959.levitte@openssl.org> References: <20160226092902.GA20863@doctor.nl2k.ab.ca> <20160226.104816.1561735000710279669.levitte@openssl.org> <20160226152601.GA16018@doctor.nl2k.ab.ca> <20160226.165932.467834483695581959.levitte@openssl.org> Message-ID: <20160226173301.GA2053@doctor.nl2k.ab.ca> On Fri, Feb 26, 2016 at 04:59:32PM +0100, Richard Levitte wrote: > In message <20160226152601.GA16018 at doctor.nl2k.ab.ca> on Fri, 26 Feb 2016 08:26:02 -0700, The Doctor said: > > doctor> On Fri, Feb 26, 2016 at 10:48:16AM +0100, Richard Levitte wrote: > doctor> > In message <20160226092902.GA20863 at doctor.nl2k.ab.ca> on Fri, 26 Feb 2016 02:29:02 -0700, The Doctor said: > doctor> > > doctor> > doctor> Please have a look at > doctor> > ... > doctor> > doctor> making update in crypto... > doctor> > doctor> make[1]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto' > doctor> > doctor> makedepend: not found > doctor> > doctor> makedepend: not found > doctor> > doctor> mv: cannot stat `Makefile.new': No such file or directory > doctor> > doctor> Makefile:136: recipe for target 'local_depend' failed > doctor> > doctor> make[1]: *** [local_depend] Error 1 > doctor> > doctor> make[1]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160226/crypto' > doctor> > doctor> Makefile:468: recipe for target 'update' failed > doctor> > doctor> make: *** [update] Error 1 > doctor> > ... > doctor> > > doctor> > Please install makedepend > doctor> > > doctor> > doctor> Where do I find makedepend ? > > I don't know BSDi, so not sure how to answer that. I'm surprised it > isn't there, though... however, it's a developper tool that > originally came with X11 (or so the story tells *). There are > tarballs here: http://xorg.freedesktop.org/releases/individual/util/ > > I'm surprised, though, as this is nothing new with 1.0.2... are you > telling us that you've *never* run 'make depend' before? > > (*) https://en.wikipedia.org/wiki/Makedepend > Found it in /usr/X11/bin > Cheers, > Richard > > -- > Richard Levitte levitte at openssl.org > OpenSSL Project http://www.openssl.org/~levitte/ > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Broadcasting the truth for 25 years From openssl-users at dukhovni.org Fri Feb 26 17:42:02 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 26 Feb 2016 17:42:02 +0000 Subject: [openssl-dev] [openssl.org #4343] master: EC_KEY_priv2buf (): check parameter sanity In-Reply-To: References: <20160226170443.GW12869@mournblade.imrryr.org> <26e72af80e074d579a6bdf39bb9250e9@usma1ex-dag1mb3.msg.corp.akamai.com> <20160226172446.GY12869@mournblade.imrryr.org> Message-ID: <20160226174201.GC12869@mournblade.imrryr.org> On Fri, Feb 26, 2016 at 12:37:22PM -0500, Jeffrey Walton wrote: > It seems like (to me) the the most direct way to mark a function as > private is to add a comment in the source code stating such. Nonsense. Source code is not API documentation, it is an implementation, not an interface contract. > That will avoid pain points for public but undocumented functions. There's must (as soon as we can get there) be no such thing as a "public, but undocumented" function. > it also seems like (to me) that tying bug fixes to documentation is a bad idea. Bug fixes to undocumented functions will be buggy, and the documentation will never happen. We need to improve code quality, a good part of that is having documentation. -- Viktor. From nounou.dadoun at avigilon.com Fri Feb 26 17:34:16 2016 From: nounou.dadoun at avigilon.com (Nounou Dadoun) Date: Fri, 26 Feb 2016 17:34:16 +0000 Subject: [openssl-dev] Failed TLSv1.2 handshake with error 67702888--bad signature Message-ID: <8149AB08BCB1F54F92680ED6104891A0E1589D@mbx027-w1-ca-4.exch027.domain.local> Trying to upgrade from TLSv1 to TLSv1.1 and 1.2 has been more problematic than I might have suspected. I have a TLS server using openssl 1.0.2d doing mutual authentication and a one line change from TLSv1 (only) to TLSv1.2 breaks the connection where in the latter the server rejects the client certificate with "error 67702888--bad signature" (and the former happily accepts it). Given that description (and the fact that it's literally a one-line change), it's hard to believe that I'm doing something wrong. Can anyone tell me why TLSv1 accepts it and TLSv1.2 doesn't? Packet capture attached and more details below, certificate is in the packet capture but I can provide it separately if it will help, thanks ... N Nou Dadoun Senior Firmware Developer, Security Specialist -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Nounou Dadoun Sent: Thursday, February 25, 2016 5:44 PM To: openssl-users at openssl.org Subject: Re: [openssl-users] Failed TLSv1.2 handshake with error 67702888--bad signature Curiouser and curiouser - I have attached two minimal packet captures in which the only difference in the server build was a change in one line (using boost with openssl): : m_context(pIoService->GetNative(), boost::asio::ssl::context::tlsv1) to : m_context(pIoService->GetNative(), boost::asio::ssl::context::sslv23) They both disable sslv2 and sslv3. The former resulted in a handshake that completed, the latter failed with the aforementioned "67702888--bad signature" logged error. The respective packet captures are attached. This one has me pretty puzzled, any idea why tls1 succeeds and tls1.2 fails? Is tls1.2 more strict about accepting the client certificate since it's complaining about a "bad signature" where tlsv1 doesn't? Anybody have any ideas? ... N Nou Dadoun Senior Firmware Developer, Security Specialist -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Nounou Dadoun Sent: Thursday, February 25, 2016 2:42 PM To: openssl-users at openssl.org Subject: [openssl-users] Failed TLSv1.2 handshake with error 67702888--bad signature I'm trying to troubleshoot some development code which is enabling TLSv1.1 and 1.2 and failing. Have an odd tls handshake failure, with an error number that I can find any documentation about (is there any?) that indicates "67702888--bad signature" which is being logged on the server side; and I'm trying to see where in the handshake things are falling apart. Looks like it's negotiating tls1.2 and agreeing on TLS_RSA_WITH_AES_256_CBC_SHA256 but the client seems to be sending a certificate although I don't see it requesting mutual authentication. I've attached a very short wireshark capture - does anyone know what that error code might be related to or can give me a hint as to what's going awry here? Thanks ... N Nou Dadoun Senior Firmware Developer, Security Specialist Office: 604.629.5182 ext 2632 Support: 888.281.5182 ?|? avigilon.com Follow?Twitter ?|? Follow?LinkedIn This email, including any files attached hereto (the "email"), contains privileged and confidential information and is only for the intended addressee(s). If this email has been sent to you in error, such sending does not constitute waiver of privilege and we request that you kindly delete the email and notify the sender. Any unauthorized use or disclosure of this email is prohibited. Avigilon and certain other trade names used herein are the registered and/or unregistered trademarks of Avigilon Corporation and/or its affiliates in Canada and other jurisdictions worldwide. -------------- next part -------------- A non-text attachment was scrubbed... Name: tlsv1_successful_handshake.pcapng Type: application/octet-stream Size: 12728 bytes Desc: tlsv1_successful_handshake.pcapng URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: tlsv1.2_failed_handshake.pcapng Type: application/octet-stream Size: 7932 bytes Desc: tlsv1.2_failed_handshake.pcapng URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ATT00001.txt URL: From noloader at gmail.com Fri Feb 26 17:50:24 2016 From: noloader at gmail.com (Jeffrey Walton) Date: Fri, 26 Feb 2016 12:50:24 -0500 Subject: [openssl-dev] [openssl.org #4343] master: EC_KEY_priv2buf (): check parameter sanity In-Reply-To: <20160226174201.GC12869@mournblade.imrryr.org> References: <20160226170443.GW12869@mournblade.imrryr.org> <26e72af80e074d579a6bdf39bb9250e9@usma1ex-dag1mb3.msg.corp.akamai.com> <20160226172446.GY12869@mournblade.imrryr.org> <20160226174201.GC12869@mournblade.imrryr.org> Message-ID: On Fri, Feb 26, 2016 at 12:42 PM, Viktor Dukhovni wrote: > On Fri, Feb 26, 2016 at 12:37:22PM -0500, Jeffrey Walton wrote: > >> It seems like (to me) the the most direct way to mark a function as >> private is to add a comment in the source code stating such. > > Nonsense. Source code is not API documentation, it is an > implementation, not an interface contract. I'm not sure I'd consider it nonsense. Studying source code on occasion is simply par for the course when working with open source libraries. I'm not sure how that no longer applies. That won't chnage by fiat. In my naiveness, if you want something to be private, then you don't expose it to the outside world. It also seems like if a function leaks into a public header, then you state that its private and it should not be called. What's the aversion to a clearly and succinctly stating something? >> ... >> it also seems like (to me) that tying bug fixes to documentation is a bad idea. > > Bug fixes to undocumented functions will be buggy, and the > documentation will never happen. We need to improve code quality, > a good part of that is having documentation. It sounds like you are trying to get half pregnant. If the code is buggy, then it should be fixed or removed. There's no middle ground. Jeff From openssl-users at dukhovni.org Fri Feb 26 18:01:24 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 26 Feb 2016 18:01:24 +0000 Subject: [openssl-dev] [openssl.org #4343] master: EC_KEY_priv2buf (): check parameter sanity In-Reply-To: References: <20160226170443.GW12869@mournblade.imrryr.org> <26e72af80e074d579a6bdf39bb9250e9@usma1ex-dag1mb3.msg.corp.akamai.com> <20160226172446.GY12869@mournblade.imrryr.org> <20160226174201.GC12869@mournblade.imrryr.org> Message-ID: <20160226180124.GD12869@mournblade.imrryr.org> On Fri, Feb 26, 2016 at 12:50:24PM -0500, Jeffrey Walton wrote: > > Nonsense. Source code is not API documentation, it is an > > implementation, not an interface contract. > > I'm not sure I'd consider it nonsense. Comments in source code are not documentation, they explain the internals of the implementation, not the contract. Users of a library need to depend on documented semantics, not implementation artefacts. > Studying source code on occasion is simply par for the course when > working with open source libraries. Here, by "open source" you mean poorly maintained. I'd like OpenSSL to leave that legacy behind. Not all open source software is poorly maintained and under-documented. > In my naiveness, if you want something to be private, then you don't > expose it to the outside world. That too, but not documenting an interface should be sufficient to dissuade users from relying on it. Sadly, important parts of OpenSSL are not yet documented, and I am proposing we become more aggressive about fixing that. One way forward is to ensure that changes must come with documentation, created if missing, updated if the interface is extended, or changed incompatibly. > It also seems like if a function leaks into a public header, then you > state that its private and it should not be called. What's the > aversion to a clearly and succinctly stating something? All I'm saying is that documentation is not optional. Neither source code nor header files are documentation. > > Bug fixes to undocumented functions will be buggy, and the > > documentation will never happen. We need to improve code quality, > > a good part of that is having documentation. > > If the code is > buggy, then it should be fixed or removed. There's no middle ground. It must be fixed *and* documented. Over and out. -- Viktor. From rt at openssl.org Fri Feb 26 18:57:03 2016 From: rt at openssl.org (Rich Salz via RT) Date: Fri, 26 Feb 2016 18:57:03 +0000 Subject: [openssl-dev] [openssl.org #4350] Failed self test 10-test_bn.t on 5th gen Core-i5 In-Reply-To: References: Message-ID: closing per OP. - Rich Salz, OpenSSL dev team; rsalz at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4350 Please log in as guest with password guest if prompted From kurt at roeckx.be Fri Feb 26 19:32:10 2016 From: kurt at roeckx.be (Kurt Roeckx) Date: Fri, 26 Feb 2016 20:32:10 +0100 Subject: [openssl-dev] openssl 1.0.2 SNAP 20160226 issues In-Reply-To: <20160226.104816.1561735000710279669.levitte@openssl.org> References: <20160226092902.GA20863@doctor.nl2k.ab.ca> <20160226.104816.1561735000710279669.levitte@openssl.org> Message-ID: <20160226193209.GA10144@roeckx.be> On Fri, Feb 26, 2016 at 10:48:16AM +0100, Richard Levitte wrote: > > Please install makedepend I didn't know we needed that. I don't have it installed. It looks like in Debian it's in xutils-dev. Kurt From kurt at roeckx.be Fri Feb 26 19:49:38 2016 From: kurt at roeckx.be (Kurt Roeckx) Date: Fri, 26 Feb 2016 20:49:38 +0100 Subject: [openssl-dev] [openssl.org #4343] master: EC_KEY_priv2buf (): check parameter sanity In-Reply-To: <20160226173414.GA12869@mournblade.imrryr.org> References: <20160226170443.GW12869@mournblade.imrryr.org> <26e72af80e074d579a6bdf39bb9250e9@usma1ex-dag1mb3.msg.corp.akamai.com> <20160226172446.GY12869@mournblade.imrryr.org> <20160226173414.GA12869@mournblade.imrryr.org> Message-ID: <20160226194938.GB10144@roeckx.be> On Fri, Feb 26, 2016 at 05:34:14PM +0000, Viktor Dukhovni wrote: > On Fri, Feb 26, 2016 at 05:29:26PM +0000, Salz, Rich wrote: > > > As just about the only team member who trolls through RT and closes things > > with any quantity, I am not sure that I agree that fixing a bug requires > > documentation if the API isn't already documented. > > Focus on fixing bugs in documented interfaces first, and even then review > the documentation, to make sure the fix comports with the documentation and > that the latter is not stale. > > Once all the bugs in documented interfaces are fixed, I'm afraid > we really must start documenting the code we're updating. Otherwise, > there's no way to know we're doing it right, and we're digging the > hole deeper. New code needs to be documented as it is written, > old code also, but at a slower pace. I have to agree with Viktor. I've also been requesting minimal documentation for the new non-public functions. If I'm changing something in any non-documented function I try documenting it, but sometimes I might forget that, and I hope someone would remind me in that case. Kurt From levitte at openssl.org Fri Feb 26 19:50:34 2016 From: levitte at openssl.org (Richard Levitte) Date: Fri, 26 Feb 2016 20:50:34 +0100 (CET) Subject: [openssl-dev] openssl 1.0.2 SNAP 20160226 issues In-Reply-To: <20160226193209.GA10144@roeckx.be> References: <20160226092902.GA20863@doctor.nl2k.ab.ca> <20160226.104816.1561735000710279669.levitte@openssl.org> <20160226193209.GA10144@roeckx.be> Message-ID: <20160226.205034.2281370179398091823.levitte@openssl.org> In message <20160226193209.GA10144 at roeckx.be> on Fri, 26 Feb 2016 20:32:10 +0100, Kurt Roeckx said: kurt> On Fri, Feb 26, 2016 at 10:48:16AM +0100, Richard Levitte wrote: kurt> > kurt> > Please install makedepend kurt> kurt> I didn't know we needed that. I don't have it installed. It kurt> looks like in Debian it's in xutils-dev. It's a fallback when the compiler doesn't do that work. On Debian, you normally use GNU C or clang, and they're both capable to do the job. That's why you never need makedepend. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From uri at ll.mit.edu Fri Feb 26 19:54:32 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Fri, 26 Feb 2016 19:54:32 +0000 Subject: [openssl-dev] [openssl.org #4343] master: EC_KEY_priv2buf (): check parameter sanity In-Reply-To: <20160226180124.GD12869@mournblade.imrryr.org> References: <20160226170443.GW12869@mournblade.imrryr.org> <26e72af80e074d579a6bdf39bb9250e9@usma1ex-dag1mb3.msg.corp.akamai.com> <20160226172446.GY12869@mournblade.imrryr.org> <20160226174201.GC12869@mournblade.imrryr.org> <20160226180124.GD12869@mournblade.imrryr.org> Message-ID: >>> Nonsense. Source code is not API documentation, it is an >> > implementation, not an interface contract. >> >> I'm not sure I'd consider it nonsense. > >Comments in source code are not documentation, they explain the >internals of the implementation, not the contract. Actually they can (and should) be both. >Users of a library need to depend on documented semantics, not >implementation >artefacts. True. But at the very least the two shouldn?t say different things. :-) >>Studying source code on occasion is simply par for the course when >> working with open source libraries. > >Here, by "open source" you mean poorly maintained. I'd like OpenSSL >to leave that legacy behind. Not all open source software is poorly >maintained and under-documented. Here you equate ?poorly documented? with ?poorly maintained?. I?m not sure it?s always true. >All I'm saying is that documentation is not optional. Neither source >code nor header files are documentation. Yes, I completely agree with this. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4324 bytes Desc: not available URL: From nounou.dadoun at avigilon.com Fri Feb 26 20:29:30 2016 From: nounou.dadoun at avigilon.com (Nounou Dadoun) Date: Fri, 26 Feb 2016 20:29:30 +0000 Subject: [openssl-dev] Failed TLSv1.2 handshake with error 67702888--bad signature Message-ID: <8149AB08BCB1F54F92680ED6104891A0E15948@mbx027-w1-ca-4.exch027.domain.local> I've extracted the certificates from the exchange to verify that the (tlsv1) successful handshake and the (tlsv1.2) failed handshake certificates are identical (they are) and I've also checked to make sure that the CA certificate that the server has for signature verification is the same as the CA certificate handed over by the client in the exchange (it is). I've also used the command line openssl verify to verify the certificate against the CA: "client_cert_success.pem: OK" However it succeeds in TLSv1 and fails in TLSv1.2 (the one line change noted below). I've now attached the certificates for quick reference - can anyone see what might be causing the different behavior between TLSv1 and TLSv1.2? Quite puzzling! Nou Dadoun Senior Firmware Developer, Security Specialist -----Original Message----- From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Nounou Dadoun Sent: Friday, February 26, 2016 9:34 AM To: openssl-dev at openssl.org Subject: [openssl-dev] Failed TLSv1.2 handshake with error 67702888--bad signature Trying to upgrade from TLSv1 to TLSv1.1 and 1.2 has been more problematic than I might have suspected. I have a TLS server using openssl 1.0.2d doing mutual authentication and a one line change from TLSv1 (only) to TLSv1.2 breaks the connection where in the latter the server rejects the client certificate with "error 67702888--bad signature" (and the former happily accepts it). Given that description (and the fact that it's literally a one-line change), it's hard to believe that I'm doing something wrong. Can anyone tell me why TLSv1 accepts it and TLSv1.2 doesn't? Packet capture attached and more details below, certificate is in the packet capture but I can provide it separately if it will help, thanks ... N Nou Dadoun Senior Firmware Developer, Security Specialist -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Nounou Dadoun Sent: Thursday, February 25, 2016 5:44 PM To: openssl-users at openssl.org Subject: Re: [openssl-users] Failed TLSv1.2 handshake with error 67702888--bad signature Curiouser and curiouser - I have attached two minimal packet captures in which the only difference in the server build was a change in one line (using boost with openssl): : m_context(pIoService->GetNative(), boost::asio::ssl::context::tlsv1) to : m_context(pIoService->GetNative(), boost::asio::ssl::context::sslv23) They both disable sslv2 and sslv3. The former resulted in a handshake that completed, the latter failed with the aforementioned "67702888--bad signature" logged error. The respective packet captures are attached. This one has me pretty puzzled, any idea why tls1 succeeds and tls1.2 fails? Is tls1.2 more strict about accepting the client certificate since it's complaining about a "bad signature" where tlsv1 doesn't? Anybody have any ideas? ... N Nou Dadoun Senior Firmware Developer, Security Specialist -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Nounou Dadoun Sent: Thursday, February 25, 2016 2:42 PM To: openssl-users at openssl.org Subject: [openssl-users] Failed TLSv1.2 handshake with error 67702888--bad signature I'm trying to troubleshoot some development code which is enabling TLSv1.1 and 1.2 and failing. Have an odd tls handshake failure, with an error number that I can find any documentation about (is there any?) that indicates "67702888--bad signature" which is being logged on the server side; and I'm trying to see where in the handshake things are falling apart. Looks like it's negotiating tls1.2 and agreeing on TLS_RSA_WITH_AES_256_CBC_SHA256 but the client seems to be sending a certificate although I don't see it requesting mutual authentication. I've attached a very short wireshark capture - does anyone know what that error code might be related to or can give me a hint as to what's going awry here? Thanks ... N Nou Dadoun Senior Firmware Developer, Security Specialist Office: 604.629.5182 ext 2632 Support: 888.281.5182 ?|? avigilon.com Follow?Twitter ?|? Follow?LinkedIn This email, including any files attached hereto (the "email"), contains privileged and confidential information and is only for the intended addressee(s). If this email has been sent to you in error, such sending does not constitute waiver of privilege and we request that you kindly delete the email and notify the sender. Any unauthorized use or disclosure of this email is prohibited. Avigilon and certain other trade names used herein are the registered and/or unregistered trademarks of Avigilon Corporation and/or its affiliates in Canada and other jurisdictions worldwide. -------------- next part -------------- A non-text attachment was scrubbed... Name: client_cert_success.pem Type: application/octet-stream Size: 1310 bytes Desc: client_cert_success.pem URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: client_cert_CA_success.pem Type: application/octet-stream Size: 1692 bytes Desc: client_cert_CA_success.pem URL: From rt at openssl.org Fri Feb 26 20:41:22 2016 From: rt at openssl.org (David Benjamin via RT) Date: Fri, 26 Feb 2016 20:41:22 +0000 Subject: [openssl-dev] [openssl.org #4346] Re: poly1305-x86.pl's AVX2 code In-Reply-To: References: Message-ID: On Thu, Feb 25, 2016 at 6:16 PM David Benjamin wrote: > From looking at valgrind, this pattern seems to give good coverage. I > used valgrind --tool=callgrind --dump-instr=yes --collect-jumps=yes and > then kcachegrind to inspect the output. (kcachegrind is a bit heavy for > this. I'm hoping I can find or write a better annotator here. Something > which looks like, say, LCOV would be ideal.) > For anyone else who wants to try this sort of thing, passing -g to the assembler (so -Wa,-g) will make callgrind_annotate emit this in a useful form without needing kcachegrind. Thanks to Steven Valdez for pointing this out. David -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4346 Please log in as guest with password guest if prompted From kurt at roeckx.be Fri Feb 26 21:42:48 2016 From: kurt at roeckx.be (Kurt Roeckx) Date: Fri, 26 Feb 2016 22:42:48 +0100 Subject: [openssl-dev] Failed TLSv1.2 handshake with error 67702888--bad signature In-Reply-To: <8149AB08BCB1F54F92680ED6104891A0E1589D@mbx027-w1-ca-4.exch027.domain.local> References: <8149AB08BCB1F54F92680ED6104891A0E1589D@mbx027-w1-ca-4.exch027.domain.local> Message-ID: <20160226214247.GA985@roeckx.be> I can only find 1 place in the server that generates an SSL_R_BAD_SIGNATURE and that's in ssl3_get_cert_verify, in the case of signature algorithms are used, which is new in TLS 1.2. I don't see anything obviously wrong, and as far as I know the test suite also tests client authentication. Kurt On Fri, Feb 26, 2016 at 05:34:16PM +0000, Nounou Dadoun wrote: > Trying to upgrade from TLSv1 to TLSv1.1 and 1.2 has been more problematic than I might have suspected. > I have a TLS server using openssl 1.0.2d doing mutual authentication and a one line change from TLSv1 (only) to TLSv1.2 breaks the connection where in the latter the server rejects the client certificate with "error 67702888--bad signature" (and the former happily accepts it). > > Given that description (and the fact that it's literally a one-line change), it's hard to believe that I'm doing something wrong. > > Can anyone tell me why TLSv1 accepts it and TLSv1.2 doesn't? Packet capture attached and more details below, certificate is in the packet capture but I can provide it separately if it will help, thanks ... N > > Nou Dadoun > Senior Firmware Developer, Security Specialist > > > -----Original Message----- > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Nounou Dadoun > Sent: Thursday, February 25, 2016 5:44 PM > To: openssl-users at openssl.org > Subject: Re: [openssl-users] Failed TLSv1.2 handshake with error 67702888--bad signature > > Curiouser and curiouser - I have attached two minimal packet captures in which the only difference in the server build was a change in one line (using boost with openssl): > : m_context(pIoService->GetNative(), boost::asio::ssl::context::tlsv1) > to > : m_context(pIoService->GetNative(), boost::asio::ssl::context::sslv23) > > They both disable sslv2 and sslv3. > The former resulted in a handshake that completed, the latter failed with the aforementioned "67702888--bad signature" logged error. The respective packet captures are attached. > > This one has me pretty puzzled, any idea why tls1 succeeds and tls1.2 fails? > > Is tls1.2 more strict about accepting the client certificate since it's complaining about a "bad signature" where tlsv1 doesn't? > > Anybody have any ideas? ... N > > Nou Dadoun > Senior Firmware Developer, Security Specialist > > > -----Original Message----- > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Nounou Dadoun > Sent: Thursday, February 25, 2016 2:42 PM > To: openssl-users at openssl.org > Subject: [openssl-users] Failed TLSv1.2 handshake with error 67702888--bad signature > > I'm trying to troubleshoot some development code which is enabling TLSv1.1 and 1.2 and failing. Have an odd tls handshake failure, with an error number that I can find any documentation about (is there any?) that indicates "67702888--bad signature" which is being logged on the server side; and I'm trying to see where in the handshake things are falling apart. > > Looks like it's negotiating tls1.2 and agreeing on TLS_RSA_WITH_AES_256_CBC_SHA256 but the client seems to be sending a certificate although I don't see it requesting mutual authentication. > > I've attached a very short wireshark capture - does anyone know what that error code might be related to or can give me a hint as to what's going awry here? Thanks ... N > > > Nou Dadoun > Senior Firmware Developer, Security Specialist > > > Office: 604.629.5182 ext 2632 > Support: 888.281.5182 ?|? avigilon.com > Follow?Twitter ?|? Follow?LinkedIn > > > This email, including any files attached hereto (the "email"), contains privileged and confidential information and is only for the intended addressee(s). If this email has been sent to you in error, such sending does not constitute waiver of privilege and we request that you kindly delete the email and notify the sender. Any unauthorized use or disclosure of this email is prohibited. Avigilon and certain other trade names used herein are the registered and/or unregistered trademarks of Avigilon Corporation and/or its affiliates in Canada and other jurisdictions worldwide. > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From rt at openssl.org Fri Feb 26 21:48:34 2016 From: rt at openssl.org (Andy Polyakov via RT) Date: Fri, 26 Feb 2016 21:48:34 +0000 Subject: [openssl-dev] [openssl.org #4346] poly1305-x86.pl's AVX2 code In-Reply-To: <56D0C82F.2060209@openssl.org> References: <56D0C82F.2060209@openssl.org> Message-ID: > There seems to be a bug in the AVX2 codepath in poly1305-x86.pl. I have not > attempted to debug this, but I have attached a test file which produces > different output in normal and AVX2 codepaths. Our existing poly1305 > implementation agrees with the former. > > $ OPENSSL_ia32cap=0 ./poly1305_test > PASS > $ ./poly1305_test > Poly1305 test failed. > got: 2e65f0054e36505687d937ff5e8ed112 > expected: 69d28f73dd09d39a92aa179da354b7ea While I keep looking further, double-check attached. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4346 Please log in as guest with password guest if prompted -------------- next part -------------- diff --git a/crypto/poly1305/asm/poly1305-x86.pl b/crypto/poly1305/asm/poly1305-x86.pl index 7c1aee5..6f743ba 100755 --- a/crypto/poly1305/asm/poly1305-x86.pl +++ b/crypto/poly1305/asm/poly1305-x86.pl @@ -1435,7 +1435,7 @@ sub X { my $reg=shift; $reg=~s/^ymm/xmm/; $reg; } &test ("eax","eax"); # is_base2_26? &jz (&label("enter_blocks")); -&set_label("enter_avx2",16); +&set_label("enter_avx2"); &vzeroupper (); &call (&label("pic_point")); @@ -1540,6 +1540,8 @@ sub X { my $reg=shift; $reg=~s/^ymm/xmm/; $reg; } &and ("ecx",-64); &and ("edx",63); + &vlazy_reduction(); + &vmovdqu (&X($T0),&QWP(16*0,"esi")); &cmp ("edx",32); &jb (&label("one")); @@ -1778,8 +1780,8 @@ sub vlazy_reduction { &vmovd (&DWP(-16*3+4*3,"edi"),"xmm3"); &vmovd (&DWP(-16*3+4*4,"edi"),"xmm4"); &vzeroupper (); + &mov ("esp","ebp"); &set_label("nodata"); - &mov ("esp","ebp"); &function_end("_poly1305_blocks_avx2"); } &set_label("const_sse2",64); From rt at openssl.org Fri Feb 26 21:59:23 2016 From: rt at openssl.org (David Benjamin via RT) Date: Fri, 26 Feb 2016 21:59:23 +0000 Subject: [openssl-dev] [openssl.org #4346] poly1305-x86.pl's AVX2 code In-Reply-To: References: <56D0C82F.2060209@openssl.org> Message-ID: On Fri, Feb 26, 2016 at 4:48 PM Andy Polyakov via RT wrote: > > There seems to be a bug in the AVX2 codepath in poly1305-x86.pl. I have > not > > attempted to debug this, but I have attached a test file which produces > > different output in normal and AVX2 codepaths. Our existing poly1305 > > implementation agrees with the former. > > > > $ OPENSSL_ia32cap=0 ./poly1305_test > > PASS > > $ ./poly1305_test > > Poly1305 test failed. > > got: 2e65f0054e36505687d937ff5e8ed112 > > expected: 69d28f73dd09d39a92aa179da354b7ea > > While I keep looking further, double-check attached. > That patch makes all of my test cases pass. (Though I don't know if I have coverage for this code because valgrind doesn't do 32-bit AVX2 yet.) David -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4346 Please log in as guest with password guest if prompted From rt at openssl.org Fri Feb 26 22:25:33 2016 From: rt at openssl.org (noloader@gmail.com via RT) Date: Fri, 26 Feb 2016 22:25:33 +0000 Subject: [openssl-dev] [openssl.org #4351] PATCH: Update Malloc docs to reflect current state of affairs In-Reply-To: References: Message-ID: There are two changes below. First, OPENSSL_cleanse() was provided documentation consistent with the new policy of "public functions have documentation; otherwise its private". Second, updated OPENSSL_clear_realloc() and OPENSSL_clear_free() to reflect current state of affairs with respect to OPENSSL_cleanse() and its recent changes (https://git.openssl.org/?p=openssl.git;a=commitdiff;h=104ce8a9f02d250dd43c255eb7b8747e81b29422;hp=380f18ed5f140e0ae1b68f3ab8f4f7c395658d9e). $ cat malloc.diff diff --git a/doc/crypto/OPENSSL_malloc.pod b/doc/crypto/OPENSSL_malloc.pod index 04fa0b7..4e08918 100644 --- a/doc/crypto/OPENSSL_malloc.pod +++ b/doc/crypto/OPENSSL_malloc.pod @@ -4,7 +4,7 @@ OPENSSL_malloc_init, OPENSSL_malloc, OPENSSL_zalloc, OPENSSL_realloc, OPENSSL_free, -OPENSSL_clear_realloc, OPENSSL_clear_free, +OPENSSL_clear_realloc, OPENSSL_clear_free, OPENSSL_cleanse CRYPTO_malloc, CRYPTO_zalloc, CRYPTO_realloc, CRYPTO_free, OPENSSL_strdup, OPENSSL_strndup, OPENSSL_memdup, OPENSSL_strlcpy, OPENSSL_strlcat, @@ -84,9 +84,17 @@ OPENSSL_zalloc() calls memset() to zero the memory before returning. OPENSSL_clear_realloc() and OPENSSL_clear_free() should be used when the buffer at B holds sensitive information. -The old buffer is filled with arbitrary data by calling OPENSSL_cleanse() +The old buffer is filled with 0's by calling OPENSSL_cleanse() before ultimately calling OPENSSL_free(). +OPENSSL_cleanse() fills B of size B with a string of 0's. +Use OPENSSL_cleanse() with care if the memory is a mapping of a file. +If the storage controller uses write compression, then its possible +that sensitive tail bytes will survive zeroization because the block +of zeros will be compressed. If the storage controller uses wear leveling, +then the old sensitive data will not be overwritten; rather, a block of +0's will be written at a new physical location. + OPENSSL_strdup(), OPENSSL_strndup() and OPENSSL_memdup() are like the equivalent C functions, except that memory is allocated by calling the OPENSSL_malloc() and should be releaed by calling OPENSSL_free(). -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4351 Please log in as guest with password guest if prompted -------------- next part -------------- diff --git a/doc/crypto/OPENSSL_malloc.pod b/doc/crypto/OPENSSL_malloc.pod index 04fa0b7..4e08918 100644 --- a/doc/crypto/OPENSSL_malloc.pod +++ b/doc/crypto/OPENSSL_malloc.pod @@ -4,7 +4,7 @@ OPENSSL_malloc_init, OPENSSL_malloc, OPENSSL_zalloc, OPENSSL_realloc, OPENSSL_free, -OPENSSL_clear_realloc, OPENSSL_clear_free, +OPENSSL_clear_realloc, OPENSSL_clear_free, OPENSSL_cleanse CRYPTO_malloc, CRYPTO_zalloc, CRYPTO_realloc, CRYPTO_free, OPENSSL_strdup, OPENSSL_strndup, OPENSSL_memdup, OPENSSL_strlcpy, OPENSSL_strlcat, @@ -84,9 +84,17 @@ OPENSSL_zalloc() calls memset() to zero the memory before returning. OPENSSL_clear_realloc() and OPENSSL_clear_free() should be used when the buffer at B holds sensitive information. -The old buffer is filled with arbitrary data by calling OPENSSL_cleanse() +The old buffer is filled with 0's by calling OPENSSL_cleanse() before ultimately calling OPENSSL_free(). +OPENSSL_cleanse() fills B of size B with a string of 0's. +Use OPENSSL_cleanse() with care if the memory is a mapping of a file. +If the storage controller uses write compression, then its possible +that sensitive tail bytes will survive zeroization because the block +of zeros will be compressed. If the storage controller uses wear leveling, +then the old sensitive data will not be overwritten; rather, a block of +0's will be written at a new physical location. + OPENSSL_strdup(), OPENSSL_strndup() and OPENSSL_memdup() are like the equivalent C functions, except that memory is allocated by calling the OPENSSL_malloc() and should be releaed by calling OPENSSL_free(). From rt at openssl.org Sat Feb 27 01:58:26 2016 From: rt at openssl.org (noloader@gmail.com via RT) Date: Sat, 27 Feb 2016 01:58:26 +0000 Subject: [openssl-dev] [openssl.org #4352] Failed test 'Duplicate ClientHello extension' when testing under Clang undefined behavior sanitizer In-Reply-To: References: Message-ID: Platform is Linux, x86_64. The failure occurs under Clang with the sanitizer. GCC is fine. I'm guessing the error output from the Undefined Behavior sanitizer is causing the test to be interpreted as a fail. $ export CC=clang $ ./config -fsanitize=undefined ... $ make depend && make ... $ make test ... ../test/recipes/70-test_sslextension.t .... 1/3 # Failed test 'Duplicate ClientHello extension' # at ../test/recipes/70-test_sslextension.t line 149. # Looks like you failed 1 test of 3. ../test/recipes/70-test_sslextension.t .... Dubious, test returned 1 (wstat 256, 0x100) Failed 1/3 subtests ... Test Summary Report ------------------- ../test/recipes/70-test_sslextension.t (Wstat: 256 Tests: 3 Failed: 1) Failed test: 2 Non-zero exit status: 1 Files=70, Tests=389, 38 wallclock secs ( 0.54 usr 0.11 sys + 28.42 cusr 2.07 csys = 31.14 CPU) Result: FAIL Failed 1/70 test programs. 1/389 subtests failed. make: *** [test] Error 255 -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4352 Please log in as guest with password guest if prompted From rt at openssl.org Sat Feb 27 09:11:18 2016 From: rt at openssl.org (Kurt Roeckx via RT) Date: Sat, 27 Feb 2016 09:11:18 +0000 Subject: [openssl-dev] [openssl.org #4352] Failed test 'Duplicate ClientHello extension' when testing under Clang undefined behavior sanitizer In-Reply-To: <20160227091106.GA24110@roeckx.be> References: <20160227091106.GA24110@roeckx.be> Message-ID: On Sat, Feb 27, 2016 at 01:58:26AM +0000, noloader at gmail.com via RT wrote: > Platform is Linux, x86_64. The failure occurs under Clang with the > sanitizer. GCC is fine. > > I'm guessing the error output from the Undefined Behavior sanitizer is > causing the test to be interpreted as a fail. It has 2 of them: apps/s_cb.c:1077:41: runtime error: index 18446744073709551614 out of bounds for type 'const unsigned char [3]' I've already fixed this, it's been reviewed, it's just not in master yet. Then there is also: crypto/include/internal/md32_common.h:380:5: runtime error: store to misaligned address 0x00000210b5fd for type 'unsigned int', which requires 4 byte alignment That seems to go away when using -DPEDANTIC Kurt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4352 Please log in as guest with password guest if prompted From rt at openssl.org Sat Feb 27 12:05:19 2016 From: rt at openssl.org (Kiyoshi KANAZAWA via RT) Date: Sat, 27 Feb 2016 12:05:19 +0000 Subject: [openssl-dev] [openssl.org #4353] openssl-1.0.2f dependency error In-Reply-To: <671841.37138.qm@web101213.mail.kks.yahoo.co.jp> References: <671841.37138.qm@web101213.mail.kks.yahoo.co.jp> Message-ID: There are dependency error in Makefile(s). SHARED_LIBS are checked in . but make will be run in .. crypto/Makefile: ?? 108? shared: buildinf.h lib subdirs ?? 109????? if [ -n "$(SHARED_LIBS)" ]; then \ ?? 110????????? (cd ..; $(MAKE) $(SHARED_LIB)); \ ?? 111????? fi ssl/Makefile: ??? 63? shared: lib ??? 64????? if [ -n "$(SHARED_LIBS)" ]; then \ ??? 65????????? (cd ..; $(MAKE) $(SHARED_LIB)); \ ??? 66????? fi I do not know if this is the reason, libcrypto.so.1.0.0 & libssl.so.1.0.0 are remade in "make install". Best regards, --- Kiyoshi -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4353 Please log in as guest with password guest if prompted From rt at openssl.org Sat Feb 27 15:19:29 2016 From: rt at openssl.org (Kiyoshi KANAZAWA via RT) Date: Sat, 27 Feb 2016 15:19:29 +0000 Subject: [openssl-dev] [openssl.org #4353] openssl-1.0.2f dependency error In-Reply-To: <874665.10193.qm@web101210.mail.kks.yahoo.co.jp> References: <671841.37138.qm@web101213.mail.kks.yahoo.co.jp> <874665.10193.qm@web101210.mail.kks.yahoo.co.jp> Message-ID: Hmm... % make libcrypto.so.1.0.0 libssl.so.1.0.0 always remakes them. It is better to change Makefile in top, but too complicated for me. Easier sample patch is as follows. diff -cr ../openssl-1.0.2f.orig/crypto/Makefile ./crypto/Makefile *** ../openssl-1.0.2f.orig/crypto/Makefile? 2016-01-28 22:57:08.000000000 +0900 --- ./crypto/Makefile?? 2016-02-28 00:08:39.481790027 +0900 *************** *** 106,112 **** ??? $(RANLIB) $(LIB) || echo Never mind. ? ? shared: buildinf.h lib subdirs !?? if [ -n "$(SHARED_LIBS)" ]; then \ ??????? (cd ..; $(MAKE) $(SHARED_LIB)); \ ??? fi ? --- 106,112 ---- ??? $(RANLIB) $(LIB) || echo Never mind. ? ? shared: buildinf.h lib subdirs !?? if [ ! -f "../$(SHARED_LIB)" ]; then \ ??????? (cd ..; $(MAKE) $(SHARED_LIB)); \ ??? fi ? diff -cr ../openssl-1.0.2f.orig/ssl/Makefile ./ssl/Makefile *** ../openssl-1.0.2f.orig/ssl/Makefile 2016-01-28 22:57:19.000000000 +0900 --- ./ssl/Makefile? 2016-02-28 00:08:39.482126645 +0900 *************** *** 61,67 **** ??? @touch lib ? ? shared: lib !?? if [ -n "$(SHARED_LIBS)" ]; then \ ??????? (cd ..; $(MAKE) $(SHARED_LIB)); \ ??? fi ? --- 61,67 ---- ??? @touch lib ? ? shared: lib !?? if [ ! -f "../$(SHARED_LIB)" ]; then \ ??????? (cd ..; $(MAKE) $(SHARED_LIB)); \ ??? fi Best Regards, --- Kiyoshi -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4353 Please log in as guest with password guest if prompted From rt at openssl.org Sat Feb 27 15:28:07 2016 From: rt at openssl.org (Kiyoshi KANAZAWA via RT) Date: Sat, 27 Feb 2016 15:28:07 +0000 Subject: [openssl-dev] [openssl.org #4353] openssl-1.0.2f dependency error In-Reply-To: <365560.68678.qm@web101213.mail.kks.yahoo.co.jp> References: <671841.37138.qm@web101213.mail.kks.yahoo.co.jp> <365560.68678.qm@web101213.mail.kks.yahoo.co.jp> Message-ID: Hmm... % make libcrypto.so.1.0.0 libssl.so.1.0.0 always remakes them. It is better to change Makefile in top, but too complicated for me. Easier sample patch is as follows. diff -cr ../openssl-1.0.2f.orig/crypto/Makefile ./crypto/Makefile *** ../openssl-1.0.2f.orig/crypto/Makefile? 2016-01-28 22:57:08.000000000 +0900 --- ./crypto/Makefile?? 2016-02-28 00:08:39.481790027 +0900 *************** *** 106,112 **** ??? $(RANLIB) $(LIB) || echo Never mind. ? ? shared: buildinf.h lib subdirs !?? if [ -n "$(SHARED_LIBS)" ]; then \ ??????? (cd ..; $(MAKE) $(SHARED_LIB)); \ ??? fi ? --- 106,112 ---- ??? $(RANLIB) $(LIB) || echo Never mind. ? ? shared: buildinf.h lib subdirs !?? if [ ! -f "../$(SHARED_LIB)" ]; then \ ??????? (cd ..; $(MAKE) $(SHARED_LIB)); \ ??? fi ? diff -cr ../openssl-1.0.2f.orig/ssl/Makefile ./ssl/Makefile *** ../openssl-1.0.2f.orig/ssl/Makefile 2016-01-28 22:57:19.000000000 +0900 --- ./ssl/Makefile? 2016-02-28 00:08:39.482126645 +0900 *************** *** 61,67 **** ??? @touch lib ? ? shared: lib !?? if [ -n "$(SHARED_LIBS)" ]; then \ ??????? (cd ..; $(MAKE) $(SHARED_LIB)); \ ??? fi ? --- 61,67 ---- ??? @touch lib ? ? shared: lib !?? if [ ! -f "../$(SHARED_LIB)" ]; then \ ??????? (cd ..; $(MAKE) $(SHARED_LIB)); \ ??? fi Best Regards, --- Kiyoshi -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4353 Please log in as guest with password guest if prompted From rt at openssl.org Sat Feb 27 18:42:57 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sat, 27 Feb 2016 18:42:57 +0000 Subject: [openssl-dev] [openssl.org #2275] CVS HEAD: BIO b_sock: ioctl(FIONBIO) is not available everywhere; completed BIO_socket_nbio() so the #ifdef clutter in apps/* and other spots can be discarded after this In-Reply-To: References: Message-ID: and the apps are converted to use that function (BIO_sock_nbio) , so fully closing this :) -- Rich Salz, OpenSSL dev team; rsalz at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2275 Please log in as guest with password guest if prompted From rt at openssl.org Sat Feb 27 20:24:07 2016 From: rt at openssl.org (noloader@gmail.com via RT) Date: Sat, 27 Feb 2016 20:24:07 +0000 Subject: [openssl-dev] [openssl.org #4354] PATCH: cross reference SSL_CTX_set_client_CA_list in SSL_CTX_use_certificate and SSL_CTX_load_verify_locations man pages In-Reply-To: References: Message-ID: Stack Overflow has a number of questions related to mutual authentication, the client and its certificate. Those visiting the man pages for functions like SSL_CTX_use_certificate and SSL_CTX_load_verify_locations don't receive the benefit of a cross reference to SSL_CTX_set_client_CA_list. This patch adds the cross reference. $ cat SSL_CTX_set_client_CA_list.diff diff --git a/doc/ssl/SSL_CTX_load_verify_locations.pod b/doc/ssl/SSL_CTX_load_verify_locations.pod index de388d3..53e119e 100644 --- a/doc/ssl/SSL_CTX_load_verify_locations.pod +++ b/doc/ssl/SSL_CTX_load_verify_locations.pod @@ -141,6 +141,7 @@ L, L, L, L, -L +L, +L =cut diff --git a/doc/ssl/SSL_CTX_use_certificate.pod b/doc/ssl/SSL_CTX_use_certificate.pod index 2bb0ea6..13bb277 100644 --- a/doc/ssl/SSL_CTX_use_certificate.pod +++ b/doc/ssl/SSL_CTX_use_certificate.pod @@ -154,6 +154,7 @@ L, L, L, L, L, L, +L, L, L -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4354 Please log in as guest with password guest if prompted -------------- next part -------------- diff --git a/doc/ssl/SSL_CTX_load_verify_locations.pod b/doc/ssl/SSL_CTX_load_verify_locations.pod index de388d3..53e119e 100644 --- a/doc/ssl/SSL_CTX_load_verify_locations.pod +++ b/doc/ssl/SSL_CTX_load_verify_locations.pod @@ -141,6 +141,7 @@ L, L, L, L, -L +L, +L =cut diff --git a/doc/ssl/SSL_CTX_use_certificate.pod b/doc/ssl/SSL_CTX_use_certificate.pod index 2bb0ea6..13bb277 100644 --- a/doc/ssl/SSL_CTX_use_certificate.pod +++ b/doc/ssl/SSL_CTX_use_certificate.pod @@ -154,6 +154,7 @@ L, L, L, L, L, L, +L, L, L From rt at openssl.org Sun Feb 28 00:00:23 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 28 Feb 2016 00:00:23 +0000 Subject: [openssl-dev] [openssl.org #4354] PATCH: cross reference SSL_CTX_set_client_CA_list in SSL_CTX_use_certificate and SSL_CTX_load_verify_locations man pages In-Reply-To: References: Message-ID: commit e0b5108; thanks. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4354 Please log in as guest with password guest if prompted From noloader at gmail.com Sun Feb 28 00:42:23 2016 From: noloader at gmail.com (Jeffrey Walton) Date: Sat, 27 Feb 2016 19:42:23 -0500 Subject: [openssl-dev] [openssl.org #4343] master: EC_KEY_priv2buf (): check parameter sanity In-Reply-To: <20160226171924.GX12869@mournblade.imrryr.org> References: <20160226170443.GW12869@mournblade.imrryr.org> <20160226171924.GX12869@mournblade.imrryr.org> Message-ID: >> Correct me if I am wrong... API's that start with capitol letters are >> public. Private interfaces use lowercase letters. >> Documented/undocumented does not really factor things. > > You're wrong. Once OpenSSL's past sins are remediated, public > interfaces are precisely those that are documented. For now, public > interfaces are either macros or functions and global variables > those whose symbols are exported by the libssl and libcrypto shared > libraries. This is not a good place to be. Please ensure this is documented somewhere. I'm having trouble finding information on the new rules. There's 15 or 20 years of using capitol and lower case identifiers to denote public and private APIs with OpenSSL. For example, see https://marc.info/?l=openssl-users&m=102683340223621 . I'm happy to tell folks that no longer applies, but we need to know what the new rules are is and when the cut-over occured. Jeff From openssl-users at dukhovni.org Sun Feb 28 05:18:58 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sun, 28 Feb 2016 00:18:58 -0500 Subject: [openssl-dev] [openssl.org #4343] master: EC_KEY_priv2buf (): check parameter sanity In-Reply-To: References: <20160226170443.GW12869@mournblade.imrryr.org> <20160226171924.GX12869@mournblade.imrryr.org> Message-ID: > On Feb 27, 2016, at 7:42 PM, Jeffrey Walton wrote: > > Please ensure this is documented somewhere. I'm having trouble finding > information on the new rules. > > There's 15 or 20 years of using capitol and lower case identifiers to > denote public and private APIs with OpenSSL. For example, see > https://marc.info/?l=openssl-users&m=102683340223621 . > > I'm happy to tell folks that no longer applies, but we need to know > what the new rules are is and when the cut-over occured. There are no new *rules*, just new goals I'm promoting in this thread. If it is not documented it is not a fully implemented public interface. The documentation is part of what it takes to be a first-class public interface. New code must be documented, and patches to existing code should bring the documentation up to date. In good part because it is hard to know whether a patch is correct when updating undocumented code, and the exercise of documenting it makes one think harder about the requisite semantics. The upper-case lower-case thing is a legacy crutch, that is likely to continue to be adhered to for some time, but increasingly it is the documentation that must delineate between public and internal interfaces. -- Viktor. From doctor at doctor.nl2k.ab.ca Sun Feb 28 13:20:42 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Sun, 28 Feb 2016 06:20:42 -0700 Subject: [openssl-dev] openssl-1.0.2-stable-SNAP-20160228 Message-ID: <20160228132041.GA20319@doctor.nl2k.ab.ca> This cropped up this morning in openssl-1.0.2-stable-SNAP-20160228 Script started on Sun Feb 28 06:15:31 2016 doctor.nl2k.ab.ca//usr/source/openssl-1.0.2-stable-SNAP-20160228$ make test testing... make[1]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160228/test' make[2]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160228' making all in apps... make[3]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160228/apps' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160228/apps' make[2]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160228' ../util/shlib_wrap.sh ./destest Doing cbcm Doing ecb Doing ede ecb Doing cbc Doing desx cbc Doing ede cbc Doing pcbc Doing cfb8 cfb16 cfb32 cfb48 cfb64 cfb64() ede_cfb64() done Doing ofb Doing ofb64 Doing ede_ofb64 Doing cbc_cksum Doing quad_cksum input word alignment test 0 1 2 3 output word alignment test 0 1 2 3 fast crypt test ../util/shlib_wrap.sh ./ideatest ecb idea ok cbc idea ok cfb64 idea ok ../util/shlib_wrap.sh ./shatest test 1 ok test 2 ok test 3 ok ../util/shlib_wrap.sh ./sha1test test 1 ok test 2 ok test 3 ok ../util/shlib_wrap.sh ./sha256t Testing SHA-256 ... passed. Testing SHA-224 ... passed. ../util/shlib_wrap.sh ./sha512t Testing SHA-512 ... passed. Testing SHA-384 ... passed. ../util/shlib_wrap.sh ./md4test test 1 ok test 2 ok test 3 ok test 4 ok test 5 ok test 6 ok test 7 ok ../util/shlib_wrap.sh ./md5test test 1 ok test 2 ok test 3 ok test 4 ok test 5 ok test 6 ok test 7 ok ../util/shlib_wrap.sh ./hmactest test 0 ok test 1 ok test 2 ok test 3 ok test 4 ok test 5 ok test 6 ok ../util/shlib_wrap.sh ./md2test No MD2 support ../util/shlib_wrap.sh ./mdc2test pad1 - ok pad2 - ok ../util/shlib_wrap.sh ./wp_test Testing Whirlpool ......... passed. ../util/shlib_wrap.sh ./rmdtest test 1 ok test 2 ok test 3 ok test 4 ok test 5 ok test 6 ok test 7 ok test 8 ok ../util/shlib_wrap.sh ./rc2test ecb RC2 ok ../util/shlib_wrap.sh ./rc4test test 0 ok test 1 ok test 2 ok test 3 ok test 4 ok test 5 ok test end processing ....................done test multi-call ....................done bulk test ok ../util/shlib_wrap.sh ./rc5test ecb RC5 ok cbc RC5 ok ../util/shlib_wrap.sh ./bftest testing blowfish in raw ecb mode testing blowfish in ecb mode testing blowfish set_key testing blowfish in cbc mode testing blowfish in cfb64 mode testing blowfish in ofb64 ../util/shlib_wrap.sh ./casttest ecb cast5 ok This test will take some time....123456789ABCDEF ok ../util/shlib_wrap.sh ./randtest test 1 done test 2 done test 3 done test 4 done starting big number library test, could take a while... test BN_add test BN_sub test BN_lshift1 test BN_lshift (fixed) test BN_lshift test BN_rshift1 test BN_rshift test BN_sqr test BN_mul test BN_div test BN_div_word test BN_div_recp test BN_mod test BN_mod_mul test BN_mont test BN_mod_exp test BN_mod_exp_mont_consttime test BN_exp test BN_kronecker ................++++++ .................................................................................................... test BN_mod_sqrt ..... ..... ..... ..... ..... ..... ..... ..... ..++++++++++++ ..... .......++++++++++++ ..... .++++++++++++ ..... ..........++++++++++++ ..... ................++++++++++++ ..... .++++++++++++ ..... ....++++++++++++ ..... ....++++++++++++ ..... test BN_GF2m_add test BN_GF2m_mod test BN_GF2m_mod_mul test BN_GF2m_mod_sqr test BN_GF2m_mod_inv test BN_GF2m_mod_div test BN_GF2m_mod_exp test BN_GF2m_mod_sqrt test BN_GF2m_mod_solve_quad running bc verify BN_add.................................................................................................... verify BN_sub...................................................................................................................................................... verify BN_lshift1.................................................................................................... verify BN_lshift (fixed).................................................................................................... verify BN_lshift.................................................................................................... verify BN_rshift1.................................................................................................... verify BN_rshift.................................................................................................... verify BN_sqr...................................................................................................... verify BN_mul...................................................................................................................................................... verify BN_div............................................................................................................................................................................................................................................................................................................ verify BN_div_word........................................................................................................................................................................................................ verify BN_div_recp............................................................................................................................................................................................................................................................................................................ verify BN_mod.................................................................................................... verify BN_mod_mul............................................................................................................................................................................................................................................................................................................ verify BN_mont..... verify BN_mod_exp..... verify BN_mod_exp_mont_consttime..... verify BN_exp..... verify BN_kronecker verify BN_mod_sqrt verify BN_GF2m_add verify BN_GF2m_mod verify BN_GF2m_mod_mul verify BN_GF2m_mod_sqr verify BN_GF2m_mod_inv verify BN_GF2m_mod_div verify BN_GF2m_mod_exp verify BN_GF2m_mod_sqrt verify BN_GF2m_mod_solve_quad 2222 tests passed test a^b%c implementations ../util/shlib_wrap.sh ./exptest ........................................................................................................................................................................................................ done test elliptic curves ../util/shlib_wrap.sh ./ectest Curve defined by Weierstrass equation y^2 = x^3 + a*x + b (mod 0x17) a = 0x1 b = 0x1 A cyclic subgroup: point at infinity x = 0xD, y = 0x7 x = 0x5, y = 0x4 x = 0x11, y = 0x3 x = 0x11, y = 0x14 x = 0x5, y = 0x13 x = 0xD, y = 0x10 Generator as octet string, compressed form: 030D Generator as octet string, uncompressed form: 040D07 Generator as octet string, hybrid form: 070D07 A representation of the inverse of that generator in Jacobian projective coordinates: X = 0xC, Y = 0xF, Z = 0xA SEC2 curve secp160r1 -- Generator: x = 0x4A96B5688EF573284664698968C38BB913CBFC82 y = 0x23A628553168947D59DCC912042351377AC5FB32 verify degree ... ok verify group order .... ok long/negative scalar tests allowing precomputation ... without precomputation ... ok NIST curve P-192 -- Generator: x = 0x188DA80EB03090F67CBF20EB43A18800F4FF0AFD82FF1012 y = 0x7192B95FFC8DA78631011ED6B24CDD573F977A11E794811 verify degree ... ok verify group order .... ok long/negative scalar tests allowing precomputation ... without precomputation ... ok NIST curve P-224 -- Generator: x = 0xB70E0CBD6BB4BF7F321390B94A03C1D356C21122343280D6115C1D21 y = 0xBD376388B5F723FB4C22DFE6CD4375A05A07476444D5819985007E34 verify degree ... ok verify group order .... ok long/negative scalar tests allowing precomputation ... without precomputation ... ok NIST curve P-256 -- Generator: x = 0x6B17D1F2E12C4247F8BCE6E563A440F277037D812DEB33A0F4A13945D898C296 y = 0x4FE342E2FE1A7F9B8EE7EB4A7C0F9E162BCE33576B315ECECBB6406837BF51F5 verify degree ... ok verify group order .... ok long/negative scalar tests allowing precomputation ... without precomputation ... ok NIST curve P-384 -- Generator: x = 0xAA87CA22BE8B05378EB1C71EF320AD746E1D3B628BA79B9859F741E082542A385502F25DBF55296C3A545E3872760AB7 y = 0x3617DE4A96262C6F5D9E98BF9292DC29F8F41DBD289A147CE9DA3113B5F0B8C00A60B1CE1D7E819D7A431D7C90EA0E5F verify degree ... ok verify group order .... ok long/negative scalar tests allowing precomputation ... without precomputation ... ok NIST curve P-521 -- Generator: x = 0xC6858E06B70404E9CD9E3ECB662395B4429C648139053FB521F828AF606B4D3DBAA14B5E77EFE75928FE1DC127A2FFA8DE3348B3C1856A429BF97E7E31C2E5BD66 y = 0x11839296A789A3BC0045C8A5FB42C7D1BD998F54449579B446817AFBD17273E662C97EE72995EF42640C550B9013FAD0761353C7086A272C24088BE94769FD16650 verify degree ... ok verify group order .... ok long/negative scalar tests allowing precomputation ... without precomputation ... ok combined multiplication ..... ok Curve defined by Weierstrass equation y^2 + x*y = x^3 + a*x^2 + b (mod 0x13) a = 0x3 b = 0x1 (0x... means binary polynomial) A cyclic subgroup: point at infinity x = 0x6, y = 0x8 x = 0x1, y = 0xD x = 0x7, y = 0x2 x = 0x0, y = 0x1 x = 0x7, y = 0x5 x = 0x1, y = 0xC x = 0x6, y = 0xE Generator as octet string, uncompressed form: 040608 NIST curve K-163 -- Generator: x = 0x2FE13C0537BBC11ACAA07D793DE4E6D5E5C94EEE8 y = 0x289070FB05D38FF58321F2E800536D538CCDAA3D9 verify degree ... ok verify group order .... ok long/negative scalar tests allowing precomputation ... without precomputation ... ok NIST curve B-163 -- Generator: x = 0x3F0EBA16286A2D57EA0991168D4994637E8343E36 y = 0xD51FBC6C71A0094FA2CDD545B11C5C0C797324F1 verify degree ... ok verify group order .... ok long/negative scalar tests allowing precomputation ... without precomputation ... ok NIST curve K-233 -- Generator: x = 0x17232BA853A7E731AF129F22FF4149563A419C26BF50A4C9D6EEFAD6126 y = 0x1DB537DECE819B7F70F555A67C427A8CD9BF18AEB9B56E0C11056FAE6A3 verify degree ... ok verify group order .... ok long/negative scalar tests allowing precomputation ... without precomputation ... ok NIST curve B-233 -- Generator: x = 0xFAC9DFCBAC8313BB2139F1BB755FEF65BC391F8B36F8F8EB7371FD558B y = 0x1006A08A41903350678E58528BEBF8A0BEFF867A7CA36716F7E01F81052 verify degree ... ok verify group order .... ok long/negative scalar tests allowing precomputation ... without precomputation ... ok NIST curve K-283 -- Generator: x = 0x503213F78CA44883F1A3B8162F188E553CD265F23C1567A16876913B0C2AC2458492836 y = 0x1CCDA380F1C9E318D90F95D07E5426FE87E45C0E8184698E45962364E34116177DD2259 verify degree ... ok verify group order .... ok long/negative scalar tests allowing precomputation ... without precomputation ... ok NIST curve B-283 -- Generator: x = 0x5F939258DB7DD90E1934F8C70B0DFEC2EED25B8557EAC9C80E2E198F8CDBECD86B12053 y = 0x3676854FE24141CB98FE6D4B20D02B4516FF702350EDDB0826779C813F0DF45BE8112F4 verify degree ... ok verify group order .... ok long/negative scalar tests allowing precomputation ... without precomputation ... ok NIST curve K-409 -- Generator: x = 0x60F05F658F49C1AD3AB1890F7184210EFD0987E307C84C27ACCFB8F9F67CC2C460189EB5AAAA62EE222EB1B35540CFE9023746 y = 0x1E369050B7C4E42ACBA1DACBF04299C3460782F918EA427E6325165E9EA10E3DA5F6C42E9C55215AA9CA27A5863EC48D8E0286B verify degree ... ok verify group order .... ok long/negative scalar tests allowing precomputation ... without precomputation ... ok NIST curve B-409 -- Generator: x = 0x15D4860D088DDB3496B0C6064756260441CDE4AF1771D4DB01FFE5B34E59703DC255A868A1180515603AEAB60794E54BB7996A7 y = 0x61B1CFAB6BE5F32BBFA78324ED106A7636B9C5A7BD198D0158AA4F5488D08F38514F1FDF4B4F40D2181B3681C364BA0273C706 verify degree ... ok verify group order .... ok long/negative scalar tests allowing precomputation ... without precomputation ... ok NIST curve K-571 -- Generator: x = 0x26EB7A859923FBC82189631F8103FE4AC9CA2970012D5D46024804801841CA44370958493B205E647DA304DB4CEB08CBBD1BA39494776FB988B47174DCA88C7E2945283A01C8972 y = 0x349DC807F4FBF374F4AEADE3BCA95314DD58CEC9F307A54FFC61EFC006D8A2C9D4979C0AC44AEA74FBEBBB9F772AEDCB620B01A7BA7AF1B320430C8591984F601CD4C143EF1C7A3 verify degree ... ok verify group order .... ok long/negative scalar tests allowing precomputation ... without precomputation ... ok NIST curve B-571 -- Generator: x = 0x303001D34B856296C16C0D40D3CD7750A93D1D2955FA80AA5F40FC8DB7B2ABDBDE53950F4C0D293CDD711A35B67FB1499AE60038614F1394ABFA3B4C850D927E1E7769C8EEC2D19 y = 0x37BF27342DA639B6DCCFFFEB73D69D78C6C27A6009CBBCA1980F8533921E8A684423E43BAB08A576291AF8F461BB2A8B3531D2F0485C19B16E2F1516E23DD3C1A4827AF1B8AC15B verify degree ... ok verify group order .... ok long/negative scalar tests allowing precomputation ... without precomputation ... ok combined multiplication ..... ok testing internal curves: ................................................................................. ok test ecdsa ../util/shlib_wrap.sh ./ecdsatest some tests from X9.62: testing prime192v1: .... ok testing prime239v1: .... ok testing c2tnb191v1: .... ok testing c2tnb239v1: .... ok testing ECDSA_sign() and ECDSA_verify() with some internal curves: secp160k1: ........ ok secp160r1: ........ ok secp160r2: ........ ok secp192k1: ........ ok secp224k1: ........ ok secp224r1: ........ ok secp256k1: ........ ok secp384r1: ........ ok secp521r1: ........ ok prime192v1: ........ ok prime192v2: ........ ok prime192v3: ........ ok prime239v1: ........ ok prime239v2: ........ ok prime239v3: ........ ok prime256v1: ........ ok sect163k1: ........ ok sect163r1: ........ ok sect163r2: ........ ok sect193r1: ........ ok sect193r2: ........ ok sect233k1: ........ ok sect233r1: ........ ok sect239k1: ........ ok sect283k1: ........ ok sect283r1: ........ ok sect409k1: ........ ok sect409r1: ........ ok sect571k1: ........ ok sect571r1: ........ ok c2pnb163v1: ........ ok c2pnb163v2: ........ ok c2pnb163v3: ........ ok c2pnb176v1: ........ ok c2tnb191v1: ........ ok c2tnb191v2: ........ ok c2tnb191v3: ........ ok c2pnb208w1: ........ ok c2tnb239v1: ........ ok c2tnb239v2: ........ ok c2tnb239v3: ........ ok c2pnb272w1: ........ ok c2pnb304w1: ........ ok c2tnb359v1: ........ ok c2pnb368w1: ........ ok c2tnb431r1: ........ ok wap-wsg-idm-ecid-wtls3: ........ ok wap-wsg-idm-ecid-wtls5: ........ ok wap-wsg-idm-ecid-wtls7: ........ ok wap-wsg-idm-ecid-wtls9: ........ ok wap-wsg-idm-ecid-wtls10: ........ ok wap-wsg-idm-ecid-wtls11: ........ ok wap-wsg-idm-ecid-wtls12: ........ ok brainpoolP160r1: ........ ok brainpoolP160t1: ........ ok brainpoolP192r1: ........ ok brainpoolP192t1: ........ ok brainpoolP224r1: ........ ok brainpoolP224t1: ........ ok brainpoolP256r1: ........ ok brainpoolP256t1: ........ ok brainpoolP320r1: ........ ok brainpoolP320t1: ........ ok brainpoolP384r1: ........ ok brainpoolP384t1: ........ ok brainpoolP512r1: ........ ok brainpoolP512t1: ........ ok ECDSA test passed test ecdh ../util/shlib_wrap.sh ./ecdhtest Testing key generation with NIST Prime-Curve P-192 .... ok Testing key generation with NIST Prime-Curve P-224 .... ok Testing key generation with NIST Prime-Curve P-256 .... ok Testing key generation with NIST Prime-Curve P-384 .... ok Testing key generation with NIST Prime-Curve P-521 .... ok Testing key generation with NIST Binary-Curve K-163 .... ok Testing key generation with NIST Binary-Curve B-163 .... ok Testing key generation with NIST Binary-Curve K-233 .... ok Testing key generation with NIST Binary-Curve B-233 .... ok Testing key generation with NIST Binary-Curve K-283 .... ok Testing key generation with NIST Binary-Curve B-283 .... ok Testing key generation with NIST Binary-Curve K-409 .... ok Testing key generation with NIST Binary-Curve B-409 .... ok Testing key generation with NIST Binary-Curve K-571 .... ok Testing key generation with NIST Binary-Curve B-571 .... ok Testing ECDH shared secret with Brainpool Prime-Curve brainpoolP256r1 ok Testing ECDH shared secret with Brainpool Prime-Curve brainpoolP384r1 ok Testing ECDH shared secret with Brainpool Prime-Curve brainpoolP512r1 ok cat base64 aes-128-cbc aes-128-cbc base64 aes-128-ecb aes-128-ecb base64 aes-192-cbc aes-192-cbc base64 aes-192-ecb aes-192-ecb base64 aes-256-cbc aes-256-cbc base64 aes-256-ecb aes-256-ecb base64 base64 base64 base64 bf bf base64 bf-cbc bf-cbc base64 bf-cfb bf-cfb base64 bf-ecb bf-ecb base64 bf-ofb bf-ofb base64 camellia-128-cbc camellia-128-cbc base64 camellia-128-ecb camellia-128-ecb base64 camellia-192-cbc camellia-192-cbc base64 camellia-192-ecb camellia-192-ecb base64 camellia-256-cbc camellia-256-cbc base64 camellia-256-ecb camellia-256-ecb base64 cast cast base64 cast-cbc cast-cbc base64 cast5-cbc cast5-cbc base64 cast5-cfb cast5-cfb base64 cast5-ecb cast5-ecb base64 cast5-ofb cast5-ofb base64 des des base64 des-cbc des-cbc base64 des-cfb des-cfb base64 des-ecb des-ecb base64 des-ede des-ede base64 des-ede-cbc des-ede-cbc base64 des-ede-cfb des-ede-cfb base64 des-ede-ofb des-ede-ofb base64 des-ede3 des-ede3 base64 des-ede3-cbc des-ede3-cbc base64 des-ede3-cfb des-ede3-cfb base64 des-ede3-ofb des-ede3-ofb base64 des-ofb des-ofb base64 des3 des3 base64 desx desx base64 idea idea base64 idea-cbc idea-cbc base64 idea-cfb idea-cfb base64 idea-ecb idea-ecb base64 idea-ofb idea-ofb base64 rc2 rc2 base64 rc2-40-cbc rc2-40-cbc base64 rc2-64-cbc rc2-64-cbc base64 rc2-cbc rc2-cbc base64 rc2-cfb rc2-cfb base64 rc2-ecb rc2-ecb base64 rc2-ofb rc2-ofb base64 rc4 rc4 base64 rc4-40 rc4-40 base64 rc5 rc5 base64 rc5-cbc rc5-cbc base64 rc5-cfb rc5-cfb base64 rc5-ecb rc5-ecb base64 rc5-ofb rc5-ofb base64 seed seed base64 seed-cbc seed-cbc base64 seed-cfb seed-cfb base64 seed-ecb seed-ecb base64 seed-ofb seed-ofb base64 zlib zlib base64 echo test normal x509v1 certificate test normal x509v1 certificate sh ./tx509 2>/dev/null testing X509 conversions p -> d p -> n p -> p d -> d n -> d Makefile:218: recipe for target 'test_x509' failed make[1]: *** [test_x509] Error 1 make[1]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160228/test' Makefile:460: recipe for target 'tests' failed make: *** [tests] Error 2 doctor.nl2k.ab.ca//usr/source/openssl-1.0.2-stable-SNAP-20160228$ exit    HARNESS_VERBOS E=yes make test TESTS='test_x509' testing... make[1]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160228/test' make[2]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160228' making all in apps... make[3]: Entering directory '/usr/source/openssl-1.0.2-stable-SNAP-20160228/apps' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160228/apps' make[2]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160228' echo test normal x509v1 certificate test normal x509v1 certificate sh ./tx509 2>/dev/null testing X509 conversions p -> d p -> n p -> p d -> d n -> d Makefile:218: recipe for target 'test_x509' failed make[1]: *** [test_x509] Error 1 make[1]: Leaving directory '/usr/source/openssl-1.0.2-stable-SNAP-20160228/test' Makefile:460: recipe for target 'tests' failed make: *** [tests] Error 2 You have new mail in /var/mail/doctor doctor.nl2k.ab.ca//usr/source/openssl-1.0.2-stable-SNAP-20160228$ exit exit Script done on Sun Feb 28 06:18:39 2016 This did not exist in openssl-1.0.2-stable-SNAP-20160227 . Please fix. -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Broadcasting the truth for 25 years From kurt at roeckx.be Sun Feb 28 13:33:39 2016 From: kurt at roeckx.be (Kurt Roeckx) Date: Sun, 28 Feb 2016 14:33:39 +0100 Subject: [openssl-dev] openssl-1.0.2-stable-SNAP-20160228 In-Reply-To: <20160228132041.GA20319@doctor.nl2k.ab.ca> References: <20160228132041.GA20319@doctor.nl2k.ab.ca> Message-ID: <20160228133339.GA29647@roeckx.be> On Sun, Feb 28, 2016 at 06:20:42AM -0700, The Doctor wrote: > This cropped up this morning in That was fixed an hour ago. Kurt From doctor at doctor.nl2k.ab.ca Sun Feb 28 13:57:13 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Sun, 28 Feb 2016 06:57:13 -0700 Subject: [openssl-dev] openssl-SNAP-20160228 findings Message-ID: <20160228135712.GA1104@doctor.nl2k.ab.ca> Script started on Sun Feb 28 06:06:32 2016 ns2.nl2k.ab.ca//usr/source/openssl-SNAP-20160228$ HARNE ESS_VERBOSE=yes make test TESTS='test_evp test_rehash test_packet' /usr/bin/perl5 ./util/files.pl Makefile > ./MINFO /usr/source/openssl-SNAP-20160228/crypto/x509v3/v3_addr.c:1046: undefined reference to `strspn' /usr/source/openssl-SNAP-20160228/crypto/x509v3/v3_addr.c:1047: undefined reference to `strspn' ./libcrypto.a(v3_tlsf.o): In function `v2i_TLS_FEATURE': /usr/source/openssl-SNAP-20160228/crypto/x509v3/v3_tlsf.c:163: undefined reference to `strtol' ./libcrypto.a(conf_lib.o): In function `OPENSSL_INIT_new': /usr/source/openssl-SNAP-20160228/crypto/conf/conf_lib.c:382: undefined reference to `malloc' ./libcrypto.a(conf_lib.o): In function `OPENSSL_INIT_set_config_filename': /usr/source/openssl-SNAP-20160228/crypto/conf/conf_lib.c:393: undefined reference to `free' /usr/source/openssl-SNAP-20160228/crypto/conf/conf_lib.c:394: undefined reference to `strdup' ./libcrypto.a(conf_lib.o): In function `OPENSSL_INIT_free': /usr/source/openssl-SNAP-20160228/crypto/conf/conf_lib.c:399: undefined reference to `free' /usr/source/openssl-SNAP-20160228/crypto/conf/conf_lib.c:400: undefined reference to `free' ./libcrypto.a(conf_api.o): In function `_CONF_get_string': /usr/source/openssl-SNAP-20160228/crypto/conf/conf_api.c:133: undefined reference to `getenv' /usr/source/openssl-SNAP-20160228/crypto/conf/conf_api.c:146: undefined reference to `getenv' ./libcrypto.a(conf_api.o): In function `conf_value_cmp': /usr/source/openssl-SNAP-20160228/crypto/conf/conf_api.c:159: undefined reference to `strcmp' /usr/source/openssl-SNAP-20160228/crypto/conf/conf_api.c:165: undefined reference to `strcmp' ./libcrypto.a(conf_api.o): In function `_CONF_new_section': /usr/source/openssl-SNAP-20160228/crypto/conf/conf_api.c:246: undefined reference to `strlen' /usr/source/openssl-SNAP-20160228/crypto/conf/conf_api.c:250: undefined reference to `memcpy' ./libcrypto.a(conf_def.o): In function `def_load_bio': /usr/source/openssl-SNAP-20160228/crypto/conf/conf_def.c:253: undefined reference to `strlen' /usr/source/openssl-SNAP-20160228/crypto/conf/conf_def.c:362: undefined reference to `strlen' /usr/source/openssl-SNAP-20160228/crypto/conf/conf_def.c:368: undefined reference to `strlen' /usr/source/openssl-SNAP-20160228/crypto/conf/conf_def.c:372: undefined reference to `strcmp' ./libcrypto.a(conf_def.o): In function `str_copy': /usr/source/openssl-SNAP-20160228/crypto/conf/conf_def.c:458: undefined reference to `strlen' /usr/source/openssl-SNAP-20160228/crypto/conf/conf_def.c:562: undefined reference to `strlen' ./libcrypto.a(conf_mod.o): In function `module_find': /usr/source/openssl-SNAP-20160228/crypto/conf/conf_mod.c:309: undefined reference to `strrchr' /usr/source/openssl-SNAP-20160228/crypto/conf/conf_mod.c:318: undefined reference to `strncmp' /usr/source/openssl-SNAP-20160228/crypto/conf/conf_mod.c:314: undefined reference to `strlen' ./libcrypto.a(conf_mod.o): In function `CONF_get1_default_config_file': /usr/source/openssl-SNAP-20160228/crypto/conf/conf_mod.c:523: undefined reference to `getenv' /usr/source/openssl-SNAP-20160228/crypto/conf/conf_mod.c:527: undefined reference to `strlen' ./libcrypto.a(conf_mod.o): In function `CONF_parse_list': /usr/include/ctype.h:155: undefined reference to `_CurrentRuneLocale' ./libcrypto.a(conf_mod.o): In function `CONF_parse_list': /usr/source/openssl-SNAP-20160228/crypto/conf/conf_mod.c:571: undefined reference to `strchr' ./libcrypto.a(conf_mod.o): In function `CONF_parse_list': /usr/include/ctype.h:155: undefined reference to `_CurrentRuneLocale' ./libcrypto.a(conf_mod.o): In function `CONF_parse_list': /usr/source/openssl-SNAP-20160228/crypto/conf/conf_mod.c:578: undefined reference to `strlen' ./libcrypto.a(conf_sap.o): In function `OPENSSL_config': /usr/source/openssl-SNAP-20160228/crypto/conf/conf_sap.c:85: undefined reference to `strdup' ./libcrypto.a(txt_db.o): In function `TXT_DB_read': /usr/source/openssl-SNAP-20160228/crypto/txt_db/txt_db.c:117: undefined reference to `strlen' ./libcrypto.a(txt_db.o): In function `TXT_DB_write': /usr/source/openssl-SNAP-20160228/crypto/txt_db/txt_db.c:247: undefined reference to `strlen' ./libcrypto.a(p12_key.o): In function `PKCS12_key_gen_uni': /usr/source/openssl-SNAP-20160228/crypto/pkcs12/p12_key.c:167: undefined reference to `memcpy' /usr/source/openssl-SNAP-20160228/crypto/pkcs12/p12_key.c:201: undefined reference to `memset' /usr/source/openssl-SNAP-20160228/crypto/pkcs12/p12_key.c:197: undefined reference to `memcpy' ./libcrypto.a(p12_mutl.o): In function `PKCS12_gen_mac': /usr/source/openssl-SNAP-20160228/crypto/pkcs12/p12_mutl.c:163: undefined reference to `getenv' ./libcrypto.a(p12_mutl.o): In function `PKCS12_setup_mac': /usr/source/openssl-SNAP-20160228/crypto/pkcs12/p12_mutl.c:250: undefined reference to `memcpy' ./libcrypto.a(p12_utl.o): In function `OPENSSL_asc2uni': /usr/source/openssl-SNAP-20160228/crypto/pkcs12/p12_utl.c:72: undefined reference to `strlen' ./libcrypto.a(ocsp_ext.o): In function `ocsp_add1_nonce': /usr/source/openssl-SNAP-20160228/crypto/ocsp/ocsp_ext.c:320: undefined reference to `memcpy' ./libcrypto.a(ocsp_ht.o): In function `parse_http_line1': /usr/include/ctype.h:155: undefined reference to `_CurrentRuneLocale' /usr/include/ctype.h:155: undefined reference to `_CurrentRuneLocale' /usr/include/ctype.h:155: undefined reference to `_CurrentRuneLocale' ./libcrypto.a(ocsp_ht.o): In function `parse_http_line1': /usr/source/openssl-SNAP-20160228/crypto/ocsp/ocsp_ht.c:290: undefined reference to `strtoul' ./libcrypto.a(ocsp_ht.o): In function `parse_http_line1': /usr/include/ctype.h:155: undefined reference to `_CurrentRuneLocale' ./libcrypto.a(ocsp_ht.o): In function `parse_http_line1': /usr/source/openssl-SNAP-20160228/crypto/ocsp/ocsp_ht.c:305: undefined reference to `strlen' ./libcrypto.a(ocsp_ht.o): In function `parse_http_line1': /usr/include/ctype.h:155: undefined reference to `_CurrentRuneLocale' ./libcrypto.a(ocsp_ht.o): In function `OCSP_REQ_CTX_nbio': /usr/source/openssl-SNAP-20160228/crypto/ocsp/ocsp_ht.c:405: undefined reference to `memchr' ./libcrypto.a(ocsp_lib.o): In function `OCSP_parse_url': /usr/source/openssl-SNAP-20160228/crypto/ocsp/ocsp_lib.c:190: undefined reference to `strchr' /usr/source/openssl-SNAP-20160228/crypto/ocsp/ocsp_lib.c:216: undefined reference to `strchr' /usr/source/openssl-SNAP-20160228/crypto/ocsp/ocsp_lib.c:241: undefined reference to `strchr' /usr/source/openssl-SNAP-20160228/crypto/ocsp/ocsp_lib.c:233: undefined reference to `strchr' ./libcrypto.a(ocsp_cl.o): In function `OCSP_check_validity': /usr/source/openssl-SNAP-20160228/crypto/ocsp/ocsp_cl.c:346: undefined reference to `time' ./libcrypto.a(v3_ocsp.o): In function `i2d_ocsp_nonce': /usr/source/openssl-SNAP-20160228/crypto/ocsp/v3_ocsp.c:226: undefined reference to `memcpy' ./libcrypto.a(ui_lib.o): In function `general_allocate_boolean': /usr/source/openssl-SNAP-20160228/crypto/ui/ui_lib.c:194: undefined reference to `strchr' ./libcrypto.a(ui_lib.o): In function `UI_construct_prompt': /usr/source/openssl-SNAP-20160228/crypto/ui/ui_lib.c:399: undefined reference to `strlen' /usr/source/openssl-SNAP-20160228/crypto/ui/ui_lib.c:401: undefined reference to `strlen' ./libcrypto.a(ui_lib.o): In function `UI_set_result': /usr/source/openssl-SNAP-20160228/crypto/ui/ui_lib.c:785: undefined reference to `strlen' /usr/source/openssl-SNAP-20160228/crypto/ui/ui_lib.c:838: undefined reference to `strchr' /usr/source/openssl-SNAP-20160228/crypto/ui/ui_lib.c:842: undefined reference to `strchr' ./libcrypto.a(ui_openssl.o): In function `write_string': /usr/source/openssl-SNAP-20160228/crypto/ui/ui_openssl.c:337: undefined reference to `fputs' /usr/source/openssl-SNAP-20160228/crypto/ui/ui_openssl.c:338: undefined reference to `fflush' ./libcrypto.a(ui_openssl.o): In function `read_string': /usr/source/openssl-SNAP-20160228/crypto/ui/ui_openssl.c:359: undefined reference to `fputs' /usr/source/openssl-SNAP-20160228/crypto/ui/ui_openssl.c:360: undefined reference to `fflush' /usr/source/openssl-SNAP-20160228/crypto/ui/ui_openssl.c:352: undefined reference to `fputs' /usr/source/openssl-SNAP-20160228/crypto/ui/ui_openssl.c:353: undefined reference to `fputs' /usr/source/openssl-SNAP-20160228/crypto/ui/ui_openssl.c:354: undefined reference to `fflush' /usr/source/openssl-SNAP-20160228/crypto/ui/ui_openssl.c:365: undefined reference to `fprintf' /usr/source/openssl-SNAP-20160228/crypto/ui/ui_openssl.c:366: undefined reference to `fflush' /usr/source/openssl-SNAP-20160228/crypto/ui/ui_openssl.c:371: undefined reference to `strcmp' /usr/source/openssl-SNAP-20160228/crypto/ui/ui_openssl.c:372: undefined reference to `fwrite' /usr/source/openssl-SNAP-20160228/crypto/ui/ui_openssl.c:373: undefined reference to `fflush' ./libcrypto.a(ui_openssl.o): In function `read_till_nl': /usr/source/openssl-SNAP-20160228/crypto/ui/ui_openssl.c:391: undefined reference to `fgets' /usr/source/openssl-SNAP-20160228/crypto/ui/ui_openssl.c:393: undefined reference to `strchr' ./libcrypto.a(ui_openssl.o): In function `read_string_inner': /usr/source/openssl-SNAP-20160228/crypto/ui/ui_openssl.c:428: undefined reference to `fgets' /usr/source/openssl-SNAP-20160228/crypto/ui/ui_openssl.c:432: undefined reference to `feof' /usr/source/openssl-SNAP-20160228/crypto/ui/ui_openssl.c:448: undefined reference to `fputc' /usr/source/openssl-SNAP-20160228/crypto/ui/ui_openssl.c:434: undefined reference to `ferror' /usr/source/openssl-SNAP-20160228/crypto/ui/ui_openssl.c:436: undefined reference to `strchr' ./libcrypto.a(ui_openssl.o): In function `open_console': /usr/source/openssl-SNAP-20160228/crypto/ui/ui_openssl.c:477: undefined reference to `fopen' /usr/source/openssl-SNAP-20160228/crypto/ui/ui_openssl.c:478: undefined reference to `__sstdin' /usr/source/openssl-SNAP-20160228/crypto/ui/ui_openssl.c:479: undefined reference to `fopen' /usr/source/openssl-SNAP-20160228/crypto/ui/ui_openssl.c:480: undefined reference to `__sstderr' /usr/source/openssl-SNAP-20160228/crypto/ui/ui_openssl.c:484: undefined reference to `fileno' /usr/source/openssl-SNAP-20160228/crypto/ui/ui_openssl.c:484: undefined reference to `tcgetattr' /usr/source/openssl-SNAP-20160228/crypto/ui/ui_openssl.c:486: undefined reference to `errno' ./libcrypto.a(ui_openssl.o): In function `noecho_console': /usr/source/openssl-SNAP-20160228/crypto/ui/ui_openssl.c:537: undefined reference to `fileno' /usr/source/openssl-SNAP-20160228/crypto/ui/ui_openssl.c:537: undefined reference to `tcsetattr' ./libcrypto.a(ui_openssl.o): In function `echo_console': /usr/source/openssl-SNAP-20160228/crypto/ui/ui_openssl.c:561: undefined reference to `fileno' /usr/source/openssl-SNAP-20160228/crypto/ui/ui_openssl.c:561: undefined reference to `tcsetattr' ./libcrypto.a(ui_openssl.o): In function `close_console': /usr/source/openssl-SNAP-20160228/crypto/ui/ui_openssl.c:565: undefined reference to `__sstdin' /usr/source/openssl-SNAP-20160228/crypto/ui/ui_openssl.c:566: undefined reference to `fclose' /usr/source/openssl-SNAP-20160228/crypto/ui/ui_openssl.c:567: undefined reference to `__sstderr' /usr/source/openssl-SNAP-20160228/crypto/ui/ui_openssl.c:568: undefined reference to `fclose' ./libcrypto.a(ui_openssl.o): In function `pushsig': /usr/source/openssl-SNAP-20160228/crypto/ui/ui_openssl.c:613: undefined reference to `sigaction' /usr/source/openssl-SNAP-20160228/crypto/ui/ui_openssl.c:621: undefined reference to `signal' ./libcrypto.a(ui_openssl.o): In function `popsig': /usr/source/openssl-SNAP-20160228/crypto/ui/ui_openssl.c:646: undefined reference to `sigaction' ./libcrypto.a(cms_enc.o): In function `cms_EncryptedContent_init': /usr/source/openssl-SNAP-20160228/crypto/cms/cms_enc.c:214: undefined reference to `memcpy' ./libcrypto.a(cms_pwri.o): In function `CMS_RecipientInfo_set0_password': /usr/source/openssl-SNAP-20160228/crypto/cms/cms_pwri.c:77: undefined reference to `strlen' ./libcrypto.a(cms_pwri.o): In function `kek_unwrap_key': /usr/source/openssl-SNAP-20160228/crypto/cms/cms_pwri.c:266: undefined reference to `memcpy' ./libcrypto.a(cms_pwri.o): In function `kek_wrap_key': /usr/source/openssl-SNAP-20160228/crypto/cms/cms_pwri.c:301: undefined reference to `memcpy' ./libcrypto.a(ts_rsp_sign.o): In function `def_time_cb': /usr/source/openssl-SNAP-20160228/crypto/ts/ts_rsp_sign.c:117: undefined reference to `gettimeofday' ./libcrypto.a(ts_rsp_sign.o): In function `TS_RESP_CTX_set_status_info': /usr/source/openssl-SNAP-20160228/crypto/ts/ts_rsp_sign.c:353: undefined reference to `strlen' ./libcrypto.a(ts_rsp_sign.o): In function `TS_RESP_set_genTime_with_precision': /usr/source/openssl-SNAP-20160228/crypto/ts/ts_rsp_sign.c:900: undefined reference to `gmtime' /usr/source/openssl-SNAP-20160228/crypto/ts/ts_rsp_sign.c:916: undefined reference to `strlen' ./libcrypto.a(ts_rsp_verify.o): In function `ts_check_status_info': /usr/source/openssl-SNAP-20160228/crypto/ts/ts_rsp_verify.c:439: undefined reference to `memset' /usr/source/openssl-SNAP-20160228/crypto/ts/ts_rsp_verify.c:465: undefined reference to `strcat' /usr/source/openssl-SNAP-20160228/crypto/ts/ts_rsp_verify.c:462: undefined reference to `strcat' ./libcrypto.a(ts_rsp_verify.o): In function `ts_get_status_text': /usr/source/openssl-SNAP-20160228/crypto/ts/ts_rsp_verify.c:505: undefined reference to `strncpy' ./libcrypto.a(ts_verify_ctx.o): In function `TS_REQ_to_TS_VERIFY_CTX': /usr/source/openssl-SNAP-20160228/crypto/ts/ts_verify_ctx.c:180: undefined reference to `memcpy' ./libcrypto.a(ts_lib.o): In function `TS_ASN1_INTEGER_print_bio': /usr/source/openssl-SNAP-20160228/crypto/ts/ts_lib.c:86: undefined reference to `strlen' ./libcrypto.a(ts_conf.o): In function `TS_CONF_set_accuracy': /usr/source/openssl-SNAP-20160228/crypto/ts/ts_conf.c:441: undefined reference to `atoi' /usr/source/openssl-SNAP-20160228/crypto/ts/ts_conf.c:444: undefined reference to `atoi' /usr/source/openssl-SNAP-20160228/crypto/ts/ts_conf.c:447: undefined reference to `atoi' ./libcrypto.a(srp_lib.o): In function `srp_Calc_k': /usr/source/openssl-SNAP-20160228/crypto/srp/srp_lib.c:90: undefined reference to `memset' ./libcrypto.a(srp_lib.o): In function `SRP_Calc_u': /usr/source/openssl-SNAP-20160228/crypto/srp/srp_lib.c:127: undefined reference to `memset' ./libcrypto.a(srp_lib.o): In function `SRP_Calc_x': /usr/source/openssl-SNAP-20160228/crypto/srp/srp_lib.c:222: undefined reference to `strlen' /usr/source/openssl-SNAP-20160228/crypto/srp/srp_lib.c:224: undefined reference to `strlen' ./libcrypto.a(srp_lib.o): In function `SRP_get_default_gN': /usr/source/openssl-SNAP-20160228/crypto/srp/srp_lib.c:359: undefined reference to `strcmp' ./libcrypto.a(srp_vfy.o): In function `t_fromb64': /usr/source/openssl-SNAP-20160228/crypto/srp/srp_vfy.c:90: undefined reference to `strlen' /usr/source/openssl-SNAP-20160228/crypto/srp/srp_vfy.c:93: undefined reference to `strchr' ./libcrypto.a(srp_vfy.o): In function `SRP_user_pwd_set_sv': /usr/source/openssl-SNAP-20160228/crypto/srp/srp_vfy.c:233: undefined reference to `strlen' /usr/source/openssl-SNAP-20160228/crypto/srp/srp_vfy.c:240: undefined reference to `strlen' ./libcrypto.a(srp_vfy.o): In function `SRP_get_gN_by_id': /usr/source/openssl-SNAP-20160228/crypto/srp/srp_vfy.c:339: undefined reference to `strcmp' ./libcrypto.a(srp_vfy.o): In function `SRP_gN_place_bn': /usr/source/openssl-SNAP-20160228/crypto/srp/srp_vfy.c:355: undefined reference to `strcmp' ./libcrypto.a(srp_vfy.o): In function `find_user': /usr/source/openssl-SNAP-20160228/crypto/srp/srp_vfy.c:498: undefined reference to `strcmp' ./libcrypto.a(srp_vfy.o): In function `SRP_VBASE_get1_by_user': /usr/source/openssl-SNAP-20160228/crypto/srp/srp_vfy.c:551: undefined reference to `strlen' /usr/source/openssl-SNAP-20160228/crypto/srp/srp_vfy.c:552: undefined reference to `strlen' ./libcrypto.a(cmac.o): In function `CMAC_Update': /usr/source/openssl-SNAP-20160228/crypto/cmac/cmac.c:202: undefined reference to `memcpy' /usr/source/openssl-SNAP-20160228/crypto/cmac/cmac.c:221: undefined reference to `memcpy' ./libcrypto.a(cmac.o): In function `CMAC_Final': /usr/source/openssl-SNAP-20160228/crypto/cmac/cmac.c:244: undefined reference to `memset' ./libcrypto.a(cm_pmeth.o): In function `pkey_cmac_ctrl_str': /usr/source/openssl-SNAP-20160228/crypto/cmac/cm_pmeth.c:162: undefined reference to `strlen' ./libcrypto.a(ct_oct.o): In function `i2o_SCT_signature': /usr/source/openssl-SNAP-20160228/crypto/ct/ct_oct.c:260: undefined reference to `memcpy' ./libcrypto.a(ct_oct.o): In function `i2o_SCT': /usr/source/openssl-SNAP-20160228/crypto/ct/ct_oct.c:311: undefined reference to `memcpy' /usr/source/openssl-SNAP-20160228/crypto/ct/ct_oct.c:317: undefined reference to `memcpy' ./libcrypto.a(async.o): In function `ASYNC_start_job': /usr/source/openssl-SNAP-20160228/crypto/async/async.c:286: undefined reference to `memcpy' ./libcrypto.a(tls1_prf.o): In function `pkey_tls1_prf_ctrl': /usr/source/openssl-SNAP-20160228/crypto/kdf/tls1_prf.c:131: undefined reference to `memcpy' ./libcrypto.a(tls1_prf.o):/usr/source/openssl-SNAP-20160228/crypto/kdf/tls1_prf.c:239: more undefined references to `memcpy' follow making all in engines... rm -f openssl shlib_target=; if [ -n "libcrypto.so.1.1 libssl.so.1.1" ]; then shlib_target="bsd-gcc-shared"; fi; LIBRARIES="-L.. -lssl -L.. -lcrypto" ; make -f ../Makefile.shared -e APPNAME=openssl OBJECTS="openssl.o asn1pars.o ca.o ciphers.o cms.o crl.o crl2p7.o dgst.o dhparam.o dsa.o dsaparam.o ec.o ecparam.o enc.o engine.o errstr.o gendsa.o genpkey.o genrsa.o nseq.o ocsp.o passwd.o pkcs12.o pkcs7.o pkcs8.o pkey.o pkeyparam.o pkeyutl.o prime.o rand.o req.o rsa.o rsautl.o s_client.o s_server.o s_time.o sess_id.o smime.o speed.o spkac.o srp.o ts.o verify.o version.o x509.o rehash.o apps.o opt.o s_cb.o s_socket.o app_rand.o " LDFLAG="-ldl -lgmp -lm -lc -lz" LIBDEPS=" $LIBRARIES " link_app.${shlib_target} LD_LIBRARY_PATH=..:/usr/contrib/qt/lib:/usr/contrib/qt/lib:/usr/libdata/perl5/i386-bsdos/CORE gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_THREADS -DZLIB -DZLIB_SHARED -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DOPENSSLDIR="/usr/contrib" -DENGINESDIR="/usr/contrib/lib/engines" -pthread -D_THREAD_SAFE -D_REENTRANT -DPERL5 -DL_ENDIAN -DTERMIOS -fomit-frame-pointer -O2 -march=i486 -Wall -g -ldl -lgmp -lm -lc -lz -Wl,-rpath,/usr/contrib/lib -o openssl openssl.o asn1pars.o ca.o ciphers.o cms.o crl.o crl2p7.o dgst.o dhparam.o dsa.o dsaparam.o ec.o ecparam.o enc.o engine.o errstr.o gendsa.o genpkey.o genrsa.o nseq.o ocsp.o passwd.o pkcs12.o pkcs7.o pkcs8.o pkey.o pkeyparam.o pkeyutl.o prime.o rand.o req.o rsa.o rsautl.o s_client.o s_server.o s_time.o sess_id.o smime.o speed.o spkac.o srp.o ts.o verify.o version.o x509.o rehash.o apps.o opt.o s_cb.o s_socket.o app_rand.o -L.. -lssl -L.. -lcrypto TOP=.. PERL=/usr/bin/perl5 /usr/bin/perl5 run_tests.pl test_evp test_rehash test_packet ../test/recipes/30-test_evp.t ..... 1..1 Test line 2488: unexpected error KEY_MISMATCH Expected: 77D6576238657B203B19CA42C18A0497F16B4844E3074AE8DFDFFA3FEDE21442FCD0069DED0948F8326A753A0FC81F17E8D3E0FB2E0D3628CF35E20C38D18906 Got: 1E206D019AE5CD5575A1CD9BD56AF7AF094ACC8A903E163BF22A417CC7073B7B864FE17944690473DBED7E2FAA5A42069150BE9FF727AC1A251E04E52537B961 Test line 2496: unexpected error KEY_MISMATCH Expected: FDBABE1C9D3472007856E7190D01E9FE7C6AD7CBC8237830E77376634B3731622EAF30D92E22A3886FF109279D9830DAC727AFB94A83EE6D8360CBDFA2CC0640 Got: 4D0B8D57109EF588586B7812B70CD2FBD4DDE5F9AD1E45A17C565E24FE247DE986CA22CFDFF6C64346C62436F301EAE987A0E424B080EACB04E70830C3B9ACE0 Test line 2504: unexpected error KEY_MISMATCH Expected: 7023BDCB3AFD7348461C06CD81FD38EBFDA8FBBA904F8E3EA9B543F6545DA1F2D5432955613F0FCF62D49705242A9AF9E61E85DC0D651E40DFCF017B45575887 Got: BF7268686B9059DAA738213780F8EEE8BC2FDD65D50DE1298B5ED2142040DB72E0CC5C6649C682EB8BC998A70D1CA8BCB73FF7367C1027403201F663239520D6 451 tests completed with 3 errors, 0 skipped not ok 1 - running evp_test evptests.txt # Failed test 'running evp_test evptests.txt' # at ../test/recipes/30-test_evp.t line 11. # Looks like you failed 1 test of 1. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/40-test_rehash.t .. Usage: rehash [options] [cert-directory...] Valid options are: -help Display this summary -compat Create both new- and old-style hash links -old Use old-style hash to generate links -n Do not remove existing links -v Verbose output 1..5 ok 1 - Testing normal rehash operations ok 2 - Testing rehash operations on readonly files ok 3 - Testing rehash operations on empty directory not ok 4 - Testing that we aren't running as a privileged user, such as root # Failed test 'Testing that we aren't running as a privileged user, such as root' # at ../test/recipes/40-test_rehash.t line 41. ok 5 # skip It's pointless to run the next test as root # Looks like you failed 1 test of 5. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/5 subtests (less 1 skipped subtest: 3 okay) ../test/recipes/70-test_packet.t .. 1..1 test_PACKET_buf_init() failed not ok 1 - running packettest # Failed test 'running packettest' # at ../test/testlib/OpenSSL/Test/Simple.pm line 70. # Looks like you failed 1 test of 1. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests Test Summary Report ------------------- ../test/recipes/30-test_evp.t (Wstat: 256 Tests: 1 Failed: 1) Failed test: 1 Non-zero exit status: 1 ../test/recipes/40-test_rehash.t (Wstat: 256 Tests: 5 Failed: 1) Failed test: 4 Non-zero exit status: 1 ../test/recipes/70-test_packet.t (Wstat: 256 Tests: 1 Failed: 1) Failed test: 1 Non-zero exit status: 1 Files=3, Tests=7, 4 wallclock secs ( 0.10 usr 0.07 sys + 2.28 cusr 1.35 csys = 3.80 CPU) Result: FAIL Failed 3/3 test programs. 3/7 subtests failed. *** Error code 1 Stop. *** Error code 1 Stop. You have new mail in /var/mail/doctor ns2.nl2k.ab.ca//usr/source/openssl-SNAP-20160228$ exit exit Script done on Sun Feb 28 06:11:26 2016 Anything that has to be addressed? -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Broadcasting the truth for 25 years From rt at openssl.org Sun Feb 28 14:50:19 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 28 Feb 2016 14:50:19 +0000 Subject: [openssl-dev] [openssl.org #4351] PATCH: Update Malloc docs to reflect current state of affairs In-Reply-To: References: Message-ID: pushed to master, thanks! -- Rich Salz, OpenSSL dev team; rsalz at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4351 Please log in as guest with password guest if prompted From dkg at fifthhorseman.net Sun Feb 28 08:32:20 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sun, 28 Feb 2016 09:32:20 +0100 Subject: [openssl-dev] [openssl.org #4343] master: EC_KEY_priv2buf (): check parameter sanity In-Reply-To: <20160226170443.GW12869@mournblade.imrryr.org> References: <20160226170443.GW12869@mournblade.imrryr.org> Message-ID: <8760x9qlpn.fsf@alice.fifthhorseman.net> On Fri 2016-02-26 18:04:43 +0100, Viktor Dukhovni wrote: > I'd like to propose a policy of no bug fixes to undocumented public > interfaces. If the interface is useful enough to fix, it has to be > documented. fwiw, i agree with Viktor on this proposal. Clear, sane APIs require documentation, and just writing up the documentation can sometimes spur people to evaluate the functionality differently and look for bugs in new ways. If anyone understands a function well enough to fix bugs in it, you should understand it well enough to write minimal documentation. --dkg From noloader at gmail.com Sun Feb 28 17:17:41 2016 From: noloader at gmail.com (Jeffrey Walton) Date: Sun, 28 Feb 2016 12:17:41 -0500 Subject: [openssl-dev] [openssl.org #4343] master: EC_KEY_priv2buf (): check parameter sanity In-Reply-To: References: <20160226170443.GW12869@mournblade.imrryr.org> <20160226171924.GX12869@mournblade.imrryr.org> Message-ID: On Sun, Feb 28, 2016 at 12:18 AM, Viktor Dukhovni wrote: > >> On Feb 27, 2016, at 7:42 PM, Jeffrey Walton wrote: >> >> Please ensure this is documented somewhere. I'm having trouble finding >> information on the new rules. >> >> There's 15 or 20 years of using capitol and lower case identifiers to >> denote public and private APIs with OpenSSL. For example, see >> https://marc.info/?l=openssl-users&m=102683340223621 . >> >> I'm happy to tell folks that no longer applies, but we need to know >> what the new rules are is and when the cut-over occured. > > There are no new *rules*, just new goals I'm promoting in this thread. > If it is not documented it is not a fully implemented public interface. > The documentation is part of what it takes to be a first-class > public interface. New code must be documented, and patches to > existing code should bring the documentation up to date. In good > part because it is hard to know whether a patch is correct when > updating undocumented code, and the exercise of documenting it makes > one think harder about the requisite semantics. > > The upper-case lower-case thing is a legacy crutch, that is likely > to continue to be adhered to for some time, but increasingly it is > the documentation that must delineate between public and internal > interfaces. Thanks Viktor. Here's the practical problem I am trying to solve. Its a policy and procedure problem. Suppose an organization has a rule that says, "no private APIs shall be used". How do I tell an organization to differentiate between public and private APIs to ensure compliance with the policy? What do I tell QA to verify compliance with the policy? In the past, we knew from the upper-case lower-case thing. I'm guessing that held until OpenSSL 1.0.2. I'm also guessing that's is going to change at 1.1.x. What do we use now? What are the actionable items or prescriptive items we can pivot on? For what its worth, this is your sandbox and I'm not trying to take any of your toys away. You're free to do what you want. The point here is it would be very helpful (necessary?) to know what's going on for organizational policies and procedures. Jeff From openssl-users at dukhovni.org Sun Feb 28 17:25:59 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sun, 28 Feb 2016 12:25:59 -0500 Subject: [openssl-dev] [openssl.org #4343] master: EC_KEY_priv2buf (): check parameter sanity In-Reply-To: References: <20160226170443.GW12869@mournblade.imrryr.org> <20160226171924.GX12869@mournblade.imrryr.org> Message-ID: > On Feb 28, 2016, at 12:17 PM, Jeffrey Walton wrote: > > Thanks Viktor. > > Here's the practical problem I am trying to solve. Its a policy and > procedure problem. > > Suppose an organization has a rule that says, "no private APIs shall > be used". How do I tell an organization to differentiate between > public and private APIs to ensure compliance with the policy? What do > I tell QA to verify compliance with the policy? With respect to OpenSSL, such a policy is untenable for applications that use advanced under-documented portions of the API. OpenSSL does not currently provide a comprehensive definition of the public API. For applications that use only the most commonly used features, the best bet is to only use documented interfaces. If you're using undocumented features, you're going out on a limb. If you're using something undocumented, but clearly important and broadly useful, contribute documentation! -- Viktor. From rsalz at akamai.com Sun Feb 28 17:27:08 2016 From: rsalz at akamai.com (Salz, Rich) Date: Sun, 28 Feb 2016 17:27:08 +0000 Subject: [openssl-dev] [openssl.org #4343] master: EC_KEY_priv2buf (): check parameter sanity In-Reply-To: References: <20160226170443.GW12869@mournblade.imrryr.org> <20160226171924.GX12869@mournblade.imrryr.org> Message-ID: <573c8b28b5604d86a2032c7dc6e87c83@usma1ex-dag1mb1.msg.corp.akamai.com> FWIW, I agree with Viktor. From kurt at roeckx.be Sun Feb 28 17:30:26 2016 From: kurt at roeckx.be (Kurt Roeckx) Date: Sun, 28 Feb 2016 18:30:26 +0100 Subject: [openssl-dev] [openssl.org #4343] master: EC_KEY_priv2buf (): check parameter sanity In-Reply-To: References: <20160226170443.GW12869@mournblade.imrryr.org> <20160226171924.GX12869@mournblade.imrryr.org> Message-ID: <20160228173026.GA4336@roeckx.be> On Sun, Feb 28, 2016 at 12:17:41PM -0500, Jeffrey Walton wrote: > On Sun, Feb 28, 2016 at 12:18 AM, Viktor Dukhovni > wrote: > > > >> On Feb 27, 2016, at 7:42 PM, Jeffrey Walton wrote: > >> > >> Please ensure this is documented somewhere. I'm having trouble finding > >> information on the new rules. > >> > >> There's 15 or 20 years of using capitol and lower case identifiers to > >> denote public and private APIs with OpenSSL. For example, see > >> https://marc.info/?l=openssl-users&m=102683340223621 . > >> > >> I'm happy to tell folks that no longer applies, but we need to know > >> what the new rules are is and when the cut-over occured. > > > > There are no new *rules*, just new goals I'm promoting in this thread. > > If it is not documented it is not a fully implemented public interface. > > The documentation is part of what it takes to be a first-class > > public interface. New code must be documented, and patches to > > existing code should bring the documentation up to date. In good > > part because it is hard to know whether a patch is correct when > > updating undocumented code, and the exercise of documenting it makes > > one think harder about the requisite semantics. > > > > The upper-case lower-case thing is a legacy crutch, that is likely > > to continue to be adhered to for some time, but increasingly it is > > the documentation that must delineate between public and internal > > interfaces. > > Thanks Viktor. > > Here's the practical problem I am trying to solve. Its a policy and > procedure problem. > > Suppose an organization has a rule that says, "no private APIs shall > be used". How do I tell an organization to differentiate between > public and private APIs to ensure compliance with the policy? What do > I tell QA to verify compliance with the policy? > > In the past, we knew from the upper-case lower-case thing. I'm > guessing that held until OpenSSL 1.0.2. I'm also guessing that's is > going to change at 1.1.x. > > What do we use now? What are the actionable items or prescriptive > items we can pivot on? Those that are in the public headers files are the ones that are (probably) meant to be public. They also end up in the .num files and are now the only exported functions on platforms that support that. But before you use those functions that are meant to be public check that they are actually documented. If they're not documented, try to get them documented before you use them. If you already use them but they're not documented, try to get them documented or avoid using them. Kurt From atulthosar at gmail.com Sun Feb 28 18:45:56 2016 From: atulthosar at gmail.com (Atul Thosar) Date: Mon, 29 Feb 2016 00:15:56 +0530 Subject: [openssl-dev] OpenSSL 1.0.2f build issue - unresolved external symbol Message-ID: Hi All, I am building OpenSSL v1.0.2f for Win32 platform, but compilation failed w/ following errors. I googled a bit, but could not locate the exact cause. Appreciate if anyone could help. Thanks in Advance. rc /fo"tmp32dll\libeay32.res" /d CRYPTO ms\version32.rc link /nologo /subsystem:console /opt:ref /debug /dll /out:out32dll\libeay32.dll /def:ms/LIBEAY32.def @C:\Users\athosar\AppData\Local\Temp\nm43EB.tmp Creating library out32dll\libeay32.lib and object out32dll\libeay32.exp cryptlib.obj : error LNK2001: unresolved external symbol _OPENSSL_ia32cap_P cryptlib.obj : error LNK2019: unresolved external symbol _OPENSSL_ia32_cpuid referenced in function _OPENSSL_cpuid_setup md5_dgst.obj : error LNK2019: unresolved external symbol _md5_block_asm_data_order referenced in function _MD5_Update sha1dgst.obj : error LNK2019: unresolved external symbol _sha1_block_data_order referenced in function _SHA1_Update sha256.obj : error LNK2019: unresolved external symbol _sha256_block_data_order referenced in function _SHA256_Update sha512.obj : error LNK2019: unresolved external symbol _sha512_block_data_order referenced in function _SHA512_Final out32dll\libeay32.dll : fatal error LNK1120: 6 unresolved externals NMAKE : fatal error U1077: '"c:\Program Files (x86)\Microsoft Visual Studio 8\VC\BIN\link.EXE"' : return code '0x460' Stop. Build machine configurations are - OS: Windows 7, 64 bit Compiler: Visual Studio 2005 Active Perl Version: v5.16.3 Initial commands given to configure OpenSSL are - perl Configure VC-WIN32 no-asm --prefix= ms\do_ms nmake -f ms\ntdll.mak -- ?BR, Atul Thosar -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Sun Feb 28 19:38:29 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 28 Feb 2016 19:38:29 +0000 Subject: [openssl-dev] [openssl.org #2363] bug: memory allocated by DH_new() may never be free()ed In-Reply-To: References: Message-ID: from Jan: I'm not exactly saying that "DH_free(DH_new()) leaks memory when in a DLL on Solaris", what I'm saying is that libcrypto does not free memory that it should in "#pragma fini(xxx)". I assume there is some memory allocated first time DH_new() is used and that memory is never freed on dlclose(). So, if I do DH_free(DH_new()) in dlopen'ed library that I then dlclose, there is a leak. link to the RT entry: http://rt.openssl.org/Ticket/Display.html?id=2363&user=guest&pass=guest if I run the test like this (different code than in RT): test.c (build as "gcc -o test -ldl test.c"): #include #include #include int main() { void (*run)(); while (1) { void *handle = dlopen("./run.so", RTLD_NOW); run = (void (*)()) dlsym(handle, "run"); (*run)(); dlclose(handle); } return (0); } run.c (build as "gcc --shared -lcrypto -fPIC -o run.so run.c"): #include int run() { DH_free(DH_new()); } on Linux, I'm leaking megabytes of memory within seconds: $ openssl version OpenSSL 1.0.1i 6 Aug 2014 $ ./test & $ top -b -p $( pgrep test ) PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 21888 pechanec 20 0 17552 2900 504 R 100.0 0.0 0:01.18 test 21888 pechanec 20 0 23228 8816 648 R 99.9 0.1 0:04.18 test 21888 pechanec 20 0 28904 14472 648 R 100.0 0.2 0:07.19 test 21888 pechanec 20 0 34448 19872 504 R 99.9 0.3 0:10.19 test^C it is a generic OpenSSL libcrypto problem. Not one that most users will ever see but still a bug. I assume there might be more leaks like that in implementation of other algorithms. cheers, Jan. -- Jan Pechanec -- Rich Salz, OpenSSL dev team; rsalz at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2363 Please log in as guest with password guest if prompted From rt at openssl.org Sun Feb 28 21:19:57 2016 From: rt at openssl.org (Andy Polyakov via RT) Date: Sun, 28 Feb 2016 21:19:57 +0000 Subject: [openssl-dev] [openssl.org #4346] poly1305-x86.pl's AVX2 code In-Reply-To: <56D36479.7010007@openssl.org> References: <56D0C82F.2060209@openssl.org> <56D36479.7010007@openssl.org> Message-ID: >> There seems to be a bug in the AVX2 codepath in poly1305-x86.pl. I have not >> attempted to debug this, but I have attached a test file which produces >> different output in normal and AVX2 codepaths. Our existing poly1305 >> implementation agrees with the former. >> >> $ OPENSSL_ia32cap=0 ./poly1305_test >> PASS >> $ ./poly1305_test >> Poly1305 test failed. >> got: 2e65f0054e36505687d937ff5e8ed112 >> expected: 69d28f73dd09d39a92aa179da354b7ea > > While I keep looking further, double-check attached. Attached is alternative solution, please double-check. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4346 Please log in as guest with password guest if prompted -------------- next part -------------- commit 3902c696c5406d68b17cecf9a9effb0edcb84eb2 Author: Andy Polyakov Date: Sun Feb 28 21:48:43 2016 +0100 poly1305/asm/poly1305-*.pl: flip horizontal add and reduction. Formally only 32-bit AVX2 code path needs this, but I choose to harmonize all vector code paths. RT#4346 diff --git a/crypto/poly1305/asm/poly1305-armv4.pl b/crypto/poly1305/asm/poly1305-armv4.pl index 65b79cf..ac202ad 100755 --- a/crypto/poly1305/asm/poly1305-armv4.pl +++ b/crypto/poly1305/asm/poly1305-armv4.pl @@ -1057,6 +1057,15 @@ poly1305_blocks_neon: .Lshort_tail: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ + @ horizontal addition + + vadd.i64 $D3#lo,$D3#lo,$D3#hi + vadd.i64 $D0#lo,$D0#lo,$D0#hi + vadd.i64 $D4#lo,$D4#lo,$D4#hi + vadd.i64 $D1#lo,$D1#lo,$D1#hi + vadd.i64 $D2#lo,$D2#lo,$D2#hi + + @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ lazy reduction, but without narrowing vshr.u64 $T0,$D3,#26 @@ -1086,15 +1095,6 @@ poly1305_blocks_neon: vadd.i64 $D1,$D1,$T0 @ h0 -> h1 vadd.i64 $D4,$D4,$T1 @ h3 -> h4 - @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ - @ horizontal addition - - vadd.i64 $D2#lo,$D2#lo,$D2#hi - vadd.i64 $D0#lo,$D0#lo,$D0#hi - vadd.i64 $D3#lo,$D3#lo,$D3#hi - vadd.i64 $D1#lo,$D1#lo,$D1#hi - vadd.i64 $D4#lo,$D4#lo,$D4#hi - cmp $len,#0 bne .Leven diff --git a/crypto/poly1305/asm/poly1305-armv8.pl b/crypto/poly1305/asm/poly1305-armv8.pl index 79185d2..f1359fd 100755 --- a/crypto/poly1305/asm/poly1305-armv8.pl +++ b/crypto/poly1305/asm/poly1305-armv8.pl @@ -791,6 +791,19 @@ poly1305_blocks_neon: .Lshort_tail: //////////////////////////////////////////////////////////////// + // horizontal add + + addp $ACC3,$ACC3,$ACC3 + ldp d8,d9,[sp,#16] // meet ABI requirements + addp $ACC0,$ACC0,$ACC0 + ldp d10,d11,[sp,#32] + addp $ACC4,$ACC4,$ACC4 + ldp d12,d13,[sp,#48] + addp $ACC1,$ACC1,$ACC1 + ldp d14,d15,[sp,#64] + addp $ACC2,$ACC2,$ACC2 + + //////////////////////////////////////////////////////////////// // lazy reduction, but without narrowing ushr $T0.2d,$ACC3,#26 @@ -822,19 +835,6 @@ poly1305_blocks_neon: add $ACC4,$ACC4,$T1.2d // h3 -> h4 //////////////////////////////////////////////////////////////// - // horizontal add - - addp $ACC2,$ACC2,$ACC2 - ldp d8,d9,[sp,#16] // meet ABI requirements - addp $ACC0,$ACC0,$ACC0 - ldp d10,d11,[sp,#32] - addp $ACC1,$ACC1,$ACC1 - ldp d12,d13,[sp,#48] - addp $ACC3,$ACC3,$ACC3 - ldp d14,d15,[sp,#64] - addp $ACC4,$ACC4,$ACC4 - - //////////////////////////////////////////////////////////////// // write the result, can be partially reduced st4 {$ACC0,$ACC1,$ACC2,$ACC3}[0],[$ctx],#16 diff --git a/crypto/poly1305/asm/poly1305-x86.pl b/crypto/poly1305/asm/poly1305-x86.pl index 7c1aee5..fb9fa2b 100755 --- a/crypto/poly1305/asm/poly1305-x86.pl +++ b/crypto/poly1305/asm/poly1305-x86.pl @@ -536,6 +536,8 @@ my $base = shift; $base = "esp" if (!defined($base)); },"edx"); sub lazy_reduction { +my $extra = shift; + ################################################################ # lazy reduction as discussed in "NEON crypto" by D.J. Bernstein # and P. Schwabe @@ -543,6 +545,7 @@ sub lazy_reduction { &movdqa ($T0,$D3); &pand ($D3,$MASK); &psrlq ($T0,26); + &$extra () if (defined($extra)); &paddq ($T0,$D4); # h3 -> h4 &movdqa ($T1,$D0); &pand ($D0,$MASK); @@ -1091,21 +1094,21 @@ my $addr = shift; &set_label("short_tail"); - &lazy_reduction (); - ################################################################ # horizontal addition + &pshufd ($T1,$D4,0b01001110); + &pshufd ($T0,$D3,0b01001110); + &paddq ($D4,$T1); + &paddq ($D3,$T0); &pshufd ($T1,$D0,0b01001110); &pshufd ($T0,$D1,0b01001110); - &paddd ($D0,$T1); + &paddq ($D0,$T1); + &paddq ($D1,$T0); &pshufd ($T1,$D2,0b01001110); - &paddd ($D1,$T0); - &pshufd ($T0,$D3,0b01001110); - &paddd ($D2,$T1); - &pshufd ($T1,$D4,0b01001110); - &paddd ($D3,$T0); - &paddd ($D4,$T1); + #&paddq ($D2,$T1); + + &lazy_reduction (sub { &paddq ($D2,$T1) }); &set_label("done"); &movd (&DWP(-16*3+4*0,"edi"),$D0); # store hash value @@ -1113,8 +1116,8 @@ my $addr = shift; &movd (&DWP(-16*3+4*2,"edi"),$D2); &movd (&DWP(-16*3+4*3,"edi"),$D3); &movd (&DWP(-16*3+4*4,"edi"),$D4); -&set_label("nodata"); &mov ("esp","ebp"); +&set_label("nodata"); &function_end("_poly1305_blocks_sse2"); &align (32); @@ -1435,7 +1438,7 @@ sub X { my $reg=shift; $reg=~s/^ymm/xmm/; $reg; } &test ("eax","eax"); # is_base2_26? &jz (&label("enter_blocks")); -&set_label("enter_avx2",16); +&set_label("enter_avx2"); &vzeroupper (); &call (&label("pic_point")); @@ -1731,31 +1734,31 @@ sub vlazy_reduction { &vpmuladd (sub { my $i=shift; &QWP(4+32*$i-128,"edx"); }); - &vlazy_reduction(); - ################################################################ # horizontal addition + &vpsrldq ($T0,$D4,8); + &vpsrldq ($T1,$D3,8); + &vpaddq ($D4,$D4,$T0); &vpsrldq ($T0,$D0,8); + &vpaddq ($D3,$D3,$T1); &vpsrldq ($T1,$D1,8); &vpaddq ($D0,$D0,$T0); &vpsrldq ($T0,$D2,8); &vpaddq ($D1,$D1,$T1); - &vpsrldq ($T1,$D3,8); + &vpermq ($T1,$D4,2); # keep folding &vpaddq ($D2,$D2,$T0); - &vpsrldq ($T0,$D4,8); - &vpaddq ($D3,$D3,$T1); - &vpermq ($T1,$D0,2); # keep folding - &vpaddq ($D4,$D4,$T0); + &vpermq ($T0,$D3,2); + &vpaddq ($D4,$D4,$T1); + &vpermq ($T1,$D0,2); + &vpaddq ($D3,$D3,$T0); &vpermq ($T0,$D1,2); &vpaddq ($D0,$D0,$T1); &vpermq ($T1,$D2,2); &vpaddq ($D1,$D1,$T0); - &vpermq ($T0,$D3,2); &vpaddq ($D2,$D2,$T1); - &vpermq ($T1,$D4,2); - &vpaddq ($D3,$D3,$T0); - &vpaddq ($D4,$D4,$T1); + + &vlazy_reduction(); &cmp ("ecx",0); &je (&label("done")); @@ -1772,14 +1775,14 @@ sub vlazy_reduction { &jmp (&label("even")); &set_label("done",16); - &vmovd (&DWP(-16*3+4*0,"edi"),"xmm0"); # store hash value - &vmovd (&DWP(-16*3+4*1,"edi"),"xmm1"); - &vmovd (&DWP(-16*3+4*2,"edi"),"xmm2"); - &vmovd (&DWP(-16*3+4*3,"edi"),"xmm3"); - &vmovd (&DWP(-16*3+4*4,"edi"),"xmm4"); + &vmovd (&DWP(-16*3+4*0,"edi"),&X($D0));# store hash value + &vmovd (&DWP(-16*3+4*1,"edi"),&X($D1)); + &vmovd (&DWP(-16*3+4*2,"edi"),&X($D2)); + &vmovd (&DWP(-16*3+4*3,"edi"),&X($D3)); + &vmovd (&DWP(-16*3+4*4,"edi"),&X($D4)); &vzeroupper (); -&set_label("nodata"); &mov ("esp","ebp"); +&set_label("nodata"); &function_end("_poly1305_blocks_avx2"); } &set_label("const_sse2",64); diff --git a/crypto/poly1305/asm/poly1305-x86_64.pl b/crypto/poly1305/asm/poly1305-x86_64.pl index b827d24..2265664 100755 --- a/crypto/poly1305/asm/poly1305-x86_64.pl +++ b/crypto/poly1305/asm/poly1305-x86_64.pl @@ -1198,6 +1198,20 @@ $code.=<<___; .Lshort_tail_avx: ################################################################ + # horizontal addition + + vpsrldq \$8,$D4,$T4 + vpsrldq \$8,$D3,$T3 + vpsrldq \$8,$D1,$T1 + vpsrldq \$8,$D0,$T0 + vpsrldq \$8,$D2,$T2 + vpaddq $T3,$D3,$D3 + vpaddq $T4,$D4,$D4 + vpaddq $T0,$D0,$D0 + vpaddq $T1,$D1,$D1 + vpaddq $T2,$D2,$D2 + + ################################################################ # lazy reduction vpsrlq \$26,$D3,$H3 @@ -1231,25 +1245,11 @@ $code.=<<___; vpand $MASK,$D3,$D3 vpaddq $H3,$D4,$D4 # h3 -> h4 - ################################################################ - # horizontal addition - - vpsrldq \$8,$D2,$T2 - vpsrldq \$8,$D0,$T0 - vpsrldq \$8,$D1,$T1 - vpsrldq \$8,$D3,$T3 - vpsrldq \$8,$D4,$T4 - vpaddq $T2,$D2,$H2 - vpaddq $T0,$D0,$H0 - vpaddq $T1,$D1,$H1 - vpaddq $T3,$D3,$H3 - vpaddq $T4,$D4,$H4 - - vmovd $H0,`4*0-48-64`($ctx) # save partially reduced - vmovd $H1,`4*1-48-64`($ctx) - vmovd $H2,`4*2-48-64`($ctx) - vmovd $H3,`4*3-48-64`($ctx) - vmovd $H4,`4*4-48-64`($ctx) + vmovd $D0,`4*0-48-64`($ctx) # save partially reduced + vmovd $D1,`4*1-48-64`($ctx) + vmovd $D2,`4*2-48-64`($ctx) + vmovd $D3,`4*3-48-64`($ctx) + vmovd $D4,`4*4-48-64`($ctx) ___ $code.=<<___ if ($win64); vmovdqa 0x50(%r11),%xmm6 @@ -1888,6 +1888,31 @@ $code.=<<___; vpaddq $H0,$D0,$H0 # h0 = d0 + h1*s4 ################################################################ + # horizontal addition + + vpsrldq \$8,$D1,$T1 + vpsrldq \$8,$H2,$T2 + vpsrldq \$8,$H3,$T3 + vpsrldq \$8,$H4,$T4 + vpsrldq \$8,$H0,$T0 + vpaddq $T1,$D1,$D1 + vpaddq $T2,$H2,$H2 + vpaddq $T3,$H3,$H3 + vpaddq $T4,$H4,$H4 + vpaddq $T0,$H0,$H0 + + vpermq \$0x2,$H3,$T3 + vpermq \$0x2,$H4,$T4 + vpermq \$0x2,$H0,$T0 + vpermq \$0x2,$D1,$T1 + vpermq \$0x2,$H2,$T2 + vpaddq $T3,$H3,$H3 + vpaddq $T4,$H4,$H4 + vpaddq $T0,$H0,$H0 + vpaddq $T1,$D1,$D1 + vpaddq $T2,$H2,$H2 + + ################################################################ # lazy reduction vpsrlq \$26,$H3,$D3 @@ -1921,31 +1946,6 @@ $code.=<<___; vpand $MASK,$H3,$H3 vpaddq $D3,$H4,$H4 # h3 -> h4 - ################################################################ - # horizontal addition - - vpsrldq \$8,$H2,$T2 - vpsrldq \$8,$H0,$T0 - vpsrldq \$8,$H1,$T1 - vpsrldq \$8,$H3,$T3 - vpsrldq \$8,$H4,$T4 - vpaddq $T2,$H2,$H2 - vpaddq $T0,$H0,$H0 - vpaddq $T1,$H1,$H1 - vpaddq $T3,$H3,$H3 - vpaddq $T4,$H4,$H4 - - vpermq \$0x2,$H2,$T2 - vpermq \$0x2,$H0,$T0 - vpermq \$0x2,$H1,$T1 - vpermq \$0x2,$H3,$T3 - vpermq \$0x2,$H4,$T4 - vpaddq $T2,$H2,$H2 - vpaddq $T0,$H0,$H0 - vpaddq $T1,$H1,$H1 - vpaddq $T3,$H3,$H3 - vpaddq $T4,$H4,$H4 - vmovd %x#$H0,`4*0-48-64`($ctx)# save partially reduced vmovd %x#$H1,`4*1-48-64`($ctx) vmovd %x#$H2,`4*2-48-64`($ctx) diff --git a/crypto/poly1305/poly1305.c b/crypto/poly1305/poly1305.c index 7c9f302..303822e 100644 --- a/crypto/poly1305/poly1305.c +++ b/crypto/poly1305/poly1305.c @@ -668,6 +668,20 @@ static const struct poly1305_test poly1305_tests[] = { "f248312e578d9d58f8b7bb4d19105431" }, /* + * AVX2 in poly1305-x86.pl failed this with 176+32 split + */ + { + "248ac31085b6c2adaaa38259a0d7192c5c35d1bb4ef39ad94c38d1c82479e2dd" + "2159a077024b0589bc8a20101b506f0a1ad0bbab76e83a83f1b94be6beae74e8" + "74cab692c5963a75436b776121ec9f62399a3e66b2d22707dae81933b6277f3c" + "8516bcbe26dbbd86f373103d7cf4cad1888c952118fbfbd0d7b4bedc4ae4936a" + "ff91157e7aa47c54442ea78d6ac251d324a0fbe49d89cc3521b66d16e9c66a37" + "09894e4eb0a4eedc4ae19468e66b81f2" + "71351b1d921ea551047abcc6b87a901fde7db79fa1818c11336dbc07244a40eb", + "000102030405060708090a0b0c0d0e0f""00000000000000000000000000000000", + "bc939bc5281480fa99c6d68c258ec42f" + }, + /* * test vectors from Google */ { @@ -844,6 +858,23 @@ int main() printf("\n"); return 1; } + + for (half = 16; half < inlen; half += 16) { + Poly1305_Init(&poly1305, key); + Poly1305_Update(&poly1305, in, half); + Poly1305_Update(&poly1305, in+half, inlen-half); + Poly1305_Final(&poly1305, out); + + if (memcmp(out, expected, sizeof(expected)) != 0) { + printf("Poly1305 test #%d/%d failed.\n", i, half); + printf("got: "); + hexdump(out, sizeof(out)); + printf("\nexpected: "); + hexdump(expected, sizeof(expected)); + printf("\n"); + return 1; + } + } } free(in); From rt at openssl.org Sun Feb 28 22:11:56 2016 From: rt at openssl.org (noloader@gmail.com via RT) Date: Sun, 28 Feb 2016 22:11:56 +0000 Subject: [openssl-dev] [openssl.org #4356] 64-bit OS X on x86_64 misidentified as i686 In-Reply-To: References: Message-ID: Working from Master: $ git reset --hard HEAD && git pull HEAD is now at 31ba0e1 Fix mk1mf build Already up-to-date. MacBook Pro from 2013 (Intel, x86_64), OS X 10.8.5, fully patched: $ ./config Operating system: i686-apple-darwinDarwin Kernel Version 12.6.0: Wed Mar 18 16:23:48 PDT 2015; root:xnu-2050.48.19~1/RELEASE_X86_64 WARNING! If you wish to build 64-bit library, then you have to invoke './Configure darwin64-x86_64-cc ' *manually*. You have about 5 seconds to press Ctrl-C to abort. ... This code from config seems to be responsible: Darwin:*) case "$MACHINE" in Power*) echo "ppc-apple-darwin${VERSION}" ;; *) echo "i686-apple-darwin${VERSION}" ;; esac exit 0 ;; And: i?86-apple-darwin*) ISA64=`(sysctl -n hw.optional.x86_64) 2>/dev/null` if [ "$ISA64" = "1" -a -z "$KERNEL_BITS" ]; then echo "WARNING! If you wish to build 64-bit library, then you have to" echo " invoke '$THERE/Configure darwin64-x86_64-cc $options' *manually*." if [ "$TEST" = "false" -a -t 1 ]; then echo " You have about 5 seconds to press Ctrl-C to abort." # The stty technique used elsewhere doesn't work on # MacOS. At least, right now on this Mac. sleep 5 fi fi if [ "$ISA64" = "1" -a "$KERNEL_BITS" = "64" ]; then OUT="darwin64-x86_64-cc" else OUT="darwin-i386-cc" fi ;; $MACHINE looks like it could help here: $ uname -m x86_64 Maybe its time to add a case for x86_64. For those who really want 32-bit, they can 'export KERNEL_BITS=32'. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4356 Please log in as guest with password guest if prompted From rt at openssl.org Sun Feb 28 22:27:49 2016 From: rt at openssl.org (Andy Polyakov via RT) Date: Sun, 28 Feb 2016 22:27:49 +0000 Subject: [openssl-dev] [openssl.org #4346] poly1305-x86.pl's AVX2 code In-Reply-To: <56D37462.6000000@openssl.org> References: <56D37462.6000000@openssl.org> Message-ID: > There seems to be a bug in the AVX2 codepath in poly1305-x86.pl. I have not > attempted to debug this, but I have attached a test file which produces > different output in normal and AVX2 codepaths. Our existing poly1305 > implementation agrees with the former. > > $ OPENSSL_ia32cap=0 ./poly1305_test > PASS > $ ./poly1305_test > Poly1305 test failed.t > got: 2e65f0054e36505687d937ff5e8ed112 > expected: 69d28f73dd09d39a92aa179da354b7ea > > You may wish to generalize that Poly1305_Update pattern into your own > tests. This is what I did to catch this: > https://boringssl-review.googlesource.com/#/c/7223/ About choice of test vector lengths. From viewpoint of exercising different branches lengths 2048 through 2048+15 would exercise same vector path. What one needs is combinations of 64*n+16*m. But you do compensate for this by exercising varying what you've called excess lengths. I suppose what I'm saying is that that +15 thing is kind of redundant in the context. This is because last block is always processed separately. > By the way, this assembly code is quite complicated. Yeah, but what you gonna do, vectorizing is hard in this case... > I wasn't able to find > problems in the others (I tested armv4, armv8, x86, and x86_64), but I'm > far from confident I've covered all the cases. > > With the caveat that I'm no assembly programmer, much of the complexity > seems to come the SIMD code needing a multiple of 2 or 4 blocks and the > implementation converting internal state back and forth from base 2^26 and > 2^64 and handling excess blocks slightly differently in different cases. (I > counted nine distinct codepaths to test in the x86_64 AVX codepath alone.) While it's correct that excess blocks are handled though 2^26<>2^64 conversion in 64-bit modules, in 32-bit modules 2^32->2^26 is one way. I mean in 32-bit modules even excess blocks are handled by vector code (because it's faster than scalar code even if you have to discard some data). Though "excess blocks" can be a little bit misleading term in the context, because it kind of makes you think that processing is done as [2|4]*n + remainder, while it's actually processed as remainder + [2|4]n. [For reference, [2|4] will become [2|4|8] as soon as support for AVX512 is added]. All this is provided that input length is longer than certain limit. Vectorized procedure requires expensive setup which is postponed till we know that input is long enough to justify additional overhead (see https://www.openssl.org/blog/blog/2016/02/15/poly1305-revised/ for background information). > The C code already buffers up to 16-byte blocks. Did you consider buffering > up to 32 or 64 bytes in C when the SIMD code called for it? Yes, but here is the thing. You'd need to be able to handle all possible remainders in either case. So I figured it would be appropriate to take "straight-forward" version for a "burn-out" to real world prior next step ;-) > I haven't tried this, so perhaps the performance costs are prohibitive, but > if the costs are modest, the simplifications may be worth it. No, it's perfectly reasonable. One should recognize though that you are unlikely to gain like a lot in TLS case, because call pattern is rather predictable. The noticeable gain would be observed in "wilder" mix of calls. BTW, at some point I also plan to make e_chacha_poly1305.c process couple of 4KB chunks at a time in order to improve cache locality... -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4346 Please log in as guest with password guest if prompted From agostrer at gmail.com Mon Feb 29 00:06:22 2016 From: agostrer at gmail.com (Alexander Gostrer) Date: Sun, 28 Feb 2016 16:06:22 -0800 Subject: [openssl-dev] ECDH engine In-Reply-To: References: <20160120201925.17788998.82513.46556@ll.mit.edu> <569FF2F0.60905@gmail.com> Message-ID: Hi Uri, Sorry, took a while to respond to your request. I cloned "https://github.com/OpenSC/libp11.git" and looked into it for some time. It is really hard for me to give you any advice without knowing the code and/or trying to debug it. My only observation is going back to my previous comment about the new EC_generate_key() function that I was adding into the openssl 1.0.2 patch. If you do not add it (and I didn't see it added to your code) then the OpenSSL TLS1.2 protocol (not sure about previous protocols) will send out to the client a software-generated ephemeral public key: it happens early in the exchange before the "ECDH_compute_key()" function is called. Of course it does not matter if you are using just OpenSSL ephemeral keys (not hardware-generated). I hope it will help. Regards, Alex. On Wed, Jan 27, 2016 at 9:25 AM, Blumenthal, Uri - 0553 - MITLL < uri at ll.mit.edu> wrote: > When I started to write the ECDSA code for engine_pkcs11 in 2011 the code > to support the method hooks was not > in the code. So I used internal OpenSSL header files to copy the > ECDSA_METHOD and replace the function needed. > Look for "BUILD_WITH_ECS_LOCL_H" in libp11. Not until 1.0.2 did OpenSSL > support the needed calls to hook ECDSA. > They did not add the hooks for ECDH. > > > I am missing one thing here. Hopefully you can help me understanding it. > > OpenSSL-1.0.2 currently supports ECDH, as I observe by running > > openssl pkeyutl -derive -inkey /tmp/derive.29494.priv.pem -peerkey > /tmp/derive.29494.token.pub.pem -out /tmp/derive.29494.shared1 > > So clearly there is working code available inside OpenSSL that does what > is needed. The only issue then is to add code to libp11 to access that > code. > > Am I correct? If not, could you please point at where/what I?m mistaken in? > > If you can't wait then you have to do it your self. *YOU* could do the > same thing for ECDH. But your code would only > be good for 1.0.2 because the whole way of doing EC methods changes in > 1.1. > > > That?s perfectly OK, because if my tea leaves reading is correct, > OpenSSL-1.0.2 will be around for several years at least. And most of the > package providers such as Macports won?t move their packages to OpenSSL-1.1 > for probably that long. So making 1.0.2 working with ECDH now will > definitely make sense for me. > > In fact, I think making libp11 compliant with OpenSSL-1.1 now is an > overreach, because this effort (unlike work on 1.0.2) is highly unlikely to > bring benefits to users for a few years. > > I believe Alexander said he had changes to OpenSSL, which is another > approach. > He has said there were here: > https://github.com/AtmelCSO/cryptoauth-openssl-engine/tree/master/patches > > > I see that the actual patch is very small. And the only meaningful (for > me) change is adding a new method EC_generate_key(). I would like to > understand why this method is needed ? is it only to allow OpenSSL to > *generate* key pair on the token? Alexander, could you comment please? > > You could also hire someone who could do more then: "test it and offer > minor enhancements". > > > First, I cannot. Second, I don?t think (and haven?t seen any evidence to > the contrary yet) that anything more is needed. Especially seeing the > minuscule amount of changes Alexander had to do to OpenSSL, and I?m not > even sure I need those if I don?t insist on being able to generate new key > pair on the token using only OpenSSL. > > (And not me. I am taking the 1.1 approach to getting ECDH. working in > engine.) > > > :-) OK, I withdraw my unexpressed and unformulated offer. Consider > yourself un-asked. :-) > > > On 1/20/2016 2:19 PM, Blumenthal, Uri - 0553 - MITLL wrote: > > Very possible that I'm missing the point here. > > Still, since openssl-1_0_2 does ECDH, and it exposes ?ECDSA to external > engine(s), how difficult would it be to add ECDH exposure? I suspect - a > good deal easier than getting 1.1 replace 1.0.x as the de-facto deployment > standard. > > Plus, by this time there already are (and reasonably common) tokens that > support ECDH, other packages that do ECDH, and people (like myself :-) > willing to test it and offer minor enhancements. > > Another point I seem to be missing - if what's necessary to implement ECDH > in an external engine is missing from 1_0_2 - how could ?Alexander write a > (presumably) working ECDH engine for 1_0_2? If he could do it, why can't > engine_pkcs11 be extended to do the same? > > > Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network. > *From: *Douglas E Engert > *Sent: *Wednesday, January 20, 2016 14:59 > *To: *openssl-dev at openssl.org? > *Reply To: *openssl-dev at openssl.org > *Subject: *Re: [openssl-dev] ECDH engine > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Mon Feb 29 01:40:34 2016 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 29 Feb 2016 01:40:34 +0000 Subject: [openssl-dev] "These are not the patches you are looking for" Message-ID: We recently posted some patches to to our public repo. Since they came out just before the announced security release, many people have been confused and thought that perhaps we posted CVE fixes prematurely. This is not the case. The commit were for fixing low-priority CVE issues, and according to our security policy (https://www.openssl.org/policies/secpolicy.html) were pushed as commits. The release we pre-announced addresses other, more serious, issues. -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Mon Feb 29 03:03:31 2016 From: rt at openssl.org (Bruce Drake via RT) Date: Mon, 29 Feb 2016 03:03:31 +0000 Subject: [openssl-dev] [openssl.org #4348] AutoReply: SSL3_GET_MESSAGE:excessive message size In-Reply-To: <56D3B4F4.1070007@dataprocessors.com.au> References: <56CF8C70.3070504@dataprocessors.com.au> <56D3B4F4.1070007@dataprocessors.com.au> Message-ID: Please close this, I found the cause was due to a multi-threaded read before the connect had completed. Sorry. On 26/02/2016 1:47 PM, The default queue via RT wrote: > Greetings, > > This message has been automatically generated in response to the > creation of a trouble ticket regarding: > "SSL3_GET_MESSAGE:excessive message size", > a summary of which appears below. > > There is no need to reply to this message right now. Your ticket has been > assigned an ID of [openssl.org #4348]. > > Please include the string: > > [openssl.org #4348] > > in the subject line of all future correspondence about this issue. To do so, > you may reply to this message. > > Thank you, > rt at openssl.org > > ------------------------------------------------------------------------- > Hi > > I am getting the following error when trying to connect to > > stream-api.betfair.com:443 > > Error connecting with SSL. > error:1408E098:SSL routines:SSL3_GET_MESSAGE:excessive message size > > using OpenSSL. However using code I wrote using SChannel it works fine. > > I looked around and it looks like this has happened before and there is > something in the code that needs to be tweaked, I am using 1.0.1r which > I have build myself, if someone could point me at the code that needs to > change to fix this I would be happy to do so. > > Regards > Bruce > > > > ------------------------------------------------------------------------- > http://rt.openssl.org/Ticket/Display.html?id=4348&user=guest&pass=guest -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4348 Please log in as guest with password guest if prompted From doctor at doctor.nl2k.ab.ca Mon Feb 29 04:20:55 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Sun, 28 Feb 2016 21:20:55 -0700 Subject: [openssl-dev] Announce: OpenSSH 7.2 released In-Reply-To: References: Message-ID: <20160229042055.GA19560@doctor.nl2k.ab.ca> On Sun, Feb 28, 2016 at 07:12:27PM -0700, Damien Miller wrote: > OpenSSH 7.2 has just been released. It will be available from the > mirrors listed at http://www.openssh.com/ shortly. > > OpenSSH is a 100% complete SSH protocol 2.0 implementation and > includes sftp client and server support. OpenSSH also includes > transitional support for the legacy SSH 1.3 and 1.5 protocols > that may be enabled at compile-time. > > Once again, we would like to thank the OpenSSH community for their > continued support of the project, especially those who contributed > code or patches, reported bugs, tested snapshots or donated to the > project. More information on donations may be found at: > http://www.openssh.com/donations.html > > Future deprecation notice > ========================= > > We plan on retiring more legacy cryptography in a near-future > release, specifically: > > * Refusing all RSA keys smaller than 1024 bits (the current minimum > is 768 bits) > > This list reflects our current intentions, but please check the final > release notes for future releases. > > Potentially-incompatible changes > ================================ > > This release disables a number of legacy cryptographic algorithms > by default in ssh: > > * Several ciphers blowfish-cbc, cast128-cbc, all arcfour variants > and the rijndael-cbc aliases for AES. > > * MD5-based and truncated HMAC algorithms. > > These algorithms are already disabled by default in sshd. > All right can we get this openssl 1.1 ready? Looks like not too much needs to be done in cipher.h line 69 needs to be changed to EVP_CIPHER_CTX *evp; In sshkey.c replace pk->type to EVP_PKEY_type Just cipher.c we get /usr/bin/gcc -g -O2 -Wall -Wall -Wpointer-arith -Wuninitialized -Wsign-compare -Wformat-security -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -ftrapv -fno-builtin-memset -I. -I. -I/usr/contrib//include -DSSHDIR=\"/etc\" -D_PATH_SSH_PROGRAM=\"/usr/contrib/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/contrib/libexec/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/usr/contrib/libexec/sftp-server\" -D_PATH_SSH_KEY_SIGN=\"/usr/contrib/libexec/ssh-keysign\" -D_PATH_SSH_PKCS11_HELPER=\"/usr/contrib/libexec/ssh-pkcs11-helper\" -D_PATH_SSH_PIDDIR=\"/var/run\" -D_PATH_PRIVSEP_CHROOT_DIR=\"/var/empty\" -DHAVE_CONFIG_H -c cipher.c -o cipher.o cipher.c: In function `cipher_init': cipher.c:329: warning: passing arg 1 of `EVP_CIPHER_CTX_reset' from incompatible pointer type cipher.c:331: warning: passing arg 1 of `EVP_CipherInit' from incompatible pointer type cipher.c:337: warning: passing arg 1 of `EVP_CIPHER_CTX_ctrl' from incompatible pointer type cipher.c:341: warning: passing arg 1 of `EVP_CIPHER_CTX_key_length' from incompatible pointer type cipher.c:343: warning: passing arg 1 of `EVP_CIPHER_CTX_set_key_length' from incompatible pointer type cipher.c:348: warning: passing arg 1 of `EVP_CipherInit' from incompatible pointer type cipher.c:360: warning: passing arg 1 of `EVP_Cipher' from incompatible pointer type cipher.c:367: warning: passing arg 1 of `EVP_CIPHER_CTX_reset' from incompatible pointer type cipher.c: In function `cipher_crypt': cipher.c:414: warning: passing arg 1 of `EVP_CIPHER_CTX_ctrl' from incompatible pointer type cipher.c:419: warning: passing arg 1 of `EVP_CIPHER_CTX_ctrl' from incompatible pointer type cipher.c:424: warning: passing arg 1 of `EVP_Cipher' from incompatible pointer type cipher.c:431: warning: passing arg 1 of `EVP_Cipher' from incompatible pointer type cipher.c:435: warning: passing arg 1 of `EVP_Cipher' from incompatible pointer type cipher.c:440: warning: passing arg 1 of `EVP_CIPHER_CTX_ctrl' from incompatible pointer type cipher.c: In function `cipher_cleanup': cipher.c:471: warning: passing arg 1 of `EVP_CIPHER_CTX_reset' from incompatible pointer type cipher.c: In function `cipher_get_keyiv_len': cipher.c:518: warning: passing arg 1 of `EVP_CIPHER_CTX_iv_length' from incompatible pointer type cipher.c: In function `cipher_get_keyiv': cipher.c:550: warning: passing arg 1 of `EVP_CIPHER_CTX_iv_length' from incompatible pointer type cipher.c:564: warning: passing arg 1 of `EVP_CIPHER_CTX_ctrl' from incompatible pointer type cipher.c:567: request for member `iv' in something not a structure or union cipher.c: In function `cipher_set_keyiv': cipher.c:598: warning: passing arg 1 of `EVP_CIPHER_CTX_iv_length' from incompatible pointer type cipher.c:604: warning: passing arg 1 of `EVP_CIPHER_CTX_ctrl' from incompatible pointer type cipher.c:607: request for member `iv' in something not a structure or union cipher.c: In function `cipher_get_keycontext': cipher.c:633: request for member `cipher' in something not a structure or union cipher.c:636: request for member `cipher_data' in something not a structure or union cipher.c: In function `cipher_set_keycontext': cipher.c:652: request for member `cipher' in something not a structure or union cipher.c:653: request for member `cipher_data' in something not a structure or union *** Error code 1 Stop. Looks like change in evp.h are the source of these errors. -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Broadcasting the truth for 25 years From rt at openssl.org Mon Feb 29 07:07:40 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 29 Feb 2016 07:07:40 +0000 Subject: [openssl-dev] [openssl.org #4348] SSL3_GET_MESSAGE:excessive message size In-Reply-To: <56CF8C70.3070504@dataprocessors.com.au> References: <56CF8C70.3070504@dataprocessors.com.au> Message-ID: closed per request -- Rich Salz, OpenSSL dev team; rsalz at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4348 Please log in as guest with password guest if prompted From matt at openssl.org Mon Feb 29 10:32:49 2016 From: matt at openssl.org (Matt Caswell) Date: Mon, 29 Feb 2016 10:32:49 +0000 Subject: [openssl-dev] MSVC 2015 internal compiler error In-Reply-To: <56CDDEFB.4020504@yahoo.no> References: <56CC81FB.2000107@openssl.org> <56CD85F9.6050307@yahoo.no> <56CD876E.7020404@openssl.org> <56CDDEFB.4020504@yahoo.no> Message-ID: <56D41E51.70604@openssl.org> On 24/02/16 16:48, Gisle Vanem wrote: > Matt Caswell wrote: > >> The complete patch is attached. This is currently going through review, >> and solves the link issue. > > That brought MSVC-2015 back on track. Thanks! > This has now been committed, so hopefully this should work again now. Matt From dwmw2 at infradead.org Mon Feb 29 13:10:38 2016 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 29 Feb 2016 13:10:38 +0000 Subject: [openssl-dev] Ubsec and Chil engines In-Reply-To: <5B8F45EA-5867-4832-916A-6B31A323A59C@temme.net> References: <56C6FCFA.4040602@openssl.org> <5B8F45EA-5867-4832-916A-6B31A323A59C@temme.net> Message-ID: <1456751438.4666.415.camel@infradead.org> On Sat, 2016-02-20 at 12:40 -0800, Sander Temme wrote: > However, I?m intrigued by the notion of a PKCS#11 Engine in OpenSSL: > it?s a standard (an OASIS standard now); it?s fairly fully featured; > everyone in the industry supports it including Thales; and you can > build a program that calls it without needing a vendor SDK, because > there are standard headers and a well defined way to get to the entry > points.? If we can come up with a way to pick a PKCS#11 slot and log > into it that makes sense (e.g. not by poking PINs into a system wide > config file etc.) then I think we?d have a winner. OK, let's explore that. Let's assume, purely for the sake of this discussion, that we ditch the engine from OpenSSL 1.1 and go *purely* with a solution based around the existing engine_pkcs11. From your point of view, what problems are there with that scenario? You talk about "a way to pick a PKCS#11 slot and log into it"... that's basically handled by RFC7512, isn't it? The PKCS#11 URI gives us a standard way to specify not only the slot but also the object therein. It *also* allows a pin-value attribute to be encoded within the URI if you want to do that. If you don't want to encode the PIN, it can be requested at runtime via a UI_METHOD that you provide. I see the Chil engine also supports an alternative callback function... does that really provide any more functionality than your own UI_METHOD does? We could potentially add that... if we must. Are there any (other) gaps in required functionality? Note that engine_pkcs11 doesn't currently support the ?module-path= query attribute. The code flow of the engine doesn't make that trivial, since we initialise the engine (and load the provider module) first and only *later* do we get given a URI to deal with. It's not beyond the wit of man to fix that though, if we need to. We *haven't* needed to care about it so far, though. General-purpose builds (such as building packages for Linux distributions) tend to just use p11-kit-proxy.so as the default module. That just makes us obey the *system* configuration for which PKCS#11 modules should be visible to which applications. And special-purpose use cases can specify a module in advance when loading the engine. Anyone migrating code which explicitly uses the Chil engine to engine_pkcs11 would be able to specify the appropriate module path when loading the engine. For sanely maintained Linux distributions at least, I want to get to a point where *any* application which can take certs/keys from a file, should *also* accept a PKCS#11 URI in place of a file name and should just work. The Fedora packaging guidelines already say that this SHOULD be the case, FWIW. > What I would like to see though is for such a PKCS#11 Engine to be > part of OpenSSL proper, Yeah yeah, but not for 1.1. Some of us are hoping to fix that for 1.2 (and not necessarily as an ENGINE but more by having PKCS#11 support properly integrated). We have agreement from copyright-holders of most of the existing engine (and libp11, where most of the *functionality* lies) to relicense it and include it in OpenSSL. -- David Woodhouse Open Source Technology Centre David.Woodhouse at intel.com Intel Corporation -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5691 bytes Desc: not available URL: From rt at openssl.org Mon Feb 29 14:36:06 2016 From: rt at openssl.org (Billy Brumley via RT) Date: Mon, 29 Feb 2016 14:36:06 +0000 Subject: [openssl-dev] [openssl.org #4357] NIST SP800-56A co-factor ECDH KATs In-Reply-To: References: Message-ID: Didn't see any co-factor ECDH tests, so here's a PR: https://github.com/openssl/openssl/pull/763 KATs parsed from here: http://csrc.nist.gov/groups/STM/cavp/documents/components/ecccdhtestvectors.zip BBB -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4357 Please log in as guest with password guest if prompted From michel.sales at free.fr Mon Feb 29 14:51:02 2016 From: michel.sales at free.fr (Michel) Date: Mon, 29 Feb 2016 15:51:02 +0100 Subject: [openssl-dev] req command crashes using config file containing passwords Message-ID: <002101d17300$9c879320$d596b960$@sales@free.fr> Hi, I have some tests scripts that were working well with 1.0.2 and are crashing using v1.1 (Windows 7). They are failing when calling the 'req' command with a configure script containing input_password/output password : openssl req -new -batch -key RootCA.key -out RootCA.csr -config RootCA.cnf "Access violation reading location . "(when freeing output password) here under the call stack : openssl.exe!CheckBytes(unsigned char * pb, unsigned char bCheck, unsigned int nSize) Line 1696 C++ openssl.exe!_free_dbg_nolock(void * pUserData, int nBlockUse) Line 1300 C++ openssl.exe!_free_dbg(void * pUserData, int nBlockUse) Line 1265 C++ openssl.exe!free(void * pUserData) Line 49 C++ openssl.exe!CRYPTO_free(void * str, const char * file, int line) Line 226 C openssl.exe!req_main(int argc, char * * argv) Line 866 C openssl.exe!do_cmd(lhash_st_FUNCTION * prog, int argc, char * * argv) Line 620 C openssl.exe!main(int argc, char * * argv) Line 324 C Let me know if I can help more. Regards, Michel. -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Mon Feb 29 18:00:25 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 29 Feb 2016 18:00:25 +0000 Subject: [openssl-dev] req command crashes using config file containing passwords In-Reply-To: <002101d17300$9c879320$d596b960$@sales@free.fr> References: <002101d17300$9c879320$d596b960$@sales@free.fr> Message-ID: <20160229180025.GL12869@mournblade.imrryr.org> On Mon, Feb 29, 2016 at 03:51:02PM +0100, Michel wrote: > They are failing when calling the 'req' command with a configure script > containing input_password/output password : Please try the patch below: -- Viktor. diff --git a/apps/req.c b/apps/req.c index 693acc2..b128fa8 100644 --- a/apps/req.c +++ b/apps/req.c @@ -198,7 +198,9 @@ int req_main(int argc, char **argv) char *extensions = NULL, *infile = NULL; char *outfile = NULL, *keyfile = NULL, *inrand = NULL; char *keyalgstr = NULL, *p, *prog, *passargin = NULL, *passargout = NULL; - char *passin = NULL, *passout = NULL, *req_exts = NULL, *subj = NULL; + char *passin = NULL, *passout = NULL; + char *nofree_passin = NULL, *nofree_passout = NULL; + char *req_exts = NULL, *subj = NULL; char *template = default_config_file, *keyout = NULL; const char *keyalg = NULL; OPTION_CHOICE o; @@ -436,15 +438,17 @@ int req_main(int argc, char **argv) } } - if (!passin) { - passin = NCONF_get_string(req_conf, SECTION, "input_password"); - if (!passin) + if (passin == NULL) { + passin = nofree_passin = + NCONF_get_string(req_conf, SECTION, "input_password"); + if (passin == NULL) ERR_clear_error(); } - if (!passout) { - passout = NCONF_get_string(req_conf, SECTION, "output_password"); - if (!passout) + if (passout == NULL) { + passout = nofree_passout = + NCONF_get_string(req_conf, SECTION, "output_password"); + if (passout == NULL) ERR_clear_error(); } @@ -862,8 +866,10 @@ int req_main(int argc, char **argv) X509_REQ_free(req); X509_free(x509ss); ASN1_INTEGER_free(serial); - OPENSSL_free(passin); - OPENSSL_free(passout); + if (passin != nofree_passin) + OPENSSL_free(passin); + if (passout != nofree_passout) + OPENSSL_free(passout); OBJ_cleanup(); return (ret); } From rt at openssl.org Mon Feb 29 18:45:04 2016 From: rt at openssl.org (esr@thyrsus.com via RT) Date: Mon, 29 Feb 2016 18:45:04 +0000 Subject: [openssl-dev] [openssl.org #4358] Problems in ocsp.1ssl In-Reply-To: <20160229175530.727EB13A0E65@snark.thyrsus.com> References: <20160229175530.727EB13A0E65@snark.thyrsus.com> Message-ID: This is automatically generated email about markup problems in a man page for which you appear to be responsible. If you are not the right person or list, please tell me so I can correct my database. See http://catb.org/~esr/doclifter/bugs.html for details on how and why these patches were generated. Feel free to email me with any questions. Note: These patches do not change the modification date of any manual page. You may wish to do that by hand. I apologize if this message seems spammy or impersonal. The volume of markup bugs I am tracking is over five hundred - there is no real alternative to generating bugmail from a database and template. -- Eric S. Raymond -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4358 Please log in as guest with password guest if prompted -------------- next part -------------- Problems with ocsp.1ssl: Unbalanced group in command synopis. You probably forgot to open or close a [ ] or { } group properly. --- ocsp.1ssl-unpatched 2016-02-29 12:48:13.618729272 -0500 +++ ocsp.1ssl 2016-02-29 12:50:05.234488918 -0500 @@ -165,7 +165,7 @@ [\fB\-path\fR] [\fB\-CApath dir\fR] [\fB\-CAfile file\fR] -[\fB\-no_alt_chains\fR]] +[\fB\-no_alt_chains\fR] [\fB\-VAfile file\fR] [\fB\-validity_period n\fR] [\fB\-status_age n\fR] From michel.sales at free.fr Mon Feb 29 20:13:36 2016 From: michel.sales at free.fr (Michel) Date: Mon, 29 Feb 2016 21:13:36 +0100 Subject: [openssl-dev] req command crashes using config file containing passwords In-Reply-To: <20160229180025.GL12869@mournblade.imrryr.org> References: <002101d17300$9c879320$d596b960$@sales@free.fr> <20160229180025.GL12869@mournblade.imrryr.org> Message-ID: <004101d1732d$ac1b7c20$04527460$@sales@free.fr> Hi Viktor, With your patch applied, I can confirm that the 'req' command now run just fine. Thanks, Michel. -----Message d'origine----- De?: openssl-dev [mailto:openssl-dev-bounces at openssl.org] De la part de Viktor Dukhovni Envoy??: lundi 29 f?vrier 2016 19:00 ??: openssl-dev at openssl.org Objet?: Re: [openssl-dev] req command crashes using config file containing passwords On Mon, Feb 29, 2016 at 03:51:02PM +0100, Michel wrote: > They are failing when calling the 'req' command with a configure script > containing input_password/output password : Please try the patch below: -- Viktor. From rt at openssl.org Mon Feb 29 21:34:38 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Mon, 29 Feb 2016 21:34:38 +0000 Subject: [openssl-dev] [openssl.org #4359] Duplicate n2l, etc., macros In-Reply-To: <798b60dd1b1541598eefb7daa8f452d6@usma1ex-dag1mb1.msg.corp.akamai.com> References: <798b60dd1b1541598eefb7daa8f452d6@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: >From discussion in GH 664 with Rob Percival. The issue of repeatd macros came up. Thanks. I've just looked at merging all of the various definitions of those macros and it's not pretty - not all of the definitions match. There's a bug in some of the definitions in ssl_locl.h ('c' is not bracketed) and some of the defintions in idea_lcl.h appear to have blatantly dishonest comments above them: /* NOTE - c is not incremented as per n2l */ #define n2ln(c,l1,l2,n) { \ c+=n; \ ... -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4359 Please log in as guest with password guest if prompted From rt at openssl.org Mon Feb 29 21:45:29 2016 From: rt at openssl.org (Roumen Petrov via RT) Date: Mon, 29 Feb 2016 21:45:29 +0000 Subject: [openssl-dev] [openssl.org #2363] bug: memory allocated by DH_new() may never be free()ed In-Reply-To: <56D4BBF0.4090107@roumenpetrov.info> References: <56D4BBF0.4090107@roumenpetrov.info> Message-ID: It is expected DH_free(DH_new()); to leaks memory. Usually XXX method initialize "extra data". Sample code is without code that clear library, at least CRYPTO_cleanup_all_ex_data is missing. Roumen -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2363 Please log in as guest with password guest if prompted From rsalz at akamai.com Mon Feb 29 21:58:52 2016 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 29 Feb 2016 21:58:52 +0000 Subject: [openssl-dev] [openssl.org #2363] bug: memory allocated by DH_new() may never be free()ed In-Reply-To: References: <56D4BBF0.4090107@roumenpetrov.info> Message-ID: <10b7c5a3e3a844f282d5942c0f2ee97f@usma1ex-dag1mb1.msg.corp.akamai.com> Roumen, you're right. Does the leak go away when the cleanup_all_ex_data is called? From rt at openssl.org Mon Feb 29 21:58:55 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Mon, 29 Feb 2016 21:58:55 +0000 Subject: [openssl-dev] [openssl.org #2363] bug: memory allocated by DH_new() may never be free()ed In-Reply-To: <10b7c5a3e3a844f282d5942c0f2ee97f@usma1ex-dag1mb1.msg.corp.akamai.com> References: <56D4BBF0.4090107@roumenpetrov.info> <10b7c5a3e3a844f282d5942c0f2ee97f@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: Roumen, you're right. Does the leak go away when the cleanup_all_ex_data is called? -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2363 Please log in as guest with password guest if prompted From rt at openssl.org Wed Feb 17 13:49:23 2016 From: rt at openssl.org (Mario Scalabrino via RT) Date: Wed, 17 Feb 2016 13:49:23 -0000 Subject: [openssl-dev] [openssl.org #4276] AutoReply: Possible bug - ts -verify -digest, error:ts_rsp_verify.c:291: In-Reply-To: <56C47A52.6090404@andifyou.com> References: <56AA3226.3060801@andifyou.com> <56C47A52.6090404@andifyou.com> Message-ID: Hello Openssl, is there any update? Do you need more information? Thank you Cheers Mario Scalabrino Untitled Document *Certify Doc * *MARIO SCALABRINO * Founder & CEO (+34) 680 128 282 mario.scalabrino at andifyou.com www.certifydoc.eu Linkedin Facebook Twitter On 28/01/2016 17:16, The default queue via RT wrote: > Greetings, > > This message has been automatically generated in response to the > creation of a trouble ticket regarding: > "Possible bug - ts -verify -digest, error:ts_rsp_verify.c:291:", > a summary of which appears below. > > There is no need to reply to this message right now. Your ticket has been > assigned an ID of [openssl.org #4276]. > > Please include the string: > > [openssl.org #4276] > > in the subject line of all future correspondence about this issue. To do so, > you may reply to this message. > > Thank you, > rt at openssl.org > > ------------------------------------------------------------------------- > > Good afternoon Openssl, > > please forward this email to whomever it may concern. > > I receive an error and the Timestamping provider suspects it is a > Openssl bug. > Could you please check if it is openssl or the certificate? > > > This is when the error occurr > /openssl ts -verify -digest > e16db7d30581e44a5540f19553852b5a4e4e26f9adc365cc846f94038ee33025 -in > /tmp/namirial.tsr -CAfile /tmp/NamirialCATSA.pem > (result:) > ************* > *Verification: FAILED** > **140236013643424:error:2F067065:time stamp > routines:TS_CHECK_SIGNING_CERTS:ess signing certificate > error:ts_rsp_verify.c:291:*/ > > > I attach a complete reproduction scenario. I don't know if it is a > problem of this TSA certificate or in Openssl due to sha256 digest, > please help. > > > (in the curl command I cannot provide you the username and password, it > is a paid service) > > Attached are the files resulting from the below commands in sequence and > the certificate of the TSA, but I'm sure you can check yourself the last > command where the error occur and advice. > > you can copy and paste the commands below if you're in Linux Ubuntu and > the files are in the /tmp/ folder > > *Reproduction scenario:* > > OS: Ubuntu 14.04 > Openssl version: OpenSSL 1.0.1f 6 Jan 2014 > > > > Generate tsq: > openssl ts -query -digest > e16db7d30581e44a5540f19553852b5a4e4e26f9adc365cc846f94038ee33025 -sha256 > -cert -out /tmp/namirial.tsq > > Readable tsq: > openssl ts -query -in /tmp/namirial.tsq -text > (result:) > ************ > Hash Algorithm: sha256 > Message data: > 0000 - e1 6d b7 d3 05 81 e4 4a-55 40 f1 95 53 85 2b 5a .m.....JU at ..S.+Z > 0010 - 4e 4e 26 f9 ad c3 65 cc-84 6f 94 03 8e e3 30 25 NN&...e..o....0% > Policy OID: unspecified > Nonce: 0x8CA62B5766A29A8B > Certificate required: yes > Extensions: > **************** > > > Generate tsr (using curl) > curl -u xxxxxxx:yyyyyy -s --data-binary @/tmp/namirial.tsq -H > 'Content-Type: application/timestamp-query' -H 'Pragma: no-cache' -H > 'Accept: application/timestamp-reply' --output /tmp/namirial.tsr > http://timestamp.firmacerta.it > > Readable tsr > openssl ts -reply -in /tmp/namirial.tsr -out /tmp/readable_tsr.txt -text > > (result:) > ****************** > Status info: > Status: Granted. > Status description: Operation Okay > Failure info: unspecified > > TST info: > Version: 1 > Policy OID: 1.3.6.1.4.1.36203.2.1 > Hash Algorithm: sha256 > Message data: > 0000 - e1 6d b7 d3 05 81 e4 4a-55 40 f1 95 53 85 2b 5a .m.....JU at ..S.+Z > 0010 - 4e 4e 26 f9 ad c3 65 cc-84 6f 94 03 8e e3 30 25 NN&...e..o....0% > Serial number: 0x1947FD96B97A42DE > Time stamp: Jan 28 14:56:16 2016 GMT > Accuracy: unspecified seconds, 0x01F4 millis, unspecified micros > Ordering: no > Nonce: 0x8CA62B5766A29A8B > TSA: unspecified > Extensions: > ************************ > > > Verify > openssl ts -verify -digest > e16db7d30581e44a5540f19553852b5a4e4e26f9adc365cc846f94038ee33025 -in > /tmp/namirial.tsr -CAfile /tmp/NamirialCATSA.pem > (result:) > ************* > *Verification: FAILED** > **140236013643424:error:2F067065:time stamp > routines:TS_CHECK_SIGNING_CERTS:ess signing certificate > error:ts_rsp_verify.c:291:* > *************** > > > -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4276 Please log in as guest with password guest if prompted -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 03-IMAGOTIPO_GRADIENT-150x150.png Type: image/png Size: 6492 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: linea.jpg Type: image/jpeg Size: 8556 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: icon_phone.jpg Type: image/jpeg Size: 11081 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: icon_mail.jpg Type: image/jpeg Size: 10866 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: icon_web.jpg Type: image/jpeg Size: 11458 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: linkedin_icon.jpg Type: image/jpeg Size: 10874 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: facebook_icon.jpg Type: image/jpeg Size: 10718 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: twitter_icon.jpg Type: image/jpeg Size: 10856 bytes Desc: not available URL: From doctor at doctor.nl2k.ab.ca Sun Feb 21 14:10:12 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Sun, 21 Feb 2016 14:10:12 -0000 Subject: [openssl-dev] Still seeing this in openssl-SNAP-20160221 Re: Openssl SNAP 20160220 issues In-Reply-To: <20160220134722.GA10611@doctor.nl2k.ab.ca> References: <20160220134722.GA10611@doctor.nl2k.ab.ca> Message-ID: <20160221140919.GA18764@doctor.nl2k.ab.ca> On Sat, Feb 20, 2016 at 06:47:22AM -0700, The Doctor wrote: > Major shop stopper > > ../test/recipes/30-test_pbelu.t ........... > 1..1 > ./pbelutest: can't load library 'ssl.so.1.1' > not ok 1 - running pbelutest > > # Failed test 'running pbelutest' > # at ../test/testlib/OpenSSL/Test/Simple.pm line 70. > # Looks like you failed 1 test of 1. > Dubious, test returned 1 (wstat 256, 0x100) > Failed 1/1 subtests > ../test/recipes/40-test_rehash.t .......... ../apps/openssl: can't load library 'ssl.so.1.1' > > 1..0 # SKIP test_rehash is not available on this platform > skipped: test_rehash is not available on this platform > ../test/recipes/70-test_clienthello.t ..... > 1..1 > ./clienthellotest: can't load library 'ssl.so.1.1' > not ok 1 - running clienthellotest > > # Failed test 'running clienthellotest' > # at ../test/recipes/70-test_clienthello.t line 13. > # Looks like you failed 1 test of 1. > Dubious, test returned 1 (wstat 256, 0x100) > Failed 1/1 subtests > ../test/recipes/70-test_packet.t .......... > 1..1 > ./packettest: can't load library 'ssl.so.1.1' > not ok 1 - running packettest > > # Failed test 'running packettest' > # at ../test/testlib/OpenSSL/Test/Simple.pm line 70. > # Looks like you failed 1 test of 1. > Dubious, test returned 1 (wstat 256, 0x100) > Failed 1/1 subtests > ../test/recipes/70-test_sslcertstatus.t ... > 1..1 > Proxy started on port 4453 > ../apps/openssl: can't load library 'ssl.so.1.1' > ../apps/openssl: can't load library 'ssl.so.1.1' > > -- > Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca > God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! > http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism > Broadcasting the truth for 25 years > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev And again today Script started on Sun Feb 21 05:56:21 2016 ns2.nl2k.ab.ca//usr/source/openssl-SNAP-20160221$ HARNESS_VERBOSE=yes make test ns2.nl2k.ab.ca//usr/source/openssl-SNAP-20160221$ HARNESS_VERBOSE=yes make test {cut irrelevant recoding out] TOP=.. PERL=/usr/bin/perl5 /usr/bin/perl5 run_tests.pl alltests ../test/recipes/01-test_ordinals.t ........ 1..2 ok 1 - Test libeay.num ok 2 - Test ssleay.num ok ../test/recipes/05-test_bf.t .............. 1..1 ./bftest: can't load library 'ssl.so.1.1' not ok 1 - running bftest # Failed test 'running bftest' # at ../test/testlib/OpenSSL/Test/Simple.pm line 70. # Looks like you failed 1 test of 1. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/05-test_cast.t ............ 1..1 ./casttest: can't load library 'ssl.so.1.1' not ok 1 - running casttest # Failed test 'running casttest' # at ../test/testlib/OpenSSL/Test/Simple.pm line 70. # Looks like you failed 1 test of 1. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/05-test_des.t ............. 1..1 ./destest: can't load library 'ssl.so.1.1' not ok 1 - running destest # Failed test 'running destest' # at ../test/testlib/OpenSSL/Test/Simple.pm line 70. # Looks like you failed 1 test of 1. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/05-test_hmac.t ............ 1..1 ./hmactest: can't load library 'ssl.so.1.1' not ok 1 - running hmactest # Failed test 'running hmactest' # at ../test/testlib/OpenSSL/Test/Simple.pm line 70. # Looks like you failed 1 test of 1. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/05-test_idea.t ............ 1..1 ./ideatest: can't load library 'ssl.so.1.1' not ok 1 - running ideatest # Failed test 'running ideatest' # at ../test/testlib/OpenSSL/Test/Simple.pm line 70. # Looks like you failed 1 test of 1. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/05-test_md2.t ............. 1..0 # SKIP md2 is not supported by this OpenSSL build skipped: md2 is not supported by this OpenSSL build ../test/recipes/05-test_md4.t ............. 1..1 ./md4test: can't load library 'ssl.so.1.1' not ok 1 - running md4test # Failed test 'running md4test' # at ../test/testlib/OpenSSL/Test/Simple.pm line 70. # Looks like you failed 1 test of 1. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/05-test_md5.t ............. 1..1 ./md5test: can't load library 'ssl.so.1.1' not ok 1 - running md5test # Failed test 'running md5test' # at ../test/testlib/OpenSSL/Test/Simple.pm line 70. # Looks like you failed 1 test of 1. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/05-test_mdc2.t ............ 1..1 ./mdc2test: can't load library 'ssl.so.1.1' not ok 1 - running mdc2test # Failed test 'running mdc2test' # at ../test/testlib/OpenSSL/Test/Simple.pm line 70. # Looks like you failed 1 test of 1. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/05-test_rand.t ............ 1..1 ./randtest: can't load library 'ssl.so.1.1' not ok 1 - running randtest # Failed test 'running randtest' # at ../test/testlib/OpenSSL/Test/Simple.pm line 70. # Looks like you failed 1 test of 1. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/05-test_rc2.t ............. 1..1 ./rc2test: can't load library 'ssl.so.1.1' not ok 1 - running rc2test # Failed test 'running rc2test' # at ../test/testlib/OpenSSL/Test/Simple.pm line 70. # Looks like you failed 1 test of 1. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/05-test_rc4.t ............. 1..1 ./rc4test: can't load library 'ssl.so.1.1' not ok 1 - running rc4test # Failed test 'running rc4test' # at ../test/testlib/OpenSSL/Test/Simple.pm line 70. # Looks like you failed 1 test of 1. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/05-test_rc5.t ............. 1..1 ./rc5test: can't load library 'ssl.so.1.1' not ok 1 - running rc5test # Failed test 'running rc5test' # at ../test/testlib/OpenSSL/Test/Simple.pm line 70. # Looks like you failed 1 test of 1. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/05-test_rmd.t ............. 1..1 ./rmdtest: can't load library 'ssl.so.1.1' not ok 1 - running rmdtest # Failed test 'running rmdtest' # at ../test/testlib/OpenSSL/Test/Simple.pm line 70. # Looks like you failed 1 test of 1. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/05-test_sha1.t ............ 1..1 ./sha1test: can't load library 'ssl.so.1.1' not ok 1 - running sha1test # Failed test 'running sha1test' # at ../test/testlib/OpenSSL/Test/Simple.pm line 70. # Looks like you failed 1 test of 1. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/05-test_sha256.t .......... 1..1 ./sha256t: can't load library 'ssl.so.1.1' not ok 1 - running sha256t # Failed test 'running sha256t' # at ../test/testlib/OpenSSL/Test/Simple.pm line 70. # Looks like you failed 1 test of 1. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/05-test_sha512.t .......... 1..1 ./sha512t: can't load library 'ssl.so.1.1' not ok 1 - running sha512t # Failed test 'running sha512t' # at ../test/testlib/OpenSSL/Test/Simple.pm line 70. # Looks like you failed 1 test of 1. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/05-test_wp.t .............. 1..1 ./wp_test: can't load library 'ssl.so.1.1' not ok 1 - running wp_test # Failed test 'running wp_test' # at ../test/testlib/OpenSSL/Test/Simple.pm line 70. # Looks like you failed 1 test of 1. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/10-test_bn.t .............. 1..3 ok 1 - require '../test/recipes/bc.pl'; ./bntest: can't load library 'ssl.so.1.1' not ok 2 - initialize # Failed test 'initialize' # at ../test/recipes/10-test_bn.t line 17. ok 3 # skip Initializing failed, skipping # Looks like you failed 1 test of 3. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/3 subtests (less 1 skipped subtest: 1 okay) ../test/recipes/10-test_exp.t ............. 1..1 ./exptest: can't load library 'ssl.so.1.1' not ok 1 - running exptest # Failed test 'running exptest' # at ../test/testlib/OpenSSL/Test/Simple.pm line 70. # Looks like you failed 1 test of 1. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/15-test_dh.t .............. 1..1 ./dhtest: can't load library 'ssl.so.1.1' not ok 1 - running dhtest # Failed test 'running dhtest' # at ../test/testlib/OpenSSL/Test/Simple.pm line 70. # Looks like you failed 1 test of 1. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/15-test_dsa.t ............. 1..6 ok 1 - require '../test/recipes/tconversion.pl'; ./dsatest: can't load library 'ssl.so.1.1' not ok 2 - running dsatest # Failed test 'running dsatest' # at ../test/recipes/15-test_dsa.t line 16. ./dsatest: can't load library 'ssl.so.1.1' not ok 3 - running dsatest -app2_1 # Failed test 'running dsatest -app2_1' # at ../test/recipes/15-test_dsa.t line 17. 1..10 ok 1 - initializing ../apps/openssl: can't load library 'ssl.so.1.1' not ok 2 - p -> d # Failed test 'p -> d' # at ../test/recipes/tconversion.pl line 53. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 3 - p -> p # Failed test 'p -> p' # at ../test/recipes/tconversion.pl line 53. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 4 - d -> d # Failed test 'd -> d' # at ../test/recipes/tconversion.pl line 63. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 5 - p -> d # Failed test 'p -> d' # at ../test/recipes/tconversion.pl line 63. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 6 - d -> p # Failed test 'd -> p' # at ../test/recipes/tconversion.pl line 63. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 7 - p -> p # Failed test 'p -> p' # at ../test/recipes/tconversion.pl line 63. not ok 8 - comparing orig to p # Failed test 'comparing orig to p' # at ../test/recipes/tconversion.pl line 72. # got: '-1' # expected: '0' not ok 9 - comparing p to dp # Failed test 'comparing p to dp' # at ../test/recipes/tconversion.pl line 80. # got: '-1' # expected: '0' not ok 10 - comparing p to pp # Failed test 'comparing p to pp' # at ../test/recipes/tconversion.pl line 80. # got: '-1' # expected: '0' # Looks like you failed 9 tests of 10. not ok 4 - dsa conversions -- private key # Failed test 'dsa conversions -- private key' # at ../test/recipes/15-test_dsa.t line 25. 1..10 ../apps/openssl: can't load library 'ssl.so.1.1' not ok 1 - initializing # Failed test 'initializing' # at ../test/recipes/tconversion.pl line 39. ok 2 # skip Not initialized, skipping... ok 3 # skip Not initialized, skipping... ok 4 # skip Not initialized, skipping... ok 5 # skip Not initialized, skipping... ok 6 # skip Not initialized, skipping... ok 7 # skip Not initialized, skipping... ok 8 # skip Not initialized, skipping... ok 9 # skip Not initialized, skipping... ok 10 # skip Not initialized, skipping... ok 11 # skip Not initialized, skipping... ok 12 # skip Not initialized, skipping... ok 13 # skip Not initialized, skipping... ok 14 # skip Not initialized, skipping... ok 15 # skip Not initialized, skipping... ok 16 # skip Not initialized, skipping... ok 17 # skip Not initialized, skipping... ok 18 # skip Not initialized, skipping... ok 19 # skip Not initialized, skipping... ok 20 # skip Not initialized, skipping... ok 21 # skip Not initialized, skipping... ok 22 # skip Not initialized, skipping... ok 23 # skip Not initialized, skipping... not ok 5 - dsa conversions -- private key PKCS\#8 1..10 # Trying to copy ../test/testdsa.pem to dsa-fff.p : Illegal seek # Looks like you planned 10 tests but ran 23. # Looks like you failed 1 test of 23 run. # Failed test 'dsa conversions -- private key PKCS\#8' # at ../test/recipes/15-test_dsa.t line 28. ok 1 - initializing ../apps/openssl: can't load library 'ssl.so.1.1' not ok 2 - p -> d # Failed test 'p -> d' # at ../test/recipes/tconversion.pl line 53. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 3 - p -> p # Failed test 'p -> p' # at ../test/recipes/tconversion.pl line 53. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 4 - d -> d # Failed test 'd -> d' # at ../test/recipes/tconversion.pl line 63. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 5 - p -> d # Failed test 'p -> d' # at ../test/recipes/tconversion.pl line 63. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 6 - d -> p # Failed test 'd -> p' # at ../test/recipes/tconversion.pl line 63. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 7 - p -> p # Failed test 'p -> p' # at ../test/recipes/tconversion.pl line 63. not ok 8 - comparing orig to p # Failed test 'comparing orig to p' # at ../test/recipes/tconversion.pl line 72. # got: '-1' # expected: '0' not ok 9 - comparing p to dp # Failed test 'comparing p to dp' # at ../test/recipes/tconversion.pl line 80. # got: '-1' # expected: '0' not ok 10 - comparing p to pp # Failed test 'comparing p to pp' # at ../test/recipes/tconversion.pl line 80. # got: '-1' # expected: '0' # Looks like you failed 9 tests of 10. not ok 6 - dsa conversions -- public key # Failed test 'dsa conversions -- public key' # at ../test/recipes/15-test_dsa.t line 32. # Looks like you failed 5 tests of 6. Dubious, test returned 5 (wstat 1280, 0x500) Failed 5/6 subtests ../test/recipes/15-test_ec.t .............. 1..5 ok 1 - require '../test/recipes/tconversion.pl'; ./ectest: can't load library 'ssl.so.1.1' not ok 2 - running ectest # Failed test 'running ectest' # at ../test/recipes/15-test_ec.t line 16. 1..10 ok 1 - initializing ../apps/openssl: can't load library 'ssl.so.1.1' not ok 2 - p -> d # Failed test 'p -> d' # at ../test/recipes/tconversion.pl line 53. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 3 - p -> p # Failed test 'p -> p' # at ../test/recipes/tconversion.pl line 53. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 4 - d -> d # Failed test 'd -> d' # at ../test/recipes/tconversion.pl line 63. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 5 - p -> d # Failed test 'p -> d' # at ../test/recipes/tconversion.pl line 63. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 6 - d -> p # Failed test 'd -> p' # at ../test/recipes/tconversion.pl line 63. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 7 - p -> p # Failed test 'p -> p' # at ../test/recipes/tconversion.pl line 63. not ok 8 - comparing orig to p # Failed test 'comparing orig to p' # at ../test/recipes/tconversion.pl line 72. # got: '-1' # expected: '0' not ok 9 - comparing p to dp # Failed test 'comparing p to dp' # at ../test/recipes/tconversion.pl line 80. # got: '-1' # expected: '0' not ok 10 - comparing p to pp # Failed test 'comparing p to pp' # at ../test/recipes/tconversion.pl line 80. # got: '-1' # expected: '0' # Looks like you failed 9 tests of 10. not ok 3 - ec conversions -- private key # Failed test 'ec conversions -- private key' # at ../test/recipes/15-test_ec.t line 24. 1..10 ../apps/openssl: can't load library 'ssl.so.1.1' not ok 1 - initializing # Failed test 'initializing' # at ../test/recipes/tconversion.pl line 39. # Trying to copy ../test/testec-p256.pem to ec-fff.p : Illegal seek ok 2 # skip Not initialized, skipping... ok 3 # skip Not initialized, skipping... ok 4 # skip Not initialized, skipping... ok 5 # skip Not initialized, skipping... ok 6 # skip Not initialized, skipping... ok 7 # skip Not initialized, skipping... ok 8 # skip Not initialized, skipping... ok 9 # skip Not initialized, skipping... ok 10 # skip Not initialized, skipping... ok 11 # skip Not initialized, skipping... ok 12 # skip Not initialized, skipping... ok 13 # skip Not initialized, skipping... ok 14 # skip Not initialized, skipping... ok 15 # skip Not initialized, skipping... ok 16 # skip Not initialized, skipping... ok 17 # skip Not initialized, skipping... ok 18 # skip Not initialized, skipping... ok 19 # skip Not initialized, skipping... ok 20 # skip Not initialized, skipping... ok 21 # skip Not initialized, skipping... ok 22 # skip Not initialized, skipping... ok 23 # skip Not initialized, skipping... not ok 4 - ec conversions -- private key PKCS\#8 1..10 # Looks like you planned 10 tests but ran 23. # Looks like you failed 1 test of 23 run. # Failed test 'ec conversions -- private key PKCS\#8' # at ../test/recipes/15-test_ec.t line 27. ok 1 - initializing ../apps/openssl: can't load library 'ssl.so.1.1' not ok 2 - p -> d # Failed test 'p -> d' # at ../test/recipes/tconversion.pl line 53. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 3 - p -> p # Failed test 'p -> p' # at ../test/recipes/tconversion.pl line 53. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 4 - d -> d # Failed test 'd -> d' # at ../test/recipes/tconversion.pl line 63. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 5 - p -> d # Failed test 'p -> d' # at ../test/recipes/tconversion.pl line 63. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 6 - d -> p # Failed test 'd -> p' # at ../test/recipes/tconversion.pl line 63. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 7 - p -> p # Failed test 'p -> p' # at ../test/recipes/tconversion.pl line 63. not ok 8 - comparing orig to p # Failed test 'comparing orig to p' # at ../test/recipes/tconversion.pl line 72. # got: '-1' # expected: '0' not ok 9 - comparing p to dp # Failed test 'comparing p to dp' # at ../test/recipes/tconversion.pl line 80. # got: '-1' # expected: '0' not ok 10 - comparing p to pp # Failed test 'comparing p to pp' # at ../test/recipes/tconversion.pl line 80. # got: '-1' # expected: '0' # Looks like you failed 9 tests of 10. not ok 5 - ec conversions -- public key # Failed test 'ec conversions -- public key' # at ../test/recipes/15-test_ec.t line 30. # Looks like you failed 4 tests of 5. Dubious, test returned 4 (wstat 1024, 0x400) Failed 4/5 subtests ../test/recipes/15-test_ecdh.t ............ 1..1 ./ecdhtest: can't load library 'ssl.so.1.1' not ok 1 - running ecdhtest # Failed test 'running ecdhtest' # at ../test/testlib/OpenSSL/Test/Simple.pm line 70. # Looks like you failed 1 test of 1. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/15-test_ecdsa.t ........... 1..1 ./ecdsatest: can't load library 'ssl.so.1.1' not ok 1 - running ecdsatest # Failed test 'running ecdsatest' # at ../test/testlib/OpenSSL/Test/Simple.pm line 70. # Looks like you failed 1 test of 1. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/15-test_rsa.t ............. 1..5 ok 1 - require '../test/recipes/tconversion.pl'; ./rsa_test: can't load library 'ssl.so.1.1' not ok 2 - running rsatest # Failed test 'running rsatest' # at ../test/recipes/15-test_rsa.t line 16. 1..10 ok 1 - initializing ../apps/openssl: can't load library 'ssl.so.1.1' not ok 2 - p -> d # Failed test 'p -> d' # at ../test/recipes/tconversion.pl line 53. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 3 - p -> p # Failed test 'p -> p' # at ../test/recipes/tconversion.pl line 53. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 4 - d -> d # Failed test 'd -> d' # at ../test/recipes/tconversion.pl line 63. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 5 - p -> d # Failed test 'p -> d' # at ../test/recipes/tconversion.pl line 63. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 6 - d -> p # Failed test 'd -> p' # at ../test/recipes/tconversion.pl line 63. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 7 - p -> p # Failed test 'p -> p' # at ../test/recipes/tconversion.pl line 63. not ok 8 - comparing orig to p # Failed test 'comparing orig to p' # at ../test/recipes/tconversion.pl line 72. # got: '-1' # expected: '0' not ok 9 - comparing p to dp # Failed test 'comparing p to dp' # at ../test/recipes/tconversion.pl line 80. # got: '-1' # expected: '0' not ok 10 - comparing p to pp # Failed test 'comparing p to pp' # at ../test/recipes/tconversion.pl line 80. # got: '-1' # expected: '0' # Looks like you failed 9 tests of 10. not ok 3 - rsa conversions -- private key # Failed test 'rsa conversions -- private key' # at ../test/recipes/15-test_rsa.t line 24. 1..10 ../apps/openssl: can't load library 'ssl.so.1.1' not ok 1 - initializing # Failed test 'initializing' # at ../test/recipes/tconversion.pl line 39. # Trying to copy ../test/testrsa.pem to rsa-fff.p : Illegal seek ok 2 # skip Not initialized, skipping... ok 3 # skip Not initialized, skipping... ok 4 # skip Not initialized, skipping... ok 5 # skip Not initialized, skipping... ok 6 # skip Not initialized, skipping... ok 7 # skip Not initialized, skipping... ok 8 # skip Not initialized, skipping... ok 9 # skip Not initialized, skipping... ok 10 # skip Not initialized, skipping... ok 11 # skip Not initialized, skipping... ok 12 # skip Not initialized, skipping... ok 13 # skip Not initialized, skipping... ok 14 # skip Not initialized, skipping... ok 15 # skip Not initialized, skipping... ok 16 # skip Not initialized, skipping... ok 17 # skip Not initialized, skipping... ok 18 # skip Not initialized, skipping... ok 19 # skip Not initialized, skipping... ok 20 # skip Not initialized, skipping... ok 21 # skip Not initialized, skipping... ok 22 # skip Not initialized, skipping... ok 23 # skip Not initialized, skipping... not ok 4 - rsa conversions -- private key PKCS\#8 1..10 # Looks like you planned 10 tests but ran 23. # Looks like you failed 1 test of 23 run. # Failed test 'rsa conversions -- private key PKCS\#8' # at ../test/recipes/15-test_rsa.t line 27. ok 1 - initializing ../apps/openssl: can't load library 'ssl.so.1.1' not ok 2 - p -> d # Failed test 'p -> d' # at ../test/recipes/tconversion.pl line 53. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 3 - p -> p # Failed test 'p -> p' # at ../test/recipes/tconversion.pl line 53. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 4 - d -> d # Failed test 'd -> d' # at ../test/recipes/tconversion.pl line 63. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 5 - p -> d # Failed test 'p -> d' # at ../test/recipes/tconversion.pl line 63. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 6 - d -> p # Failed test 'd -> p' # at ../test/recipes/tconversion.pl line 63. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 7 - p -> p # Failed test 'p -> p' # at ../test/recipes/tconversion.pl line 63. not ok 8 - comparing orig to p # Failed test 'comparing orig to p' # at ../test/recipes/tconversion.pl line 72. # got: '-1' # expected: '0' not ok 9 - comparing p to dp # Failed test 'comparing p to dp' # at ../test/recipes/tconversion.pl line 80. # got: '-1' # expected: '0' not ok 10 - comparing p to pp # Failed test 'comparing p to pp' # at ../test/recipes/tconversion.pl line 80. # got: '-1' # expected: '0' # Looks like you failed 9 tests of 10. not ok 5 - rsa conversions -- public key # Failed test 'rsa conversions -- public key' # at ../test/recipes/15-test_rsa.t line 31. # Looks like you failed 4 tests of 5. Dubious, test returned 4 (wstat 1024, 0x400) Failed 4/5 subtests ../test/recipes/20-test_enc.t ............. ../apps/openssl: can't load library 'ssl.so.1.1' 1..1 ok 1 ok ../test/recipes/25-test_crl.t ............. 1..2 ok 1 - require '../test/recipes/tconversion.pl'; 1..10 ok 1 - initializing ../apps/openssl: can't load library 'ssl.so.1.1' not ok 2 - p -> d # Failed test 'p -> d' # at ../test/recipes/tconversion.pl line 53. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 3 - p -> p # Failed test 'p -> p' # at ../test/recipes/tconversion.pl line 53. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 4 - d -> d # Failed test 'd -> d' # at ../test/recipes/tconversion.pl line 63. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 5 - p -> d # Failed test 'p -> d' # at ../test/recipes/tconversion.pl line 63. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 6 - d -> p # Failed test 'd -> p' # at ../test/recipes/tconversion.pl line 63. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 7 - p -> p # Failed test 'p -> p' # at ../test/recipes/tconversion.pl line 63. not ok 8 - comparing orig to p # Failed test 'comparing orig to p' # at ../test/recipes/tconversion.pl line 72. # got: '-1' # expected: '0' not ok 9 - comparing p to dp # Failed test 'comparing p to dp' # at ../test/recipes/tconversion.pl line 80. # got: '-1' # expected: '0' not ok 10 - comparing p to pp # Failed test 'comparing p to pp' # at ../test/recipes/tconversion.pl line 80. # got: '-1' # expected: '0' # Looks like you failed 9 tests of 10. not ok 2 - crl conversions # Failed test 'crl conversions' # at ../test/recipes/25-test_crl.t line 17. # Looks like you failed 1 test of 2. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/2 subtests ../test/recipes/25-test_gen.t ............. 1..1 # There should be a 2 sequences of .'s and some +'s. # There should not be more that at most 80 per line 1..2 ../apps/openssl: can't load library 'ssl.so.1.1' not ok 1 - Generating request # Failed test 'Generating request' # at ../test/recipes/25-test_gen.t line 37. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 2 - Verifying signature on request # Failed test 'Verifying signature on request' # at ../test/recipes/25-test_gen.t line 41. # Looks like you failed 2 tests of 2. not ok 1 - generating certificate requests # Failed test 'generating certificate requests' # at ../test/recipes/25-test_gen.t line 44. # Looks like you failed 1 test of 1. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/25-test_pkcs7.t ........... 1..3 ok 1 - require '../test/recipes/tconversion.pl'; 1..10 ok 1 - initializing ../apps/openssl: can't load library 'ssl.so.1.1' not ok 2 - p -> d # Failed test 'p -> d' # at ../test/recipes/tconversion.pl line 53. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 3 - p -> p # Failed test 'p -> p' # at ../test/recipes/tconversion.pl line 53. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 4 - d -> d # Failed test 'd -> d' # at ../test/recipes/tconversion.pl line 63. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 5 - p -> d # Failed test 'p -> d' # at ../test/recipes/tconversion.pl line 63. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 6 - d -> p # Failed test 'd -> p' # at ../test/recipes/tconversion.pl line 63. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 7 - p -> p # Failed test 'p -> p' # at ../test/recipes/tconversion.pl line 63. not ok 8 - comparing orig to p # Failed test 'comparing orig to p' # at ../test/recipes/tconversion.pl line 72. # got: '-1' # expected: '0' not ok 9 - comparing p to dp # Failed test 'comparing p to dp' # at ../test/recipes/tconversion.pl line 80. # got: '-1' # expected: '0' not ok 10 - comparing p to pp # Failed test 'comparing p to pp' # at ../test/recipes/tconversion.pl line 80. # got: '-1' # expected: '0' # Looks like you failed 9 tests of 10. not ok 2 - pkcs7 conversions -- pkcs7 # Failed test 'pkcs7 conversions -- pkcs7' # at ../test/recipes/25-test_pkcs7.t line 17. 1..9 ok 1 - initializing ../apps/openssl: can't load library 'ssl.so.1.1' not ok 2 - p -> d # Failed test 'p -> d' # at ../test/recipes/tconversion.pl line 53. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 3 - p -> p # Failed test 'p -> p' # at ../test/recipes/tconversion.pl line 53. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 4 - d -> d # Failed test 'd -> d' # at ../test/recipes/tconversion.pl line 63. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 5 - p -> d # Failed test 'p -> d' # at ../test/recipes/tconversion.pl line 63. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 6 - d -> p # Failed test 'd -> p' # at ../test/recipes/tconversion.pl line 63. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 7 - p -> p # Failed test 'p -> p' # at ../test/recipes/tconversion.pl line 63. not ok 8 - comparing p to dp # Failed test 'comparing p to dp' # at ../test/recipes/tconversion.pl line 80. # got: '-1' # expected: '0' not ok 9 - comparing p to pp # Failed test 'comparing p to pp' # at ../test/recipes/tconversion.pl line 80. # got: '-1' # expected: '0' # Looks like you failed 8 tests of 9. not ok 3 - pkcs7 conversions -- pkcs7d # Failed test 'pkcs7 conversions -- pkcs7d' # at ../test/recipes/25-test_pkcs7.t line 20. # Looks like you failed 2 tests of 3. Dubious, test returned 2 (wstat 512, 0x200) Failed 2/3 subtests ../test/recipes/25-test_req.t ............. 1..3 ok 1 - require '../test/recipes/tconversion.pl'; 1..10 not ok 1 - initializing # Failed test 'initializing' # at ../test/recipes/tconversion.pl line 43. # Trying to copy testreq.pem to req-fff.p : No such file or directory ok 2 # skip Not initialized, skipping... ok 3 # skip Not initialized, skipping... ok 4 # skip Not initialized, skipping... ok 5 # skip Not initialized, skipping... ok 6 # skip Not initialized, skipping... ok 7 # skip Not initialized, skipping... ok 8 # skip Not initialized, skipping... ok 9 # skip Not initialized, skipping... ok 10 # skip Not initialized, skipping... ok 11 # skip Not initialized, skipping... ok 12 # skip Not initialized, skipping... ok 13 # skip Not initialized, skipping... ok 14 # skip Not initialized, skipping... ok 15 # skip Not initialized, skipping... ok 16 # skip Not initialized, skipping... ok 17 # skip Not initialized, skipping... ok 18 # skip Not initialized, skipping... ok 19 # skip Not initialized, skipping... ok 20 # skip Not initialized, skipping... ok 21 # skip Not initialized, skipping... ok 22 # skip Not initialized, skipping... ok 23 # skip Not initialized, skipping... not ok 24 - planned to run 10 but done_testing() expects 23 # Failed test 'planned to run 10 but done_testing() expects 23' # at /usr/libdata/perl5/5.16.3/Test/More.pm line 221. # Looks like you planned 10 tests but ran 24. # Looks like you failed 2 tests of 24 run. not ok 2 - req conversions # Failed test 'req conversions' # at ../test/recipes/25-test_req.t line 42. 1..10 not ok 1 - initializing # Failed test 'initializing' # at ../test/recipes/tconversion.pl line 43. # Trying to copy testreq.pem to req-fff.p : No such file or directory ok 2 # skip Not initialized, skipping... ok 3 # skip Not initialized, skipping... ok 4 # skip Not initialized, skipping... ok 5 # skip Not initialized, skipping... ok 6 # skip Not initialized, skipping... ok 7 # skip Not initialized, skipping... ok 8 # skip Not initialized, skipping... ok 9 # skip Not initialized, skipping... ok 10 # skip Not initialized, skipping... ok 11 # skip Not initialized, skipping... ok 12 # skip Not initialized, skipping... ok 13 # skip Not initialized, skipping... ok 14 # skip Not initialized, skipping... ok 15 # skip Not initialized, skipping... ok 16 # skip Not initialized, skipping... ok 17 # skip Not initialized, skipping... ok 18 # skip Not initialized, skipping... ok 19 # skip Not initialized, skipping... ok 20 # skip Not initialized, skipping... ok 21 # skip Not initialized, skipping... ok 22 # skip Not initialized, skipping... ok 23 # skip Not initialized, skipping... not ok 24 - planned to run 10 but done_testing() expects 23 # Failed test 'planned to run 10 but done_testing() expects 23' # at /usr/libdata/perl5/5.16.3/Test/More.pm line 221. # Looks like you planned 10 tests but ran 24. # Looks like you failed 2 tests of 24 run. not ok 3 - req conversions -- testreq2 # Failed test 'req conversions -- testreq2' # at ../test/recipes/25-test_req.t line 42. # Looks like you failed 2 tests of 3. Dubious, test returned 2 (wstat 512, 0x200) Failed 2/3 subtests ../test/recipes/25-test_sid.t ............. 1..2 ok 1 - require '../test/recipes/tconversion.pl'; 1..10 ok 1 - initializing ../apps/openssl: can't load library 'ssl.so.1.1' not ok 2 - p -> d # Failed test 'p -> d' # at ../test/recipes/tconversion.pl line 53. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 3 - p -> p # Failed test 'p -> p' # at ../test/recipes/tconversion.pl line 53. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 4 - d -> d # Failed test 'd -> d' # at ../test/recipes/tconversion.pl line 63. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 5 - p -> d # Failed test 'p -> d' # at ../test/recipes/tconversion.pl line 63. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 6 - d -> p # Failed test 'd -> p' # at ../test/recipes/tconversion.pl line 63. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 7 - p -> p # Failed test 'p -> p' # at ../test/recipes/tconversion.pl line 63. not ok 8 - comparing orig to p # Failed test 'comparing orig to p' # at ../test/recipes/tconversion.pl line 72. # got: '-1' # expected: '0' not ok 9 - comparing p to dp # Failed test 'comparing p to dp' # at ../test/recipes/tconversion.pl line 80. # got: '-1' # expected: '0' not ok 10 - comparing p to pp # Failed test 'comparing p to pp' # at ../test/recipes/tconversion.pl line 80. # got: '-1' # expected: '0' # Looks like you failed 9 tests of 10. not ok 2 - sid conversions # Failed test 'sid conversions' # at ../test/recipes/25-test_sid.t line 17. # Looks like you failed 1 test of 2. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/2 subtests ../test/recipes/25-test_verify.t .......... 1..81 ../apps/openssl: can't load library 'ssl.so.1.1' not ok 1 - accept compat trust # Failed test 'accept compat trust' # at ../test/recipes/25-test_verify.t line 25. ../apps/openssl: can't load library 'ssl.so.1.1' ok 2 - fail trusted non-ca root ../apps/openssl: can't load library 'ssl.so.1.1' ok 3 - fail server trust non-ca root ../apps/openssl: can't load library 'ssl.so.1.1' ok 4 - fail wildcard trust non-ca root ../apps/openssl: can't load library 'ssl.so.1.1' ok 5 - fail wrong root key ../apps/openssl: can't load library 'ssl.so.1.1' ok 6 - fail wrong root DN ../apps/openssl: can't load library 'ssl.so.1.1' not ok 7 - accept server purpose # Failed test 'accept server purpose' # at ../test/recipes/25-test_verify.t line 42. ../apps/openssl: can't load library 'ssl.so.1.1' ok 8 - fail client purpose ../apps/openssl: can't load library 'ssl.so.1.1' not ok 9 - accept server trust # Failed test 'accept server trust' # at ../test/recipes/25-test_verify.t line 46. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 10 - accept server trust with server purpose # Failed test 'accept server trust with server purpose' # at ../test/recipes/25-test_verify.t line 48. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 11 - accept server trust with client purpose # Failed test 'accept server trust with client purpose' # at ../test/recipes/25-test_verify.t line 50. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 12 - accept wildcard trust # Failed test 'accept wildcard trust' # at ../test/recipes/25-test_verify.t line 53. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 13 - accept wildcard trust with server purpose # Failed test 'accept wildcard trust with server purpose' # at ../test/recipes/25-test_verify.t line 55. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 14 - accept wildcard trust with client purpose # Failed test 'accept wildcard trust with client purpose' # at ../test/recipes/25-test_verify.t line 57. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 15 - accept client mistrust # Failed test 'accept client mistrust' # at ../test/recipes/25-test_verify.t line 60. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 16 - accept client mistrust with server purpose # Failed test 'accept client mistrust with server purpose' # at ../test/recipes/25-test_verify.t line 62. ../apps/openssl: can't load library 'ssl.so.1.1' ok 17 - fail client mistrust with client purpose ../apps/openssl: can't load library 'ssl.so.1.1' ok 18 - fail client trust ../apps/openssl: can't load library 'ssl.so.1.1' ok 19 - fail client trust with server purpose ../apps/openssl: can't load library 'ssl.so.1.1' ok 20 - fail client trust with client purpose ../apps/openssl: can't load library 'ssl.so.1.1' ok 21 - fail rejected EKU ../apps/openssl: can't load library 'ssl.so.1.1' ok 22 - fail server mistrust with server purpose ../apps/openssl: can't load library 'ssl.so.1.1' ok 23 - fail server mistrust with client purpose ../apps/openssl: can't load library 'ssl.so.1.1' ok 24 - fail wildcard mistrust ../apps/openssl: can't load library 'ssl.so.1.1' ok 25 - fail wildcard mistrust with server purpose ../apps/openssl: can't load library 'ssl.so.1.1' ok 26 - fail wildcard mistrust with client purpose ../apps/openssl: can't load library 'ssl.so.1.1' not ok 27 - accept trusted-first path # Failed test 'accept trusted-first path' # at ../test/recipes/25-test_verify.t line 91. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 28 - accept trusted-first path with server trust # Failed test 'accept trusted-first path with server trust' # at ../test/recipes/25-test_verify.t line 94. ../apps/openssl: can't load library 'ssl.so.1.1' ok 29 - fail trusted-first path with server mistrust ../apps/openssl: can't load library 'ssl.so.1.1' ok 30 - fail trusted-first path with client trust ../apps/openssl: can't load library 'ssl.so.1.1' ok 31 - fail non-CA untrusted intermediate ../apps/openssl: can't load library 'ssl.so.1.1' ok 32 - fail non-CA trusted intermediate ../apps/openssl: can't load library 'ssl.so.1.1' ok 33 - fail non-CA server trust intermediate ../apps/openssl: can't load library 'ssl.so.1.1' ok 34 - fail non-CA wildcard trust intermediate ../apps/openssl: can't load library 'ssl.so.1.1' ok 35 - fail wrong intermediate CA key ../apps/openssl: can't load library 'ssl.so.1.1' ok 36 - fail wrong intermediate CA DN ../apps/openssl: can't load library 'ssl.so.1.1' ok 37 - fail wrong intermediate CA issuer ../apps/openssl: can't load library 'ssl.so.1.1' ok 38 - fail untrusted partial chain ../apps/openssl: can't load library 'ssl.so.1.1' not ok 39 - accept trusted partial chain # Failed test 'accept trusted partial chain' # at ../test/recipes/25-test_verify.t line 121. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 40 - accept partial chain with server purpose # Failed test 'accept partial chain with server purpose' # at ../test/recipes/25-test_verify.t line 123. ../apps/openssl: can't load library 'ssl.so.1.1' ok 41 - fail partial chain with client purpose ../apps/openssl: can't load library 'ssl.so.1.1' not ok 42 - accept server trust partial chain # Failed test 'accept server trust partial chain' # at ../test/recipes/25-test_verify.t line 127. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 43 - accept server trust client purpose partial chain # Failed test 'accept server trust client purpose partial chain' # at ../test/recipes/25-test_verify.t line 129. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 44 - accept client mistrust partial chain # Failed test 'accept client mistrust partial chain' # at ../test/recipes/25-test_verify.t line 131. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 45 - accept wildcard trust partial chain # Failed test 'accept wildcard trust partial chain' # at ../test/recipes/25-test_verify.t line 133. ../apps/openssl: can't load library 'ssl.so.1.1' ok 46 - fail untrusted partial issuer with ignored server trust ../apps/openssl: can't load library 'ssl.so.1.1' ok 47 - fail server mistrust partial chain ../apps/openssl: can't load library 'ssl.so.1.1' ok 48 - fail client trust partial chain ../apps/openssl: can't load library 'ssl.so.1.1' ok 49 - fail wildcard mistrust partial chain ../apps/openssl: can't load library 'ssl.so.1.1' not ok 50 - accept server trust # Failed test 'accept server trust' # at ../test/recipes/25-test_verify.t line 147. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 51 - accept wildcard trust # Failed test 'accept wildcard trust' # at ../test/recipes/25-test_verify.t line 149. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 52 - accept server purpose # Failed test 'accept server purpose' # at ../test/recipes/25-test_verify.t line 151. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 53 - accept server trust and purpose # Failed test 'accept server trust and purpose' # at ../test/recipes/25-test_verify.t line 153. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 54 - accept wildcard trust and server purpose # Failed test 'accept wildcard trust and server purpose' # at ../test/recipes/25-test_verify.t line 155. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 55 - accept client mistrust and server purpose # Failed test 'accept client mistrust and server purpose' # at ../test/recipes/25-test_verify.t line 157. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 56 - accept server trust and client purpose # Failed test 'accept server trust and client purpose' # at ../test/recipes/25-test_verify.t line 159. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 57 - accept wildcard trust and client purpose # Failed test 'accept wildcard trust and client purpose' # at ../test/recipes/25-test_verify.t line 161. ../apps/openssl: can't load library 'ssl.so.1.1' ok 58 - fail client purpose ../apps/openssl: can't load library 'ssl.so.1.1' ok 59 - fail wildcard mistrust ../apps/openssl: can't load library 'ssl.so.1.1' ok 60 - fail server mistrust ../apps/openssl: can't load library 'ssl.so.1.1' ok 61 - fail client trust ../apps/openssl: can't load library 'ssl.so.1.1' ok 62 - fail client trust and server purpose ../apps/openssl: can't load library 'ssl.so.1.1' ok 63 - fail client trust and client purpose ../apps/openssl: can't load library 'ssl.so.1.1' ok 64 - fail server mistrust and client purpose ../apps/openssl: can't load library 'ssl.so.1.1' ok 65 - fail client mistrust and client purpose ../apps/openssl: can't load library 'ssl.so.1.1' ok 66 - fail server mistrust and server purpose ../apps/openssl: can't load library 'ssl.so.1.1' ok 67 - fail wildcard mistrust and server purpose ../apps/openssl: can't load library 'ssl.so.1.1' ok 68 - fail wildcard mistrust and client purpose ../apps/openssl: can't load library 'ssl.so.1.1' not ok 69 - accept client chain # Failed test 'accept client chain' # at ../test/recipes/25-test_verify.t line 187. ../apps/openssl: can't load library 'ssl.so.1.1' ok 70 - fail server leaf purpose ../apps/openssl: can't load library 'ssl.so.1.1' ok 71 - fail client leaf purpose ../apps/openssl: can't load library 'ssl.so.1.1' ok 72 - fail wrong intermediate CA key ../apps/openssl: can't load library 'ssl.so.1.1' ok 73 - fail wrong intermediate CA DN ../apps/openssl: can't load library 'ssl.so.1.1' ok 74 - fail expired leaf ../apps/openssl: can't load library 'ssl.so.1.1' not ok 75 - accept last-resort direct leaf match # Failed test 'accept last-resort direct leaf match' # at ../test/recipes/25-test_verify.t line 199. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 76 - accept last-resort direct leaf match # Failed test 'accept last-resort direct leaf match' # at ../test/recipes/25-test_verify.t line 201. ../apps/openssl: can't load library 'ssl.so.1.1' ok 77 - fail last-resort direct leaf non-match ../apps/openssl: can't load library 'ssl.so.1.1' not ok 78 - accept direct match with server trust # Failed test 'accept direct match with server trust' # at ../test/recipes/25-test_verify.t line 205. ../apps/openssl: can't load library 'ssl.so.1.1' ok 79 - fail direct match with server mistrust ../apps/openssl: can't load library 'ssl.so.1.1' not ok 80 - accept direct match with client trust # Failed test 'accept direct match with client trust' # at ../test/recipes/25-test_verify.t line 209. ../apps/openssl: can't load library 'ssl.so.1.1' ok 81 - reject direct match with client mistrust # Looks like you failed 31 tests of 81. Dubious, test returned 31 (wstat 7936, 0x1f00) Failed 31/81 subtests ../test/recipes/25-test_x509.t ............ 1..4 ok 1 - require '../test/recipes/tconversion.pl'; 1..10 ok 1 - initializing ../apps/openssl: can't load library 'ssl.so.1.1' not ok 2 - p -> d # Failed test 'p -> d' # at ../test/recipes/tconversion.pl line 53. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 3 - p -> p # Failed test 'p -> p' # at ../test/recipes/tconversion.pl line 53. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 4 - d -> d # Failed test 'd -> d' # at ../test/recipes/tconversion.pl line 63. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 5 - p -> d # Failed test 'p -> d' # at ../test/recipes/tconversion.pl line 63. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 6 - d -> p # Failed test 'd -> p' # at ../test/recipes/tconversion.pl line 63. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 7 - p -> p # Failed test 'p -> p' # at ../test/recipes/tconversion.pl line 63. not ok 8 - comparing orig to p # Failed test 'comparing orig to p' # at ../test/recipes/tconversion.pl line 72. # got: '-1' # expected: '0' not ok 9 - comparing p to dp # Failed test 'comparing p to dp' # at ../test/recipes/tconversion.pl line 80. # got: '-1' # expected: '0' not ok 10 - comparing p to pp # Failed test 'comparing p to pp' # at ../test/recipes/tconversion.pl line 80. # got: '-1' # expected: '0' # Looks like you failed 9 tests of 10. not ok 2 - x509 -- x.509 v1 certificate # Failed test 'x509 -- x.509 v1 certificate' # at ../test/recipes/25-test_x509.t line 17. 1..10 ok 1 - initializing ../apps/openssl: can't load library 'ssl.so.1.1' not ok 2 - p -> d # Failed test 'p -> d' # at ../test/recipes/tconversion.pl line 53. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 3 - p -> p # Failed test 'p -> p' # at ../test/recipes/tconversion.pl line 53. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 4 - d -> d # Failed test 'd -> d' # at ../test/recipes/tconversion.pl line 63. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 5 - p -> d # Failed test 'p -> d' # at ../test/recipes/tconversion.pl line 63. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 6 - d -> p # Failed test 'd -> p' # at ../test/recipes/tconversion.pl line 63. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 7 - p -> p # Failed test 'p -> p' # at ../test/recipes/tconversion.pl line 63. not ok 8 - comparing orig to p # Failed test 'comparing orig to p' # at ../test/recipes/tconversion.pl line 72. # got: '-1' # expected: '0' not ok 9 - comparing p to dp # Failed test 'comparing p to dp' # at ../test/recipes/tconversion.pl line 80. # got: '-1' # expected: '0' not ok 10 - comparing p to pp # Failed test 'comparing p to pp' # at ../test/recipes/tconversion.pl line 80. # got: '-1' # expected: '0' # Looks like you failed 9 tests of 10. not ok 3 - x509 -- first x.509 v3 certificate # Failed test 'x509 -- first x.509 v3 certificate' # at ../test/recipes/25-test_x509.t line 20. 1..10 ok 1 - initializing ../apps/openssl: can't load library 'ssl.so.1.1' not ok 2 - p -> d # Failed test 'p -> d' # at ../test/recipes/tconversion.pl line 53. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 3 - p -> p # Failed test 'p -> p' # at ../test/recipes/tconversion.pl line 53. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 4 - d -> d # Failed test 'd -> d' # at ../test/recipes/tconversion.pl line 63. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 5 - p -> d # Failed test 'p -> d' # at ../test/recipes/tconversion.pl line 63. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 6 - d -> p # Failed test 'd -> p' # at ../test/recipes/tconversion.pl line 63. ../apps/openssl: can't load library 'ssl.so.1.1' not ok 7 - p -> p # Failed test 'p -> p' # at ../test/recipes/tconversion.pl line 63. not ok 8 - comparing orig to p # Failed test 'comparing orig to p' # at ../test/recipes/tconversion.pl line 72. # got: '-1' # expected: '0' not ok 9 - comparing p to dp # Failed test 'comparing p to dp' # at ../test/recipes/tconversion.pl line 80. # got: '-1' # expected: '0' not ok 10 - comparing p to pp # Failed test 'comparing p to pp' # at ../test/recipes/tconversion.pl line 80. # got: '-1' # expected: '0' # Looks like you failed 9 tests of 10. not ok 4 - x509 -- second x.509 v3 certificate # Failed test 'x509 -- second x.509 v3 certificate' # at ../test/recipes/25-test_x509.t line 23. # Looks like you failed 3 tests of 4. Dubious, test returned 3 (wstat 768, 0x300) Failed 3/4 subtests ../test/recipes/30-test_engine.t .......... 1..1 ./enginetest: can't load library 'ssl.so.1.1' not ok 1 - running enginetest # Failed test 'running enginetest' # at ../test/recipes/30-test_engine.t line 11. # Looks like you failed 1 test of 1. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/30-test_evp.t ............. 1..1 ./evp_test: can't load library 'ssl.so.1.1' not ok 1 - running evp_test evptests.txt # Failed test 'running evp_test evptests.txt' # at ../test/recipes/30-test_evp.t line 11. # Looks like you failed 1 test of 1. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/30-test_evp_extra.t ....... 1..1 ./evp_extra_test: can't load library 'ssl.so.1.1' not ok 1 - running evp_extra_test # Failed test 'running evp_extra_test' # at ../test/recipes/30-test_evp_extra.t line 11. # Looks like you failed 1 test of 1. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/30-test_pbelu.t ........... 1..1 ./pbelutest: can't load library 'ssl.so.1.1' not ok 1 - running pbelutest # Failed test 'running pbelutest' # at ../test/testlib/OpenSSL/Test/Simple.pm line 70. # Looks like you failed 1 test of 1. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/40-test_rehash.t .......... ../apps/openssl: can't load library 'ssl.so.1.1' 1..0 # SKIP test_rehash is not available on this platform skipped: test_rehash is not available on this platform ../test/recipes/70-test_clienthello.t ..... 1..1 ./clienthellotest: can't load library 'ssl.so.1.1' not ok 1 - running clienthellotest # Failed test 'running clienthellotest' # at ../test/recipes/70-test_clienthello.t line 13. # Looks like you failed 1 test of 1. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/70-test_packet.t .......... 1..1 ./packettest: can't load library 'ssl.so.1.1' not ok 1 - running packettest # Failed test 'running packettest' # at ../test/testlib/OpenSSL/Test/Simple.pm line 70. # Looks like you failed 1 test of 1. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../test/recipes/70-test_sslcertstatus.t ... 1..1 Proxy started on port 4453 ../apps/openssl: can't load library 'ssl.so.1.1' ../apps/openssl: can't load library 'ssl.so.1.1' ^CYou have new mail in /var/mail/doctor ns2.nl2k.ab.ca//usr/source/openssl-SNAP-20160221$ exit exit Script done on Sun Feb 21 06:04:13 2016 Please fix -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Broadcasting the truth for 25 years From rt at openssl.org Tue Feb 23 10:34:24 2016 From: rt at openssl.org (Mario Scalabrino via RT) Date: Tue, 23 Feb 2016 10:34:24 -0000 Subject: [openssl-dev] [openssl.org #4276] AutoReply: Possible bug - ts -verify -digest, error:ts_rsp_verify.c:291: In-Reply-To: <56CC3593.9040709@andifyou.com> References: <56AA3226.3060801@andifyou.com> <56C47A52.6090404@andifyou.com> <56CC3593.9040709@andifyou.com> Message-ID: Hello Openssl, can you please tell me something? I don't understand if anybody reads this email. Almost a month has passed. Mario Scalabrino Untitled Document On 17/02/2016 14:49, Mario Scalabrino wrote: > Hello Openssl, > > is there any update? Do you need more information? > > Thank you > > Cheers > > Mario Scalabrino > > Untitled Document > *Certify Doc * > > *MARIO SCALABRINO * > > Founder & CEO > > (+34) 680 128 282 > > mario.scalabrino at andifyou.com > > www.certifydoc.eu > > Linkedin Facebook > Twitter > > > > On 28/01/2016 17:16, The default queue via RT wrote: >> Greetings, >> >> This message has been automatically generated in response to the >> creation of a trouble ticket regarding: >> "Possible bug - ts -verify -digest, error:ts_rsp_verify.c:291:", >> a summary of which appears below. >> >> There is no need to reply to this message right now. Your ticket has been >> assigned an ID of [openssl.org #4276]. >> >> Please include the string: >> >> [openssl.org #4276] >> >> in the subject line of all future correspondence about this issue. To do so, >> you may reply to this message. >> >> Thank you, >> rt at openssl.org >> >> ------------------------------------------------------------------------- >> >> Good afternoon Openssl, >> >> please forward this email to whomever it may concern. >> >> I receive an error and the Timestamping provider suspects it is a >> Openssl bug. >> Could you please check if it is openssl or the certificate? >> >> >> This is when the error occurr >> /openssl ts -verify -digest >> e16db7d30581e44a5540f19553852b5a4e4e26f9adc365cc846f94038ee33025 -in >> /tmp/namirial.tsr -CAfile /tmp/NamirialCATSA.pem >> (result:) >> ************* >> *Verification: FAILED** >> **140236013643424:error:2F067065:time stamp >> routines:TS_CHECK_SIGNING_CERTS:ess signing certificate >> error:ts_rsp_verify.c:291:*/ >> >> >> I attach a complete reproduction scenario. I don't know if it is a >> problem of this TSA certificate or in Openssl due to sha256 digest, >> please help. >> >> >> (in the curl command I cannot provide you the username and password, it >> is a paid service) >> >> Attached are the files resulting from the below commands in sequence and >> the certificate of the TSA, but I'm sure you can check yourself the last >> command where the error occur and advice. >> >> you can copy and paste the commands below if you're in Linux Ubuntu and >> the files are in the /tmp/ folder >> >> *Reproduction scenario:* >> >> OS: Ubuntu 14.04 >> Openssl version: OpenSSL 1.0.1f 6 Jan 2014 >> >> >> >> Generate tsq: >> openssl ts -query -digest >> e16db7d30581e44a5540f19553852b5a4e4e26f9adc365cc846f94038ee33025 -sha256 >> -cert -out /tmp/namirial.tsq >> >> Readable tsq: >> openssl ts -query -in /tmp/namirial.tsq -text >> (result:) >> ************ >> Hash Algorithm: sha256 >> Message data: >> 0000 - e1 6d b7 d3 05 81 e4 4a-55 40 f1 95 53 85 2b 5a .m.....JU at ..S.+Z >> 0010 - 4e 4e 26 f9 ad c3 65 cc-84 6f 94 03 8e e3 30 25 NN&...e..o....0% >> Policy OID: unspecified >> Nonce: 0x8CA62B5766A29A8B >> Certificate required: yes >> Extensions: >> **************** >> >> >> Generate tsr (using curl) >> curl -u xxxxxxx:yyyyyy -s --data-binary @/tmp/namirial.tsq -H >> 'Content-Type: application/timestamp-query' -H 'Pragma: no-cache' -H >> 'Accept: application/timestamp-reply' --output /tmp/namirial.tsr >> http://timestamp.firmacerta.it >> >> Readable tsr >> openssl ts -reply -in /tmp/namirial.tsr -out /tmp/readable_tsr.txt -text >> >> (result:) >> ****************** >> Status info: >> Status: Granted. >> Status description: Operation Okay >> Failure info: unspecified >> >> TST info: >> Version: 1 >> Policy OID: 1.3.6.1.4.1.36203.2.1 >> Hash Algorithm: sha256 >> Message data: >> 0000 - e1 6d b7 d3 05 81 e4 4a-55 40 f1 95 53 85 2b 5a .m.....JU at ..S.+Z >> 0010 - 4e 4e 26 f9 ad c3 65 cc-84 6f 94 03 8e e3 30 25 NN&...e..o....0% >> Serial number: 0x1947FD96B97A42DE >> Time stamp: Jan 28 14:56:16 2016 GMT >> Accuracy: unspecified seconds, 0x01F4 millis, unspecified micros >> Ordering: no >> Nonce: 0x8CA62B5766A29A8B >> TSA: unspecified >> Extensions: >> ************************ >> >> >> Verify >> openssl ts -verify -digest >> e16db7d30581e44a5540f19553852b5a4e4e26f9adc365cc846f94038ee33025 -in >> /tmp/namirial.tsr -CAfile /tmp/NamirialCATSA.pem >> (result:) >> ************* >> *Verification: FAILED** >> **140236013643424:error:2F067065:time stamp >> routines:TS_CHECK_SIGNING_CERTS:ess signing certificate >> error:ts_rsp_verify.c:291:* >> *************** >> >> >> > -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4276 Please log in as guest with password guest if prompted -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 6492 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 8556 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 11081 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 10866 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 11458 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 10874 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 10718 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 10856 bytes Desc: not available URL: From rt at openssl.org Sun Feb 28 14:33:34 2016 From: rt at openssl.org (Simon Richter via RT) Date: Sun, 28 Feb 2016 14:33:34 +0000 Subject: [openssl-dev] [openssl.org #4355] OpenSSL 1.0.2 branch fails to build with MSVC In-Reply-To: <56D2EE94.1050309@hogyros.de> References: <1405509101.5.1456612972774.JavaMail.jenkins@kicadjenkins> <56D2EE94.1050309@hogyros.de> Message-ID: Hi, I just got this from our Jenkins instance that follows OpenSSL 1.0.2: Simon -------- Forwarded Message -------- Subject: Build failed in Jenkins: windows-openssl-msvc ? x86,windows #283 Date: Sat, 27 Feb 2016 23:42:52 +0100 (CET) See Changes: [rsalz] Fix possible memory leak on BUF_MEM_grow_clean failure [rsalz] Fix two possible leaks ------------------------------------------ [...truncated 943 lines...] o_names.c cl /Fotmp32dll\obj_dat.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\objects\obj_dat.c obj_dat.c cl /Fotmp32dll\obj_lib.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\objects\obj_lib.c obj_lib.c cl /Fotmp32dll\obj_err.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\objects\obj_err.c obj_err.c cl /Fotmp32dll\obj_xref.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\objects\obj_xref.c obj_xref.c cl /Fotmp32dll\encode.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\evp\encode.c encode.c cl /Fotmp32dll\digest.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\evp\digest.c digest.c cl /Fotmp32dll\evp_enc.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\evp\evp_enc.c evp_enc.c cl /Fotmp32dll\evp_key.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\evp\evp_key.c evp_key.c cl /Fotmp32dll\evp_acnf.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\evp\evp_acnf.c evp_acnf.c cl /Fotmp32dll\evp_cnf.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\evp\evp_cnf.c evp_cnf.c cl /Fotmp32dll\e_des.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\evp\e_des.c e_des.c cl /Fotmp32dll\e_bf.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\evp\e_bf.c e_bf.c cl /Fotmp32dll\e_idea.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\evp\e_idea.c e_idea.c cl /Fotmp32dll\e_des3.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\evp\e_des3.c e_des3.c cl /Fotmp32dll\e_camellia.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\evp\e_camellia.c e_camellia.c cl /Fotmp32dll\e_rc4.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\evp\e_rc4.c e_rc4.c cl /Fotmp32dll\e_aes.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\evp\e_aes.c e_aes.c cl /Fotmp32dll\names.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\evp\names.c names.c cl /Fotmp32dll\e_seed.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\evp\e_seed.c e_seed.c cl /Fotmp32dll\e_xcbc_d.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\evp\e_xcbc_d.c e_xcbc_d.c cl /Fotmp32dll\e_rc2.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\evp\e_rc2.c e_rc2.c cl /Fotmp32dll\e_cast.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\evp\e_cast.c e_cast.c cl /Fotmp32dll\e_rc5.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\evp\e_rc5.c e_rc5.c cl /Fotmp32dll\m_null.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\evp\m_null.c m_null.c cl /Fotmp32dll\m_md4.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\evp\m_md4.c m_md4.c cl /Fotmp32dll\m_md5.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\evp\m_md5.c m_md5.c cl /Fotmp32dll\m_sha.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\evp\m_sha.c m_sha.c cl /Fotmp32dll\m_sha1.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\evp\m_sha1.c m_sha1.c cl /Fotmp32dll\m_wp.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\evp\m_wp.c m_wp.c cl /Fotmp32dll\m_dss.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\evp\m_dss.c m_dss.c cl /Fotmp32dll\m_dss1.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\evp\m_dss1.c m_dss1.c cl /Fotmp32dll\m_mdc2.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\evp\m_mdc2.c m_mdc2.c cl /Fotmp32dll\m_ripemd.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\evp\m_ripemd.c m_ripemd.c cl /Fotmp32dll\m_ecdsa.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\evp\m_ecdsa.c m_ecdsa.c cl /Fotmp32dll\p_open.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\evp\p_open.c p_open.c cl /Fotmp32dll\p_seal.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\evp\p_seal.c p_seal.c cl /Fotmp32dll\p_sign.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\evp\p_sign.c p_sign.c cl /Fotmp32dll\p_verify.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\evp\p_verify.c p_verify.c cl /Fotmp32dll\p_lib.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\evp\p_lib.c p_lib.c cl /Fotmp32dll\p_enc.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\evp\p_enc.c p_enc.c cl /Fotmp32dll\p_dec.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\evp\p_dec.c p_dec.c cl /Fotmp32dll\bio_md.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\evp\bio_md.c bio_md.c cl /Fotmp32dll\bio_b64.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\evp\bio_b64.c bio_b64.c cl /Fotmp32dll\bio_enc.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\evp\bio_enc.c bio_enc.c cl /Fotmp32dll\evp_err.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\evp\evp_err.c evp_err.c cl /Fotmp32dll\e_null.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\evp\e_null.c e_null.c cl /Fotmp32dll\c_all.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\evp\c_all.c c_all.c cl /Fotmp32dll\c_allc.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\evp\c_allc.c c_allc.c cl /Fotmp32dll\c_alld.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\evp\c_alld.c c_alld.c cl /Fotmp32dll\evp_lib.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\evp\evp_lib.c evp_lib.c cl /Fotmp32dll\bio_ok.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\evp\bio_ok.c bio_ok.c cl /Fotmp32dll\evp_pkey.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\evp\evp_pkey.c evp_pkey.c cl /Fotmp32dll\evp_pbe.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\evp\evp_pbe.c evp_pbe.c cl /Fotmp32dll\p5_crpt.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\evp\p5_crpt.c p5_crpt.c cl /Fotmp32dll\p5_crpt2.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\evp\p5_crpt2.c p5_crpt2.c cl /Fotmp32dll\e_old.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\evp\e_old.c e_old.c cl /Fotmp32dll\pmeth_lib.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\evp\pmeth_lib.c pmeth_lib.c cl /Fotmp32dll\pmeth_fn.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\evp\pmeth_fn.c pmeth_fn.c cl /Fotmp32dll\pmeth_gn.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\evp\pmeth_gn.c pmeth_gn.c cl /Fotmp32dll\m_sigver.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\evp\m_sigver.c m_sigver.c cl /Fotmp32dll\e_aes_cbc_hmac_sha1.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\evp\e_aes_cbc_hmac_sha1.c e_aes_cbc_hmac_sha1.c cl /Fotmp32dll\e_aes_cbc_hmac_sha256.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\evp\e_aes_cbc_hmac_sha256.c e_aes_cbc_hmac_sha256.c cl /Fotmp32dll\e_rc4_hmac_md5.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\evp\e_rc4_hmac_md5.c e_rc4_hmac_md5.c cl /Fotmp32dll\a_object.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\asn1\a_object.c a_object.c cl /Fotmp32dll\a_bitstr.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\asn1\a_bitstr.c a_bitstr.c cl /Fotmp32dll\a_utctm.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\asn1\a_utctm.c a_utctm.c cl /Fotmp32dll\a_gentm.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\asn1\a_gentm.c a_gentm.c cl /Fotmp32dll\a_time.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\asn1\a_time.c a_time.c cl /Fotmp32dll\a_int.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\asn1\a_int.c a_int.c cl /Fotmp32dll\a_octet.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\asn1\a_octet.c a_octet.c cl /Fotmp32dll\a_print.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\asn1\a_print.c a_print.c cl /Fotmp32dll\a_type.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\asn1\a_type.c a_type.c cl /Fotmp32dll\a_set.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\asn1\a_set.c a_set.c cl /Fotmp32dll\a_dup.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\asn1\a_dup.c a_dup.c cl /Fotmp32dll\a_d2i_fp.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\asn1\a_d2i_fp.c a_d2i_fp.c cl /Fotmp32dll\a_i2d_fp.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\asn1\a_i2d_fp.c a_i2d_fp.c cl /Fotmp32dll\a_enum.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\asn1\a_enum.c a_enum.c cl /Fotmp32dll\a_utf8.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\asn1\a_utf8.c a_utf8.c cl /Fotmp32dll\a_sign.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\asn1\a_sign.c a_sign.c cl /Fotmp32dll\a_digest.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\asn1\a_digest.c a_digest.c cl /Fotmp32dll\a_verify.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\asn1\a_verify.c a_verify.c cl /Fotmp32dll\a_mbstr.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\asn1\a_mbstr.c a_mbstr.c cl /Fotmp32dll\a_strex.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\asn1\a_strex.c a_strex.c cl /Fotmp32dll\x_algor.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\asn1\x_algor.c x_algor.c cl /Fotmp32dll\x_val.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\asn1\x_val.c x_val.c cl /Fotmp32dll\x_pubkey.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\asn1\x_pubkey.c x_pubkey.c cl /Fotmp32dll\x_sig.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\asn1\x_sig.c x_sig.c cl /Fotmp32dll\x_req.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\asn1\x_req.c x_req.c cl /Fotmp32dll\x_attrib.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\asn1\x_attrib.c x_attrib.c cl /Fotmp32dll\x_bignum.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\asn1\x_bignum.c x_bignum.c cl /Fotmp32dll\x_long.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\asn1\x_long.c x_long.c cl /Fotmp32dll\x_name.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\asn1\x_name.c x_name.c cl /Fotmp32dll\x_x509.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\asn1\x_x509.c x_x509.c cl /Fotmp32dll\x_x509a.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\asn1\x_x509a.c x_x509a.c cl /Fotmp32dll\x_crl.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\asn1\x_crl.c x_crl.c cl /Fotmp32dll\x_info.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\asn1\x_info.c x_info.c cl /Fotmp32dll\x_spki.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\asn1\x_spki.c x_spki.c cl /Fotmp32dll\nsseq.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\asn1\nsseq.c nsseq.c cl /Fotmp32dll\x_nx509.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\asn1\x_nx509.c x_nx509.c cl /Fotmp32dll\d2i_pu.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\asn1\d2i_pu.c d2i_pu.c cl /Fotmp32dll\d2i_pr.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\asn1\d2i_pr.c d2i_pr.c cl /Fotmp32dll\i2d_pu.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\asn1\i2d_pu.c i2d_pu.c cl /Fotmp32dll\i2d_pr.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\asn1\i2d_pr.c i2d_pr.c cl /Fotmp32dll\t_req.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\asn1\t_req.c t_req.c cl /Fotmp32dll\t_x509.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\asn1\t_x509.c t_x509.c cl /Fotmp32dll\t_x509a.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\asn1\t_x509a.c t_x509a.c cl /Fotmp32dll\t_crl.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\asn1\t_crl.c t_crl.c cl /Fotmp32dll\t_pkey.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\asn1\t_pkey.c t_pkey.c cl /Fotmp32dll\t_spki.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\asn1\t_spki.c t_spki.c cl /Fotmp32dll\t_bitst.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\asn1\t_bitst.c t_bitst.c cl /Fotmp32dll\tasn_new.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\asn1\tasn_new.c tasn_new.c cl /Fotmp32dll\tasn_fre.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\asn1\tasn_fre.c tasn_fre.c cl /Fotmp32dll\tasn_enc.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\asn1\tasn_enc.c tasn_enc.c cl /Fotmp32dll\tasn_dec.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\asn1\tasn_dec.c tasn_dec.c .\crypto\asn1\tasn_dec.c(720): error C2078: too many initializers NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\cl.EXE"' : return code '0x2' Stop. nmake> /f ms\ntdll.mak install Microsoft (R) Program Maintenance Utility Version 14.00.23026.0 Copyright (C) Microsoft Corporation. All rights reserved. Building OpenSSL cl /Fotmp32dll\tasn_dec.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\asn1\tasn_dec.c tasn_dec.c .\crypto\asn1\tasn_dec.c(720): error C2078: too many initializers NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\cl.EXE"' : return code '0x2' Stop. exit> 2 Build step 'Execute Windows batch command' marked build as failure [WARNINGS] Skipping publisher since build result is FAILURE Archiving artifacts -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4355 Please log in as guest with password guest if prompted -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: not available URL: