From sfhacker at hotmail.com Wed Jun 1 03:37:57 2016 From: sfhacker at hotmail.com (Sergio NNX) Date: Wed, 1 Jun 2016 13:37:57 +1000 Subject: [openssl-dev] [OpenSSL][1.0.2h] Memory leaks In-Reply-To: <5343CAC0.2010103@gmail.com> References: <5343CAC0.2010103@gmail.com> Message-ID: Ciao. Just built OpenSSL 1.0.2h from source and when running the tests I can see some memory leaks. The same did not happen when building previous versions on the same environment and same command line options. Thanks in advance. Find below the last bit of a long long long test output: ... ... ... ALL OCSP TESTS SUCCESSFUL Test X509v3_check_* ../util/shlib_wrap.sh ./v3nametest ../util/shlib_wrap.sh ./heartbeat_test Test constant time utilites ../util/shlib_wrap.sh ./constant_time_test Testing constant time operations... ok (ran 1908 tests) test_verify_extra ../util/shlib_wrap.sh ./verify_extra_test PASS test_clienthello ../util/shlib_wrap.sh ./clienthellotest [04:21:51] 221 file=buf_str.c, line=92, thread=1772, number=16, address=00867FC8 [04:21:51] 426 file=eng_lib.c, line=168, thread=1772, number=4, address=00869648 [04:21:51] 455 file=stack.c, line=162, thread=1772, number=20, address=0086ADE8 [04:21:51] 418 file=lhash.c, line=122, thread=1772, number=64, address=00869588 [04:21:51] 222 file=buf_str.c, line=92, thread=1772, number=7, address=00BBFDC8 [04:21:51] 419 file=eng_lib.c, line=168, thread=1772, number=4, address=008695D0 [04:21:51] 411 file=lhash.c, line=122, thread=1772, number=64, address=008694C8 [04:21:51] 428 file=stack.c, line=162, thread=1772, number=20, address=0086ACC8 [04:21:51] 412 file=eng_lib.c, line=168, thread=1772, number=4, address=00869510 [04:21:51] 266 file=stack.c, line=162, thread=1772, number=20, address=0086AC68 [04:21:51] 72 file=eng_lib.c, line=69, thread=1772, number=112, address=00BBFD50 [04:21:51] 251 file=stack.c, line=162, thread=1772, number=20, address=0086AC08 [04:21:51] 236 file=stack.c, line=162, thread=1772, number=20, address=0086ABA8 [04:21:51] 233 file=lhash.c, line=122, thread=1772, number=64, address=0086AB48 [04:21:51] 234 file=eng_lib.c, line=168, thread=1772, number=4, address=00BB27F0 [04:21:51] 255 file=lhash.c, line=122, thread=1772, number=64, address=0086C0A8 [04:21:51] 256 file=eng_lib.c, line=168, thread=1772, number=4, address=0086C0F0 [04:21:51] 429 file=stack.c, line=164, thread=1772, number=32, address=00871E98 [04:21:51] 456 file=stack.c, line=164, thread=1772, number=16, address=0086E860 [04:21:51] 261 file=eng_table.c, line=150, thread=1772, number=16, address=00868520 [04:21:51] 417 file=lhash.c, line=120, thread=1772, number=96, address=00869520 [04:21:51] 421 file=stack.c, line=162, thread=1772, number=20, address=0086ACA8 [04:21:51] 260 file=lhash.c, line=191, thread=1772, number=12, address=008684F0 [04:21:51] 224 file=buf_str.c, line=92, thread=1772, number=18, address=0086A8C0 [04:21:51] 223 file=ameth_lib.c, line=289, thread=1772, number=108, address=0086A848 [04:21:51] 259 file=stack.c, line=164, thread=1772, number=16, address=008684C0 [04:21:51] 262 file=stack.c, line=162, thread=1772, number=20, address=0086AC48 [04:21:51] 431 file=lhash.c, line=120, thread=1772, number=96, address=00871D78 [04:21:51] 253 file=lhash.c, line=191, thread=1772, number=12, address=00868418 [04:21:51] 247 file=stack.c, line=162, thread=1772, number=20, address=0086ABE8 [04:21:51] 133 file=eng_lib.c, line=69, thread=1772, number=112, address=008693E8 [04:21:51] 252 file=stack.c, line=164, thread=1772, number=16, address=008683E8 [04:21:51] 410 file=lhash.c, line=120, thread=1772, number=96, address=00869460 [04:21:51] 220 file=ameth_lib.c, line=289, thread=1772, number=108, address=0086A7D0 [04:21:51] 219 file=eng_lib.c, line=69, thread=1772, number=112, address=0086A758 [04:21:51] 425 file=lhash.c, line=122, thread=1772, number=64, address=00871D30 [04:21:51] 437 file=lhash.c, line=191, thread=1772, number=12, address=0086E608 [04:21:51] 257 file=eng_table.c, line=150, thread=1772, number=16, address=008644A8 [04:21:51] 250 file=eng_table.c, line=150, thread=1772, number=16, address=008683A0 [04:21:51] 113 file=eng_lib.c, line=69, thread=1772, number=112, address=00868B70 [04:21:51] 246 file=eng_table.c, line=150, thread=1772, number=16, address=008682F8 [04:21:51] 249 file=lhash.c, line=191, thread=1772, number=12, address=00868370 [04:21:51] 248 file=stack.c, line=164, thread=1772, number=16, address=00868340 [04:21:51] 361 file=eng_lib.c, line=69, thread=1772, number=112, address=0086FD48 [04:21:51] 195 file=eng_lib.c, line=69, thread=1772, number=112, address=00869E68 [04:21:51] 218 file=eng_lib.c, line=69, thread=1772, number=112, address=0086A6E0 [04:21:51] 434 file=eng_table.c, line=150, thread=1772, number=16, address=0086E590 [04:21:51] 430 file=lhash.c, line=191, thread=1772, number=12, address=0086E518 [04:21:51] 231 file=pmeth_lib.c, line=200, thread=1772, number=108, address=0086AA68 [04:21:51] 232 file=lhash.c, line=120, thread=1772, number=96, address=0086AAE0 [04:21:51] 242 file=lhash.c, line=191, thread=1772, number=12, address=00868280 [04:21:51] 239 file=eng_table.c, line=150, thread=1772, number=16, address=00868208 [04:21:51] 241 file=stack.c, line=164, thread=1772, number=16, address=00868250 [04:21:51] 238 file=lhash.c, line=191, thread=1772, number=12, address=008681D8 [04:21:51] 98 file=eng_lib.c, line=69, thread=1772, number=112, address=00866AF8 [04:21:51] 237 file=stack.c, line=164, thread=1772, number=16, address=008681A8 [04:21:51] 427 file=eng_table.c, line=150, thread=1772, number=16, address=0086E4A0 [04:21:51] 423 file=lhash.c, line=191, thread=1772, number=12, address=0086E428 [04:21:51] 229 file=pmeth_lib.c, line=200, thread=1772, number=108, address=0086A978 [04:21:51] 230 file=pmeth_lib.c, line=200, thread=1772, number=108, address=0086A9F0 [04:21:51] 245 file=eng_lib.c, line=168, thread=1772, number=4, address=008662E0 [04:21:51] 254 file=lhash.c, line=120, thread=1772, number=96, address=0086C040 [04:21:51] 171 file=eng_lib.c, line=69, thread=1772, number=112, address=00866268 [04:21:51] 435 file=stack.c, line=162, thread=1772, number=20, address=0086ACE8 [04:21:51] 235 file=eng_table.c, line=150, thread=1772, number=16, address=00868160 [04:21:51] 422 file=stack.c, line=164, thread=1772, number=32, address=00871EC0 [04:21:51] 414 file=stack.c, line=162, thread=1772, number=20, address=0086AC88 [04:21:51] 420 file=eng_table.c, line=150, thread=1772, number=16, address=0086E3B0 [04:21:51] 416 file=lhash.c, line=191, thread=1772, number=12, address=0086E338 [04:21:51] 258 file=stack.c, line=162, thread=1772, number=20, address=0086AC28 [04:21:51] 159 file=eng_lib.c, line=69, thread=1772, number=112, address=008661F0 [04:21:51] 54 file=eng_lib.c, line=69, thread=1772, number=112, address=00865978 [04:21:51] 228 file=buf_str.c, line=92, thread=1772, number=9, address=008680A0 [04:21:51] 244 file=lhash.c, line=122, thread=1772, number=64, address=0086BFF8 [04:21:51] 240 file=stack.c, line=162, thread=1772, number=20, address=0086ABC8 [04:21:51] 225 file=buf_str.c, line=92, thread=1772, number=9, address=00868040 [04:21:51] 413 file=eng_table.c, line=150, thread=1772, number=16, address=0086E2C0 [04:21:51] 53 file=eng_lib.c, line=168, thread=1772, number=4, address=00BBFFD8 [04:21:51] 415 file=stack.c, line=164, thread=1772, number=64, address=00871EE8 [04:21:51] 227 file=buf_str.c, line=92, thread=1772, number=18, address=0086A958 [04:21:51] 52 file=stack.c, line=164, thread=1772, number=64, address=00871E28 [04:21:51] 436 file=stack.c, line=164, thread=1772, number=32, address=00871E70 [04:21:51] 226 file=ameth_lib.c, line=289, thread=1772, number=108, address=0086A8E0 [04:21:51] 51 file=stack.c, line=162, thread=1772, number=20, address=00865958 [04:21:51] 432 file=lhash.c, line=122, thread=1772, number=64, address=00871DE0 [04:21:51] 243 file=lhash.c, line=120, thread=1772, number=96, address=0086BF90 [04:21:51] 46 file=eng_lib.c, line=69, thread=1772, number=112, address=008658E0 [04:21:51] 433 file=eng_lib.c, line=168, thread=1772, number=4, address=00869658 [04:21:51] 265 file=eng_table.c, line=150, thread=1772, number=16, address=008685C8 [04:21:51] 268 file=lhash.c, line=191, thread=1772, number=12, address=00868640 [04:21:51] 264 file=lhash.c, line=191, thread=1772, number=12, address=00868598 [04:21:51] 267 file=stack.c, line=164, thread=1772, number=16, address=00868610 [04:21:51] 263 file=stack.c, line=164, thread=1772, number=16, address=00868568 [04:21:51] 424 file=lhash.c, line=120, thread=1772, number=96, address=008695E0 4141 bytes leaked in 94 chunks test_sslv2conftest ../util/shlib_wrap.sh ./sslv2conftest SSLv2 CONF Test number 0 SSLv2 CONF Test number 1 [04:21:51] 420 file=eng_lib.c, line=168, thread=1164, number=4, address=020095F8 [04:21:51] 427 file=eng_lib.c, line=168, thread=1164, number=4, address=02009670 [04:21:51] 424 file=lhash.c, line=191, thread=1164, number=12, address=0200E478 [04:21:51] 428 file=eng_table.c, line=150, thread=1164, number=16, address=0200E4F0 [04:21:51] 456 file=stack.c, line=162, thread=1164, number=20, address=0200AE10 [04:21:51] 413 file=eng_lib.c, line=168, thread=1164, number=4, address=02009538 [04:21:51] 419 file=lhash.c, line=122, thread=1164, number=64, address=020095B0 [04:21:51] 417 file=lhash.c, line=191, thread=1164, number=12, address=0200E388 [04:21:51] 421 file=eng_table.c, line=150, thread=1164, number=16, address=0200E400 [04:21:51] 429 file=stack.c, line=162, thread=1164, number=20, address=0200ACF0 [04:21:51] 412 file=lhash.c, line=122, thread=1164, number=64, address=020094F0 [04:21:51] 267 file=stack.c, line=162, thread=1164, number=20, address=0200AC90 [04:21:51] 414 file=eng_table.c, line=150, thread=1164, number=16, address=0200E310 [04:21:51] 252 file=stack.c, line=162, thread=1164, number=20, address=0200AC30 [04:21:51] 237 file=stack.c, line=162, thread=1164, number=20, address=0200ABD0 [04:21:51] 54 file=eng_lib.c, line=168, thread=1164, number=4, address=00A2FFD0 [04:21:51] 234 file=lhash.c, line=122, thread=1164, number=64, address=0200AB70 [04:21:51] 258 file=eng_table.c, line=150, thread=1164, number=16, address=020044C0 [04:21:51] 437 file=stack.c, line=164, thread=1164, number=32, address=02011EA8 [04:21:51] 416 file=stack.c, line=164, thread=1164, number=64, address=02011F20 [04:21:51] 225 file=buf_str.c, line=92, thread=1164, number=18, address=0200A8E8 [04:21:51] 433 file=lhash.c, line=122, thread=1164, number=64, address=02011E18 [04:21:51] 261 file=lhash.c, line=191, thread=1164, number=12, address=02008530 [04:21:51] 53 file=stack.c, line=164, thread=1164, number=64, address=02011E60 [04:21:51] 260 file=stack.c, line=164, thread=1164, number=16, address=02008500 [04:21:51] 411 file=lhash.c, line=120, thread=1164, number=96, address=02009488 [04:21:51] 254 file=lhash.c, line=191, thread=1164, number=12, address=02008458 [04:21:51] 422 file=stack.c, line=162, thread=1164, number=20, address=0200ACD0 [04:21:51] 253 file=stack.c, line=164, thread=1164, number=16, address=02008428 [04:21:51] 224 file=ameth_lib.c, line=289, thread=1164, number=108, address=0200A870 [04:21:51] 221 file=ameth_lib.c, line=289, thread=1164, number=108, address=0200A7F8 [04:21:51] 263 file=stack.c, line=162, thread=1164, number=20, address=0200AC70 [04:21:51] 47 file=eng_lib.c, line=69, thread=1164, number=112, address=020058E8 [04:21:51] 248 file=stack.c, line=162, thread=1164, number=20, address=0200AC10 [04:21:51] 134 file=eng_lib.c, line=69, thread=1164, number=112, address=02009410 [04:21:51] 114 file=eng_lib.c, line=69, thread=1164, number=112, address=02008B98 [04:21:51] 251 file=eng_table.c, line=150, thread=1164, number=16, address=020083E0 [04:21:51] 247 file=eng_table.c, line=150, thread=1164, number=16, address=02008338 [04:21:51] 250 file=lhash.c, line=191, thread=1164, number=12, address=020083B0 [04:21:51] 220 file=eng_lib.c, line=69, thread=1164, number=112, address=0200A780 [04:21:51] 219 file=eng_lib.c, line=69, thread=1164, number=112, address=0200A708 [04:21:51] 233 file=lhash.c, line=120, thread=1164, number=96, address=0200AB08 [04:21:51] 249 file=stack.c, line=164, thread=1164, number=16, address=02008380 [04:21:51] 257 file=eng_lib.c, line=168, thread=1164, number=4, address=0200C128 [04:21:51] 240 file=eng_table.c, line=150, thread=1164, number=16, address=02008248 [04:21:51] 243 file=lhash.c, line=191, thread=1164, number=12, address=020082C0 [04:21:51] 196 file=eng_lib.c, line=69, thread=1164, number=112, address=02009E90 [04:21:51] 232 file=pmeth_lib.c, line=200, thread=1164, number=108, address=0200AA90 [04:21:51] 231 file=pmeth_lib.c, line=200, threSSLv2 CONF test: PASSED ad=1164, number=108, address=0200AA18 [04:21:51] 239 file=lhash.c, line=191, thread=1164, number=12, address=02008218 [04:21:51] 242 file=stack.c, line=164, thread=1164, number=16, address=02008290 [04:21:51] 238 file=stack.c, line=164, thread=1164, number=16, address=020081E8 [04:21:51] 235 file=eng_lib.c, line=168, thread=1164, number=4, address=02006308 [04:21:51] 246 file=eng_lib.c, line=168, thread=1164, number=4, address=0200C068 [04:21:51] 256 file=lhash.c, line=122, thread=1164, number=64, address=0200C0E0 [04:21:51] 457 file=stack.c, line=164, thread=1164, number=16, address=0200E8B0 [04:21:51] 223 file=buf_str.c, line=92, thread=1164, number=7, address=00A2FE00 [04:21:51] 99 file=eng_lib.c, line=69, thread=1164, number=112, address=02006B20 [04:21:51] 73 file=eng_lib.c, line=69, thread=1164, number=112, address=00A2FD88 [04:21:51] 230 file=pmeth_lib.c, line=200, thread=1164, number=108, address=0200A9A0 [04:21:51] 236 file=eng_table.c, line=150, thread=1164, number=16, address=020081A0 [04:21:51] 245 file=lhash.c, line=122, thread=1164, number=64, address=0200C020 [04:21:51] 430 file=stack.c, line=164, thread=1164, number=32, address=02011ED0 [04:21:51] 172 file=eng_lib.c, line=69, thread=1164, number=112, address=02006290 [04:21:51] 160 file=eng_lib.c, line=69, thread=1164, number=112, address=02006218 [04:21:51] 436 file=stack.c, line=162, thread=1164, number=20, address=0200AD10 [04:21:51] 229 file=buf_str.c, line=92, thread=1164, number=9, address=020080E0 [04:21:51] 415 file=stack.c, line=162, thread=1164, number=20, address=0200ACB0 [04:21:51] 222 file=buf_str.c, line=92, thread=1164, number=16, address=02008008 [04:21:51] 226 file=buf_str.c, line=92, thread=1164, number=9, address=02008080 [04:21:51] 426 file=lhash.c, line=122, thread=1164, number=64, address=02011D68 [04:21:51] 259 file=stack.c, line=162, thread=1164, number=20, address=0200AC50 [04:21:51] 55 file=eng_lib.c, line=69, thread=1164, number=112, address=020059A0 [04:21:51] 432 file=lhash.c, line=120, thread=1164, number=96, address=02011DB0 [04:21:51] 438 file=lhash.c, line=191, thread=1164, number=12, address=0200E658 [04:21:51] 241 file=stack.c, line=162, thread=1164, number=20, address=0200ABF0 [04:21:51] 431 file=lhash.c, line=191, thread=1164, number=12, address=0200E568 [04:21:51] 435 file=eng_table.c, line=150, thread=1164, number=16, address=0200E5E0 [04:21:51] 362 file=eng_lib.c, line=69, thread=1164, number=112, address=0200FD80 [04:21:51] 255 file=lhash.c, line=120, thread=1164, number=96, address=0200C078 [04:21:51] 423 file=stack.c, line=164, thread=1164, number=32, address=02011EF8 [04:21:51] 227 file=ameth_lib.c, line=289, thread=1164, number=108, address=0200A908 [04:21:51] 228 file=buf_str.c, line=92, thread=1164, number=18, address=0200A980 [04:21:51] 244 file=lhash.c, line=120, thread=1164, number=96, address=0200BFB8 [04:21:51] 52 file=stack.c, line=162, thread=1164, number=20, address=02005980 [04:21:51] 266 file=eng_table.c, line=150, thread=1164, number=16, address=02008608 [04:21:51] 425 file=lhash.c, line=120, thread=1164, number=96, address=02009608 [04:21:51] 269 file=lhash.c, line=191, thread=1164, number=12, address=02008680 [04:21:51] 434 file=eng_lib.c, line=168, thread=1164, number=4, address=02009680 [04:21:51] 265 file=lhash.c, line=191, thread=1164, number=12, address=020085D8 [04:21:51] 268 file=stack.c, line=164, thread=1164, number=16, address=02008650 [04:21:51] 264 file=stack.c, line=164, thread=1164, number=16, address=020085A8 [04:21:51] 418 file=lhash.c, line=120, thread=1164, number=96, address=02009548 [04:21:51] 262 file=eng_table.c, line=150, thread=1164, number=16, address=02008560 4141 bytes leaked in 94 chunks make[1]: Leaving directory `/src/openssl-1.0.2h/test' OPENSSL_CONF=apps/openssl.cnf util/opensslwrap.sh version -a OpenSSL 1.0.2h-fips 3 May 2016 built on: reproducible build, date unspecified platform: mingw options: bn(64,32) rc4(idx,int) des(ptr,risc1,16,long) idea(int) blowfish(idx) compiler: /mingw/bin/gcc.exe -I. -I.. -I../include -DZLIB -DOPENSSL_THREADS -D_MT -DDSO_WIN32 -DOPENSSL_SSL_CLIENT_ENGINE_AUTO=capi -DOPENSSL_CAPIENG_DIALOG -DL_ENDIAN -DWIN32_LEAN_AND_MEAN -DWINVER=0x0501 -D_WIN32_WINNT=0x0501 -D_WIN32_IE=0x0501 -DPTW32_STATIC_LIB -O0 -pipe -mms-bitfields -fno-builtin -march=i686 -mtune=i686 -fomit-frame-pointer -Wall -I/mingw/include OPENSSLDIR: "C:/OpenSSL" -------------- next part -------------- An HTML attachment was scrubbed... URL: From darshanmody at avaya.com Wed Jun 1 03:54:20 2016 From: darshanmody at avaya.com (Mody, Darshan (Darshan)) Date: Wed, 1 Jun 2016 03:54:20 +0000 Subject: [openssl-dev] Null Ciphers in FIPS mode Message-ID: <25D2EC755404B4409F263AC6D050FEBB25D5C9B5@AZ-FFEXMB03.global.avaya.com> Hi, Does Openssl allows NULL ciphers when we put openssl in FIPS mode? Thanks Darshan -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Wed Jun 1 09:11:14 2016 From: rt at openssl.org (noloader@gmail.com via RT) Date: Wed, 01 Jun 2016 09:11:14 +0000 Subject: [openssl-dev] [openssl.org #4379] "arch/async_posix.h:67:24: error: ucontext.h: No such file or directory" under OpenBSD 5.7/64-bit In-Reply-To: References: Message-ID: Hi Matt, I'm testing this now. Jeff On Tue, May 24, 2016 at 6:42 PM, Matt Caswell via RT wrote: > On Wed May 11 10:24:31 2016, matt wrote: >> Hi Jeff >> >> Please could you try the attached patch? > > Hi Jeff > > Were you able to try out the patch? > > Thanks > > Matt > > -- > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4379 > Please log in as guest with password guest if prompted > -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4379 Please log in as guest with password guest if prompted From rt at openssl.org Wed Jun 1 09:17:18 2016 From: rt at openssl.org (noloader@gmail.com via RT) Date: Wed, 01 Jun 2016 09:17:18 +0000 Subject: [openssl-dev] [openssl.org #4379] "arch/async_posix.h:67:24: error: ucontext.h: No such file or directory" under OpenBSD 5.7/64-bit In-Reply-To: References: Message-ID: > Please could you try the attached patch? It tested OK. 'make test' executed without any problems. Ship it and close the ticket. Jeff On Wed, May 11, 2016 at 6:24 AM, Matt Caswell via RT wrote: > On Sat Mar 05 02:22:00 2016, noloader at gmail.com wrote: >> cc -I.. -I../.. -I../modes -I../include -I../../include -DDSO_DLFCN >> -DHAVE_DLFCN_H -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE >> -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/engines\"" -DL_ENDIAN -Wall -O3 >> -pthread -D_THREAD_SAFE -D_REENTRANT -Wa,--noexecstack -fPIC -c >> async.c -o async.o >> In file included from async_locl.h:69, >> from async.c:62: >> arch/async_posix.h:67:24: error: ucontext.h: No such file or directory >> In file included from async_locl.h:69, >> from async.c:62: >> arch/async_posix.h: In function 'async_fibre_swapcontext': >> arch/async_posix.h:85: warning: implicit declaration of function >> 'setcontext' >> *** Error 1 in crypto/async (Makefile:65 'async.o') >> *** Error 1 in crypto (Makefile:91 'subdirs') >> *** Error 1 in /home/jwalton/openssl (Makefile:291 'build_crypto') > > Hi Jeff > > Please could you try the attached patch? > > Thanks > -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4379 Please log in as guest with password guest if prompted From rt at openssl.org Wed Jun 1 09:56:49 2016 From: rt at openssl.org (Matt Caswell via RT) Date: Wed, 01 Jun 2016 09:56:49 +0000 Subject: [openssl-dev] [openssl.org #4379] "arch/async_posix.h:67:24: error: ucontext.h: No such file or directory" under OpenBSD 5.7/64-bit In-Reply-To: References: Message-ID: On Wed Jun 01 09:17:18 2016, noloader at gmail.com wrote: > > Please could you try the attached patch? > > It tested OK. 'make test' executed without any problems. Ship it and > close the ticket. Pushed in commit e51329d38. Closing ticket. Thanks Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4379 Please log in as guest with password guest if prompted From aeh at db.org Wed Jun 1 10:15:29 2016 From: aeh at db.org (Alfred E. Heggestad) Date: Wed, 1 Jun 2016 12:15:29 +0200 Subject: [openssl-dev] DTLS retransmission api Message-ID: <574EB5C1.4060005@db.org> hi, we are using DTLS from OpenSSL to implement DTLS-SRTP in our product (Wire.com) .. The code and implementation works really well and is very robust. We are using OpenSSL version 1.0.2g since our product is deployed globally on mobile data networks, we have quite variable latency and packetloss. The patch below shows my working code, it has an initial retransmit timeout of 400 ms which is incrementing by 10% for every re-trans. obviously this patch cannot make it into the official tree. but I would like to discuss with you guys the option to add some kind of API for: - Setting the initial RTO for DTLS (in milliseconds). - Setting the retransmit policy for DTLS, i.e. should it double or increment by X for every re-trans. in addition we have seen the code hit this assert in production: /*OPENSSL_assert(0);*/ /* XDTLS: want to see if we ever get here */ so I would say it should be safe to remove it. Best Regards, Alfred E. Heggestad Berlin -- diff -Naur openssl-1.0.2g/ssl/d1_lib.c openssl/ssl/d1_lib.c --- openssl-1.0.2g/ssl/d1_lib.c 2016-03-01 14:35:53.000000000 +0100 +++ openssl/ssl/d1_lib.c 2016-06-01 10:45:27.000000000 +0200 @@ -359,6 +359,8 @@ void dtls1_start_timer(SSL *s) { + struct timeval diff; + #ifndef OPENSSL_NO_SCTP /* Disable timer for SCTP */ if (BIO_dgram_is_sctp(SSL_get_wbio(s))) { @@ -369,14 +371,17 @@ /* If timer is not set, initialize duration with 1 second */ if (s->d1->next_timeout.tv_sec == 0 && s->d1->next_timeout.tv_usec == 0) { - s->d1->timeout_duration = 1; + s->d1->timeout_duration = 0.400; } /* Set timeout to current time */ get_current_time(&(s->d1->next_timeout)); /* Add duration to current time */ - s->d1->next_timeout.tv_sec += s->d1->timeout_duration; + diff.tv_sec = 0; + diff.tv_usec = 1000000*s->d1->timeout_duration; + timeradd(&s->d1->next_timeout, &diff, &s->d1->next_timeout); + BIO_ctrl(SSL_get_rbio(s), BIO_CTRL_DGRAM_SET_NEXT_TIMEOUT, 0, &(s->d1->next_timeout)); } @@ -441,7 +446,7 @@ void dtls1_double_timeout(SSL *s) { - s->d1->timeout_duration *= 2; + s->d1->timeout_duration *= 1.10; if (s->d1->timeout_duration > 60) s->d1->timeout_duration = 60; dtls1_start_timer(s); diff -Naur openssl-1.0.2g/ssl/d1_pkt.c openssl/ssl/d1_pkt.c --- openssl-1.0.2g/ssl/d1_pkt.c 2016-03-01 14:35:53.000000000 +0100 +++ openssl/ssl/d1_pkt.c 2016-03-08 14:39:44.000000000 +0100 @@ -1502,7 +1502,7 @@ * will happen with non blocking IO */ if (s->s3->wbuf.left != 0) { - OPENSSL_assert(0); /* XDTLS: want to see if we ever get here */ + /*OPENSSL_assert(0);*/ /* XDTLS: want to see if we ever get here */ return (ssl3_write_pending(s, type, buf, len)); } diff -Naur openssl-1.0.2g/ssl/dtls1.h openssl/ssl/dtls1.h --- openssl-1.0.2g/ssl/dtls1.h 2016-03-01 14:35:53.000000000 +0100 +++ openssl/ssl/dtls1.h 2016-03-08 14:39:44.000000000 +0100 @@ -225,8 +225,8 @@ * Indicates when the last handshake msg or heartbeat sent will timeout */ struct timeval next_timeout; - /* Timeout duration */ - unsigned short timeout_duration; + /* Timeout duration in Seconds */ + double timeout_duration; /* * storage for Alert/Handshake protocol data received but not yet * processed by ssl3_read_bytes: From matt at openssl.org Wed Jun 1 11:58:04 2016 From: matt at openssl.org (Matt Caswell) Date: Wed, 1 Jun 2016 12:58:04 +0100 Subject: [openssl-dev] DTLS retransmission api In-Reply-To: <574EB5C1.4060005@db.org> References: <574EB5C1.4060005@db.org> Message-ID: <574ECDCC.6000607@openssl.org> On 01/06/16 11:15, Alfred E. Heggestad wrote: > hi, > > we are using DTLS from OpenSSL to implement DTLS-SRTP in our > product (Wire.com) .. The code and implementation works really well > and is very robust. We are using OpenSSL version 1.0.2g > > > since our product is deployed globally on mobile data networks, > we have quite variable latency and packetloss. The patch below > shows my working code, it has an initial retransmit timeout > of 400 ms which is incrementing by 10% for every re-trans. > > > obviously this patch cannot make it into the official tree. > > > but I would like to discuss with you guys the option to > add some kind of API for: > > - Setting the initial RTO for DTLS (in milliseconds). > - Setting the retransmit policy for DTLS, i.e. should it > double or increment by X for every re-trans. I think an API for that would be a great idea. Perhaps a callback could be used so that you can set exactly the policy you want? > > > in addition we have seen the code hit this assert > in production: > > > /*OPENSSL_assert(0);*/ /* XDTLS: want to see if we ever get here */ > > > so I would say it should be safe to remove it. Hmmmmm....the question is why does it get there? It shouldn't. Matt > > > > > Best Regards, > > Alfred E. Heggestad > Berlin > > > > -- > > diff -Naur openssl-1.0.2g/ssl/d1_lib.c openssl/ssl/d1_lib.c > --- openssl-1.0.2g/ssl/d1_lib.c 2016-03-01 14:35:53.000000000 +0100 > +++ openssl/ssl/d1_lib.c 2016-06-01 10:45:27.000000000 +0200 > @@ -359,6 +359,8 @@ > > void dtls1_start_timer(SSL *s) > { > + struct timeval diff; > + > #ifndef OPENSSL_NO_SCTP > /* Disable timer for SCTP */ > if (BIO_dgram_is_sctp(SSL_get_wbio(s))) { > @@ -369,14 +371,17 @@ > > /* If timer is not set, initialize duration with 1 second */ > if (s->d1->next_timeout.tv_sec == 0 && s->d1->next_timeout.tv_usec > == 0) { > - s->d1->timeout_duration = 1; > + s->d1->timeout_duration = 0.400; > } > > /* Set timeout to current time */ > get_current_time(&(s->d1->next_timeout)); > > /* Add duration to current time */ > - s->d1->next_timeout.tv_sec += s->d1->timeout_duration; > + diff.tv_sec = 0; > + diff.tv_usec = 1000000*s->d1->timeout_duration; > + timeradd(&s->d1->next_timeout, &diff, &s->d1->next_timeout); > + > BIO_ctrl(SSL_get_rbio(s), BIO_CTRL_DGRAM_SET_NEXT_TIMEOUT, 0, > &(s->d1->next_timeout)); > } > @@ -441,7 +446,7 @@ > > void dtls1_double_timeout(SSL *s) > { > - s->d1->timeout_duration *= 2; > + s->d1->timeout_duration *= 1.10; > if (s->d1->timeout_duration > 60) > s->d1->timeout_duration = 60; > dtls1_start_timer(s); > diff -Naur openssl-1.0.2g/ssl/d1_pkt.c openssl/ssl/d1_pkt.c > --- openssl-1.0.2g/ssl/d1_pkt.c 2016-03-01 14:35:53.000000000 +0100 > +++ openssl/ssl/d1_pkt.c 2016-03-08 14:39:44.000000000 +0100 > @@ -1502,7 +1502,7 @@ > * will happen with non blocking IO > */ > if (s->s3->wbuf.left != 0) { > - OPENSSL_assert(0); /* XDTLS: want to see if we ever get > here */ > + /*OPENSSL_assert(0);*/ /* XDTLS: want to see if we ever > get here */ > return (ssl3_write_pending(s, type, buf, len)); > } > > diff -Naur openssl-1.0.2g/ssl/dtls1.h openssl/ssl/dtls1.h > --- openssl-1.0.2g/ssl/dtls1.h 2016-03-01 14:35:53.000000000 +0100 > +++ openssl/ssl/dtls1.h 2016-03-08 14:39:44.000000000 +0100 > @@ -225,8 +225,8 @@ > * Indicates when the last handshake msg or heartbeat sent will > timeout > */ > struct timeval next_timeout; > - /* Timeout duration */ > - unsigned short timeout_duration; > + /* Timeout duration in Seconds */ > + double timeout_duration; > /* > * storage for Alert/Handshake protocol data received but not yet > * processed by ssl3_read_bytes: > > From rt at openssl.org Wed Jun 1 12:24:23 2016 From: rt at openssl.org (Matt Caswell via RT) Date: Wed, 01 Jun 2016 12:24:23 +0000 Subject: [openssl-dev] [openssl.org #4244] dhparam -check should In-Reply-To: <892C51C9-EDF8-436A-8E58-F440C4145ECB@akamai.com> References: <892C51C9-EDF8-436A-8E58-F440C4145ECB@akamai.com> Message-ID: dhparam will never generate parameters that fail DH_check(). It would be an internal error if it did. I added a sanity check anyway and also brought the documentation up to date. Commit eeb21772e. Closing this ticket. Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4244 Please log in as guest with password guest if prompted From rsalz at akamai.com Wed Jun 1 12:32:04 2016 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 1 Jun 2016 12:32:04 +0000 Subject: [openssl-dev] Null Ciphers in FIPS mode In-Reply-To: <25D2EC755404B4409F263AC6D050FEBB25D5C9B5@AZ-FFEXMB03.global.avaya.com> References: <25D2EC755404B4409F263AC6D050FEBB25D5C9B5@AZ-FFEXMB03.global.avaya.com> Message-ID: <6336952607ad423b97d86e0c4862292f@usma1ex-dag1mb1.msg.corp.akamai.com> FIPS does not allow NULL ciphers, so no. -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz From: Mody, Darshan (Darshan) [mailto:darshanmody at avaya.com] Sent: Tuesday, May 31, 2016 11:54 PM To: openssl-dev at openssl.org Subject: [openssl-dev] Null Ciphers in FIPS mode Hi, Does Openssl allows NULL ciphers when we put openssl in FIPS mode? Thanks Darshan -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Wed Jun 1 12:47:12 2016 From: rt at openssl.org (Rich Salz via RT) Date: Wed, 01 Jun 2016 12:47:12 +0000 Subject: [openssl-dev] [openssl.org #4388] [PATCH] Don't be sensitive to the order of ALPN and NPN. In-Reply-To: References: Message-ID: Fixed in a different way by commit 0351baae36afe1182237e0bd88ec9d13f5c97f32 -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4388 Please log in as guest with password guest if prompted From rt at openssl.org Wed Jun 1 13:27:58 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Wed, 01 Jun 2016 13:27:58 +0000 Subject: [openssl-dev] [openssl.org #4458] "implicitly declared function" warnings due to missing include In-Reply-To: References: Message-ID: This has been fixed in commit 7233bea263 Closing this ticket. Cheers, Richard On Wed May 25 21:46:01 2016, levitte wrote: > I don't get such warnings. Can you tell me what system and with what > tool chain > (including versions)? > > On Sun Mar 20 13:07:43 2016, noloader at gmail.com wrote: > > The missing include caused a number of "implicitly > > declared function" warnings due to use of strcmpcase and strncmpcase. > > > > $ egrep -IR '(strcasecmp|strncasecmp)' * | cut -f 1 -d ':' | sort | > > uniq > > apps/apps.c > > apps/ca.c > > apps/ocsp.c > > apps/rehash.c > > apps/s_server.c > > crypto/asn1/ameth_lib.c > > crypto/engine/tb_asnmth.c > > crypto/o_str.c > > crypto/x509v3/v3_ncons.c > > crypto/x509v3/v3_tlsf.c > > crypto/x509v3/v3_utl.c > > e_os.h > > include/internal/o_str.h > > ssl/ssl_conf.c > > test/ssltest.c > > test/v3nametest.c > > > > > -- > Richard Levitte > levitte at openssl.org -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4458 Please log in as guest with password guest if prompted From rt at openssl.org Wed Jun 1 13:29:48 2016 From: rt at openssl.org (Rich Salz via RT) Date: Wed, 01 Jun 2016 13:29:48 +0000 Subject: [openssl-dev] [openssl.org #4337] SEGV Fault in the DES_fcrypt In-Reply-To: References: Message-ID: Fixed in commit 6493e48. -- 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 Wed Jun 1 14:46:32 2016 From: rt at openssl.org (Rich Salz via RT) Date: Wed, 01 Jun 2016 14:46:32 +0000 Subject: [openssl-dev] [openssl.org #2630] Segmentation-fault in ssleay_rand_bytes() after generating a large (INT_MAX) random buffer In-Reply-To: <4FC9889C08DD8B4CA45FFA819B58E9FF018912F4E3F4@DEACCRX001.deac.awl.atosorigin.net> References: <4FC9889C08DD8B4CA45FFA819B58E9FF018912F4E3F4@DEACCRX001.deac.awl.atosorigin.net> Message-ID: Fixed in master (1.1) with commit 0f91e1d -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2630 Please log in as guest with password guest if prompted From rt at openssl.org Wed Jun 1 14:46:57 2016 From: rt at openssl.org (Rich Salz via RT) Date: Wed, 01 Jun 2016 14:46:57 +0000 Subject: [openssl-dev] [openssl.org #2877] openssl rand does not check write(2) return code In-Reply-To: <20120912105435.GA5972@vogel.cx> References: <20120912105435.GA5972@vogel.cx> Message-ID: Fixed in master with commit 0f91e1d. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2877 Please log in as guest with password guest if prompted From xoloki at gmail.com Wed Jun 1 17:14:45 2016 From: xoloki at gmail.com (Joey Yandle) Date: Wed, 1 Jun 2016 10:14:45 -0700 Subject: [openssl-dev] [OpenSSL][1.0.2h] Memory leaks In-Reply-To: References: <5343CAC0.2010103@gmail.com> Message-ID: <574F1805.9080203@gmail.com> I tried to reproduce this last night, on the following platforms: linux x86_64 fips windows win64a fips windows mingw64 fips make test succeeded with no errors on the first two platforms. For windows/mingw64, though, I did get a different error: test SSL protocol test ssl3 is forbidden in FIPS mode 180668:error:2D07808C:FIPS routines:FIPS_module_mode_set:unsupported platform:fips.c:322: ssl2 disabled: skipping test test tls1 181056:error:2D07808C:FIPS routines:FIPS_module_mode_set:unsupported platform:fips.c:322: make[1]: *** [test_ssl] Error 1 make[1]: Leaving directory `/c/src/openssl-1.0.2h/test' make: *** [tests] Error 2 However, if I do make -k test, then I finish without the memory leaks you saw: ALL OCSP TESTS SUCCESSFUL Test X509v3_check_* ../util/shlib_wrap.sh ./v3nametest ../util/shlib_wrap.sh ./heartbeat_test Test constant time utilites ../util/shlib_wrap.sh ./constant_time_test Testing constant time operations... ok (ran 1908 tests) test_verify_extra ../util/shlib_wrap.sh ./verify_extra_test PASS test_clienthello ../util/shlib_wrap.sh ./clienthellotest test_sslv2conftest ../util/shlib_wrap.sh ./sslv2conftest SSLv2 CONF Test number 0 SSLv2 CONF Test number 1 SSLv2 CONF test: PASSED How did you configure/build? What versions of mingw/msys did you use? cheers, Joey On 05/31/2016 08:37 PM, Sergio NNX wrote: > Ciao. > > Just built OpenSSL 1.0.2h from source and when running the tests I can > see some memory leaks. > The same did not happen when building previous versions on the same > environment and same command line options. > > Thanks in advance. > > Find below the last bit of a long long long test output: > > ... > ... > ... > ALL OCSP TESTS SUCCESSFUL > Test X509v3_check_* > ../util/shlib_wrap.sh ./v3nametest > ../util/shlib_wrap.sh ./heartbeat_test > Test constant time utilites > ../util/shlib_wrap.sh ./constant_time_test > Testing constant time operations... > ok (ran 1908 tests) > test_verify_extra > ../util/shlib_wrap.sh ./verify_extra_test > PASS > test_clienthello > ../util/shlib_wrap.sh ./clienthellotest > [04:21:51] 221 file=buf_str.c, line=92, thread=1772, number=16, > address=00867FC8 > [04:21:51] 426 file=eng_lib.c, line=168, thread=1772, number=4, > address=00869648 > [04:21:51] 455 file=stack.c, line=162, thread=1772, number=20, > address=0086ADE8 > [04:21:51] 418 file=lhash.c, line=122, thread=1772, number=64, > address=00869588 > [04:21:51] 222 file=buf_str.c, line=92, thread=1772, number=7, > address=00BBFDC8 > [04:21:51] 419 file=eng_lib.c, line=168, thread=1772, number=4, > address=008695D0 > [04:21:51] 411 file=lhash.c, line=122, thread=1772, number=64, > address=008694C8 > [04:21:51] 428 file=stack.c, line=162, thread=1772, number=20, > address=0086ACC8 > [04:21:51] 412 file=eng_lib.c, line=168, thread=1772, number=4, > address=00869510 > [04:21:51] 266 file=stack.c, line=162, thread=1772, number=20, > address=0086AC68 > [04:21:51] 72 file=eng_lib.c, line=69, thread=1772, number=112, > address=00BBFD50 > [04:21:51] 251 file=stack.c, line=162, thread=1772, number=20, > address=0086AC08 > [04:21:51] 236 file=stack.c, line=162, thread=1772, number=20, > address=0086ABA8 > [04:21:51] 233 file=lhash.c, line=122, thread=1772, number=64, > address=0086AB48 > [04:21:51] 234 file=eng_lib.c, line=168, thread=1772, number=4, > address=00BB27F0 > [04:21:51] 255 file=lhash.c, line=122, thread=1772, number=64, > address=0086C0A8 > [04:21:51] 256 file=eng_lib.c, line=168, thread=1772, number=4, > address=0086C0F0 > [04:21:51] 429 file=stack.c, line=164, thread=1772, number=32, > address=00871E98 > [04:21:51] 456 file=stack.c, line=164, thread=1772, number=16, > address=0086E860 > [04:21:51] 261 file=eng_table.c, line=150, thread=1772, number=16, > address=00868520 > [04:21:51] 417 file=lhash.c, line=120, thread=1772, number=96, > address=00869520 > [04:21:51] 421 file=stack.c, line=162, thread=1772, number=20, > address=0086ACA8 > [04:21:51] 260 file=lhash.c, line=191, thread=1772, number=12, > address=008684F0 > [04:21:51] 224 file=buf_str.c, line=92, thread=1772, number=18, > address=0086A8C0 > [04:21:51] 223 file=ameth_lib.c, line=289, thread=1772, number=108, > address=0086A848 > [04:21:51] 259 file=stack.c, line=164, thread=1772, number=16, > address=008684C0 > [04:21:51] 262 file=stack.c, line=162, thread=1772, number=20, > address=0086AC48 > [04:21:51] 431 file=lhash.c, line=120, thread=1772, number=96, > address=00871D78 > [04:21:51] 253 file=lhash.c, line=191, thread=1772, number=12, > address=00868418 > [04:21:51] 247 file=stack.c, line=162, thread=1772, number=20, > address=0086ABE8 > [04:21:51] 133 file=eng_lib.c, line=69, thread=1772, number=112, > address=008693E8 > [04:21:51] 252 file=stack.c, line=164, thread=1772, number=16, > address=008683E8 > [04:21:51] 410 file=lhash.c, line=120, thread=1772, number=96, > address=00869460 > [04:21:51] 220 file=ameth_lib.c, line=289, thread=1772, number=108, > address=0086A7D0 > [04:21:51] 219 file=eng_lib.c, line=69, thread=1772, number=112, > address=0086A758 > [04:21:51] 425 file=lhash.c, line=122, thread=1772, number=64, > address=00871D30 > [04:21:51] 437 file=lhash.c, line=191, thread=1772, number=12, > address=0086E608 > [04:21:51] 257 file=eng_table.c, line=150, thread=1772, number=16, > address=008644A8 > [04:21:51] 250 file=eng_table.c, line=150, thread=1772, number=16, > address=008683A0 > [04:21:51] 113 file=eng_lib.c, line=69, thread=1772, number=112, > address=00868B70 > [04:21:51] 246 file=eng_table.c, line=150, thread=1772, number=16, > address=008682F8 > [04:21:51] 249 file=lhash.c, line=191, thread=1772, number=12, > address=00868370 > [04:21:51] 248 file=stack.c, line=164, thread=1772, number=16, > address=00868340 > [04:21:51] 361 file=eng_lib.c, line=69, thread=1772, number=112, > address=0086FD48 > [04:21:51] 195 file=eng_lib.c, line=69, thread=1772, number=112, > address=00869E68 > [04:21:51] 218 file=eng_lib.c, line=69, thread=1772, number=112, > address=0086A6E0 > [04:21:51] 434 file=eng_table.c, line=150, thread=1772, number=16, > address=0086E590 > [04:21:51] 430 file=lhash.c, line=191, thread=1772, number=12, > address=0086E518 > [04:21:51] 231 file=pmeth_lib.c, line=200, thread=1772, number=108, > address=0086AA68 > [04:21:51] 232 file=lhash.c, line=120, thread=1772, number=96, > address=0086AAE0 > [04:21:51] 242 file=lhash.c, line=191, thread=1772, number=12, > address=00868280 > [04:21:51] 239 file=eng_table.c, line=150, thread=1772, number=16, > address=00868208 > [04:21:51] 241 file=stack.c, line=164, thread=1772, number=16, > address=00868250 > [04:21:51] 238 file=lhash.c, line=191, thread=1772, number=12, > address=008681D8 > [04:21:51] 98 file=eng_lib.c, line=69, thread=1772, number=112, > address=00866AF8 > [04:21:51] 237 file=stack.c, line=164, thread=1772, number=16, > address=008681A8 > [04:21:51] 427 file=eng_table.c, line=150, thread=1772, number=16, > address=0086E4A0 > [04:21:51] 423 file=lhash.c, line=191, thread=1772, number=12, > address=0086E428 > [04:21:51] 229 file=pmeth_lib.c, line=200, thread=1772, number=108, > address=0086A978 > [04:21:51] 230 file=pmeth_lib.c, line=200, thread=1772, number=108, > address=0086A9F0 > [04:21:51] 245 file=eng_lib.c, line=168, thread=1772, number=4, > address=008662E0 > [04:21:51] 254 file=lhash.c, line=120, thread=1772, number=96, > address=0086C040 > [04:21:51] 171 file=eng_lib.c, line=69, thread=1772, number=112, > address=00866268 > [04:21:51] 435 file=stack.c, line=162, thread=1772, number=20, > address=0086ACE8 > [04:21:51] 235 file=eng_table.c, line=150, thread=1772, number=16, > address=00868160 > [04:21:51] 422 file=stack.c, line=164, thread=1772, number=32, > address=00871EC0 > [04:21:51] 414 file=stack.c, line=162, thread=1772, number=20, > address=0086AC88 > [04:21:51] 420 file=eng_table.c, line=150, thread=1772, number=16, > address=0086E3B0 > [04:21:51] 416 file=lhash.c, line=191, thread=1772, number=12, > address=0086E338 > [04:21:51] 258 file=stack.c, line=162, thread=1772, number=20, > address=0086AC28 > [04:21:51] 159 file=eng_lib.c, line=69, thread=1772, number=112, > address=008661F0 > [04:21:51] 54 file=eng_lib.c, line=69, thread=1772, number=112, > address=00865978 > [04:21:51] 228 file=buf_str.c, line=92, thread=1772, number=9, > address=008680A0 > [04:21:51] 244 file=lhash.c, line=122, thread=1772, number=64, > address=0086BFF8 > [04:21:51] 240 file=stack.c, line=162, thread=1772, number=20, > address=0086ABC8 > [04:21:51] 225 file=buf_str.c, line=92, thread=1772, number=9, > address=00868040 > [04:21:51] 413 file=eng_table.c, line=150, thread=1772, number=16, > address=0086E2C0 > [04:21:51] 53 file=eng_lib.c, line=168, thread=1772, number=4, > address=00BBFFD8 > [04:21:51] 415 file=stack.c, line=164, thread=1772, number=64, > address=00871EE8 > [04:21:51] 227 file=buf_str.c, line=92, thread=1772, number=18, > address=0086A958 > [04:21:51] 52 file=stack.c, line=164, thread=1772, number=64, > address=00871E28 > [04:21:51] 436 file=stack.c, line=164, thread=1772, number=32, > address=00871E70 > [04:21:51] 226 file=ameth_lib.c, line=289, thread=1772, number=108, > address=0086A8E0 > [04:21:51] 51 file=stack.c, line=162, thread=1772, number=20, > address=00865958 > [04:21:51] 432 file=lhash.c, line=122, thread=1772, number=64, > address=00871DE0 > [04:21:51] 243 file=lhash.c, line=120, thread=1772, number=96, > address=0086BF90 > [04:21:51] 46 file=eng_lib.c, line=69, thread=1772, number=112, > address=008658E0 > [04:21:51] 433 file=eng_lib.c, line=168, thread=1772, number=4, > address=00869658 > [04:21:51] 265 file=eng_table.c, line=150, thread=1772, number=16, > address=008685C8 > [04:21:51] 268 file=lhash.c, line=191, thread=1772, number=12, > address=00868640 > [04:21:51] 264 file=lhash.c, line=191, thread=1772, number=12, > address=00868598 > [04:21:51] 267 file=stack.c, line=164, thread=1772, number=16, > address=00868610 > [04:21:51] 263 file=stack.c, line=164, thread=1772, number=16, > address=00868568 > [04:21:51] 424 file=lhash.c, line=120, thread=1772, number=96, > address=008695E0 > 4141 bytes leaked in 94 chunks > test_sslv2conftest > ../util/shlib_wrap.sh ./sslv2conftest > SSLv2 CONF Test number 0 > SSLv2 CONF Test number 1 > [04:21:51] 420 file=eng_lib.c, line=168, thread=1164, number=4, > address=020095F8 > [04:21:51] 427 file=eng_lib.c, line=168, thread=1164, number=4, > address=02009670 > [04:21:51] 424 file=lhash.c, line=191, thread=1164, number=12, > address=0200E478 > [04:21:51] 428 file=eng_table.c, line=150, thread=1164, number=16, > address=0200E4F0 > [04:21:51] 456 file=stack.c, line=162, thread=1164, number=20, > address=0200AE10 > [04:21:51] 413 file=eng_lib.c, line=168, thread=1164, number=4, > address=02009538 > [04:21:51] 419 file=lhash.c, line=122, thread=1164, number=64, > address=020095B0 > [04:21:51] 417 file=lhash.c, line=191, thread=1164, number=12, > address=0200E388 > [04:21:51] 421 file=eng_table.c, line=150, thread=1164, number=16, > address=0200E400 > [04:21:51] 429 file=stack.c, line=162, thread=1164, number=20, > address=0200ACF0 > [04:21:51] 412 file=lhash.c, line=122, thread=1164, number=64, > address=020094F0 > [04:21:51] 267 file=stack.c, line=162, thread=1164, number=20, > address=0200AC90 > [04:21:51] 414 file=eng_table.c, line=150, thread=1164, number=16, > address=0200E310 > [04:21:51] 252 file=stack.c, line=162, thread=1164, number=20, > address=0200AC30 > [04:21:51] 237 file=stack.c, line=162, thread=1164, number=20, > address=0200ABD0 > [04:21:51] 54 file=eng_lib.c, line=168, thread=1164, number=4, > address=00A2FFD0 > [04:21:51] 234 file=lhash.c, line=122, thread=1164, number=64, > address=0200AB70 > [04:21:51] 258 file=eng_table.c, line=150, thread=1164, number=16, > address=020044C0 > [04:21:51] 437 file=stack.c, line=164, thread=1164, number=32, > address=02011EA8 > [04:21:51] 416 file=stack.c, line=164, thread=1164, number=64, > address=02011F20 > [04:21:51] 225 file=buf_str.c, line=92, thread=1164, number=18, > address=0200A8E8 > [04:21:51] 433 file=lhash.c, line=122, thread=1164, number=64, > address=02011E18 > [04:21:51] 261 file=lhash.c, line=191, thread=1164, number=12, > address=02008530 > [04:21:51] 53 file=stack.c, line=164, thread=1164, number=64, > address=02011E60 > [04:21:51] 260 file=stack.c, line=164, thread=1164, number=16, > address=02008500 > [04:21:51] 411 file=lhash.c, line=120, thread=1164, number=96, > address=02009488 > [04:21:51] 254 file=lhash.c, line=191, thread=1164, number=12, > address=02008458 > [04:21:51] 422 file=stack.c, line=162, thread=1164, number=20, > address=0200ACD0 > [04:21:51] 253 file=stack.c, line=164, thread=1164, number=16, > address=02008428 > [04:21:51] 224 file=ameth_lib.c, line=289, thread=1164, number=108, > address=0200A870 > [04:21:51] 221 file=ameth_lib.c, line=289, thread=1164, number=108, > address=0200A7F8 > [04:21:51] 263 file=stack.c, line=162, thread=1164, number=20, > address=0200AC70 > [04:21:51] 47 file=eng_lib.c, line=69, thread=1164, number=112, > address=020058E8 > [04:21:51] 248 file=stack.c, line=162, thread=1164, number=20, > address=0200AC10 > [04:21:51] 134 file=eng_lib.c, line=69, thread=1164, number=112, > address=02009410 > [04:21:51] 114 file=eng_lib.c, line=69, thread=1164, number=112, > address=02008B98 > [04:21:51] 251 file=eng_table.c, line=150, thread=1164, number=16, > address=020083E0 > [04:21:51] 247 file=eng_table.c, line=150, thread=1164, number=16, > address=02008338 > [04:21:51] 250 file=lhash.c, line=191, thread=1164, number=12, > address=020083B0 > [04:21:51] 220 file=eng_lib.c, line=69, thread=1164, number=112, > address=0200A780 > [04:21:51] 219 file=eng_lib.c, line=69, thread=1164, number=112, > address=0200A708 > [04:21:51] 233 file=lhash.c, line=120, thread=1164, number=96, > address=0200AB08 > [04:21:51] 249 file=stack.c, line=164, thread=1164, number=16, > address=02008380 > [04:21:51] 257 file=eng_lib.c, line=168, thread=1164, number=4, > address=0200C128 > [04:21:51] 240 file=eng_table.c, line=150, thread=1164, number=16, > address=02008248 > [04:21:51] 243 file=lhash.c, line=191, thread=1164, number=12, > address=020082C0 > [04:21:51] 196 file=eng_lib.c, line=69, thread=1164, number=112, > address=02009E90 > [04:21:51] 232 file=pmeth_lib.c, line=200, thread=1164, number=108, > address=0200AA90 > [04:21:51] 231 file=pmeth_lib.c, line=200, threSSLv2 CONF test: PASSED > ad=1164, number=108, address=0200AA18 > [04:21:51] 239 file=lhash.c, line=191, thread=1164, number=12, > address=02008218 > [04:21:51] 242 file=stack.c, line=164, thread=1164, number=16, > address=02008290 > [04:21:51] 238 file=stack.c, line=164, thread=1164, number=16, > address=020081E8 > [04:21:51] 235 file=eng_lib.c, line=168, thread=1164, number=4, > address=02006308 > [04:21:51] 246 file=eng_lib.c, line=168, thread=1164, number=4, > address=0200C068 > [04:21:51] 256 file=lhash.c, line=122, thread=1164, number=64, > address=0200C0E0 > [04:21:51] 457 file=stack.c, line=164, thread=1164, number=16, > address=0200E8B0 > [04:21:51] 223 file=buf_str.c, line=92, thread=1164, number=7, > address=00A2FE00 > [04:21:51] 99 file=eng_lib.c, line=69, thread=1164, number=112, > address=02006B20 > [04:21:51] 73 file=eng_lib.c, line=69, thread=1164, number=112, > address=00A2FD88 > [04:21:51] 230 file=pmeth_lib.c, line=200, thread=1164, number=108, > address=0200A9A0 > [04:21:51] 236 file=eng_table.c, line=150, thread=1164, number=16, > address=020081A0 > [04:21:51] 245 file=lhash.c, line=122, thread=1164, number=64, > address=0200C020 > [04:21:51] 430 file=stack.c, line=164, thread=1164, number=32, > address=02011ED0 > [04:21:51] 172 file=eng_lib.c, line=69, thread=1164, number=112, > address=02006290 > [04:21:51] 160 file=eng_lib.c, line=69, thread=1164, number=112, > address=02006218 > [04:21:51] 436 file=stack.c, line=162, thread=1164, number=20, > address=0200AD10 > [04:21:51] 229 file=buf_str.c, line=92, thread=1164, number=9, > address=020080E0 > [04:21:51] 415 file=stack.c, line=162, thread=1164, number=20, > address=0200ACB0 > [04:21:51] 222 file=buf_str.c, line=92, thread=1164, number=16, > address=02008008 > [04:21:51] 226 file=buf_str.c, line=92, thread=1164, number=9, > address=02008080 > [04:21:51] 426 file=lhash.c, line=122, thread=1164, number=64, > address=02011D68 > [04:21:51] 259 file=stack.c, line=162, thread=1164, number=20, > address=0200AC50 > [04:21:51] 55 file=eng_lib.c, line=69, thread=1164, number=112, > address=020059A0 > [04:21:51] 432 file=lhash.c, line=120, thread=1164, number=96, > address=02011DB0 > [04:21:51] 438 file=lhash.c, line=191, thread=1164, number=12, > address=0200E658 > [04:21:51] 241 file=stack.c, line=162, thread=1164, number=20, > address=0200ABF0 > [04:21:51] 431 file=lhash.c, line=191, thread=1164, number=12, > address=0200E568 > [04:21:51] 435 file=eng_table.c, line=150, thread=1164, number=16, > address=0200E5E0 > [04:21:51] 362 file=eng_lib.c, line=69, thread=1164, number=112, > address=0200FD80 > [04:21:51] 255 file=lhash.c, line=120, thread=1164, number=96, > address=0200C078 > [04:21:51] 423 file=stack.c, line=164, thread=1164, number=32, > address=02011EF8 > [04:21:51] 227 file=ameth_lib.c, line=289, thread=1164, number=108, > address=0200A908 > [04:21:51] 228 file=buf_str.c, line=92, thread=1164, number=18, > address=0200A980 > [04:21:51] 244 file=lhash.c, line=120, thread=1164, number=96, > address=0200BFB8 > [04:21:51] 52 file=stack.c, line=162, thread=1164, number=20, > address=02005980 > [04:21:51] 266 file=eng_table.c, line=150, thread=1164, number=16, > address=02008608 > [04:21:51] 425 file=lhash.c, line=120, thread=1164, number=96, > address=02009608 > [04:21:51] 269 file=lhash.c, line=191, thread=1164, number=12, > address=02008680 > [04:21:51] 434 file=eng_lib.c, line=168, thread=1164, number=4, > address=02009680 > [04:21:51] 265 file=lhash.c, line=191, thread=1164, number=12, > address=020085D8 > [04:21:51] 268 file=stack.c, line=164, thread=1164, number=16, > address=02008650 > [04:21:51] 264 file=stack.c, line=164, thread=1164, number=16, > address=020085A8 > [04:21:51] 418 file=lhash.c, line=120, thread=1164, number=96, > address=02009548 > [04:21:51] 262 file=eng_table.c, line=150, thread=1164, number=16, > address=02008560 > 4141 bytes leaked in 94 chunks > make[1]: Leaving directory `/src/openssl-1.0.2h/test' > OPENSSL_CONF=apps/openssl.cnf util/opensslwrap.sh version -a > OpenSSL 1.0.2h-fips 3 May 2016 > built on: reproducible build, date unspecified > platform: mingw > options: bn(64,32) rc4(idx,int) des(ptr,risc1,16,long) idea(int) > blowfish(idx) > compiler: /mingw/bin/gcc.exe -I. -I.. -I../include -DZLIB > -DOPENSSL_THREADS -D_MT -DDSO_WIN32 > -DOPENSSL_SSL_CLIENT_ENGINE_AUTO=capi -DOPENSSL_CAPIENG_DIALOG > -DL_ENDIAN -DWIN32_LEAN_AND_MEAN -DWINVER=0x0501 -D_WIN32_WINNT=0x0501 > -D_WIN32_IE=0x0501 -DPTW32_STATIC_LIB -O0 -pipe -mms-bitfields > -fno-builtin -march=i686 -mtune=i686 -fomit-frame-pointer -Wall > -I/mingw/include > OPENSSLDIR: "C:/OpenSSL" > > > > From rt at openssl.org Wed Jun 1 17:51:54 2016 From: rt at openssl.org (Sebastian Andrzej Siewior via RT) Date: Wed, 01 Jun 2016 17:51:54 +0000 Subject: [openssl-dev] [openssl.org #4548] s390x build problem In-Reply-To: <20160601172458.GA5298@breakpoint.cc> References: <20160530195815.GA18832@roeckx.be> <0f31bcda-3c71-4ae2-7130-33b3a1d0d0e1@openssl.org> <20160601172458.GA5298@breakpoint.cc> Message-ID: On 2016-05-30 20:23:35 [+0000], Andy Polyakov via RT wrote: > > I'm getting: > > crypto/chacha/chacha-s390x.S: Assembler messages: > > crypto/chacha/chacha-s390x.S:7: Error: Unrecognized opcode: `clgije' > > > > > > A full build log is available on: > > https://buildd.debian.org/status/fetch.php?pkg=openssl&arch=s390x&ver=1.1.0~pre5-1&stamp=1464594754 > > It's overly easy to get carried away if you have access to single > system. Double-check attached. I made this while I did not notice this earlier: https://github.com/openssl/openssl/pull/1146 It fixes the chacha thing + memcpy. Sebastian -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4548 Please log in as guest with password guest if prompted From rt at openssl.org Wed Jun 1 18:48:08 2016 From: rt at openssl.org (noloader@gmail.com via RT) Date: Wed, 01 Jun 2016 18:48:08 +0000 Subject: [openssl-dev] [openssl.org #4196] BeagleBone Black detected as ARMv4 In-Reply-To: References: <57326056.1030402@openssl.org> Message-ID: On Tue, May 10, 2016 at 6:27 PM, Andy Polyakov via RT wrote: >> This seems like an odd result considering the BeagleBone Black >> processor is closer to a NEON. > > Well, ./config script should add -march=armv7-a option and that is more > than enough to make it NEON-capable. In fact linux-armv4 target covers > *all* post-v4 32-bit processors, it's all about additional flags. For > those who want to distribute single software package suitable for > multiple processors it's even possible to produce "universal" binaries > (see commentary in 10-main.cf)... It looks like this has been cleared with 1.1.0-pre6. Close it. beaglebone:openssl$ ./config Operating system: armv7l-whatever-linux2 Configuring for linux-armv4 Configuring OpenSSL version 1.1.0-pre6-dev (0x0x10100006L) no-asan [default] OPENSSL_NO_ASAN (skip dir) no-crypto-mdebug [default] OPENSSL_NO_CRYPTO_MDEBUG (skip dir) no-crypto-mdebug-backtrace [default] 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-fuzz [default] OPENSSL_NO_FUZZ (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-ssl-trace [default] OPENSSL_NO_SSL_TRACE (skip dir) no-ssl3 [default] OPENSSL_NO_SSL3 (skip dir) no-ssl3-method [default] OPENSSL_NO_SSL3_METHOD (skip dir) no-ubsan [default] OPENSSL_NO_UBSAN (skip dir) no-unit-test [default] OPENSSL_NO_UNIT_TEST (skip dir) no-weak-ssl-ciphers [default] OPENSSL_NO_WEAK_SSL_CIPHERS (skip dir) no-zlib [default] no-zlib-dynamic [default] Configuring for linux-armv4 CC =gcc CFLAG =-Wall -O3 -pthread -march=armv7-a -Wa,--noexecstack SHARED_CFLAG =-fPIC DEFINES =DSO_DLFCN HAVE_DLFCN_H NDEBUG OPENSSL_THREADS OPENSSL_NO_STATIC_ENGINE OPENSSL_PIC 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 APPS_OBJ = CPUID_OBJ =armcap.o armv4cpuid.o UPLINK_OBJ = 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 BLAKE2_OBJ = PROCESSOR = RANLIB =ranlib ARFLAGS = PERL =/usr/bin/perl THIRTY_TWO_BIT mode BN_LLONG mode RC4 uses unsigned char Configured for linux-armv4. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4196 Please log in as guest with password guest if prompted From rt at openssl.org Wed Jun 1 18:52:00 2016 From: rt at openssl.org (Rich Salz via RT) Date: Wed, 01 Jun 2016 18:52:00 +0000 Subject: [openssl-dev] [openssl.org #4196] BeagleBone Black detected as ARMv4 In-Reply-To: References: Message-ID: As you requested :) Closing. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4196 Please log in as guest with password guest if prompted From rt at openssl.org Wed Jun 1 19:15:47 2016 From: rt at openssl.org (noloader@gmail.com via RT) Date: Wed, 01 Jun 2016 19:15:47 +0000 Subject: [openssl-dev] [openssl.org #4434] AutoReply: Gentoo 13, x86_64: 4 failed self tests In-Reply-To: References: Message-ID: It looks like there's still some problems with our old friend afalgtest. Below is from 1.1.0-pre6 on 1 JUN 2016 ********** $ cat gentoo-result.txt ( cd test; \ SRCTOP=../. \ BLDTOP=../. \ PERL="/usr/bin/perl" \ EXE_EXT= \ OPENSSL_ENGINES=.././engines \ /usr/bin/perl .././test/run_tests.pl ) sh: line 1: 27759 Aborted ../util/shlib_wrap.sh ./aborttest 2> /dev/null ../test/recipes/01-test_abort.t ............ ok ../test/recipes/01-test_ordinals.t ......... ok ../test/recipes/01-test_symbol_presence.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_d2i.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 # Failed test 'running afalgtest' # at ../test/recipes/30-test_afalg.t line 23. # Looks like you failed 1 test of 1. ../test/recipes/30-test_afalg.t ............ Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../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_asyncio.t .......... ok ../test/recipes/70-test_clienthello.t ...... ok ../test/recipes/70-test_packet.t ........... ok ../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_cipherlist.t ....... ok ../test/recipes/80-test_cms.t .............. ok ../test/recipes/80-test_ct.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_new.t .......... ok ../test/recipes/80-test_ssl_old.t .......... ok ../test/recipes/80-test_ssl_test_ctx.t ..... ok ../test/recipes/80-test_tsa.t .............. ok ../test/recipes/80-test_x509aux.t .......... ok ../test/recipes/90-test_async.t ............ ok ../test/recipes/90-test_bioprint.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_threads.t .......... ok ../test/recipes/90-test_v3name.t ........... ok Test Summary Report ------------------- ../test/recipes/30-test_afalg.t (Wstat: 256 Tests: 1 Failed: 1) Failed test: 1 Non-zero exit status: 1 Files=80, Tests=409, 34 wallclock secs ( 0.40 usr 0.11 sys + 23.22 cusr 4.34 csys = 28.07 CPU) Result: FAIL Failed 1/80 test programs. 1/409 subtests failed. Makefile:125: recipe for target 'tests' failed make: *** [tests] Error 255 -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4434 Please log in as guest with password guest if prompted From rt at openssl.org Wed Jun 1 19:54:51 2016 From: rt at openssl.org (noloader@gmail.com via RT) Date: Wed, 01 Jun 2016 19:54:51 +0000 Subject: [openssl-dev] [openssl.org #4553] Re: Fedora 1, i386: error: field `next_timeout` has incomplete type In-Reply-To: References: Message-ID: So testing with 1.1.0-pre6 from 1 JUN 2016 appears to show some new issues. ./config detects as i686-linux-whatever. However, there are some issues with CFLAGS. The '-arch x86_64' makes it appear to be configured for quasi-OS X mode. I believe -m32 should be used if an arch is needed. There's also some complaints about -c and -o, but I think the compiler confusion starts earlier. Here's a screen capture of the error: http://postimg.org/image/e9nvrko17/ . My apologies for the screen capture. I kind of cheat and get the tarball onto the VM by building an ISO and mounting it with the CDROM. I have not figured out how to get data to travel the other way. Jeff On Sun, Mar 20, 2016 at 8:31 AM, Jeffrey Walton wrote: > I know this is kind of an old machine with GCC 3.3... > > With an updated PERL and a './config no-asm -D_XOPEN_SOURCE=600', I > can almost get through a compile. After libcrypto.a is built, the next > compile line is: > > gcc ... -c -o ssl/bio_ssl.o ssl/bio_ssl.c > > At that point, there's a: > > In file included from ssl/bio_ssl.c:65 > ssl/ssl_locl.h:1501: error: field `next_timeout` has incomplete type > [ssl/bio_ssl.o] Error 1 > > The issue was cleared by adding to "ssl/ssl_locl.h". > > ********** > > ar r libcrypto.a crypto/aes/aes_cbc.o crypto/aes/aes_cfb.o > crypto/aes/aes_core.o crypto/aes/aes_ecb.o crypto/aes/aes_ige.o > crypto/aes/aes_misc.o crypto/aes/aes_ofb.o crypto/aes/aes_wrap.o > crypto/asn1/a_bitstr.o crypto/asn1/a_d2i_fp.o crypto/asn1/a_digest.o > crypto/asn1/a_dup.o crypto/asn1/a_gentm.o crypto/asn1/a_i2d_fp.o > crypto/asn1/a_int.o crypto/asn1/a_mbstr.o crypto/asn1/a_object.o > crypto/asn1/a_octet.o crypto/asn1/a_print.o crypto/asn1/a_sign.o > crypto/asn1/a_strex.o crypto/asn1/a_strnid.o crypto/asn1/a_time.o > crypto/asn1/a_type.o crypto/asn1/a_utctm.o crypto/asn1/a_utf8.o > crypto/asn1/a_verify.o crypto/asn1/ameth_lib.o crypto/asn1/asn1_err.o > crypto/asn1/asn1_gen.o crypto/asn1/asn1_lib.o crypto/asn1/asn1_par.o > crypto/asn1/asn_mime.o crypto/asn1/asn_moid.o crypto/asn1/asn_mstbl.o > crypto/asn1/asn_pack.o crypto/asn1/bio_asn1.o crypto/asn1/bio_ndef.o > crypto/asn1/d2i_pr.o crypto/asn1/d2i_pu.o crypto/asn1/evp_asn1.o > crypto/asn1/f_int.o crypto/asn1/f_string.o crypto/asn1/i2d_pr.o > crypto/asn1/i2d_pu.o crypto/asn1/n_pkey.o crypto/asn1/nsseq.o > crypto/asn1/p5_pbe.o crypto/asn1/p5_pbev2.o crypto/asn1/p5_scrypt.o > crypto/asn1/p8_pkey.o crypto/asn1/t_bitst.o crypto/asn1/t_pkey.o > crypto/asn1/t_spki.o crypto/asn1/tasn_dec.o crypto/asn1/tasn_enc.o > crypto/asn1/tasn_fre.o crypto/asn1/tasn_new.o crypto/asn1/tasn_prn.o > crypto/asn1/tasn_scn.o crypto/asn1/tasn_typ.o crypto/asn1/tasn_utl.o > crypto/asn1/x_algor.o crypto/asn1/x_bignum.o crypto/asn1/x_info.o > crypto/asn1/x_long.o crypto/asn1/x_pkey.o crypto/asn1/x_pubkey.o > crypto/asn1/x_sig.o crypto/asn1/x_spki.o crypto/asn1/x_val.o > crypto/async/arch/async_null.o crypto/async/arch/async_posix.o > crypto/async/arch/async_win.o crypto/async/async.o > crypto/async/async_err.o crypto/async/async_wait.o > crypto/bf/bf_cfb64.o crypto/bf/bf_ecb.o crypto/bf/bf_enc.o > crypto/bf/bf_ofb64.o crypto/bf/bf_skey.o crypto/bio/b_addr.o > crypto/bio/b_dump.o crypto/bio/b_print.o crypto/bio/b_sock.o > crypto/bio/b_sock2.o crypto/bio/bf_buff.o crypto/bio/bf_nbio.o > crypto/bio/bf_null.o crypto/bio/bio_cb.o crypto/bio/bio_err.o > crypto/bio/bio_lib.o crypto/bio/bss_acpt.o crypto/bio/bss_bio.o > crypto/bio/bss_conn.o crypto/bio/bss_dgram.o crypto/bio/bss_fd.o > crypto/bio/bss_file.o crypto/bio/bss_log.o crypto/bio/bss_mem.o > crypto/bio/bss_null.o crypto/bio/bss_sock.o crypto/blake2/blake2b.o > crypto/blake2/blake2s.o crypto/blake2/m_blake2b.o > crypto/blake2/m_blake2s.o crypto/bn/bn_add.o crypto/bn/bn_asm.o > crypto/bn/bn_blind.o crypto/bn/bn_const.o crypto/bn/bn_ctx.o > crypto/bn/bn_depr.o crypto/bn/bn_dh.o crypto/bn/bn_div.o > crypto/bn/bn_err.o crypto/bn/bn_exp.o crypto/bn/bn_exp2.o > crypto/bn/bn_gcd.o crypto/bn/bn_gf2m.o crypto/bn/bn_intern.o > crypto/bn/bn_kron.o crypto/bn/bn_lib.o crypto/bn/bn_mod.o > crypto/bn/bn_mont.o crypto/bn/bn_mpi.o crypto/bn/bn_mul.o > crypto/bn/bn_nist.o crypto/bn/bn_prime.o crypto/bn/bn_print.o > crypto/bn/bn_rand.o crypto/bn/bn_recp.o crypto/bn/bn_shift.o > crypto/bn/bn_sqr.o crypto/bn/bn_sqrt.o crypto/bn/bn_srp.o > crypto/bn/bn_word.o crypto/bn/bn_x931p.o crypto/buffer/buf_err.o > crypto/buffer/buffer.o crypto/camellia/camellia.o > crypto/camellia/cmll_cbc.o crypto/camellia/cmll_cfb.o > crypto/camellia/cmll_ctr.o crypto/camellia/cmll_ecb.o > crypto/camellia/cmll_misc.o crypto/camellia/cmll_ofb.o > crypto/cast/c_cfb64.o crypto/cast/c_ecb.o crypto/cast/c_enc.o > crypto/cast/c_ofb64.o crypto/cast/c_skey.o crypto/chacha/chacha_enc.o > crypto/cmac/cm_ameth.o crypto/cmac/cm_pmeth.o crypto/cmac/cmac.o > crypto/cms/cms_asn1.o crypto/cms/cms_att.o crypto/cms/cms_cd.o > crypto/cms/cms_dd.o crypto/cms/cms_enc.o crypto/cms/cms_env.o > crypto/cms/cms_err.o crypto/cms/cms_ess.o crypto/cms/cms_io.o > crypto/cms/cms_kari.o crypto/cms/cms_lib.o crypto/cms/cms_pwri.o > crypto/cms/cms_sd.o crypto/cms/cms_smime.o crypto/comp/c_zlib.o > crypto/comp/comp_err.o crypto/comp/comp_lib.o crypto/conf/conf_api.o > crypto/conf/conf_def.o crypto/conf/conf_err.o crypto/conf/conf_lib.o > crypto/conf/conf_mall.o crypto/conf/conf_mod.o crypto/conf/conf_sap.o > crypto/cpt_err.o crypto/cryptlib.o crypto/ct/ct_b64.o > crypto/ct/ct_err.o crypto/ct/ct_log.o crypto/ct/ct_oct.o > crypto/ct/ct_policy.o crypto/ct/ct_prn.o crypto/ct/ct_sct.o > crypto/ct/ct_sct_ctx.o crypto/ct/ct_vfy.o crypto/ct/ct_x509v3.o > crypto/cversion.o crypto/des/cbc_cksm.o crypto/des/cbc_enc.o > crypto/des/cfb64ede.o crypto/des/cfb64enc.o crypto/des/cfb_enc.o > crypto/des/des_enc.o crypto/des/ecb3_enc.o crypto/des/ecb_enc.o > crypto/des/enc_read.o crypto/des/enc_writ.o crypto/des/fcrypt.o > crypto/des/fcrypt_b.o crypto/des/ofb64ede.o crypto/des/ofb64enc.o > crypto/des/ofb_enc.o crypto/des/pcbc_enc.o crypto/des/qud_cksm.o > crypto/des/rand_key.o crypto/des/read2pwd.o crypto/des/rpc_enc.o > crypto/des/set_key.o crypto/des/str2key.o crypto/des/xcbc_enc.o > crypto/dh/dh_ameth.o crypto/dh/dh_asn1.o crypto/dh/dh_check.o > crypto/dh/dh_depr.o crypto/dh/dh_err.o crypto/dh/dh_gen.o > crypto/dh/dh_kdf.o crypto/dh/dh_key.o crypto/dh/dh_lib.o > crypto/dh/dh_pmeth.o crypto/dh/dh_prn.o crypto/dh/dh_rfc5114.o > crypto/dsa/dsa_ameth.o crypto/dsa/dsa_asn1.o crypto/dsa/dsa_depr.o > crypto/dsa/dsa_err.o crypto/dsa/dsa_gen.o crypto/dsa/dsa_key.o > crypto/dsa/dsa_lib.o crypto/dsa/dsa_ossl.o crypto/dsa/dsa_pmeth.o > crypto/dsa/dsa_prn.o crypto/dsa/dsa_sign.o crypto/dsa/dsa_vrf.o > crypto/dso/dso_dl.o crypto/dso/dso_dlfcn.o crypto/dso/dso_err.o > crypto/dso/dso_lib.o crypto/dso/dso_null.o crypto/dso/dso_openssl.o > crypto/dso/dso_vms.o crypto/dso/dso_win32.o crypto/ebcdic.o > crypto/ec/curve25519.o crypto/ec/ec2_mult.o crypto/ec/ec2_oct.o > crypto/ec/ec2_smpl.o crypto/ec/ec_25519.o crypto/ec/ec_ameth.o > crypto/ec/ec_asn1.o crypto/ec/ec_check.o crypto/ec/ec_curve.o > crypto/ec/ec_cvt.o crypto/ec/ec_err.o crypto/ec/ec_key.o > crypto/ec/ec_kmeth.o crypto/ec/ec_lib.o crypto/ec/ec_mult.o > crypto/ec/ec_oct.o crypto/ec/ec_pmeth.o crypto/ec/ec_print.o > crypto/ec/ecdh_kdf.o crypto/ec/ecdh_ossl.o crypto/ec/ecdsa_ossl.o > crypto/ec/ecdsa_sign.o crypto/ec/ecdsa_vrf.o crypto/ec/eck_prn.o > crypto/ec/ecp_mont.o crypto/ec/ecp_nist.o crypto/ec/ecp_nistp224.o > crypto/ec/ecp_nistp256.o crypto/ec/ecp_nistp521.o > crypto/ec/ecp_nistputil.o crypto/ec/ecp_oct.o crypto/ec/ecp_smpl.o > crypto/engine/eng_all.o crypto/engine/eng_cnf.o > crypto/engine/eng_cryptodev.o crypto/engine/eng_ctrl.o > crypto/engine/eng_dyn.o crypto/engine/eng_err.o > crypto/engine/eng_fat.o crypto/engine/eng_init.o > crypto/engine/eng_lib.o crypto/engine/eng_list.o > crypto/engine/eng_openssl.o crypto/engine/eng_pkey.o > crypto/engine/eng_rdrand.o crypto/engine/eng_table.o > crypto/engine/tb_asnmth.o crypto/engine/tb_cipher.o > crypto/engine/tb_dh.o crypto/engine/tb_digest.o crypto/engine/tb_dsa.o > crypto/engine/tb_eckey.o crypto/engine/tb_pkmeth.o > crypto/engine/tb_rand.o crypto/engine/tb_rsa.o crypto/err/err.o > crypto/err/err_all.o crypto/err/err_prn.o crypto/evp/bio_b64.o > crypto/evp/bio_enc.o crypto/evp/bio_md.o crypto/evp/bio_ok.o > crypto/evp/c_allc.o crypto/evp/c_alld.o crypto/evp/cmeth_lib.o > crypto/evp/digest.o crypto/evp/e_aes.o > crypto/evp/e_aes_cbc_hmac_sha1.o crypto/evp/e_aes_cbc_hmac_sha256.o > crypto/evp/e_bf.o crypto/evp/e_camellia.o crypto/evp/e_cast.o > crypto/evp/e_chacha20_poly1305.o crypto/evp/e_des.o > crypto/evp/e_des3.o crypto/evp/e_idea.o crypto/evp/e_null.o > crypto/evp/e_old.o crypto/evp/e_rc2.o crypto/evp/e_rc4.o > crypto/evp/e_rc4_hmac_md5.o crypto/evp/e_rc5.o crypto/evp/e_seed.o > crypto/evp/e_xcbc_d.o crypto/evp/encode.o crypto/evp/evp_cnf.o > crypto/evp/evp_enc.o crypto/evp/evp_err.o crypto/evp/evp_key.o > crypto/evp/evp_lib.o crypto/evp/evp_pbe.o crypto/evp/evp_pkey.o > crypto/evp/m_md2.o crypto/evp/m_md4.o crypto/evp/m_md5.o > crypto/evp/m_md5_sha1.o crypto/evp/m_mdc2.o crypto/evp/m_null.o > crypto/evp/m_ripemd.o crypto/evp/m_sha1.o crypto/evp/m_sigver.o > crypto/evp/m_wp.o crypto/evp/names.o crypto/evp/p5_crpt.o > crypto/evp/p5_crpt2.o crypto/evp/p_dec.o crypto/evp/p_enc.o > crypto/evp/p_lib.o crypto/evp/p_open.o crypto/evp/p_seal.o > crypto/evp/p_sign.o crypto/evp/p_verify.o crypto/evp/pmeth_fn.o > crypto/evp/pmeth_gn.o crypto/evp/pmeth_lib.o crypto/evp/scrypt.o > crypto/ex_data.o crypto/hmac/hm_ameth.o crypto/hmac/hm_pmeth.o > crypto/hmac/hmac.o crypto/idea/i_cbc.o crypto/idea/i_cfb64.o > crypto/idea/i_ecb.o crypto/idea/i_ofb64.o crypto/idea/i_skey.o > crypto/init.o crypto/kdf/hkdf.o crypto/kdf/kdf_err.o > crypto/kdf/tls1_prf.o crypto/lhash/lh_stats.o crypto/lhash/lhash.o > crypto/md4/md4_dgst.o crypto/md4/md4_one.o crypto/md5/md5_dgst.o > crypto/md5/md5_one.o crypto/mdc2/mdc2_one.o crypto/mdc2/mdc2dgst.o > crypto/mem.o crypto/mem_clr.o crypto/mem_dbg.o crypto/mem_sec.o > crypto/modes/cbc128.o crypto/modes/ccm128.o crypto/modes/cfb128.o > crypto/modes/ctr128.o crypto/modes/cts128.o crypto/modes/gcm128.o > crypto/modes/ocb128.o crypto/modes/ofb128.o crypto/modes/wrap128.o > crypto/modes/xts128.o crypto/o_dir.o crypto/o_fips.o crypto/o_init.o > crypto/o_str.o crypto/o_time.o crypto/objects/o_names.o > crypto/objects/obj_dat.o crypto/objects/obj_err.o > crypto/objects/obj_lib.o crypto/objects/obj_xref.o > crypto/ocsp/ocsp_asn.o crypto/ocsp/ocsp_cl.o crypto/ocsp/ocsp_err.o > crypto/ocsp/ocsp_ext.o crypto/ocsp/ocsp_ht.o crypto/ocsp/ocsp_lib.o > crypto/ocsp/ocsp_prn.o crypto/ocsp/ocsp_srv.o crypto/ocsp/ocsp_vfy.o > crypto/ocsp/v3_ocsp.o crypto/pem/pem_all.o crypto/pem/pem_err.o > crypto/pem/pem_info.o crypto/pem/pem_lib.o crypto/pem/pem_oth.o > crypto/pem/pem_pk8.o crypto/pem/pem_pkey.o crypto/pem/pem_sign.o > crypto/pem/pem_x509.o crypto/pem/pem_xaux.o crypto/pem/pvkfmt.o > crypto/pkcs12/p12_add.o crypto/pkcs12/p12_asn.o > crypto/pkcs12/p12_attr.o crypto/pkcs12/p12_crpt.o > crypto/pkcs12/p12_crt.o crypto/pkcs12/p12_decr.o > crypto/pkcs12/p12_init.o crypto/pkcs12/p12_key.o > crypto/pkcs12/p12_kiss.o crypto/pkcs12/p12_mutl.o > crypto/pkcs12/p12_npas.o crypto/pkcs12/p12_p8d.o > crypto/pkcs12/p12_p8e.o crypto/pkcs12/p12_sbag.o > crypto/pkcs12/p12_utl.o crypto/pkcs12/pk12err.o crypto/pkcs7/bio_pk7.o > crypto/pkcs7/pk7_asn1.o crypto/pkcs7/pk7_attr.o > crypto/pkcs7/pk7_doit.o crypto/pkcs7/pk7_lib.o crypto/pkcs7/pk7_mime.o > crypto/pkcs7/pk7_smime.o crypto/pkcs7/pkcs7err.o > crypto/poly1305/poly1305.o crypto/rand/md_rand.o > crypto/rand/rand_egd.o crypto/rand/rand_err.o crypto/rand/rand_lib.o > crypto/rand/rand_unix.o crypto/rand/rand_vms.o crypto/rand/rand_win.o > crypto/rand/randfile.o crypto/rc2/rc2_cbc.o crypto/rc2/rc2_ecb.o > crypto/rc2/rc2_skey.o crypto/rc2/rc2cfb64.o crypto/rc2/rc2ofb64.o > crypto/rc4/rc4_enc.o crypto/rc4/rc4_skey.o crypto/ripemd/rmd_dgst.o > crypto/ripemd/rmd_one.o crypto/rsa/rsa_ameth.o crypto/rsa/rsa_asn1.o > crypto/rsa/rsa_chk.o crypto/rsa/rsa_crpt.o crypto/rsa/rsa_depr.o > crypto/rsa/rsa_err.o crypto/rsa/rsa_gen.o crypto/rsa/rsa_lib.o > crypto/rsa/rsa_none.o crypto/rsa/rsa_null.o crypto/rsa/rsa_oaep.o > crypto/rsa/rsa_ossl.o crypto/rsa/rsa_pk1.o crypto/rsa/rsa_pmeth.o > crypto/rsa/rsa_prn.o crypto/rsa/rsa_pss.o crypto/rsa/rsa_saos.o > crypto/rsa/rsa_sign.o crypto/rsa/rsa_ssl.o crypto/rsa/rsa_x931.o > crypto/rsa/rsa_x931g.o crypto/seed/seed.o crypto/seed/seed_cbc.o > crypto/seed/seed_cfb.o crypto/seed/seed_ecb.o crypto/seed/seed_ofb.o > crypto/sha/sha1_one.o crypto/sha/sha1dgst.o crypto/sha/sha256.o > crypto/sha/sha512.o crypto/srp/srp_lib.o crypto/srp/srp_vfy.o > crypto/stack/stack.o crypto/threads_none.o crypto/threads_pthread.o > crypto/threads_win.o crypto/ts/ts_asn1.o crypto/ts/ts_conf.o > crypto/ts/ts_err.o crypto/ts/ts_lib.o crypto/ts/ts_req_print.o > crypto/ts/ts_req_utils.o crypto/ts/ts_rsp_print.o > crypto/ts/ts_rsp_sign.o crypto/ts/ts_rsp_utils.o > crypto/ts/ts_rsp_verify.o crypto/ts/ts_verify_ctx.o > crypto/txt_db/txt_db.o crypto/ui/ui_err.o crypto/ui/ui_lib.o > crypto/ui/ui_openssl.o crypto/ui/ui_util.o crypto/uid.o > crypto/whrlpool/wp_block.o crypto/whrlpool/wp_dgst.o > crypto/x509/by_dir.o crypto/x509/by_file.o crypto/x509/t_crl.o > crypto/x509/t_req.o crypto/x509/t_x509.o crypto/x509/x509_att.o > crypto/x509/x509_cmp.o crypto/x509/x509_d2.o crypto/x509/x509_def.o > crypto/x509/x509_err.o crypto/x509/x509_ext.o crypto/x509/x509_lu.o > crypto/x509/x509_obj.o crypto/x509/x509_r2x.o crypto/x509/x509_req.o > crypto/x509/x509_set.o crypto/x509/x509_trs.o crypto/x509/x509_txt.o > crypto/x509/x509_v3.o crypto/x509/x509_vfy.o crypto/x509/x509_vpm.o > crypto/x509/x509cset.o crypto/x509/x509name.o crypto/x509/x509rset.o > crypto/x509/x509spki.o crypto/x509/x509type.o crypto/x509/x_all.o > crypto/x509/x_attrib.o crypto/x509/x_crl.o crypto/x509/x_exten.o > crypto/x509/x_name.o crypto/x509/x_req.o crypto/x509/x_x509.o > crypto/x509/x_x509a.o crypto/x509v3/pcy_cache.o > crypto/x509v3/pcy_data.o crypto/x509v3/pcy_lib.o > crypto/x509v3/pcy_map.o crypto/x509v3/pcy_node.o > crypto/x509v3/pcy_tree.o crypto/x509v3/v3_addr.o > crypto/x509v3/v3_akey.o crypto/x509v3/v3_akeya.o > crypto/x509v3/v3_alt.o crypto/x509v3/v3_asid.o > crypto/x509v3/v3_bcons.o crypto/x509v3/v3_bitst.o > crypto/x509v3/v3_conf.o crypto/x509v3/v3_cpols.o > crypto/x509v3/v3_crld.o crypto/x509v3/v3_enum.o > crypto/x509v3/v3_extku.o crypto/x509v3/v3_genn.o > crypto/x509v3/v3_ia5.o crypto/x509v3/v3_info.o crypto/x509v3/v3_int.o > crypto/x509v3/v3_lib.o crypto/x509v3/v3_ncons.o crypto/x509v3/v3_pci.o > crypto/x509v3/v3_pcia.o crypto/x509v3/v3_pcons.o > crypto/x509v3/v3_pku.o crypto/x509v3/v3_pmaps.o crypto/x509v3/v3_prn.o > crypto/x509v3/v3_purp.o crypto/x509v3/v3_skey.o > crypto/x509v3/v3_sxnet.o crypto/x509v3/v3_tlsf.o > crypto/x509v3/v3_utl.o crypto/x509v3/v3err.o engines/e_capi.o > engines/e_dasync.o engines/e_padlock.o > /usr/bin/ranlib libcrypto.a || echo Never mind. > gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_THREADS > -DOPENSSL_NO_DYNAMIC_ENGINE -DOPENSSL_PIC -D_XOPEN_SOURCE=600 > -DOPENSSLDIR="\"/usr/local/ssl\"" > -DENGINESDIR="\"/usr/local/lib/engines\"" -Wall -O3 -pthread > -DL_ENDIAN -fomit-frame-pointer -fPIC -Iinclude -I. -c -o > ssl/bio_ssl.o ssl/bio_ssl.c > In file included from ssl/bio_ssl.c:65: > ssl/ssl_locl.h:1501: error: field `next_timeout' has incomplete type -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4553 Please log in as guest with password guest if prompted From rt at openssl.org Wed Jun 1 20:37:29 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Wed, 01 Jun 2016 20:37:29 +0000 Subject: [openssl-dev] [openssl.org #4434] Gentoo 13, x86_64: 4 failed self tests In-Reply-To: References: Message-ID: Please try this and send us the result: make test TESTS=test_afalg VERBOSE=1 On Wed Jun 01 19:15:47 2016, noloader at gmail.com wrote: > It looks like there's still some problems with our old friend afalgtest. > > Below is from 1.1.0-pre6 on 1 JUN 2016 > > ********** > > $ cat gentoo-result.txt > ( cd test; \ > SRCTOP=../. \ > BLDTOP=../. \ > PERL="/usr/bin/perl" \ > EXE_EXT= \ > OPENSSL_ENGINES=.././engines \ > /usr/bin/perl .././test/run_tests.pl ) > sh: line 1: 27759 Aborted ../util/shlib_wrap.sh > ./aborttest 2> /dev/null > ../test/recipes/01-test_abort.t ............ ok > ../test/recipes/01-test_ordinals.t ......... ok > ../test/recipes/01-test_symbol_presence.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_d2i.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 > > # Failed test 'running afalgtest' > # at ../test/recipes/30-test_afalg.t line 23. > # Looks like you failed 1 test of 1. > ../test/recipes/30-test_afalg.t ............ > Dubious, test returned 1 (wstat 256, 0x100) > Failed 1/1 subtests > ../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_asyncio.t .......... ok > ../test/recipes/70-test_clienthello.t ...... ok > ../test/recipes/70-test_packet.t ........... ok > ../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_cipherlist.t ....... ok > ../test/recipes/80-test_cms.t .............. ok > ../test/recipes/80-test_ct.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_new.t .......... ok > ../test/recipes/80-test_ssl_old.t .......... ok > ../test/recipes/80-test_ssl_test_ctx.t ..... ok > ../test/recipes/80-test_tsa.t .............. ok > ../test/recipes/80-test_x509aux.t .......... ok > ../test/recipes/90-test_async.t ............ ok > ../test/recipes/90-test_bioprint.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_threads.t .......... ok > ../test/recipes/90-test_v3name.t ........... ok > > Test Summary Report > ------------------- > ../test/recipes/30-test_afalg.t (Wstat: 256 Tests: 1 Failed: 1) > Failed test: 1 > Non-zero exit status: 1 > Files=80, Tests=409, 34 wallclock secs ( 0.40 usr 0.11 sys + 23.22 > cusr 4.34 csys = 28.07 CPU) > Result: FAIL > Failed 1/80 test programs. 1/409 subtests failed. > Makefile:125: recipe for target 'tests' failed > make: *** [tests] Error 255 > -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4434 Please log in as guest with password guest if prompted From rt at openssl.org Wed Jun 1 20:47:24 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Wed, 01 Jun 2016 20:47:24 +0000 Subject: [openssl-dev] [openssl.org #4553] Re: Fedora 1, i386: error: field `next_timeout` has incomplete type In-Reply-To: References: Message-ID: Please give us the full configuration command you used, including environment variables that may affect it. Just the presence of '-ansi' tells me that you didn't just say './config' without any arguments. On Wed Jun 01 19:54:51 2016, noloader at gmail.com wrote: > So testing with 1.1.0-pre6 from 1 JUN 2016 appears to show some new issues. > > ./config detects as i686-linux-whatever. However, there are some > issues with CFLAGS. The '-arch x86_64' makes it appear to be > configured for quasi-OS X mode. I believe -m32 should be used if an > arch is needed. There's also some complaints about -c and -o, but I > think the compiler confusion starts earlier. > > Here's a screen capture of the error: http://postimg.org/image/e9nvrko17/ . > > My apologies for the screen capture. I kind of cheat and get the > tarball onto the VM by building an ISO and mounting it with the CDROM. > I have not figured out how to get data to travel the other way. > > Jeff > > On Sun, Mar 20, 2016 at 8:31 AM, Jeffrey Walton wrote: > > I know this is kind of an old machine with GCC 3.3... > > > > With an updated PERL and a './config no-asm -D_XOPEN_SOURCE=600', I > > can almost get through a compile. After libcrypto.a is built, the next > > compile line is: > > > > gcc ... -c -o ssl/bio_ssl.o ssl/bio_ssl.c > > > > At that point, there's a: > > > > In file included from ssl/bio_ssl.c:65 > > ssl/ssl_locl.h:1501: error: field `next_timeout` has incomplete type > > [ssl/bio_ssl.o] Error 1 > > > > The issue was cleared by adding to "ssl/ssl_locl.h". > > > > ********** > > > > ar r libcrypto.a crypto/aes/aes_cbc.o crypto/aes/aes_cfb.o > > crypto/aes/aes_core.o crypto/aes/aes_ecb.o crypto/aes/aes_ige.o > > crypto/aes/aes_misc.o crypto/aes/aes_ofb.o crypto/aes/aes_wrap.o > > crypto/asn1/a_bitstr.o crypto/asn1/a_d2i_fp.o crypto/asn1/a_digest.o > > crypto/asn1/a_dup.o crypto/asn1/a_gentm.o crypto/asn1/a_i2d_fp.o > > crypto/asn1/a_int.o crypto/asn1/a_mbstr.o crypto/asn1/a_object.o > > crypto/asn1/a_octet.o crypto/asn1/a_print.o crypto/asn1/a_sign.o > > crypto/asn1/a_strex.o crypto/asn1/a_strnid.o crypto/asn1/a_time.o > > crypto/asn1/a_type.o crypto/asn1/a_utctm.o crypto/asn1/a_utf8.o > > crypto/asn1/a_verify.o crypto/asn1/ameth_lib.o crypto/asn1/asn1_err.o > > crypto/asn1/asn1_gen.o crypto/asn1/asn1_lib.o crypto/asn1/asn1_par.o > > crypto/asn1/asn_mime.o crypto/asn1/asn_moid.o crypto/asn1/asn_mstbl.o > > crypto/asn1/asn_pack.o crypto/asn1/bio_asn1.o crypto/asn1/bio_ndef.o > > crypto/asn1/d2i_pr.o crypto/asn1/d2i_pu.o crypto/asn1/evp_asn1.o > > crypto/asn1/f_int.o crypto/asn1/f_string.o crypto/asn1/i2d_pr.o > > crypto/asn1/i2d_pu.o crypto/asn1/n_pkey.o crypto/asn1/nsseq.o > > crypto/asn1/p5_pbe.o crypto/asn1/p5_pbev2.o crypto/asn1/p5_scrypt.o > > crypto/asn1/p8_pkey.o crypto/asn1/t_bitst.o crypto/asn1/t_pkey.o > > crypto/asn1/t_spki.o crypto/asn1/tasn_dec.o crypto/asn1/tasn_enc.o > > crypto/asn1/tasn_fre.o crypto/asn1/tasn_new.o crypto/asn1/tasn_prn.o > > crypto/asn1/tasn_scn.o crypto/asn1/tasn_typ.o crypto/asn1/tasn_utl.o > > crypto/asn1/x_algor.o crypto/asn1/x_bignum.o crypto/asn1/x_info.o > > crypto/asn1/x_long.o crypto/asn1/x_pkey.o crypto/asn1/x_pubkey.o > > crypto/asn1/x_sig.o crypto/asn1/x_spki.o crypto/asn1/x_val.o > > crypto/async/arch/async_null.o crypto/async/arch/async_posix.o > > crypto/async/arch/async_win.o crypto/async/async.o > > crypto/async/async_err.o crypto/async/async_wait.o > > crypto/bf/bf_cfb64.o crypto/bf/bf_ecb.o crypto/bf/bf_enc.o > > crypto/bf/bf_ofb64.o crypto/bf/bf_skey.o crypto/bio/b_addr.o > > crypto/bio/b_dump.o crypto/bio/b_print.o crypto/bio/b_sock.o > > crypto/bio/b_sock2.o crypto/bio/bf_buff.o crypto/bio/bf_nbio.o > > crypto/bio/bf_null.o crypto/bio/bio_cb.o crypto/bio/bio_err.o > > crypto/bio/bio_lib.o crypto/bio/bss_acpt.o crypto/bio/bss_bio.o > > crypto/bio/bss_conn.o crypto/bio/bss_dgram.o crypto/bio/bss_fd.o > > crypto/bio/bss_file.o crypto/bio/bss_log.o crypto/bio/bss_mem.o > > crypto/bio/bss_null.o crypto/bio/bss_sock.o crypto/blake2/blake2b.o > > crypto/blake2/blake2s.o crypto/blake2/m_blake2b.o > > crypto/blake2/m_blake2s.o crypto/bn/bn_add.o crypto/bn/bn_asm.o > > crypto/bn/bn_blind.o crypto/bn/bn_const.o crypto/bn/bn_ctx.o > > crypto/bn/bn_depr.o crypto/bn/bn_dh.o crypto/bn/bn_div.o > > crypto/bn/bn_err.o crypto/bn/bn_exp.o crypto/bn/bn_exp2.o > > crypto/bn/bn_gcd.o crypto/bn/bn_gf2m.o crypto/bn/bn_intern.o > > crypto/bn/bn_kron.o crypto/bn/bn_lib.o crypto/bn/bn_mod.o > > crypto/bn/bn_mont.o crypto/bn/bn_mpi.o crypto/bn/bn_mul.o > > crypto/bn/bn_nist.o crypto/bn/bn_prime.o crypto/bn/bn_print.o > > crypto/bn/bn_rand.o crypto/bn/bn_recp.o crypto/bn/bn_shift.o > > crypto/bn/bn_sqr.o crypto/bn/bn_sqrt.o crypto/bn/bn_srp.o > > crypto/bn/bn_word.o crypto/bn/bn_x931p.o crypto/buffer/buf_err.o > > crypto/buffer/buffer.o crypto/camellia/camellia.o > > crypto/camellia/cmll_cbc.o crypto/camellia/cmll_cfb.o > > crypto/camellia/cmll_ctr.o crypto/camellia/cmll_ecb.o > > crypto/camellia/cmll_misc.o crypto/camellia/cmll_ofb.o > > crypto/cast/c_cfb64.o crypto/cast/c_ecb.o crypto/cast/c_enc.o > > crypto/cast/c_ofb64.o crypto/cast/c_skey.o crypto/chacha/chacha_enc.o > > crypto/cmac/cm_ameth.o crypto/cmac/cm_pmeth.o crypto/cmac/cmac.o > > crypto/cms/cms_asn1.o crypto/cms/cms_att.o crypto/cms/cms_cd.o > > crypto/cms/cms_dd.o crypto/cms/cms_enc.o crypto/cms/cms_env.o > > crypto/cms/cms_err.o crypto/cms/cms_ess.o crypto/cms/cms_io.o > > crypto/cms/cms_kari.o crypto/cms/cms_lib.o crypto/cms/cms_pwri.o > > crypto/cms/cms_sd.o crypto/cms/cms_smime.o crypto/comp/c_zlib.o > > crypto/comp/comp_err.o crypto/comp/comp_lib.o crypto/conf/conf_api.o > > crypto/conf/conf_def.o crypto/conf/conf_err.o crypto/conf/conf_lib.o > > crypto/conf/conf_mall.o crypto/conf/conf_mod.o crypto/conf/conf_sap.o > > crypto/cpt_err.o crypto/cryptlib.o crypto/ct/ct_b64.o > > crypto/ct/ct_err.o crypto/ct/ct_log.o crypto/ct/ct_oct.o > > crypto/ct/ct_policy.o crypto/ct/ct_prn.o crypto/ct/ct_sct.o > > crypto/ct/ct_sct_ctx.o crypto/ct/ct_vfy.o crypto/ct/ct_x509v3.o > > crypto/cversion.o crypto/des/cbc_cksm.o crypto/des/cbc_enc.o > > crypto/des/cfb64ede.o crypto/des/cfb64enc.o crypto/des/cfb_enc.o > > crypto/des/des_enc.o crypto/des/ecb3_enc.o crypto/des/ecb_enc.o > > crypto/des/enc_read.o crypto/des/enc_writ.o crypto/des/fcrypt.o > > crypto/des/fcrypt_b.o crypto/des/ofb64ede.o crypto/des/ofb64enc.o > > crypto/des/ofb_enc.o crypto/des/pcbc_enc.o crypto/des/qud_cksm.o > > crypto/des/rand_key.o crypto/des/read2pwd.o crypto/des/rpc_enc.o > > crypto/des/set_key.o crypto/des/str2key.o crypto/des/xcbc_enc.o > > crypto/dh/dh_ameth.o crypto/dh/dh_asn1.o crypto/dh/dh_check.o > > crypto/dh/dh_depr.o crypto/dh/dh_err.o crypto/dh/dh_gen.o > > crypto/dh/dh_kdf.o crypto/dh/dh_key.o crypto/dh/dh_lib.o > > crypto/dh/dh_pmeth.o crypto/dh/dh_prn.o crypto/dh/dh_rfc5114.o > > crypto/dsa/dsa_ameth.o crypto/dsa/dsa_asn1.o crypto/dsa/dsa_depr.o > > crypto/dsa/dsa_err.o crypto/dsa/dsa_gen.o crypto/dsa/dsa_key.o > > crypto/dsa/dsa_lib.o crypto/dsa/dsa_ossl.o crypto/dsa/dsa_pmeth.o > > crypto/dsa/dsa_prn.o crypto/dsa/dsa_sign.o crypto/dsa/dsa_vrf.o > > crypto/dso/dso_dl.o crypto/dso/dso_dlfcn.o crypto/dso/dso_err.o > > crypto/dso/dso_lib.o crypto/dso/dso_null.o crypto/dso/dso_openssl.o > > crypto/dso/dso_vms.o crypto/dso/dso_win32.o crypto/ebcdic.o > > crypto/ec/curve25519.o crypto/ec/ec2_mult.o crypto/ec/ec2_oct.o > > crypto/ec/ec2_smpl.o crypto/ec/ec_25519.o crypto/ec/ec_ameth.o > > crypto/ec/ec_asn1.o crypto/ec/ec_check.o crypto/ec/ec_curve.o > > crypto/ec/ec_cvt.o crypto/ec/ec_err.o crypto/ec/ec_key.o > > crypto/ec/ec_kmeth.o crypto/ec/ec_lib.o crypto/ec/ec_mult.o > > crypto/ec/ec_oct.o crypto/ec/ec_pmeth.o crypto/ec/ec_print.o > > crypto/ec/ecdh_kdf.o crypto/ec/ecdh_ossl.o crypto/ec/ecdsa_ossl.o > > crypto/ec/ecdsa_sign.o crypto/ec/ecdsa_vrf.o crypto/ec/eck_prn.o > > crypto/ec/ecp_mont.o crypto/ec/ecp_nist.o crypto/ec/ecp_nistp224.o > > crypto/ec/ecp_nistp256.o crypto/ec/ecp_nistp521.o > > crypto/ec/ecp_nistputil.o crypto/ec/ecp_oct.o crypto/ec/ecp_smpl.o > > crypto/engine/eng_all.o crypto/engine/eng_cnf.o > > crypto/engine/eng_cryptodev.o crypto/engine/eng_ctrl.o > > crypto/engine/eng_dyn.o crypto/engine/eng_err.o > > crypto/engine/eng_fat.o crypto/engine/eng_init.o > > crypto/engine/eng_lib.o crypto/engine/eng_list.o > > crypto/engine/eng_openssl.o crypto/engine/eng_pkey.o > > crypto/engine/eng_rdrand.o crypto/engine/eng_table.o > > crypto/engine/tb_asnmth.o crypto/engine/tb_cipher.o > > crypto/engine/tb_dh.o crypto/engine/tb_digest.o crypto/engine/tb_dsa.o > > crypto/engine/tb_eckey.o crypto/engine/tb_pkmeth.o > > crypto/engine/tb_rand.o crypto/engine/tb_rsa.o crypto/err/err.o > > crypto/err/err_all.o crypto/err/err_prn.o crypto/evp/bio_b64.o > > crypto/evp/bio_enc.o crypto/evp/bio_md.o crypto/evp/bio_ok.o > > crypto/evp/c_allc.o crypto/evp/c_alld.o crypto/evp/cmeth_lib.o > > crypto/evp/digest.o crypto/evp/e_aes.o > > crypto/evp/e_aes_cbc_hmac_sha1.o crypto/evp/e_aes_cbc_hmac_sha256.o > > crypto/evp/e_bf.o crypto/evp/e_camellia.o crypto/evp/e_cast.o > > crypto/evp/e_chacha20_poly1305.o crypto/evp/e_des.o > > crypto/evp/e_des3.o crypto/evp/e_idea.o crypto/evp/e_null.o > > crypto/evp/e_old.o crypto/evp/e_rc2.o crypto/evp/e_rc4.o > > crypto/evp/e_rc4_hmac_md5.o crypto/evp/e_rc5.o crypto/evp/e_seed.o > > crypto/evp/e_xcbc_d.o crypto/evp/encode.o crypto/evp/evp_cnf.o > > crypto/evp/evp_enc.o crypto/evp/evp_err.o crypto/evp/evp_key.o > > crypto/evp/evp_lib.o crypto/evp/evp_pbe.o crypto/evp/evp_pkey.o > > crypto/evp/m_md2.o crypto/evp/m_md4.o crypto/evp/m_md5.o > > crypto/evp/m_md5_sha1.o crypto/evp/m_mdc2.o crypto/evp/m_null.o > > crypto/evp/m_ripemd.o crypto/evp/m_sha1.o crypto/evp/m_sigver.o > > crypto/evp/m_wp.o crypto/evp/names.o crypto/evp/p5_crpt.o > > crypto/evp/p5_crpt2.o crypto/evp/p_dec.o crypto/evp/p_enc.o > > crypto/evp/p_lib.o crypto/evp/p_open.o crypto/evp/p_seal.o > > crypto/evp/p_sign.o crypto/evp/p_verify.o crypto/evp/pmeth_fn.o > > crypto/evp/pmeth_gn.o crypto/evp/pmeth_lib.o crypto/evp/scrypt.o > > crypto/ex_data.o crypto/hmac/hm_ameth.o crypto/hmac/hm_pmeth.o > > crypto/hmac/hmac.o crypto/idea/i_cbc.o crypto/idea/i_cfb64.o > > crypto/idea/i_ecb.o crypto/idea/i_ofb64.o crypto/idea/i_skey.o > > crypto/init.o crypto/kdf/hkdf.o crypto/kdf/kdf_err.o > > crypto/kdf/tls1_prf.o crypto/lhash/lh_stats.o crypto/lhash/lhash.o > > crypto/md4/md4_dgst.o crypto/md4/md4_one.o crypto/md5/md5_dgst.o > > crypto/md5/md5_one.o crypto/mdc2/mdc2_one.o crypto/mdc2/mdc2dgst.o > > crypto/mem.o crypto/mem_clr.o crypto/mem_dbg.o crypto/mem_sec.o > > crypto/modes/cbc128.o crypto/modes/ccm128.o crypto/modes/cfb128.o > > crypto/modes/ctr128.o crypto/modes/cts128.o crypto/modes/gcm128.o > > crypto/modes/ocb128.o crypto/modes/ofb128.o crypto/modes/wrap128.o > > crypto/modes/xts128.o crypto/o_dir.o crypto/o_fips.o crypto/o_init.o > > crypto/o_str.o crypto/o_time.o crypto/objects/o_names.o > > crypto/objects/obj_dat.o crypto/objects/obj_err.o > > crypto/objects/obj_lib.o crypto/objects/obj_xref.o > > crypto/ocsp/ocsp_asn.o crypto/ocsp/ocsp_cl.o crypto/ocsp/ocsp_err.o > > crypto/ocsp/ocsp_ext.o crypto/ocsp/ocsp_ht.o crypto/ocsp/ocsp_lib.o > > crypto/ocsp/ocsp_prn.o crypto/ocsp/ocsp_srv.o crypto/ocsp/ocsp_vfy.o > > crypto/ocsp/v3_ocsp.o crypto/pem/pem_all.o crypto/pem/pem_err.o > > crypto/pem/pem_info.o crypto/pem/pem_lib.o crypto/pem/pem_oth.o > > crypto/pem/pem_pk8.o crypto/pem/pem_pkey.o crypto/pem/pem_sign.o > > crypto/pem/pem_x509.o crypto/pem/pem_xaux.o crypto/pem/pvkfmt.o > > crypto/pkcs12/p12_add.o crypto/pkcs12/p12_asn.o > > crypto/pkcs12/p12_attr.o crypto/pkcs12/p12_crpt.o > > crypto/pkcs12/p12_crt.o crypto/pkcs12/p12_decr.o > > crypto/pkcs12/p12_init.o crypto/pkcs12/p12_key.o > > crypto/pkcs12/p12_kiss.o crypto/pkcs12/p12_mutl.o > > crypto/pkcs12/p12_npas.o crypto/pkcs12/p12_p8d.o > > crypto/pkcs12/p12_p8e.o crypto/pkcs12/p12_sbag.o > > crypto/pkcs12/p12_utl.o crypto/pkcs12/pk12err.o crypto/pkcs7/bio_pk7.o > > crypto/pkcs7/pk7_asn1.o crypto/pkcs7/pk7_attr.o > > crypto/pkcs7/pk7_doit.o crypto/pkcs7/pk7_lib.o crypto/pkcs7/pk7_mime.o > > crypto/pkcs7/pk7_smime.o crypto/pkcs7/pkcs7err.o > > crypto/poly1305/poly1305.o crypto/rand/md_rand.o > > crypto/rand/rand_egd.o crypto/rand/rand_err.o crypto/rand/rand_lib.o > > crypto/rand/rand_unix.o crypto/rand/rand_vms.o crypto/rand/rand_win.o > > crypto/rand/randfile.o crypto/rc2/rc2_cbc.o crypto/rc2/rc2_ecb.o > > crypto/rc2/rc2_skey.o crypto/rc2/rc2cfb64.o crypto/rc2/rc2ofb64.o > > crypto/rc4/rc4_enc.o crypto/rc4/rc4_skey.o crypto/ripemd/rmd_dgst.o > > crypto/ripemd/rmd_one.o crypto/rsa/rsa_ameth.o crypto/rsa/rsa_asn1.o > > crypto/rsa/rsa_chk.o crypto/rsa/rsa_crpt.o crypto/rsa/rsa_depr.o > > crypto/rsa/rsa_err.o crypto/rsa/rsa_gen.o crypto/rsa/rsa_lib.o > > crypto/rsa/rsa_none.o crypto/rsa/rsa_null.o crypto/rsa/rsa_oaep.o > > crypto/rsa/rsa_ossl.o crypto/rsa/rsa_pk1.o crypto/rsa/rsa_pmeth.o > > crypto/rsa/rsa_prn.o crypto/rsa/rsa_pss.o crypto/rsa/rsa_saos.o > > crypto/rsa/rsa_sign.o crypto/rsa/rsa_ssl.o crypto/rsa/rsa_x931.o > > crypto/rsa/rsa_x931g.o crypto/seed/seed.o crypto/seed/seed_cbc.o > > crypto/seed/seed_cfb.o crypto/seed/seed_ecb.o crypto/seed/seed_ofb.o > > crypto/sha/sha1_one.o crypto/sha/sha1dgst.o crypto/sha/sha256.o > > crypto/sha/sha512.o crypto/srp/srp_lib.o crypto/srp/srp_vfy.o > > crypto/stack/stack.o crypto/threads_none.o crypto/threads_pthread.o > > crypto/threads_win.o crypto/ts/ts_asn1.o crypto/ts/ts_conf.o > > crypto/ts/ts_err.o crypto/ts/ts_lib.o crypto/ts/ts_req_print.o > > crypto/ts/ts_req_utils.o crypto/ts/ts_rsp_print.o > > crypto/ts/ts_rsp_sign.o crypto/ts/ts_rsp_utils.o > > crypto/ts/ts_rsp_verify.o crypto/ts/ts_verify_ctx.o > > crypto/txt_db/txt_db.o crypto/ui/ui_err.o crypto/ui/ui_lib.o > > crypto/ui/ui_openssl.o crypto/ui/ui_util.o crypto/uid.o > > crypto/whrlpool/wp_block.o crypto/whrlpool/wp_dgst.o > > crypto/x509/by_dir.o crypto/x509/by_file.o crypto/x509/t_crl.o > > crypto/x509/t_req.o crypto/x509/t_x509.o crypto/x509/x509_att.o > > crypto/x509/x509_cmp.o crypto/x509/x509_d2.o crypto/x509/x509_def.o > > crypto/x509/x509_err.o crypto/x509/x509_ext.o crypto/x509/x509_lu.o > > crypto/x509/x509_obj.o crypto/x509/x509_r2x.o crypto/x509/x509_req.o > > crypto/x509/x509_set.o crypto/x509/x509_trs.o crypto/x509/x509_txt.o > > crypto/x509/x509_v3.o crypto/x509/x509_vfy.o crypto/x509/x509_vpm.o > > crypto/x509/x509cset.o crypto/x509/x509name.o crypto/x509/x509rset.o > > crypto/x509/x509spki.o crypto/x509/x509type.o crypto/x509/x_all.o > > crypto/x509/x_attrib.o crypto/x509/x_crl.o crypto/x509/x_exten.o > > crypto/x509/x_name.o crypto/x509/x_req.o crypto/x509/x_x509.o > > crypto/x509/x_x509a.o crypto/x509v3/pcy_cache.o > > crypto/x509v3/pcy_data.o crypto/x509v3/pcy_lib.o > > crypto/x509v3/pcy_map.o crypto/x509v3/pcy_node.o > > crypto/x509v3/pcy_tree.o crypto/x509v3/v3_addr.o > > crypto/x509v3/v3_akey.o crypto/x509v3/v3_akeya.o > > crypto/x509v3/v3_alt.o crypto/x509v3/v3_asid.o > > crypto/x509v3/v3_bcons.o crypto/x509v3/v3_bitst.o > > crypto/x509v3/v3_conf.o crypto/x509v3/v3_cpols.o > > crypto/x509v3/v3_crld.o crypto/x509v3/v3_enum.o > > crypto/x509v3/v3_extku.o crypto/x509v3/v3_genn.o > > crypto/x509v3/v3_ia5.o crypto/x509v3/v3_info.o crypto/x509v3/v3_int.o > > crypto/x509v3/v3_lib.o crypto/x509v3/v3_ncons.o crypto/x509v3/v3_pci.o > > crypto/x509v3/v3_pcia.o crypto/x509v3/v3_pcons.o > > crypto/x509v3/v3_pku.o crypto/x509v3/v3_pmaps.o crypto/x509v3/v3_prn.o > > crypto/x509v3/v3_purp.o crypto/x509v3/v3_skey.o > > crypto/x509v3/v3_sxnet.o crypto/x509v3/v3_tlsf.o > > crypto/x509v3/v3_utl.o crypto/x509v3/v3err.o engines/e_capi.o > > engines/e_dasync.o engines/e_padlock.o > > /usr/bin/ranlib libcrypto.a || echo Never mind. > > gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_THREADS > > -DOPENSSL_NO_DYNAMIC_ENGINE -DOPENSSL_PIC -D_XOPEN_SOURCE=600 > > -DOPENSSLDIR="\"/usr/local/ssl\"" > > -DENGINESDIR="\"/usr/local/lib/engines\"" -Wall -O3 -pthread > > -DL_ENDIAN -fomit-frame-pointer -fPIC -Iinclude -I. -c -o > > ssl/bio_ssl.o ssl/bio_ssl.c > > In file included from ssl/bio_ssl.c:65: > > ssl/ssl_locl.h:1501: error: field `next_timeout' has incomplete type > -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4553 Please log in as guest with password guest if prompted From rt at openssl.org Wed Jun 1 21:22:24 2016 From: rt at openssl.org (noloader@gmail.com via RT) Date: Wed, 01 Jun 2016 21:22:24 +0000 Subject: [openssl-dev] [openssl.org #4553] Re: Fedora 1, i386: error: field `next_timeout` has incomplete type In-Reply-To: References: Message-ID: On Wed, Jun 1, 2016 at 4:47 PM, Richard Levitte via RT wrote: > Please give us the full configuration command you used, including environment > variables that may affect it. Just the presence of '-ansi' tells me that you > didn't just say './config' without any arguments. Sorry Richard. Yes, it was a straight "./config" followed by a "make". I deleted the the openssl directory and started over. Previously I just unzipped overtop the old installation. I'm guessing something was misconfigured because I get further now. Here's the new issue: chacha-x86.s assembler problems, http://postimg.org/image/sl28mxfmz/. I also "git pull" followed by a new ISO build for the VM. Same result. Jeff > On Wed Jun 01 19:54:51 2016, noloader at gmail.com wrote: >> So testing with 1.1.0-pre6 from 1 JUN 2016 appears to show some new issues. >> >> ./config detects as i686-linux-whatever. However, there are some >> issues with CFLAGS. The '-arch x86_64' makes it appear to be >> configured for quasi-OS X mode. I believe -m32 should be used if an >> arch is needed. There's also some complaints about -c and -o, but I >> think the compiler confusion starts earlier. >> >> Here's a screen capture of the error: http://postimg.org/image/e9nvrko17/ . >> >> My apologies for the screen capture. I kind of cheat and get the >> tarball onto the VM by building an ISO and mounting it with the CDROM. >> I have not figured out how to get data to travel the other way. >> >> Jeff >> >> On Sun, Mar 20, 2016 at 8:31 AM, Jeffrey Walton wrote: >> > I know this is kind of an old machine with GCC 3.3... >> > >> > With an updated PERL and a './config no-asm -D_XOPEN_SOURCE=600', I >> > can almost get through a compile. After libcrypto.a is built, the next >> > compile line is: >> > >> > gcc ... -c -o ssl/bio_ssl.o ssl/bio_ssl.c >> > >> > At that point, there's a: >> > >> > In file included from ssl/bio_ssl.c:65 >> > ssl/ssl_locl.h:1501: error: field `next_timeout` has incomplete type >> > [ssl/bio_ssl.o] Error 1 >> > >> > The issue was cleared by adding to "ssl/ssl_locl.h". >> > >> > ********** >> > >> > ar r libcrypto.a crypto/aes/aes_cbc.o crypto/aes/aes_cfb.o >> > crypto/aes/aes_core.o crypto/aes/aes_ecb.o crypto/aes/aes_ige.o >> > crypto/aes/aes_misc.o crypto/aes/aes_ofb.o crypto/aes/aes_wrap.o >> > crypto/asn1/a_bitstr.o crypto/asn1/a_d2i_fp.o crypto/asn1/a_digest.o >> > crypto/asn1/a_dup.o crypto/asn1/a_gentm.o crypto/asn1/a_i2d_fp.o >> > crypto/asn1/a_int.o crypto/asn1/a_mbstr.o crypto/asn1/a_object.o >> > crypto/asn1/a_octet.o crypto/asn1/a_print.o crypto/asn1/a_sign.o >> > crypto/asn1/a_strex.o crypto/asn1/a_strnid.o crypto/asn1/a_time.o >> > crypto/asn1/a_type.o crypto/asn1/a_utctm.o crypto/asn1/a_utf8.o >> > crypto/asn1/a_verify.o crypto/asn1/ameth_lib.o crypto/asn1/asn1_err.o >> > crypto/asn1/asn1_gen.o crypto/asn1/asn1_lib.o crypto/asn1/asn1_par.o >> > crypto/asn1/asn_mime.o crypto/asn1/asn_moid.o crypto/asn1/asn_mstbl.o >> > crypto/asn1/asn_pack.o crypto/asn1/bio_asn1.o crypto/asn1/bio_ndef.o >> > crypto/asn1/d2i_pr.o crypto/asn1/d2i_pu.o crypto/asn1/evp_asn1.o >> > crypto/asn1/f_int.o crypto/asn1/f_string.o crypto/asn1/i2d_pr.o >> > crypto/asn1/i2d_pu.o crypto/asn1/n_pkey.o crypto/asn1/nsseq.o >> > crypto/asn1/p5_pbe.o crypto/asn1/p5_pbev2.o crypto/asn1/p5_scrypt.o >> > crypto/asn1/p8_pkey.o crypto/asn1/t_bitst.o crypto/asn1/t_pkey.o >> > crypto/asn1/t_spki.o crypto/asn1/tasn_dec.o crypto/asn1/tasn_enc.o >> > crypto/asn1/tasn_fre.o crypto/asn1/tasn_new.o crypto/asn1/tasn_prn.o >> > crypto/asn1/tasn_scn.o crypto/asn1/tasn_typ.o crypto/asn1/tasn_utl.o >> > crypto/asn1/x_algor.o crypto/asn1/x_bignum.o crypto/asn1/x_info.o >> > crypto/asn1/x_long.o crypto/asn1/x_pkey.o crypto/asn1/x_pubkey.o >> > crypto/asn1/x_sig.o crypto/asn1/x_spki.o crypto/asn1/x_val.o >> > crypto/async/arch/async_null.o crypto/async/arch/async_posix.o >> > crypto/async/arch/async_win.o crypto/async/async.o >> > crypto/async/async_err.o crypto/async/async_wait.o >> > crypto/bf/bf_cfb64.o crypto/bf/bf_ecb.o crypto/bf/bf_enc.o >> > crypto/bf/bf_ofb64.o crypto/bf/bf_skey.o crypto/bio/b_addr.o >> > crypto/bio/b_dump.o crypto/bio/b_print.o crypto/bio/b_sock.o >> > crypto/bio/b_sock2.o crypto/bio/bf_buff.o crypto/bio/bf_nbio.o >> > crypto/bio/bf_null.o crypto/bio/bio_cb.o crypto/bio/bio_err.o >> > crypto/bio/bio_lib.o crypto/bio/bss_acpt.o crypto/bio/bss_bio.o >> > crypto/bio/bss_conn.o crypto/bio/bss_dgram.o crypto/bio/bss_fd.o >> > crypto/bio/bss_file.o crypto/bio/bss_log.o crypto/bio/bss_mem.o >> > crypto/bio/bss_null.o crypto/bio/bss_sock.o crypto/blake2/blake2b.o >> > crypto/blake2/blake2s.o crypto/blake2/m_blake2b.o >> > crypto/blake2/m_blake2s.o crypto/bn/bn_add.o crypto/bn/bn_asm.o >> > crypto/bn/bn_blind.o crypto/bn/bn_const.o crypto/bn/bn_ctx.o >> > crypto/bn/bn_depr.o crypto/bn/bn_dh.o crypto/bn/bn_div.o >> > crypto/bn/bn_err.o crypto/bn/bn_exp.o crypto/bn/bn_exp2.o >> > crypto/bn/bn_gcd.o crypto/bn/bn_gf2m.o crypto/bn/bn_intern.o >> > crypto/bn/bn_kron.o crypto/bn/bn_lib.o crypto/bn/bn_mod.o >> > crypto/bn/bn_mont.o crypto/bn/bn_mpi.o crypto/bn/bn_mul.o >> > crypto/bn/bn_nist.o crypto/bn/bn_prime.o crypto/bn/bn_print.o >> > crypto/bn/bn_rand.o crypto/bn/bn_recp.o crypto/bn/bn_shift.o >> > crypto/bn/bn_sqr.o crypto/bn/bn_sqrt.o crypto/bn/bn_srp.o >> > crypto/bn/bn_word.o crypto/bn/bn_x931p.o crypto/buffer/buf_err.o >> > crypto/buffer/buffer.o crypto/camellia/camellia.o >> > crypto/camellia/cmll_cbc.o crypto/camellia/cmll_cfb.o >> > crypto/camellia/cmll_ctr.o crypto/camellia/cmll_ecb.o >> > crypto/camellia/cmll_misc.o crypto/camellia/cmll_ofb.o >> > crypto/cast/c_cfb64.o crypto/cast/c_ecb.o crypto/cast/c_enc.o >> > crypto/cast/c_ofb64.o crypto/cast/c_skey.o crypto/chacha/chacha_enc.o >> > crypto/cmac/cm_ameth.o crypto/cmac/cm_pmeth.o crypto/cmac/cmac.o >> > crypto/cms/cms_asn1.o crypto/cms/cms_att.o crypto/cms/cms_cd.o >> > crypto/cms/cms_dd.o crypto/cms/cms_enc.o crypto/cms/cms_env.o >> > crypto/cms/cms_err.o crypto/cms/cms_ess.o crypto/cms/cms_io.o >> > crypto/cms/cms_kari.o crypto/cms/cms_lib.o crypto/cms/cms_pwri.o >> > crypto/cms/cms_sd.o crypto/cms/cms_smime.o crypto/comp/c_zlib.o >> > crypto/comp/comp_err.o crypto/comp/comp_lib.o crypto/conf/conf_api.o >> > crypto/conf/conf_def.o crypto/conf/conf_err.o crypto/conf/conf_lib.o >> > crypto/conf/conf_mall.o crypto/conf/conf_mod.o crypto/conf/conf_sap.o >> > crypto/cpt_err.o crypto/cryptlib.o crypto/ct/ct_b64.o >> > crypto/ct/ct_err.o crypto/ct/ct_log.o crypto/ct/ct_oct.o >> > crypto/ct/ct_policy.o crypto/ct/ct_prn.o crypto/ct/ct_sct.o >> > crypto/ct/ct_sct_ctx.o crypto/ct/ct_vfy.o crypto/ct/ct_x509v3.o >> > crypto/cversion.o crypto/des/cbc_cksm.o crypto/des/cbc_enc.o >> > crypto/des/cfb64ede.o crypto/des/cfb64enc.o crypto/des/cfb_enc.o >> > crypto/des/des_enc.o crypto/des/ecb3_enc.o crypto/des/ecb_enc.o >> > crypto/des/enc_read.o crypto/des/enc_writ.o crypto/des/fcrypt.o >> > crypto/des/fcrypt_b.o crypto/des/ofb64ede.o crypto/des/ofb64enc.o >> > crypto/des/ofb_enc.o crypto/des/pcbc_enc.o crypto/des/qud_cksm.o >> > crypto/des/rand_key.o crypto/des/read2pwd.o crypto/des/rpc_enc.o >> > crypto/des/set_key.o crypto/des/str2key.o crypto/des/xcbc_enc.o >> > crypto/dh/dh_ameth.o crypto/dh/dh_asn1.o crypto/dh/dh_check.o >> > crypto/dh/dh_depr.o crypto/dh/dh_err.o crypto/dh/dh_gen.o >> > crypto/dh/dh_kdf.o crypto/dh/dh_key.o crypto/dh/dh_lib.o >> > crypto/dh/dh_pmeth.o crypto/dh/dh_prn.o crypto/dh/dh_rfc5114.o >> > crypto/dsa/dsa_ameth.o crypto/dsa/dsa_asn1.o crypto/dsa/dsa_depr.o >> > crypto/dsa/dsa_err.o crypto/dsa/dsa_gen.o crypto/dsa/dsa_key.o >> > crypto/dsa/dsa_lib.o crypto/dsa/dsa_ossl.o crypto/dsa/dsa_pmeth.o >> > crypto/dsa/dsa_prn.o crypto/dsa/dsa_sign.o crypto/dsa/dsa_vrf.o >> > crypto/dso/dso_dl.o crypto/dso/dso_dlfcn.o crypto/dso/dso_err.o >> > crypto/dso/dso_lib.o crypto/dso/dso_null.o crypto/dso/dso_openssl.o >> > crypto/dso/dso_vms.o crypto/dso/dso_win32.o crypto/ebcdic.o >> > crypto/ec/curve25519.o crypto/ec/ec2_mult.o crypto/ec/ec2_oct.o >> > crypto/ec/ec2_smpl.o crypto/ec/ec_25519.o crypto/ec/ec_ameth.o >> > crypto/ec/ec_asn1.o crypto/ec/ec_check.o crypto/ec/ec_curve.o >> > crypto/ec/ec_cvt.o crypto/ec/ec_err.o crypto/ec/ec_key.o >> > crypto/ec/ec_kmeth.o crypto/ec/ec_lib.o crypto/ec/ec_mult.o >> > crypto/ec/ec_oct.o crypto/ec/ec_pmeth.o crypto/ec/ec_print.o >> > crypto/ec/ecdh_kdf.o crypto/ec/ecdh_ossl.o crypto/ec/ecdsa_ossl.o >> > crypto/ec/ecdsa_sign.o crypto/ec/ecdsa_vrf.o crypto/ec/eck_prn.o >> > crypto/ec/ecp_mont.o crypto/ec/ecp_nist.o crypto/ec/ecp_nistp224.o >> > crypto/ec/ecp_nistp256.o crypto/ec/ecp_nistp521.o >> > crypto/ec/ecp_nistputil.o crypto/ec/ecp_oct.o crypto/ec/ecp_smpl.o >> > crypto/engine/eng_all.o crypto/engine/eng_cnf.o >> > crypto/engine/eng_cryptodev.o crypto/engine/eng_ctrl.o >> > crypto/engine/eng_dyn.o crypto/engine/eng_err.o >> > crypto/engine/eng_fat.o crypto/engine/eng_init.o >> > crypto/engine/eng_lib.o crypto/engine/eng_list.o >> > crypto/engine/eng_openssl.o crypto/engine/eng_pkey.o >> > crypto/engine/eng_rdrand.o crypto/engine/eng_table.o >> > crypto/engine/tb_asnmth.o crypto/engine/tb_cipher.o >> > crypto/engine/tb_dh.o crypto/engine/tb_digest.o crypto/engine/tb_dsa.o >> > crypto/engine/tb_eckey.o crypto/engine/tb_pkmeth.o >> > crypto/engine/tb_rand.o crypto/engine/tb_rsa.o crypto/err/err.o >> > crypto/err/err_all.o crypto/err/err_prn.o crypto/evp/bio_b64.o >> > crypto/evp/bio_enc.o crypto/evp/bio_md.o crypto/evp/bio_ok.o >> > crypto/evp/c_allc.o crypto/evp/c_alld.o crypto/evp/cmeth_lib.o >> > crypto/evp/digest.o crypto/evp/e_aes.o >> > crypto/evp/e_aes_cbc_hmac_sha1.o crypto/evp/e_aes_cbc_hmac_sha256.o >> > crypto/evp/e_bf.o crypto/evp/e_camellia.o crypto/evp/e_cast.o >> > crypto/evp/e_chacha20_poly1305.o crypto/evp/e_des.o >> > crypto/evp/e_des3.o crypto/evp/e_idea.o crypto/evp/e_null.o >> > crypto/evp/e_old.o crypto/evp/e_rc2.o crypto/evp/e_rc4.o >> > crypto/evp/e_rc4_hmac_md5.o crypto/evp/e_rc5.o crypto/evp/e_seed.o >> > crypto/evp/e_xcbc_d.o crypto/evp/encode.o crypto/evp/evp_cnf.o >> > crypto/evp/evp_enc.o crypto/evp/evp_err.o crypto/evp/evp_key.o >> > crypto/evp/evp_lib.o crypto/evp/evp_pbe.o crypto/evp/evp_pkey.o >> > crypto/evp/m_md2.o crypto/evp/m_md4.o crypto/evp/m_md5.o >> > crypto/evp/m_md5_sha1.o crypto/evp/m_mdc2.o crypto/evp/m_null.o >> > crypto/evp/m_ripemd.o crypto/evp/m_sha1.o crypto/evp/m_sigver.o >> > crypto/evp/m_wp.o crypto/evp/names.o crypto/evp/p5_crpt.o >> > crypto/evp/p5_crpt2.o crypto/evp/p_dec.o crypto/evp/p_enc.o >> > crypto/evp/p_lib.o crypto/evp/p_open.o crypto/evp/p_seal.o >> > crypto/evp/p_sign.o crypto/evp/p_verify.o crypto/evp/pmeth_fn.o >> > crypto/evp/pmeth_gn.o crypto/evp/pmeth_lib.o crypto/evp/scrypt.o >> > crypto/ex_data.o crypto/hmac/hm_ameth.o crypto/hmac/hm_pmeth.o >> > crypto/hmac/hmac.o crypto/idea/i_cbc.o crypto/idea/i_cfb64.o >> > crypto/idea/i_ecb.o crypto/idea/i_ofb64.o crypto/idea/i_skey.o >> > crypto/init.o crypto/kdf/hkdf.o crypto/kdf/kdf_err.o >> > crypto/kdf/tls1_prf.o crypto/lhash/lh_stats.o crypto/lhash/lhash.o >> > crypto/md4/md4_dgst.o crypto/md4/md4_one.o crypto/md5/md5_dgst.o >> > crypto/md5/md5_one.o crypto/mdc2/mdc2_one.o crypto/mdc2/mdc2dgst.o >> > crypto/mem.o crypto/mem_clr.o crypto/mem_dbg.o crypto/mem_sec.o >> > crypto/modes/cbc128.o crypto/modes/ccm128.o crypto/modes/cfb128.o >> > crypto/modes/ctr128.o crypto/modes/cts128.o crypto/modes/gcm128.o >> > crypto/modes/ocb128.o crypto/modes/ofb128.o crypto/modes/wrap128.o >> > crypto/modes/xts128.o crypto/o_dir.o crypto/o_fips.o crypto/o_init.o >> > crypto/o_str.o crypto/o_time.o crypto/objects/o_names.o >> > crypto/objects/obj_dat.o crypto/objects/obj_err.o >> > crypto/objects/obj_lib.o crypto/objects/obj_xref.o >> > crypto/ocsp/ocsp_asn.o crypto/ocsp/ocsp_cl.o crypto/ocsp/ocsp_err.o >> > crypto/ocsp/ocsp_ext.o crypto/ocsp/ocsp_ht.o crypto/ocsp/ocsp_lib.o >> > crypto/ocsp/ocsp_prn.o crypto/ocsp/ocsp_srv.o crypto/ocsp/ocsp_vfy.o >> > crypto/ocsp/v3_ocsp.o crypto/pem/pem_all.o crypto/pem/pem_err.o >> > crypto/pem/pem_info.o crypto/pem/pem_lib.o crypto/pem/pem_oth.o >> > crypto/pem/pem_pk8.o crypto/pem/pem_pkey.o crypto/pem/pem_sign.o >> > crypto/pem/pem_x509.o crypto/pem/pem_xaux.o crypto/pem/pvkfmt.o >> > crypto/pkcs12/p12_add.o crypto/pkcs12/p12_asn.o >> > crypto/pkcs12/p12_attr.o crypto/pkcs12/p12_crpt.o >> > crypto/pkcs12/p12_crt.o crypto/pkcs12/p12_decr.o >> > crypto/pkcs12/p12_init.o crypto/pkcs12/p12_key.o >> > crypto/pkcs12/p12_kiss.o crypto/pkcs12/p12_mutl.o >> > crypto/pkcs12/p12_npas.o crypto/pkcs12/p12_p8d.o >> > crypto/pkcs12/p12_p8e.o crypto/pkcs12/p12_sbag.o >> > crypto/pkcs12/p12_utl.o crypto/pkcs12/pk12err.o crypto/pkcs7/bio_pk7.o >> > crypto/pkcs7/pk7_asn1.o crypto/pkcs7/pk7_attr.o >> > crypto/pkcs7/pk7_doit.o crypto/pkcs7/pk7_lib.o crypto/pkcs7/pk7_mime.o >> > crypto/pkcs7/pk7_smime.o crypto/pkcs7/pkcs7err.o >> > crypto/poly1305/poly1305.o crypto/rand/md_rand.o >> > crypto/rand/rand_egd.o crypto/rand/rand_err.o crypto/rand/rand_lib.o >> > crypto/rand/rand_unix.o crypto/rand/rand_vms.o crypto/rand/rand_win.o >> > crypto/rand/randfile.o crypto/rc2/rc2_cbc.o crypto/rc2/rc2_ecb.o >> > crypto/rc2/rc2_skey.o crypto/rc2/rc2cfb64.o crypto/rc2/rc2ofb64.o >> > crypto/rc4/rc4_enc.o crypto/rc4/rc4_skey.o crypto/ripemd/rmd_dgst.o >> > crypto/ripemd/rmd_one.o crypto/rsa/rsa_ameth.o crypto/rsa/rsa_asn1.o >> > crypto/rsa/rsa_chk.o crypto/rsa/rsa_crpt.o crypto/rsa/rsa_depr.o >> > crypto/rsa/rsa_err.o crypto/rsa/rsa_gen.o crypto/rsa/rsa_lib.o >> > crypto/rsa/rsa_none.o crypto/rsa/rsa_null.o crypto/rsa/rsa_oaep.o >> > crypto/rsa/rsa_ossl.o crypto/rsa/rsa_pk1.o crypto/rsa/rsa_pmeth.o >> > crypto/rsa/rsa_prn.o crypto/rsa/rsa_pss.o crypto/rsa/rsa_saos.o >> > crypto/rsa/rsa_sign.o crypto/rsa/rsa_ssl.o crypto/rsa/rsa_x931.o >> > crypto/rsa/rsa_x931g.o crypto/seed/seed.o crypto/seed/seed_cbc.o >> > crypto/seed/seed_cfb.o crypto/seed/seed_ecb.o crypto/seed/seed_ofb.o >> > crypto/sha/sha1_one.o crypto/sha/sha1dgst.o crypto/sha/sha256.o >> > crypto/sha/sha512.o crypto/srp/srp_lib.o crypto/srp/srp_vfy.o >> > crypto/stack/stack.o crypto/threads_none.o crypto/threads_pthread.o >> > crypto/threads_win.o crypto/ts/ts_asn1.o crypto/ts/ts_conf.o >> > crypto/ts/ts_err.o crypto/ts/ts_lib.o crypto/ts/ts_req_print.o >> > crypto/ts/ts_req_utils.o crypto/ts/ts_rsp_print.o >> > crypto/ts/ts_rsp_sign.o crypto/ts/ts_rsp_utils.o >> > crypto/ts/ts_rsp_verify.o crypto/ts/ts_verify_ctx.o >> > crypto/txt_db/txt_db.o crypto/ui/ui_err.o crypto/ui/ui_lib.o >> > crypto/ui/ui_openssl.o crypto/ui/ui_util.o crypto/uid.o >> > crypto/whrlpool/wp_block.o crypto/whrlpool/wp_dgst.o >> > crypto/x509/by_dir.o crypto/x509/by_file.o crypto/x509/t_crl.o >> > crypto/x509/t_req.o crypto/x509/t_x509.o crypto/x509/x509_att.o >> > crypto/x509/x509_cmp.o crypto/x509/x509_d2.o crypto/x509/x509_def.o >> > crypto/x509/x509_err.o crypto/x509/x509_ext.o crypto/x509/x509_lu.o >> > crypto/x509/x509_obj.o crypto/x509/x509_r2x.o crypto/x509/x509_req.o >> > crypto/x509/x509_set.o crypto/x509/x509_trs.o crypto/x509/x509_txt.o >> > crypto/x509/x509_v3.o crypto/x509/x509_vfy.o crypto/x509/x509_vpm.o >> > crypto/x509/x509cset.o crypto/x509/x509name.o crypto/x509/x509rset.o >> > crypto/x509/x509spki.o crypto/x509/x509type.o crypto/x509/x_all.o >> > crypto/x509/x_attrib.o crypto/x509/x_crl.o crypto/x509/x_exten.o >> > crypto/x509/x_name.o crypto/x509/x_req.o crypto/x509/x_x509.o >> > crypto/x509/x_x509a.o crypto/x509v3/pcy_cache.o >> > crypto/x509v3/pcy_data.o crypto/x509v3/pcy_lib.o >> > crypto/x509v3/pcy_map.o crypto/x509v3/pcy_node.o >> > crypto/x509v3/pcy_tree.o crypto/x509v3/v3_addr.o >> > crypto/x509v3/v3_akey.o crypto/x509v3/v3_akeya.o >> > crypto/x509v3/v3_alt.o crypto/x509v3/v3_asid.o >> > crypto/x509v3/v3_bcons.o crypto/x509v3/v3_bitst.o >> > crypto/x509v3/v3_conf.o crypto/x509v3/v3_cpols.o >> > crypto/x509v3/v3_crld.o crypto/x509v3/v3_enum.o >> > crypto/x509v3/v3_extku.o crypto/x509v3/v3_genn.o >> > crypto/x509v3/v3_ia5.o crypto/x509v3/v3_info.o crypto/x509v3/v3_int.o >> > crypto/x509v3/v3_lib.o crypto/x509v3/v3_ncons.o crypto/x509v3/v3_pci.o >> > crypto/x509v3/v3_pcia.o crypto/x509v3/v3_pcons.o >> > crypto/x509v3/v3_pku.o crypto/x509v3/v3_pmaps.o crypto/x509v3/v3_prn.o >> > crypto/x509v3/v3_purp.o crypto/x509v3/v3_skey.o >> > crypto/x509v3/v3_sxnet.o crypto/x509v3/v3_tlsf.o >> > crypto/x509v3/v3_utl.o crypto/x509v3/v3err.o engines/e_capi.o >> > engines/e_dasync.o engines/e_padlock.o >> > /usr/bin/ranlib libcrypto.a || echo Never mind. >> > gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_THREADS >> > -DOPENSSL_NO_DYNAMIC_ENGINE -DOPENSSL_PIC -D_XOPEN_SOURCE=600 >> > -DOPENSSLDIR="\"/usr/local/ssl\"" >> > -DENGINESDIR="\"/usr/local/lib/engines\"" -Wall -O3 -pthread >> > -DL_ENDIAN -fomit-frame-pointer -fPIC -Iinclude -I. -c -o >> > ssl/bio_ssl.o ssl/bio_ssl.c >> > In file included from ssl/bio_ssl.c:65: >> > ssl/ssl_locl.h:1501: error: field `next_timeout' has incomplete type -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4553 Please log in as guest with password guest if prompted From sfhacker at hotmail.com Wed Jun 1 22:18:30 2016 From: sfhacker at hotmail.com (Sergio NNX) Date: Thu, 2 Jun 2016 08:18:30 +1000 Subject: [openssl-dev] [OpenSSL][1.0.2h] Memory leaks In-Reply-To: <574F1805.9080203@gmail.com> References: <5343CAC0.2010103@gmail.com>, , <574F1805.9080203@gmail.com> Message-ID: > How did you configure/build? What versions of mingw/msys did you use? ./configure mingw --prefix=/mingw make depend make all make test MSYS 1.0.18(0.48/3/2) 2012-11-21 22:34 i686 unknown; targ=MINGW32 GCC 6.1.0 32-bit Memory leaks didn't occur with previous OpenSSL versions using the same environment. I'm trying OpenSSL from master now but facing issues with Perl at the moment. Grrr. Can you try building it using MinGW/MSYS 32-bit? Thanks for looking at it. Cheers. Ser. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Wed Jun 1 22:20:38 2016 From: rt at openssl.org (Matt Caswell via RT) Date: Wed, 01 Jun 2016 22:20:38 +0000 Subject: [openssl-dev] [openssl.org #4434] Gentoo 13, x86_64: 4 failed self tests In-Reply-To: References: Message-ID: Hi Jeff Please could you try the attached patch? Thanks Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4434 Please log in as guest with password guest if prompted -------------- next part -------------- A non-text attachment was scrubbed... Name: afalg-sock-broken.patch Type: text/x-patch Size: 2146 bytes Desc: not available URL: From rt at openssl.org Wed Jun 1 22:29:45 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Wed, 01 Jun 2016 22:29:45 +0000 Subject: [openssl-dev] [openssl.org #4553] Re: Fedora 1, i386: error: field `next_timeout` has incomplete type In-Reply-To: References: Message-ID: Does it make a difference if you add 'no-sse2' to your configuration command? On Wed Jun 01 21:22:24 2016, noloader at gmail.com wrote: > On Wed, Jun 1, 2016 at 4:47 PM, Richard Levitte via RT > wrote: > > Please give us the full configuration command you used, including > > environment > > variables that may affect it. Just the presence of '-ansi' tells me > > that you > > didn't just say './config' without any arguments. > > Sorry Richard. Yes, it was a straight "./config" followed by a "make". > > I deleted the the openssl directory and started over. Previously I > just unzipped overtop the old installation. I'm guessing something was > misconfigured because I get further now. > > Here's the new issue: chacha-x86.s assembler problems, > http://postimg.org/image/sl28mxfmz/. > > I also "git pull" followed by a new ISO build for the VM. Same result. > > Jeff > > > On Wed Jun 01 19:54:51 2016, noloader at gmail.com wrote: > >> So testing with 1.1.0-pre6 from 1 JUN 2016 appears to show some new > >> issues. > >> > >> ./config detects as i686-linux-whatever. However, there are some > >> issues with CFLAGS. The '-arch x86_64' makes it appear to be > >> configured for quasi-OS X mode. I believe -m32 should be used if an > >> arch is needed. There's also some complaints about -c and -o, but I > >> think the compiler confusion starts earlier. > >> > >> Here's a screen capture of the error: > >> http://postimg.org/image/e9nvrko17/ . > >> > >> My apologies for the screen capture. I kind of cheat and get the > >> tarball onto the VM by building an ISO and mounting it with the > >> CDROM. > >> I have not figured out how to get data to travel the other way. > >> > >> Jeff > >> > >> On Sun, Mar 20, 2016 at 8:31 AM, Jeffrey Walton > >> wrote: > >> > I know this is kind of an old machine with GCC 3.3... > >> > > >> > With an updated PERL and a './config no-asm -D_XOPEN_SOURCE=600', > >> > I > >> > can almost get through a compile. After libcrypto.a is built, the > >> > next > >> > compile line is: > >> > > >> > gcc ... -c -o ssl/bio_ssl.o ssl/bio_ssl.c > >> > > >> > At that point, there's a: > >> > > >> > In file included from ssl/bio_ssl.c:65 > >> > ssl/ssl_locl.h:1501: error: field `next_timeout` has incomplete > >> > type > >> > [ssl/bio_ssl.o] Error 1 > >> > > >> > The issue was cleared by adding to "ssl/ssl_locl.h". > >> > > >> > ********** > >> > > >> > ar r libcrypto.a crypto/aes/aes_cbc.o crypto/aes/aes_cfb.o > >> > crypto/aes/aes_core.o crypto/aes/aes_ecb.o crypto/aes/aes_ige.o > >> > crypto/aes/aes_misc.o crypto/aes/aes_ofb.o crypto/aes/aes_wrap.o > >> > crypto/asn1/a_bitstr.o crypto/asn1/a_d2i_fp.o > >> > crypto/asn1/a_digest.o > >> > crypto/asn1/a_dup.o crypto/asn1/a_gentm.o crypto/asn1/a_i2d_fp.o > >> > crypto/asn1/a_int.o crypto/asn1/a_mbstr.o crypto/asn1/a_object.o > >> > crypto/asn1/a_octet.o crypto/asn1/a_print.o crypto/asn1/a_sign.o > >> > crypto/asn1/a_strex.o crypto/asn1/a_strnid.o crypto/asn1/a_time.o > >> > crypto/asn1/a_type.o crypto/asn1/a_utctm.o crypto/asn1/a_utf8.o > >> > crypto/asn1/a_verify.o crypto/asn1/ameth_lib.o > >> > crypto/asn1/asn1_err.o > >> > crypto/asn1/asn1_gen.o crypto/asn1/asn1_lib.o > >> > crypto/asn1/asn1_par.o > >> > crypto/asn1/asn_mime.o crypto/asn1/asn_moid.o > >> > crypto/asn1/asn_mstbl.o > >> > crypto/asn1/asn_pack.o crypto/asn1/bio_asn1.o > >> > crypto/asn1/bio_ndef.o > >> > crypto/asn1/d2i_pr.o crypto/asn1/d2i_pu.o crypto/asn1/evp_asn1.o > >> > crypto/asn1/f_int.o crypto/asn1/f_string.o crypto/asn1/i2d_pr.o > >> > crypto/asn1/i2d_pu.o crypto/asn1/n_pkey.o crypto/asn1/nsseq.o > >> > crypto/asn1/p5_pbe.o crypto/asn1/p5_pbev2.o > >> > crypto/asn1/p5_scrypt.o > >> > crypto/asn1/p8_pkey.o crypto/asn1/t_bitst.o crypto/asn1/t_pkey.o > >> > crypto/asn1/t_spki.o crypto/asn1/tasn_dec.o crypto/asn1/tasn_enc.o > >> > crypto/asn1/tasn_fre.o crypto/asn1/tasn_new.o > >> > crypto/asn1/tasn_prn.o > >> > crypto/asn1/tasn_scn.o crypto/asn1/tasn_typ.o > >> > crypto/asn1/tasn_utl.o > >> > crypto/asn1/x_algor.o crypto/asn1/x_bignum.o crypto/asn1/x_info.o > >> > crypto/asn1/x_long.o crypto/asn1/x_pkey.o crypto/asn1/x_pubkey.o > >> > crypto/asn1/x_sig.o crypto/asn1/x_spki.o crypto/asn1/x_val.o > >> > crypto/async/arch/async_null.o crypto/async/arch/async_posix.o > >> > crypto/async/arch/async_win.o crypto/async/async.o > >> > crypto/async/async_err.o crypto/async/async_wait.o > >> > crypto/bf/bf_cfb64.o crypto/bf/bf_ecb.o crypto/bf/bf_enc.o > >> > crypto/bf/bf_ofb64.o crypto/bf/bf_skey.o crypto/bio/b_addr.o > >> > crypto/bio/b_dump.o crypto/bio/b_print.o crypto/bio/b_sock.o > >> > crypto/bio/b_sock2.o crypto/bio/bf_buff.o crypto/bio/bf_nbio.o > >> > crypto/bio/bf_null.o crypto/bio/bio_cb.o crypto/bio/bio_err.o > >> > crypto/bio/bio_lib.o crypto/bio/bss_acpt.o crypto/bio/bss_bio.o > >> > crypto/bio/bss_conn.o crypto/bio/bss_dgram.o crypto/bio/bss_fd.o > >> > crypto/bio/bss_file.o crypto/bio/bss_log.o crypto/bio/bss_mem.o > >> > crypto/bio/bss_null.o crypto/bio/bss_sock.o > >> > crypto/blake2/blake2b.o > >> > crypto/blake2/blake2s.o crypto/blake2/m_blake2b.o > >> > crypto/blake2/m_blake2s.o crypto/bn/bn_add.o crypto/bn/bn_asm.o > >> > crypto/bn/bn_blind.o crypto/bn/bn_const.o crypto/bn/bn_ctx.o > >> > crypto/bn/bn_depr.o crypto/bn/bn_dh.o crypto/bn/bn_div.o > >> > crypto/bn/bn_err.o crypto/bn/bn_exp.o crypto/bn/bn_exp2.o > >> > crypto/bn/bn_gcd.o crypto/bn/bn_gf2m.o crypto/bn/bn_intern.o > >> > crypto/bn/bn_kron.o crypto/bn/bn_lib.o crypto/bn/bn_mod.o > >> > crypto/bn/bn_mont.o crypto/bn/bn_mpi.o crypto/bn/bn_mul.o > >> > crypto/bn/bn_nist.o crypto/bn/bn_prime.o crypto/bn/bn_print.o > >> > crypto/bn/bn_rand.o crypto/bn/bn_recp.o crypto/bn/bn_shift.o > >> > crypto/bn/bn_sqr.o crypto/bn/bn_sqrt.o crypto/bn/bn_srp.o > >> > crypto/bn/bn_word.o crypto/bn/bn_x931p.o crypto/buffer/buf_err.o > >> > crypto/buffer/buffer.o crypto/camellia/camellia.o > >> > crypto/camellia/cmll_cbc.o crypto/camellia/cmll_cfb.o > >> > crypto/camellia/cmll_ctr.o crypto/camellia/cmll_ecb.o > >> > crypto/camellia/cmll_misc.o crypto/camellia/cmll_ofb.o > >> > crypto/cast/c_cfb64.o crypto/cast/c_ecb.o crypto/cast/c_enc.o > >> > crypto/cast/c_ofb64.o crypto/cast/c_skey.o > >> > crypto/chacha/chacha_enc.o > >> > crypto/cmac/cm_ameth.o crypto/cmac/cm_pmeth.o crypto/cmac/cmac.o > >> > crypto/cms/cms_asn1.o crypto/cms/cms_att.o crypto/cms/cms_cd.o > >> > crypto/cms/cms_dd.o crypto/cms/cms_enc.o crypto/cms/cms_env.o > >> > crypto/cms/cms_err.o crypto/cms/cms_ess.o crypto/cms/cms_io.o > >> > crypto/cms/cms_kari.o crypto/cms/cms_lib.o crypto/cms/cms_pwri.o > >> > crypto/cms/cms_sd.o crypto/cms/cms_smime.o crypto/comp/c_zlib.o > >> > crypto/comp/comp_err.o crypto/comp/comp_lib.o > >> > crypto/conf/conf_api.o > >> > crypto/conf/conf_def.o crypto/conf/conf_err.o > >> > crypto/conf/conf_lib.o > >> > crypto/conf/conf_mall.o crypto/conf/conf_mod.o > >> > crypto/conf/conf_sap.o > >> > crypto/cpt_err.o crypto/cryptlib.o crypto/ct/ct_b64.o > >> > crypto/ct/ct_err.o crypto/ct/ct_log.o crypto/ct/ct_oct.o > >> > crypto/ct/ct_policy.o crypto/ct/ct_prn.o crypto/ct/ct_sct.o > >> > crypto/ct/ct_sct_ctx.o crypto/ct/ct_vfy.o crypto/ct/ct_x509v3.o > >> > crypto/cversion.o crypto/des/cbc_cksm.o crypto/des/cbc_enc.o > >> > crypto/des/cfb64ede.o crypto/des/cfb64enc.o crypto/des/cfb_enc.o > >> > crypto/des/des_enc.o crypto/des/ecb3_enc.o crypto/des/ecb_enc.o > >> > crypto/des/enc_read.o crypto/des/enc_writ.o crypto/des/fcrypt.o > >> > crypto/des/fcrypt_b.o crypto/des/ofb64ede.o crypto/des/ofb64enc.o > >> > crypto/des/ofb_enc.o crypto/des/pcbc_enc.o crypto/des/qud_cksm.o > >> > crypto/des/rand_key.o crypto/des/read2pwd.o crypto/des/rpc_enc.o > >> > crypto/des/set_key.o crypto/des/str2key.o crypto/des/xcbc_enc.o > >> > crypto/dh/dh_ameth.o crypto/dh/dh_asn1.o crypto/dh/dh_check.o > >> > crypto/dh/dh_depr.o crypto/dh/dh_err.o crypto/dh/dh_gen.o > >> > crypto/dh/dh_kdf.o crypto/dh/dh_key.o crypto/dh/dh_lib.o > >> > crypto/dh/dh_pmeth.o crypto/dh/dh_prn.o crypto/dh/dh_rfc5114.o > >> > crypto/dsa/dsa_ameth.o crypto/dsa/dsa_asn1.o crypto/dsa/dsa_depr.o > >> > crypto/dsa/dsa_err.o crypto/dsa/dsa_gen.o crypto/dsa/dsa_key.o > >> > crypto/dsa/dsa_lib.o crypto/dsa/dsa_ossl.o crypto/dsa/dsa_pmeth.o > >> > crypto/dsa/dsa_prn.o crypto/dsa/dsa_sign.o crypto/dsa/dsa_vrf.o > >> > crypto/dso/dso_dl.o crypto/dso/dso_dlfcn.o crypto/dso/dso_err.o > >> > crypto/dso/dso_lib.o crypto/dso/dso_null.o > >> > crypto/dso/dso_openssl.o > >> > crypto/dso/dso_vms.o crypto/dso/dso_win32.o crypto/ebcdic.o > >> > crypto/ec/curve25519.o crypto/ec/ec2_mult.o crypto/ec/ec2_oct.o > >> > crypto/ec/ec2_smpl.o crypto/ec/ec_25519.o crypto/ec/ec_ameth.o > >> > crypto/ec/ec_asn1.o crypto/ec/ec_check.o crypto/ec/ec_curve.o > >> > crypto/ec/ec_cvt.o crypto/ec/ec_err.o crypto/ec/ec_key.o > >> > crypto/ec/ec_kmeth.o crypto/ec/ec_lib.o crypto/ec/ec_mult.o > >> > crypto/ec/ec_oct.o crypto/ec/ec_pmeth.o crypto/ec/ec_print.o > >> > crypto/ec/ecdh_kdf.o crypto/ec/ecdh_ossl.o crypto/ec/ecdsa_ossl.o > >> > crypto/ec/ecdsa_sign.o crypto/ec/ecdsa_vrf.o crypto/ec/eck_prn.o > >> > crypto/ec/ecp_mont.o crypto/ec/ecp_nist.o crypto/ec/ecp_nistp224.o > >> > crypto/ec/ecp_nistp256.o crypto/ec/ecp_nistp521.o > >> > crypto/ec/ecp_nistputil.o crypto/ec/ecp_oct.o crypto/ec/ecp_smpl.o > >> > crypto/engine/eng_all.o crypto/engine/eng_cnf.o > >> > crypto/engine/eng_cryptodev.o crypto/engine/eng_ctrl.o > >> > crypto/engine/eng_dyn.o crypto/engine/eng_err.o > >> > crypto/engine/eng_fat.o crypto/engine/eng_init.o > >> > crypto/engine/eng_lib.o crypto/engine/eng_list.o > >> > crypto/engine/eng_openssl.o crypto/engine/eng_pkey.o > >> > crypto/engine/eng_rdrand.o crypto/engine/eng_table.o > >> > crypto/engine/tb_asnmth.o crypto/engine/tb_cipher.o > >> > crypto/engine/tb_dh.o crypto/engine/tb_digest.o > >> > crypto/engine/tb_dsa.o > >> > crypto/engine/tb_eckey.o crypto/engine/tb_pkmeth.o > >> > crypto/engine/tb_rand.o crypto/engine/tb_rsa.o crypto/err/err.o > >> > crypto/err/err_all.o crypto/err/err_prn.o crypto/evp/bio_b64.o > >> > crypto/evp/bio_enc.o crypto/evp/bio_md.o crypto/evp/bio_ok.o > >> > crypto/evp/c_allc.o crypto/evp/c_alld.o crypto/evp/cmeth_lib.o > >> > crypto/evp/digest.o crypto/evp/e_aes.o > >> > crypto/evp/e_aes_cbc_hmac_sha1.o > >> > crypto/evp/e_aes_cbc_hmac_sha256.o > >> > crypto/evp/e_bf.o crypto/evp/e_camellia.o crypto/evp/e_cast.o > >> > crypto/evp/e_chacha20_poly1305.o crypto/evp/e_des.o > >> > crypto/evp/e_des3.o crypto/evp/e_idea.o crypto/evp/e_null.o > >> > crypto/evp/e_old.o crypto/evp/e_rc2.o crypto/evp/e_rc4.o > >> > crypto/evp/e_rc4_hmac_md5.o crypto/evp/e_rc5.o crypto/evp/e_seed.o > >> > crypto/evp/e_xcbc_d.o crypto/evp/encode.o crypto/evp/evp_cnf.o > >> > crypto/evp/evp_enc.o crypto/evp/evp_err.o crypto/evp/evp_key.o > >> > crypto/evp/evp_lib.o crypto/evp/evp_pbe.o crypto/evp/evp_pkey.o > >> > crypto/evp/m_md2.o crypto/evp/m_md4.o crypto/evp/m_md5.o > >> > crypto/evp/m_md5_sha1.o crypto/evp/m_mdc2.o crypto/evp/m_null.o > >> > crypto/evp/m_ripemd.o crypto/evp/m_sha1.o crypto/evp/m_sigver.o > >> > crypto/evp/m_wp.o crypto/evp/names.o crypto/evp/p5_crpt.o > >> > crypto/evp/p5_crpt2.o crypto/evp/p_dec.o crypto/evp/p_enc.o > >> > crypto/evp/p_lib.o crypto/evp/p_open.o crypto/evp/p_seal.o > >> > crypto/evp/p_sign.o crypto/evp/p_verify.o crypto/evp/pmeth_fn.o > >> > crypto/evp/pmeth_gn.o crypto/evp/pmeth_lib.o crypto/evp/scrypt.o > >> > crypto/ex_data.o crypto/hmac/hm_ameth.o crypto/hmac/hm_pmeth.o > >> > crypto/hmac/hmac.o crypto/idea/i_cbc.o crypto/idea/i_cfb64.o > >> > crypto/idea/i_ecb.o crypto/idea/i_ofb64.o crypto/idea/i_skey.o > >> > crypto/init.o crypto/kdf/hkdf.o crypto/kdf/kdf_err.o > >> > crypto/kdf/tls1_prf.o crypto/lhash/lh_stats.o crypto/lhash/lhash.o > >> > crypto/md4/md4_dgst.o crypto/md4/md4_one.o crypto/md5/md5_dgst.o > >> > crypto/md5/md5_one.o crypto/mdc2/mdc2_one.o crypto/mdc2/mdc2dgst.o > >> > crypto/mem.o crypto/mem_clr.o crypto/mem_dbg.o crypto/mem_sec.o > >> > crypto/modes/cbc128.o crypto/modes/ccm128.o crypto/modes/cfb128.o > >> > crypto/modes/ctr128.o crypto/modes/cts128.o crypto/modes/gcm128.o > >> > crypto/modes/ocb128.o crypto/modes/ofb128.o crypto/modes/wrap128.o > >> > crypto/modes/xts128.o crypto/o_dir.o crypto/o_fips.o > >> > crypto/o_init.o > >> > crypto/o_str.o crypto/o_time.o crypto/objects/o_names.o > >> > crypto/objects/obj_dat.o crypto/objects/obj_err.o > >> > crypto/objects/obj_lib.o crypto/objects/obj_xref.o > >> > crypto/ocsp/ocsp_asn.o crypto/ocsp/ocsp_cl.o > >> > crypto/ocsp/ocsp_err.o > >> > crypto/ocsp/ocsp_ext.o crypto/ocsp/ocsp_ht.o > >> > crypto/ocsp/ocsp_lib.o > >> > crypto/ocsp/ocsp_prn.o crypto/ocsp/ocsp_srv.o > >> > crypto/ocsp/ocsp_vfy.o > >> > crypto/ocsp/v3_ocsp.o crypto/pem/pem_all.o crypto/pem/pem_err.o > >> > crypto/pem/pem_info.o crypto/pem/pem_lib.o crypto/pem/pem_oth.o > >> > crypto/pem/pem_pk8.o crypto/pem/pem_pkey.o crypto/pem/pem_sign.o > >> > crypto/pem/pem_x509.o crypto/pem/pem_xaux.o crypto/pem/pvkfmt.o > >> > crypto/pkcs12/p12_add.o crypto/pkcs12/p12_asn.o > >> > crypto/pkcs12/p12_attr.o crypto/pkcs12/p12_crpt.o > >> > crypto/pkcs12/p12_crt.o crypto/pkcs12/p12_decr.o > >> > crypto/pkcs12/p12_init.o crypto/pkcs12/p12_key.o > >> > crypto/pkcs12/p12_kiss.o crypto/pkcs12/p12_mutl.o > >> > crypto/pkcs12/p12_npas.o crypto/pkcs12/p12_p8d.o > >> > crypto/pkcs12/p12_p8e.o crypto/pkcs12/p12_sbag.o > >> > crypto/pkcs12/p12_utl.o crypto/pkcs12/pk12err.o > >> > crypto/pkcs7/bio_pk7.o > >> > crypto/pkcs7/pk7_asn1.o crypto/pkcs7/pk7_attr.o > >> > crypto/pkcs7/pk7_doit.o crypto/pkcs7/pk7_lib.o > >> > crypto/pkcs7/pk7_mime.o > >> > crypto/pkcs7/pk7_smime.o crypto/pkcs7/pkcs7err.o > >> > crypto/poly1305/poly1305.o crypto/rand/md_rand.o > >> > crypto/rand/rand_egd.o crypto/rand/rand_err.o > >> > crypto/rand/rand_lib.o > >> > crypto/rand/rand_unix.o crypto/rand/rand_vms.o > >> > crypto/rand/rand_win.o > >> > crypto/rand/randfile.o crypto/rc2/rc2_cbc.o crypto/rc2/rc2_ecb.o > >> > crypto/rc2/rc2_skey.o crypto/rc2/rc2cfb64.o crypto/rc2/rc2ofb64.o > >> > crypto/rc4/rc4_enc.o crypto/rc4/rc4_skey.o > >> > crypto/ripemd/rmd_dgst.o > >> > crypto/ripemd/rmd_one.o crypto/rsa/rsa_ameth.o > >> > crypto/rsa/rsa_asn1.o > >> > crypto/rsa/rsa_chk.o crypto/rsa/rsa_crpt.o crypto/rsa/rsa_depr.o > >> > crypto/rsa/rsa_err.o crypto/rsa/rsa_gen.o crypto/rsa/rsa_lib.o > >> > crypto/rsa/rsa_none.o crypto/rsa/rsa_null.o crypto/rsa/rsa_oaep.o > >> > crypto/rsa/rsa_ossl.o crypto/rsa/rsa_pk1.o crypto/rsa/rsa_pmeth.o > >> > crypto/rsa/rsa_prn.o crypto/rsa/rsa_pss.o crypto/rsa/rsa_saos.o > >> > crypto/rsa/rsa_sign.o crypto/rsa/rsa_ssl.o crypto/rsa/rsa_x931.o > >> > crypto/rsa/rsa_x931g.o crypto/seed/seed.o crypto/seed/seed_cbc.o > >> > crypto/seed/seed_cfb.o crypto/seed/seed_ecb.o > >> > crypto/seed/seed_ofb.o > >> > crypto/sha/sha1_one.o crypto/sha/sha1dgst.o crypto/sha/sha256.o > >> > crypto/sha/sha512.o crypto/srp/srp_lib.o crypto/srp/srp_vfy.o > >> > crypto/stack/stack.o crypto/threads_none.o > >> > crypto/threads_pthread.o > >> > crypto/threads_win.o crypto/ts/ts_asn1.o crypto/ts/ts_conf.o > >> > crypto/ts/ts_err.o crypto/ts/ts_lib.o crypto/ts/ts_req_print.o > >> > crypto/ts/ts_req_utils.o crypto/ts/ts_rsp_print.o > >> > crypto/ts/ts_rsp_sign.o crypto/ts/ts_rsp_utils.o > >> > crypto/ts/ts_rsp_verify.o crypto/ts/ts_verify_ctx.o > >> > crypto/txt_db/txt_db.o crypto/ui/ui_err.o crypto/ui/ui_lib.o > >> > crypto/ui/ui_openssl.o crypto/ui/ui_util.o crypto/uid.o > >> > crypto/whrlpool/wp_block.o crypto/whrlpool/wp_dgst.o > >> > crypto/x509/by_dir.o crypto/x509/by_file.o crypto/x509/t_crl.o > >> > crypto/x509/t_req.o crypto/x509/t_x509.o crypto/x509/x509_att.o > >> > crypto/x509/x509_cmp.o crypto/x509/x509_d2.o > >> > crypto/x509/x509_def.o > >> > crypto/x509/x509_err.o crypto/x509/x509_ext.o > >> > crypto/x509/x509_lu.o > >> > crypto/x509/x509_obj.o crypto/x509/x509_r2x.o > >> > crypto/x509/x509_req.o > >> > crypto/x509/x509_set.o crypto/x509/x509_trs.o > >> > crypto/x509/x509_txt.o > >> > crypto/x509/x509_v3.o crypto/x509/x509_vfy.o > >> > crypto/x509/x509_vpm.o > >> > crypto/x509/x509cset.o crypto/x509/x509name.o > >> > crypto/x509/x509rset.o > >> > crypto/x509/x509spki.o crypto/x509/x509type.o crypto/x509/x_all.o > >> > crypto/x509/x_attrib.o crypto/x509/x_crl.o crypto/x509/x_exten.o > >> > crypto/x509/x_name.o crypto/x509/x_req.o crypto/x509/x_x509.o > >> > crypto/x509/x_x509a.o crypto/x509v3/pcy_cache.o > >> > crypto/x509v3/pcy_data.o crypto/x509v3/pcy_lib.o > >> > crypto/x509v3/pcy_map.o crypto/x509v3/pcy_node.o > >> > crypto/x509v3/pcy_tree.o crypto/x509v3/v3_addr.o > >> > crypto/x509v3/v3_akey.o crypto/x509v3/v3_akeya.o > >> > crypto/x509v3/v3_alt.o crypto/x509v3/v3_asid.o > >> > crypto/x509v3/v3_bcons.o crypto/x509v3/v3_bitst.o > >> > crypto/x509v3/v3_conf.o crypto/x509v3/v3_cpols.o > >> > crypto/x509v3/v3_crld.o crypto/x509v3/v3_enum.o > >> > crypto/x509v3/v3_extku.o crypto/x509v3/v3_genn.o > >> > crypto/x509v3/v3_ia5.o crypto/x509v3/v3_info.o > >> > crypto/x509v3/v3_int.o > >> > crypto/x509v3/v3_lib.o crypto/x509v3/v3_ncons.o > >> > crypto/x509v3/v3_pci.o > >> > crypto/x509v3/v3_pcia.o crypto/x509v3/v3_pcons.o > >> > crypto/x509v3/v3_pku.o crypto/x509v3/v3_pmaps.o > >> > crypto/x509v3/v3_prn.o > >> > crypto/x509v3/v3_purp.o crypto/x509v3/v3_skey.o > >> > crypto/x509v3/v3_sxnet.o crypto/x509v3/v3_tlsf.o > >> > crypto/x509v3/v3_utl.o crypto/x509v3/v3err.o engines/e_capi.o > >> > engines/e_dasync.o engines/e_padlock.o > >> > /usr/bin/ranlib libcrypto.a || echo Never mind. > >> > gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_THREADS > >> > -DOPENSSL_NO_DYNAMIC_ENGINE -DOPENSSL_PIC -D_XOPEN_SOURCE=600 > >> > -DOPENSSLDIR="\"/usr/local/ssl\"" > >> > -DENGINESDIR="\"/usr/local/lib/engines\"" -Wall -O3 -pthread > >> > -DL_ENDIAN -fomit-frame-pointer -fPIC -Iinclude -I. -c -o > >> > ssl/bio_ssl.o ssl/bio_ssl.c > >> > In file included from ssl/bio_ssl.c:65: > >> > ssl/ssl_locl.h:1501: error: field `next_timeout' has incomplete > >> > type -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4553 Please log in as guest with password guest if prompted From rt at openssl.org Wed Jun 1 22:31:14 2016 From: rt at openssl.org (Sebastian Andrzej Siewior via RT) Date: Wed, 01 Jun 2016 22:31:14 +0000 Subject: [openssl-dev] [openssl.org #4549] powerpc test problem: missing symbols In-Reply-To: <20160601223108.GA32018@breakpoint.cc> References: <20160530200039.GB18832@roeckx.be> <77236419-5c66-8055-4b86-9ce9c7c4cef6@openssl.org> <20160601223108.GA32018@breakpoint.cc> Message-ID: On 2016-05-30 21:28:06 [+0000], Andy Polyakov via RT wrote: > For what it's worth I can't reproduce problem on Fedora or RedHat. The test |? |# The following symbols are missing in libcrypto.so: |# _shadow_DES_check_key |not ok 2 - check that there are no missing symbols in libcrypto.so |? So it is about DES_check_key which is the only variable using OPENSSL_IMPLEMENT_GLOBAL (and I don't see it beeing used). On x86-64 : | $ nm -Pg crypto/des/set_key.o|grep _shadow_DES_check_key | _shadow_DES_check_key B 0000000000000000 0000000000000004 and on powerpc I get: | $ nm -Pg crypto/des/set_key.o|grep _shadow_DES_check_key | _shadow_DES_check_key S 00000000 00000004 and this fixes it: --- a/test/recipes/01-test_symbol_presence.t +++ b/test/recipes/01-test_symbol_presence.t @@ -57,7 +57,7 @@ foreach my $libname (@libnames) { note "Number of lines in \@def_lines before massaging: ", scalar @def_lines; # Massage the nm output to only contain defined symbols - @nm_lines = sort map { s| .*||; $_ } grep(m|.* [BCDT] .*|, @nm_lines); + @nm_lines = sort map { s| .*||; $_ } grep(m|.* [BCDST] .*|, @nm_lines); # Massage the mkdef.pl output to only contain global symbols # The output we got is in Unix .map format, which has a global I make a proper pull req later? Sebastian -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4549 Please log in as guest with password guest if prompted From rt at openssl.org Wed Jun 1 22:45:08 2016 From: rt at openssl.org (noloader@gmail.com via RT) Date: Wed, 01 Jun 2016 22:45:08 +0000 Subject: [openssl-dev] [openssl.org #4553] Re: Fedora 1, i386: error: field `next_timeout` has incomplete type In-Reply-To: References: Message-ID: On Wed, Jun 1, 2016 at 4:47 PM, Richard Levitte via RT wrote: > Please give us the full configuration command you used, including environment > variables that may affect it. Just the presence of '-ansi' tells me that you > didn't just say './config' without any arguments. I know what happened here... I'm working on OS X, and I built the ISO from OpenSSL's git. Those are OS X artifacts that were added to the ISO. Shouldn't a new configure clear that sort of thing? (We no longer have 'make dclean' to prepare the sources). Jeff -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4553 Please log in as guest with password guest if prompted From xoloki at gmail.com Wed Jun 1 23:39:20 2016 From: xoloki at gmail.com (Joey Yandle) Date: Wed, 1 Jun 2016 16:39:20 -0700 Subject: [openssl-dev] [OpenSSL][1.0.2h] Memory leaks In-Reply-To: References: <5343CAC0.2010103@gmail.com> <574F1805.9080203@gmail.com> Message-ID: Works for me with mingw 32-bit: ALL OCSP TESTS SUCCESSFUL Test X509v3_check_* ../util/shlib_wrap.sh ./v3nametest ../util/shlib_wrap.sh ./heartbeat_test Test constant time utilites ../util/shlib_wrap.sh ./constant_time_test Testing constant time operations... ok (ran 1908 tests) test_verify_extra ../util/shlib_wrap.sh ./verify_extra_test PASS test_clienthello ../util/shlib_wrap.sh ./clienthellotest test_sslv2conftest ../util/shlib_wrap.sh ./sslv2conftest SSLv2 CONF Test number 0 SSLv2 CONF Test number 1 SSLv2 CONF test: PASSED make[1]: Leaving directory `/c/src/openssl-1.0.2h/test' OPENSSL_CONF=apps/openssl.cnf util/opensslwrap.sh version -a OpenSSL 1.0.2h-fips 3 May 2016 built on: reproducible build, date unspecified platform: mingw options: bn(64,32) rc4(8x,mmx) des(ptr,risc1,16,long) idea(int) blowfish(idx) compiler: gcc -I. -I.. -I../include -DOPENSSL_THREADS -D_MT -DDSO_WIN32 -DL_ENDIAN -DWIN32_LEAN_AND_MEAN -fomit-frame-pointer -O3 -march=i486 -Wall -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL _IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -I/usr/local/ssl/fips-2.0/include -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM OPENSSLDIR: "/usr/local/ssl" On 6/1/2016 3:18 PM, Sergio NNX wrote: >> How did you configure/build? What versions of mingw/msys did you use? > > ./configure mingw --prefix=/mingw > make depend > make all > make test > > MSYS 1.0.18(0.48/3/2) 2012-11-21 22:34 i686 unknown; targ=MINGW32 > GCC 6.1.0 32-bit > > Memory leaks didn't occur with previous OpenSSL versions using the same > environment. > I'm trying OpenSSL from master now but facing issues with Perl at the > moment. Grrr. > > Can you try building it using MinGW/MSYS 32-bit? > > Thanks for looking at it. > > Cheers. > > Ser. > > > From rt at openssl.org Thu Jun 2 00:12:21 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Thu, 02 Jun 2016 00:12:21 +0000 Subject: [openssl-dev] [openssl.org #4553] Re: Fedora 1, i386: error: field `next_timeout` has incomplete type In-Reply-To: References: Message-ID: On Wed Jun 01 22:45:08 2016, noloader at gmail.com wrote: > On Wed, Jun 1, 2016 at 4:47 PM, Richard Levitte via RT > wrote: > > Please give us the full configuration command you used, including > > environment > > variables that may affect it. Just the presence of '-ansi' tells me > > that you > > didn't just say './config' without any arguments. > > I know what happened here... I'm working on OS X, and I built the ISO > from OpenSSL's git. Those are OS X artifacts that were added to the > ISO. > > Shouldn't a new configure clear that sort of thing? (We no longer have > 'make dclean' to prepare the sources). If you want a pristine git workspace, I suggest using the following: git clean -dfx Cheers, Richard -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4553 Please log in as guest with password guest if prompted From rt at openssl.org Thu Jun 2 01:14:18 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Thu, 02 Jun 2016 01:14:18 +0000 Subject: [openssl-dev] [openssl.org #4549] powerpc test problem: missing symbols In-Reply-To: References: <20160530200039.GB18832@roeckx.be> <77236419-5c66-8055-4b86-9ce9c7c4cef6@openssl.org> <20160601223108.GA32018@breakpoint.cc> Message-ID: Applied and merged into master. Thank you. Closing this ticket. Cheers, Richard On Wed Jun 01 22:31:14 2016, sebastian at breakpoint.cc wrote: > On 2016-05-30 21:28:06 [+0000], Andy Polyakov via RT wrote: > > For what it's worth I can't reproduce problem on Fedora or RedHat. > > The test > |? > |# The following symbols are missing in libcrypto.so: > |# _shadow_DES_check_key > |not ok 2 - check that there are no missing symbols in libcrypto.so > |? > > So it is about DES_check_key which is the only variable using > OPENSSL_IMPLEMENT_GLOBAL (and I don't see it beeing used). > > On x86-64 : > | $ nm -Pg crypto/des/set_key.o|grep _shadow_DES_check_key > | _shadow_DES_check_key B 0000000000000000 0000000000000004 > > and on powerpc I get: > | $ nm -Pg crypto/des/set_key.o|grep _shadow_DES_check_key > | _shadow_DES_check_key S 00000000 00000004 > > and this fixes it: > > --- a/test/recipes/01-test_symbol_presence.t > +++ b/test/recipes/01-test_symbol_presence.t > @@ -57,7 +57,7 @@ foreach my $libname (@libnames) { > note "Number of lines in \@def_lines before massaging: ", > scalar @def_lines; > > # Massage the nm output to only contain defined symbols > - @nm_lines = sort map { s| .*||; $_ } grep(m|.* [BCDT] .*|, > @nm_lines); > + @nm_lines = sort map { s| .*||; $_ } grep(m|.* [BCDST] .*|, > @nm_lines); > > # Massage the mkdef.pl output to only contain global symbols > # The output we got is in Unix .map format, which has a global > > I make a proper pull req later? > > Sebastian -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4549 Please log in as guest with password guest if prompted From nikhil.agarwal at nxp.com Thu Jun 2 09:59:02 2016 From: nikhil.agarwal at nxp.com (Nikhil Agarwal) Date: Thu, 2 Jun 2016 09:59:02 +0000 Subject: [openssl-dev] 1.1 release being delayed In-Reply-To: References: Message-ID: When it is expected to release now? Regards Nikhil -----Original Message----- From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Salz, Rich Sent: Monday, May 23, 2016 6:46 PM To: openssl-dev at openssl.org; openssl-users at openssl.org Subject: [openssl-dev] 1.1 release being delayed ... in case you haven't noticed :) Our announced release date for 1.1 has come and gone. We want to close many more bugs before we release it. In the meantime, please test against master or a daily snapshot or the last beta release. Thanks for your patience! -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From steve at openssl.org Thu Jun 2 12:11:31 2016 From: steve at openssl.org (Dr. Stephen Henson) Date: Thu, 2 Jun 2016 12:11:31 +0000 Subject: [openssl-dev] Null Ciphers in FIPS mode In-Reply-To: <25D2EC755404B4409F263AC6D050FEBB25D5C9B5@AZ-FFEXMB03.global.avaya.com> References: <25D2EC755404B4409F263AC6D050FEBB25D5C9B5@AZ-FFEXMB03.global.avaya.com> Message-ID: <20160602121131.GA15907@openssl.org> On Wed, Jun 01, 2016, Mody, Darshan (Darshan) wrote: > > Does Openssl allows NULL ciphers when we put openssl in FIPS mode? > If you mean NULL ciphersuites then yes though they're not enabled by default just like non-FIPS mode. 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 Jun 2 13:01:00 2016 From: rt at openssl.org (Ian Miller via RT) Date: Thu, 02 Jun 2016 13:01:00 +0000 Subject: [openssl-dev] [openssl.org #4554] Bug: psk argument of the s_client/s_server command strips leading zero bytes. In-Reply-To: <5750202B.6020300@adder.com> References: <5750202B.6020300@adder.com> Message-ID: In s_client.c (function psk_client_db), the "-psk" value is converted from hexadecimal to binary by converting to a BN using BN_hex2bn() [line 285] and then from BN to binary using BN_bn2bin [line 301]. This means that it is not possible to input a key where the first byte is zero. e.g. If the user specifies "-psk 00010203". BN_hex2bin converted this to 0x10203. BN_bn2Bin converted this to { 0x01, 0x02, 0x03 } where on the specified { 0x00, 0x01, 0x02, 0x03 }. The same problem seems to exist in s_server.c. This has probably not be detected in testing as given the same "-psk" values s_server and s_client produce the same key. I found this in 1.1.0-pre5. It is at least as old as 1.0.1e, and seems to date from the addition of the PSK code. -- Ian Miller Senior Software Engineer ADDER Technology Saxon Way Bar Hill Cambridge CB23 8SL United Kingdom Europe Head Office Tel: +44 (0)1954 780044 Fax: +44 (0)1954 780081 Web: www.adder.com ----------------------------------------------------------------------------------------------------------------------------------------- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify your system manager. Any views expressed in this message are those of the individual sender and not necessarily those of Adder Technology Limited. Adder Technology Limited is a company registered in England and Wales with company number 1823478 and VAT number GB 388 8704 87 and registered office address 110 Regent Road, Leicester LE1 7LT, UK. Adder Corporation is a company registered in Delaware, United States of America with a trading address of 350R Merrimac Street, Newburyport, MA 01950. ----------------------------------------------------------------------------------------------------------------------------------------- This footnote confirms that this email message has been swept for the presence of computer viruses, however, you should make no reliance upon this when opening this message or any attachments. ----------------------------------------------------------------------------------------------------------------------------------------- -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4554 Please log in as guest with password guest if prompted From rt at openssl.org Thu Jun 2 13:29:35 2016 From: rt at openssl.org (Andy Polyakov via RT) Date: Thu, 02 Jun 2016 13:29:35 +0000 Subject: [openssl-dev] [openssl.org #4548] s390x build problem In-Reply-To: <575034F7.2090507@openssl.org> References: <20160530195815.GA18832@roeckx.be> <0f31bcda-3c71-4ae2-7130-33b3a1d0d0e1@openssl.org> <20160601172458.GA5298@breakpoint.cc> <575034F7.2090507@openssl.org> Message-ID: >>> I'm getting: >>> crypto/chacha/chacha-s390x.S: Assembler messages: >>> crypto/chacha/chacha-s390x.S:7: Error: Unrecognized opcode: `clgije' >>> >>> >>> A full build log is available on: >>> https://buildd.debian.org/status/fetch.php?pkg=openssl&arch=s390x&ver=1.1.0~pre5-1&stamp=1464594754 >> >> It's overly easy to get carried away if you have access to single >> system. Double-check attached. > > I made this while I did not notice this earlier: > https://github.com/openssl/openssl/pull/1146 > > It fixes the chacha thing + memcpy. Thanks!!! There is couple of problems with suggested modifications though. First general comment. While 31-bit is arguably not very fashionable, bugs are still reported at occasions. Important to keep in mind that 31-bit build still requires z/Arch processor *and* highgprs kernel feature, i.e. target is not s390 systems (note lack of x), but 64-bit processor running 64-bit OS, just running legacy *process*. Goal also is to minimize deviations and "parametrize", so that most of the code is constantly "exposed" to assembler. That's what are those ${g} things are and that's why #if clauses are limited to clearing most significant 32 bits of registers. This means that suggestion to introduce big #if in CRYPTO_memcmp is not considered favourable. Adhering to non-extension instructions is. Another problem is with suggested ltgr in chacha-s390x. It has to be "parametrized", i.e. look as lt${g}r. Because in 31-bit build there is no guarantee that most significant 32-bit of $len register are actually zero-ed. In other words could you double-check attached patch instead? -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4548 Please log in as guest with password guest if prompted -------------- next part -------------- A non-text attachment was scrubbed... Name: s390x.diff Type: text/x-diff Size: 1289 bytes Desc: not available URL: From rt at openssl.org Thu Jun 2 13:33:25 2016 From: rt at openssl.org (Stephen Henson via RT) Date: Thu, 02 Jun 2016 13:33:25 +0000 Subject: [openssl-dev] [openssl.org #4474] Overflow optimizations being taken by GCC In-Reply-To: References: Message-ID: It looks like a lot of these warnings are bogus. For example ct_validation is only ever set to 0 or 1 yet it throws out a warning with if(ct_vlidation) in one place while not warning about a similar expression just above it. I tidied up ocsp_prn.c which avoided the warning in that file: though again it didn't seem to be genuine. 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=4474 Please log in as guest with password guest if prompted From aeh at db.org Thu Jun 2 13:33:53 2016 From: aeh at db.org (Alfred E. Heggestad) Date: Thu, 2 Jun 2016 15:33:53 +0200 Subject: [openssl-dev] DTLS retransmission api In-Reply-To: <574ECDCC.6000607@openssl.org> References: <574EB5C1.4060005@db.org> <574ECDCC.6000607@openssl.org> Message-ID: <575035C1.1000305@db.org> On 01/06/16 13:58, Matt Caswell wrote: > > > On 01/06/16 11:15, Alfred E. Heggestad wrote: >> hi, >> >> we are using DTLS from OpenSSL to implement DTLS-SRTP in our >> product (Wire.com) .. The code and implementation works really well >> and is very robust. We are using OpenSSL version 1.0.2g >> >> >> since our product is deployed globally on mobile data networks, >> we have quite variable latency and packetloss. The patch below >> shows my working code, it has an initial retransmit timeout >> of 400 ms which is incrementing by 10% for every re-trans. >> >> >> obviously this patch cannot make it into the official tree. >> >> >> but I would like to discuss with you guys the option to >> add some kind of API for: >> >> - Setting the initial RTO for DTLS (in milliseconds). >> - Setting the retransmit policy for DTLS, i.e. should it >> double or increment by X for every re-trans. > > I think an API for that would be a great idea. Perhaps a callback could > be used so that you can set exactly the policy you want? > Thank you, Matt I can work on a patch for this, if you guys can help me to define the API. I think we only need one CTRL api to set the next re-transmit interval. then in the application code that calls this: - DTLSv1_handle_timeout - DTLSv1_get_timeout can also call DTLS_set_retrans_interval(400) >> >> >> in addition we have seen the code hit this assert >> in production: >> >> >> /*OPENSSL_assert(0);*/ /* XDTLS: want to see if we ever get here */ >> >> >> so I would say it should be safe to remove it. > > Hmmmmm....the question is why does it get there? It shouldn't. > I can try to reproduce this. We have seen that this assert was executed, when the code was under quite heavy load and lots of traffic. /alfred > > Matt > > >> >> >> >> >> Best Regards, >> >> Alfred E. Heggestad >> Berlin >> >> >> >> -- >> >> diff -Naur openssl-1.0.2g/ssl/d1_lib.c openssl/ssl/d1_lib.c >> --- openssl-1.0.2g/ssl/d1_lib.c 2016-03-01 14:35:53.000000000 +0100 >> +++ openssl/ssl/d1_lib.c 2016-06-01 10:45:27.000000000 +0200 >> @@ -359,6 +359,8 @@ >> >> void dtls1_start_timer(SSL *s) >> { >> + struct timeval diff; >> + >> #ifndef OPENSSL_NO_SCTP >> /* Disable timer for SCTP */ >> if (BIO_dgram_is_sctp(SSL_get_wbio(s))) { >> @@ -369,14 +371,17 @@ >> >> /* If timer is not set, initialize duration with 1 second */ >> if (s->d1->next_timeout.tv_sec == 0 && s->d1->next_timeout.tv_usec >> == 0) { >> - s->d1->timeout_duration = 1; >> + s->d1->timeout_duration = 0.400; >> } >> >> /* Set timeout to current time */ >> get_current_time(&(s->d1->next_timeout)); >> >> /* Add duration to current time */ >> - s->d1->next_timeout.tv_sec += s->d1->timeout_duration; >> + diff.tv_sec = 0; >> + diff.tv_usec = 1000000*s->d1->timeout_duration; >> + timeradd(&s->d1->next_timeout, &diff, &s->d1->next_timeout); >> + >> BIO_ctrl(SSL_get_rbio(s), BIO_CTRL_DGRAM_SET_NEXT_TIMEOUT, 0, >> &(s->d1->next_timeout)); >> } >> @@ -441,7 +446,7 @@ >> >> void dtls1_double_timeout(SSL *s) >> { >> - s->d1->timeout_duration *= 2; >> + s->d1->timeout_duration *= 1.10; >> if (s->d1->timeout_duration > 60) >> s->d1->timeout_duration = 60; >> dtls1_start_timer(s); >> diff -Naur openssl-1.0.2g/ssl/d1_pkt.c openssl/ssl/d1_pkt.c >> --- openssl-1.0.2g/ssl/d1_pkt.c 2016-03-01 14:35:53.000000000 +0100 >> +++ openssl/ssl/d1_pkt.c 2016-03-08 14:39:44.000000000 +0100 >> @@ -1502,7 +1502,7 @@ >> * will happen with non blocking IO >> */ >> if (s->s3->wbuf.left != 0) { >> - OPENSSL_assert(0); /* XDTLS: want to see if we ever get >> here */ >> + /*OPENSSL_assert(0);*/ /* XDTLS: want to see if we ever >> get here */ >> return (ssl3_write_pending(s, type, buf, len)); >> } >> >> diff -Naur openssl-1.0.2g/ssl/dtls1.h openssl/ssl/dtls1.h >> --- openssl-1.0.2g/ssl/dtls1.h 2016-03-01 14:35:53.000000000 +0100 >> +++ openssl/ssl/dtls1.h 2016-03-08 14:39:44.000000000 +0100 >> @@ -225,8 +225,8 @@ >> * Indicates when the last handshake msg or heartbeat sent will >> timeout >> */ >> struct timeval next_timeout; >> - /* Timeout duration */ >> - unsigned short timeout_duration; >> + /* Timeout duration in Seconds */ >> + double timeout_duration; >> /* >> * storage for Alert/Handshake protocol data received but not yet >> * processed by ssl3_read_bytes: >> >> From matt at openssl.org Thu Jun 2 14:03:59 2016 From: matt at openssl.org (Matt Caswell) Date: Thu, 2 Jun 2016 15:03:59 +0100 Subject: [openssl-dev] DTLS retransmission api In-Reply-To: <575035C1.1000305@db.org> References: <574EB5C1.4060005@db.org> <574ECDCC.6000607@openssl.org> <575035C1.1000305@db.org> Message-ID: <57503CCF.3030505@openssl.org> On 02/06/16 14:33, Alfred E. Heggestad wrote: > > > On 01/06/16 13:58, Matt Caswell wrote: >> >> >> On 01/06/16 11:15, Alfred E. Heggestad wrote: >>> hi, >>> >>> we are using DTLS from OpenSSL to implement DTLS-SRTP in our >>> product (Wire.com) .. The code and implementation works really well >>> and is very robust. We are using OpenSSL version 1.0.2g >>> >>> >>> since our product is deployed globally on mobile data networks, >>> we have quite variable latency and packetloss. The patch below >>> shows my working code, it has an initial retransmit timeout >>> of 400 ms which is incrementing by 10% for every re-trans. >>> >>> >>> obviously this patch cannot make it into the official tree. >>> >>> >>> but I would like to discuss with you guys the option to >>> add some kind of API for: >>> >>> - Setting the initial RTO for DTLS (in milliseconds). >>> - Setting the retransmit policy for DTLS, i.e. should it >>> double or increment by X for every re-trans. >> >> I think an API for that would be a great idea. Perhaps a callback could >> be used so that you can set exactly the policy you want? >> > > Thank you, Matt > > > I can work on a patch for this, if you guys can help me to define > the API. > > > I think we only need one CTRL api to set the next re-transmit > interval. then in the application code that calls this: > > - DTLSv1_handle_timeout > - DTLSv1_get_timeout > > > can also call DTLS_set_retrans_interval(400) > I'm not sure I follow you. I was thinking something like: int DTLS_set_timer_cb(SSL *s, int (*cb)(SSL *s, int timer)); Then where in the current code we have: dtls1_double_timeout(s); We might instead do if(s->d1->timer_cb != NULL) s->d1->timeout_duration = timer_cb(s, s->d1->timeout_duration); else dtls1_double_timeout(s); And in dtls1_start_timer() where we have: /* If timer is not set, initialize duration with 1 second */ if (s->d1->next_timeout.tv_sec == 0 && s->d1->next_timeout.tv_usec == 0) { s->d1->timeout_duration = 1; } Instead have: /* If timer is not set, initialize duration with 1 second */ if (s->d1->next_timeout.tv_sec == 0 && s->d1->next_timeout.tv_usec == 0) { if (s->d1->timer_cb != NULL) s->d1->timeout_duration = s->d1_timeout_cb(s, 0); else s->d1->timeout_duration = 1; } ...or something like that. Matt From rt at openssl.org Thu Jun 2 15:50:31 2016 From: rt at openssl.org (Steffen Nurpmeso via RT) Date: Thu, 02 Jun 2016 15:50:31 +0000 Subject: [openssl-dev] [openssl.org #4556] Unknown: mysterious perl(1) error during [master:8d054a5] installation process In-Reply-To: <20160602135552.e8rIjE0Hl%steffen@sdaoden.eu> References: <20160602135552.e8rIjE0Hl%steffen@sdaoden.eu> Message-ID: Hello. I have never seen something like this: Parser.c: loadable library and perl binaries are mismatched (got handshake key 0xdb00080, needed 0xdb80080) This is v5.24 on a Linux system, and it flawless afaik. Thanks. --steffen -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4556 Please log in as guest with password guest if prompted From rt at openssl.org Thu Jun 2 15:50:31 2016 From: rt at openssl.org (Steffen Nurpmeso via RT) Date: Thu, 02 Jun 2016 15:50:31 +0000 Subject: [openssl-dev] [openssl.org #4555] Enhancement request: allow installation without manuals, but anyway without HTML manuals In-Reply-To: <20160602135348.leCesUqxQ%steffen@sdaoden.eu> References: <20160602135348.leCesUqxQ%steffen@sdaoden.eu> Message-ID: Oh yes, please! --steffen -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4555 Please log in as guest with password guest if prompted From rt at openssl.org Thu Jun 2 15:50:32 2016 From: rt at openssl.org (Steffen Nurpmeso via RT) Date: Thu, 02 Jun 2016 15:50:32 +0000 Subject: [openssl-dev] [openssl.org #4557] Nit: temporary files left over after [master:8d054a5] installation process In-Reply-To: <20160602135301.iakH2OamT%steffen@sdaoden.eu> References: <20160602135301.iakH2OamT%steffen@sdaoden.eu> Message-ID: Yep: -rw------- 1 steffen steffen 1848 Jun 2 14:46 VhXl383LiQ -rw------- 1 steffen steffen 1612 Jun 2 14:46 F1RkvxEZi0 -rw------- 1 steffen steffen 1848 Jun 2 14:46 qg_wML0XIF -rw------- 1 steffen steffen 1848 Jun 2 14:46 4MUN7KIs69 -rw------- 1 steffen steffen 1840 Jun 2 14:46 fU_zMQI7Wb -rw------- 1 steffen steffen 1848 Jun 2 14:46 gbNE7UjUAJ -rw------- 1 steffen steffen 1848 Jun 2 14:46 P2Vff7Duiz -rw------- 1 steffen steffen 1840 Jun 2 14:46 3E_oztoePh ;do head -n 1 $i; done: -----BEGIN SSL SESSION PARAMETERS----- -----BEGIN SSL SESSION PARAMETERS----- -----BEGIN SSL SESSION PARAMETERS----- -----BEGIN SSL SESSION PARAMETERS----- -----BEGIN SSL SESSION PARAMETERS----- -----BEGIN SSL SESSION PARAMETERS----- -----BEGIN SSL SESSION PARAMETERS----- -----BEGIN SSL SESSION PARAMETERS----- --steffen -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4557 Please log in as guest with password guest if prompted From rt at openssl.org Thu Jun 2 15:56:07 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Thu, 02 Jun 2016 15:56:07 +0000 Subject: [openssl-dev] [openssl.org #4555] Enhancement request: allow installation without manuals, but anyway without HTML manuals In-Reply-To: <20160602135348.leCesUqxQ%steffen@sdaoden.eu> References: <20160602135348.leCesUqxQ%steffen@sdaoden.eu> Message-ID: On Thu Jun 02 15:50:31 2016, steffen at sdaoden.eu wrote: > Oh yes, please! The 'install' target calls three other targets: install_sw install_ssldirs install_docs So if you simple do 'make install_sw' or 'nmake install_sw', I think you'll get what you want. Closing this ticket. -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4555 Please log in as guest with password guest if prompted From rt at openssl.org Thu Jun 2 16:00:12 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Thu, 02 Jun 2016 16:00:12 +0000 Subject: [openssl-dev] [openssl.org #4556] Unknown: mysterious perl(1) error during [master:8d054a5] installation process In-Reply-To: <20160602135552.e8rIjE0Hl%steffen@sdaoden.eu> References: <20160602135552.e8rIjE0Hl%steffen@sdaoden.eu> Message-ID: On Thu Jun 02 15:50:31 2016, steffen at sdaoden.eu wrote: > Hello. > > I have never seen something like this: > > Parser.c: loadable library and perl binaries are mismatched (got > handshake key 0xdb00080, needed 0xdb80080) > > This is v5.24 on a Linux system, and it flawless afaik. Are you sure that you don't have perl modules that you installed separately with an earlier perl version? You may need to update those. Either way, this is not an OpenSSL issue, it's a perl one. Closing this ticket. -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4556 Please log in as guest with password guest if prompted From rt at openssl.org Thu Jun 2 23:24:45 2016 From: rt at openssl.org (paul.dale@oracle.com via RT) Date: Thu, 02 Jun 2016 23:24:45 +0000 Subject: [openssl-dev] [openssl.org #4558] Performance issue with DTLS packet reassembly In-Reply-To: <933e3679-12fc-409c-a5e6-2cd0d1293951@default> References: <933e3679-12fc-409c-a5e6-2cd0d1293951@default> Message-ID: The DTLS packet reassembly code has a performance problem that could result in a DoS attack being possible. The DTLS packet reassembly uses the data structure defined in ssl/pqueue.c for the purpose (it is the only user of this data structure that I can find). This source file implements a priority queue using a singly linked list. This means O(n^2) worst case complexity, where n is the number of fragments. A better, and in fact optimal, solution would be to use a heap for the purpose giving O(n log n) worst case complexity. Doing this would prevent a potential DoS attack. The attack would consist of fragmenting the DTLS stream into as many small packets as possible and sending them in sequential order. Each fragment will require a complete traversal of the list to be added. Continue sending these as long as the DoS is wanted. For reference, changing the list search method or ordering won't prevent such an attack, it just means a different packet ordering is required. Tim Hudson suggested I submit this even though I haven't been able to find time to craft a patch. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4558 Please log in as guest with password guest if prompted From rt at openssl.org Fri Jun 3 08:28:16 2016 From: rt at openssl.org (Andy Polyakov via RT) Date: Fri, 03 Jun 2016 08:28:16 +0000 Subject: [openssl-dev] [openssl.org #4512] ChaCha20_ctr32 function increments 64 bit counter? In-Reply-To: <57513F9A.5000704@openssl.org> References: <201604151110.u3FBAW7v017702@d06av02.portsmouth.uk.ibm.com> <5720B83D.1040006@openssl.org> <201604271351.u3RDpqeQ029781@d06av07.portsmouth.uk.ibm.com> <57513F9A.5000704@openssl.org> Message-ID: Hi, > I'm aware it doesn't affect anything because the caller shouldn't process > more than 2^32 * 64 bytes per key/nonce setup anyway. > > I was just wondering because it differs from the s390 asm implementation > (and whether there is a particular reason to do so). Implementation is harmonized with subroutine name now, case is being dismissed. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4512 Please log in as guest with password guest if prompted From aeh at db.org Fri Jun 3 09:52:29 2016 From: aeh at db.org (Alfred E. Heggestad) Date: Fri, 3 Jun 2016 11:52:29 +0200 Subject: [openssl-dev] DTLS retransmission api In-Reply-To: <57503CCF.3030505@openssl.org> References: <574EB5C1.4060005@db.org> <574ECDCC.6000607@openssl.org> <575035C1.1000305@db.org> <57503CCF.3030505@openssl.org> Message-ID: <5751535D.4020704@db.org> On 02/06/16 16:03, Matt Caswell wrote: > > > On 02/06/16 14:33, Alfred E. Heggestad wrote: >> >> >> On 01/06/16 13:58, Matt Caswell wrote: >>> >>> >>> On 01/06/16 11:15, Alfred E. Heggestad wrote: >>>> hi, >>>> >>>> we are using DTLS from OpenSSL to implement DTLS-SRTP in our >>>> product (Wire.com) .. The code and implementation works really well >>>> and is very robust. We are using OpenSSL version 1.0.2g >>>> >>>> >>>> since our product is deployed globally on mobile data networks, >>>> we have quite variable latency and packetloss. The patch below >>>> shows my working code, it has an initial retransmit timeout >>>> of 400 ms which is incrementing by 10% for every re-trans. >>>> >>>> >>>> obviously this patch cannot make it into the official tree. >>>> >>>> >>>> but I would like to discuss with you guys the option to >>>> add some kind of API for: >>>> >>>> - Setting the initial RTO for DTLS (in milliseconds). >>>> - Setting the retransmit policy for DTLS, i.e. should it >>>> double or increment by X for every re-trans. >>> >>> I think an API for that would be a great idea. Perhaps a callback could >>> be used so that you can set exactly the policy you want? >>> >> >> Thank you, Matt >> >> >> I can work on a patch for this, if you guys can help me to define >> the API. >> >> >> I think we only need one CTRL api to set the next re-transmit >> interval. then in the application code that calls this: >> >> - DTLSv1_handle_timeout >> - DTLSv1_get_timeout >> >> >> can also call DTLS_set_retrans_interval(400) >> > > I'm not sure I follow you. I was thinking something like: > > int DTLS_set_timer_cb(SSL *s, int (*cb)(SSL *s, int timer)); > > Then where in the current code we have: > > dtls1_double_timeout(s); > > We might instead do > > if(s->d1->timer_cb != NULL) > s->d1->timeout_duration = timer_cb(s, s->d1->timeout_duration); > else > dtls1_double_timeout(s); > > > And in dtls1_start_timer() where we have: > > /* If timer is not set, initialize duration with 1 second */ > if (s->d1->next_timeout.tv_sec == 0 && s->d1->next_timeout.tv_usec > == 0) { > s->d1->timeout_duration = 1; > } > > > Instead have: > > /* If timer is not set, initialize duration with 1 second */ > if (s->d1->next_timeout.tv_sec == 0 && s->d1->next_timeout.tv_usec > == 0) { > if (s->d1->timer_cb != NULL) > s->d1->timeout_duration = s->d1_timeout_cb(s, 0); > else > s->d1->timeout_duration = 1; > } > > Hi Matt, thanks for the suggested API and code. Please find below a suggested patch that implements this new callback. the patch is based on 1.0.2-dev from GIT: url: git://git.openssl.org/openssl.git branch: origin/OpenSSL_1_0_2-stable I have renamed "timeout_duration" on purpose, since the units have changed from "seconds" to "milliseconds". From e6c9fbe470ab1901010e90b727313ebc7875b40f Mon Sep 17 00:00:00 2001 From: "Alfred E. Heggestad" Date: Fri, 3 Jun 2016 11:31:45 +0200 Subject: [PATCH] add support for DTLS callback for timeout value --- ssl/d1_lib.c | 45 +++++++++++++++++++++++++++++++++++++-------- ssl/dtls1.h | 9 +++++++-- ssl/ssl.h | 4 ++++ 3 files changed, 48 insertions(+), 10 deletions(-) diff --git a/ssl/d1_lib.c b/ssl/d1_lib.c index ee78921..235635a 100644 --- a/ssl/d1_lib.c +++ b/ssl/d1_lib.c @@ -240,6 +240,8 @@ void dtls1_clear(SSL *s) unsigned int link_mtu; if (s->d1) { + dtls_timer_cb *timer_cb = s->d1->timer_cb; + unprocessed_rcds = s->d1->unprocessed_rcds.q; processed_rcds = s->d1->processed_rcds.q; buffered_messages = s->d1->buffered_messages; @@ -252,6 +254,9 @@ void dtls1_clear(SSL *s) memset(s->d1, 0, sizeof(*(s->d1))); + /* Restore the timer callback from previous state */ + s->d1->timer_cb = timer_cb; + if (s->server) { s->d1->cookie_len = sizeof(s->d1->cookie); } @@ -359,6 +364,8 @@ const SSL_CIPHER *dtls1_get_cipher(unsigned int u) void dtls1_start_timer(SSL *s) { + struct timeval diff; + #ifndef OPENSSL_NO_SCTP /* Disable timer for SCTP */ if (BIO_dgram_is_sctp(SSL_get_wbio(s))) { @@ -367,16 +374,24 @@ void dtls1_start_timer(SSL *s) } #endif - /* If timer is not set, initialize duration with 1 second */ + /* If timer is not set, initialize duration with 1 second or + * a user-specified value if the timer callback is installed. */ if (s->d1->next_timeout.tv_sec == 0 && s->d1->next_timeout.tv_usec == 0) { - s->d1->timeout_duration = 1; + + if (s->d1->timer_cb != NULL) + s->d1->timeout_duration_ms = s->d1->timer_cb(s, 1000); + else + s->d1->timeout_duration_ms = 1000; } /* Set timeout to current time */ get_current_time(&(s->d1->next_timeout)); /* Add duration to current time */ - s->d1->next_timeout.tv_sec += s->d1->timeout_duration; + diff.tv_sec = s->d1->timeout_duration_ms / 1000; + diff.tv_usec = (s->d1->timeout_duration_ms % 1000) * 1000; + timeradd(&s->d1->next_timeout, &diff, &s->d1->next_timeout); + BIO_ctrl(SSL_get_rbio(s), BIO_CTRL_DGRAM_SET_NEXT_TIMEOUT, 0, &(s->d1->next_timeout)); } @@ -441,9 +456,9 @@ int dtls1_is_timer_expired(SSL *s) void dtls1_double_timeout(SSL *s) { - s->d1->timeout_duration *= 2; - if (s->d1->timeout_duration > 60) - s->d1->timeout_duration = 60; + s->d1->timeout_duration_ms *= 2; + if (s->d1->timeout_duration_ms > 60000) + s->d1->timeout_duration_ms = 60000; dtls1_start_timer(s); } @@ -452,7 +467,7 @@ void dtls1_stop_timer(SSL *s) /* Reset everything */ memset(&(s->d1->timeout), 0, sizeof(struct dtls1_timeout_st)); memset(&(s->d1->next_timeout), 0, sizeof(struct timeval)); - s->d1->timeout_duration = 1; + s->d1->timeout_duration_ms = 1000; BIO_ctrl(SSL_get_rbio(s), BIO_CTRL_DGRAM_SET_NEXT_TIMEOUT, 0, &(s->d1->next_timeout)); /* Clear retransmission buffer */ @@ -491,7 +506,12 @@ int dtls1_handle_timeout(SSL *s) return 0; } - dtls1_double_timeout(s); + if (s->d1->timer_cb != NULL) { + const unsigned ms = s->d1->timer_cb(s, s->d1->timeout_duration_ms); + s->d1->timeout_duration_ms = ms; + } + else + dtls1_double_timeout(s); if (dtls1_check_timeout_num(s) < 0) return -1; @@ -571,3 +591,12 @@ static int dtls1_handshake_write(SSL *s) { return dtls1_do_write(s, SSL3_RT_HANDSHAKE); } + + +void DTLS_set_timer_cb(SSL *s, unsigned (*cb)(SSL *s, unsigned timeout_ms)) +{ + if (!s || !s->d1) + return; + + s->d1->timer_cb = cb; +} diff --git a/ssl/dtls1.h b/ssl/dtls1.h index 30bbcf2..53abe32 100644 --- a/ssl/dtls1.h +++ b/ssl/dtls1.h @@ -125,6 +125,8 @@ extern "C" { /* Max MTU overhead we know about so far is 40 for IPv6 + 8 for UDP */ # define DTLS1_MAX_MTU_OVERHEAD 48 +typedef unsigned (dtls_timer_cb)(SSL *s, unsigned timer); + typedef struct dtls1_bitmap_st { unsigned long map; /* track 32 packets on 32-bit systems and 64 * - on 64-bit systems */ @@ -225,8 +227,8 @@ typedef struct dtls1_state_st { * Indicates when the last handshake msg or heartbeat sent will timeout */ struct timeval next_timeout; - /* Timeout duration */ - unsigned short timeout_duration; + /* Timeout duration in [milliseconds] */ + unsigned short timeout_duration_ms; /* * storage for Alert/Handshake protocol data received but not yet * processed by ssl3_read_bytes: @@ -246,6 +248,9 @@ typedef struct dtls1_state_st { int next_state; int shutdown_received; # endif + + dtls_timer_cb *timer_cb; + } DTLS1_STATE; typedef struct dtls1_record_data_st { diff --git a/ssl/ssl.h b/ssl/ssl.h index 028681a..4251226 100644 --- a/ssl/ssl.h +++ b/ssl/ssl.h @@ -3155,6 +3155,10 @@ void ERR_load_SSL_strings(void); # define SSL_R_X509_LIB 268 # define SSL_R_X509_VERIFICATION_SETUP_PROBLEMS 269 + +void DTLS_set_timer_cb(SSL *s, unsigned (*cb)(SSL *s, unsigned timer)); + + #ifdef __cplusplus } #endif -- 1.9.3 (Apple Git-50) From matt at openssl.org Fri Jun 3 10:19:13 2016 From: matt at openssl.org (Matt Caswell) Date: Fri, 3 Jun 2016 11:19:13 +0100 Subject: [openssl-dev] DTLS retransmission api In-Reply-To: <5751535D.4020704@db.org> References: <574EB5C1.4060005@db.org> <574ECDCC.6000607@openssl.org> <575035C1.1000305@db.org> <57503CCF.3030505@openssl.org> <5751535D.4020704@db.org> Message-ID: <575159A1.209@openssl.org> On 03/06/16 10:52, Alfred E. Heggestad wrote: > Hi Matt, > > thanks for the suggested API and code. Please find below a suggested > patch that implements this new callback. > > > the patch is based on 1.0.2-dev from GIT: > > url: git://git.openssl.org/openssl.git > branch: origin/OpenSSL_1_0_2-stable > > > I have renamed "timeout_duration" on purpose, since the units have > changed from "seconds" to "milliseconds". Hi Alfred Thanks for the submission. In order to ease the review process please read this file for some guidance on how to submit patches: https://github.com/openssl/openssl/blob/master/CONTRIBUTING The preferred way is via github because it makes it much easier for us to comment on the code in detail and provide feedback. I've not looked at your code in detail yet (I'll wait until I see the submission come in via github (or RT if you choose to go that way - see CONTRIBUTING)). I'll make a few high-level points though: - Because this is a new feature you need to create it from the master branch in git not the 1.0.2 branch. 1.0.2 is a stable branch and only receives bug fixes. - We are currently focussing on the 1.1.0 release which is now in feature freeze, so it may be a while before we get to look at it. - All new features must have documentation with them. Take a look at the existing pod files in the doc directory for some examples of our style. Matt From rt at openssl.org Fri Jun 3 12:57:51 2016 From: rt at openssl.org (=?UTF-8?B?RW1pbGlhIEvDpHNwZXI=?= via RT) Date: Fri, 03 Jun 2016 12:57:51 +0000 Subject: [openssl-dev] [openssl.org #4393] [PATCH] Call EC_GROUP_order_bits in priv2opt. In-Reply-To: <20160115122726.641b7574@pc1> References: <20160115122726.641b7574@pc1> Message-ID: Merge RT4241 here as these are best handled together. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4393 Please log in as guest with password guest if prompted From aeh at db.org Fri Jun 3 13:04:35 2016 From: aeh at db.org (Alfred E. Heggestad) Date: Fri, 3 Jun 2016 15:04:35 +0200 Subject: [openssl-dev] DTLS retransmission api In-Reply-To: <575159A1.209@openssl.org> References: <574EB5C1.4060005@db.org> <574ECDCC.6000607@openssl.org> <575035C1.1000305@db.org> <57503CCF.3030505@openssl.org> <5751535D.4020704@db.org> <575159A1.209@openssl.org> Message-ID: <57518063.4060405@db.org> On 03/06/16 12:19, Matt Caswell wrote: > > > On 03/06/16 10:52, Alfred E. Heggestad wrote: >> Hi Matt, >> >> thanks for the suggested API and code. Please find below a suggested >> patch that implements this new callback. >> >> >> the patch is based on 1.0.2-dev from GIT: >> >> url: git://git.openssl.org/openssl.git >> branch: origin/OpenSSL_1_0_2-stable >> >> >> I have renamed "timeout_duration" on purpose, since the units have >> changed from "seconds" to "milliseconds". > > Hi Alfred > > Thanks for the submission. In order to ease the review process please > read this file for some guidance on how to submit patches: > > https://github.com/openssl/openssl/blob/master/CONTRIBUTING > > The preferred way is via github because it makes it much easier for us > to comment on the code in detail and provide feedback. > > I've not looked at your code in detail yet (I'll wait until I see the > submission come in via github (or RT if you choose to go that way - see > CONTRIBUTING)). I'll make a few high-level points though: > > - Because this is a new feature you need to create it from the master > branch in git not the 1.0.2 branch. 1.0.2 is a stable branch and only > receives bug fixes. > > - We are currently focussing on the 1.1.0 release which is now in > feature freeze, so it may be a while before we get to look at it. > > - All new features must have documentation with them. Take a look at the > existing pod files in the doc directory for some examples of our style. > thanks, I have created a new PR: https://github.com/openssl/openssl/pull/1160 /alfred From rt at openssl.org Fri Jun 3 13:32:54 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Fri, 03 Jun 2016 13:32:54 +0000 Subject: [openssl-dev] [openssl.org #4557] Nit: temporary files left over after [master:8d054a5] installation process In-Reply-To: <20160602135301.iakH2OamT%steffen@sdaoden.eu> References: <20160602135301.iakH2OamT%steffen@sdaoden.eu> Message-ID: Thank you! Found the tests that generated this and made sure the temporary files get removed. Please get a fresh checkout of the master branch and check again. Closing this ticket. Cheers, Richard On Thu Jun 02 15:50:32 2016, steffen at sdaoden.eu wrote: > Yep: > > -rw------- 1 steffen steffen 1848 Jun 2 14:46 VhXl383LiQ > -rw------- 1 steffen steffen 1612 Jun 2 14:46 F1RkvxEZi0 > -rw------- 1 steffen steffen 1848 Jun 2 14:46 qg_wML0XIF > -rw------- 1 steffen steffen 1848 Jun 2 14:46 4MUN7KIs69 > -rw------- 1 steffen steffen 1840 Jun 2 14:46 fU_zMQI7Wb > -rw------- 1 steffen steffen 1848 Jun 2 14:46 gbNE7UjUAJ > -rw------- 1 steffen steffen 1848 Jun 2 14:46 P2Vff7Duiz > -rw------- 1 steffen steffen 1840 Jun 2 14:46 3E_oztoePh > > ;do head -n 1 $i; done: > > -----BEGIN SSL SESSION PARAMETERS----- > -----BEGIN SSL SESSION PARAMETERS----- > -----BEGIN SSL SESSION PARAMETERS----- > -----BEGIN SSL SESSION PARAMETERS----- > -----BEGIN SSL SESSION PARAMETERS----- > -----BEGIN SSL SESSION PARAMETERS----- > -----BEGIN SSL SESSION PARAMETERS----- > -----BEGIN SSL SESSION PARAMETERS----- > > --steffen > -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4557 Please log in as guest with password guest if prompted From uri at ll.mit.edu Fri Jun 3 15:40:30 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Fri, 3 Jun 2016 15:40:30 +0000 Subject: [openssl-dev] Inconsistency between implementation and docs in openssl cms Message-ID: Manual page for ?openssl cms? says: If the -decrypt option is used without a recipient certificate then an attempt is made to locate the recipient by trying each potential recipient in turn using the supplied private key. To thwart the MMA attack (Bleichenbacher's attack on PKCS #1 v1.5 RSA padding) all recipients are tried whether they succeed or not and if no recipients match the message is "decrypted" using a random key which will typically output garbage. The -debug_decrypt option can be used to disable the MMA attack protection and return an error if no recipient can be found: this option should be used with caution. The first paragraph does not seem to be true - from what I observed, when no recipient is specified, the decryption always fails - in contradiction to the above. This is how I created an encrypted SMIME: $ openssl version OpenSSL 1.0.2h 3 May 2016 $ openssl cms -encrypt -aes256 -inform SMIME -in Cyph_Bot_test.eml -outform SMIME -out Cyph_Bot_test.smime.eml -subject SMIME_ECC ~/Documents/Certs/me_mouse_yubi_9d_.pem Decryption with explicitly specified -recip works: $ openssl cms -engine pkcs11 -keyform engine -decrypt -aes256 -inform SMIME -in Cyph_Bot_test.smime.eml -outform SMIME -out Cyph_Bot_test.decrypt.eml -recip ~/Documents/Certs/me_mouse_yubi_9d_.pem -inkey "pkcs11:object=KEY%20MAN%20key;object-type=private" engine "pkcs11" set. PKCS#11 token PIN: $ tail Cyph_Bot_test.decrypt.eml Message-id: Date: Sun, 02 Jun 2013 00:56:22 -0400 To: Cloud Mouse MIME-version: 1.0 (1.0) X-Mailer: iPad Mail (10B329) 4DFJ3ECyu3XQmJJtPTXp1HJXeCSFnmL8euXcOSc1NGmDm9fqgR0RU+s0Rl1oggUJ But the same decryption fails when -recip is omitted: $ openssl cms -engine pkcs11 -keyform engine -decrypt -aes256 -inform SMIME -in Cyph_Bot_test.smime.eml -outform SMIME -out Cyph_Bot_test.decrypt1.eml -inkey "pkcs11:object=KEY%20MAN%20key;object-type=private" engine "pkcs11" set. PKCS#11 token PIN: Error decrypting CMS structure 140735083847760:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:529: $ Adding -debug_decrypt flag reveals the problem: $ openssl cms -engine pkcs11 -keyform engine -decrypt -debug_decrypt -aes256 -inform SMIME -in Cyph_Bot_test.smime.eml -outform SMIME -out Cyph_Bot_test.decrypt1.eml -inkey "pkcs11:object=KEY%20MAN%20key;object-type=private" engine "pkcs11" set. PKCS#11 token PIN: Error decrypting CMS using private key 140735083847760:error:2E072084:CMS routines:CMS_decrypt_set1_pkey:no matching recipient:cms_smime.c:661: $ Either the decryptor fails to properly determine the match (and should be fixed), or the documentation is wrong (ad should be edited). -- Regards, Uri Blumenthal -------------- 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 Fri Jun 3 16:09:05 2016 From: rt at openssl.org (Rich Salz via RT) Date: Fri, 03 Jun 2016 16:09:05 +0000 Subject: [openssl-dev] [openssl.org #4135] Fix for a multi-threading issue in policy cache creation In-Reply-To: <1942672.Q6Gmu0TQVo@acid> References: <1942672.Q6Gmu0TQVo@acid> Message-ID: Commit 7d6df9e in master. Thanks! -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4135 Please log in as guest with password guest if prompted From rt at openssl.org Fri Jun 3 17:05:59 2016 From: rt at openssl.org (Dan Kegel via RT) Date: Fri, 03 Jun 2016 17:05:59 +0000 Subject: [openssl-dev] [openssl.org #4559] bug: CRYPTO_set_mem_functions() Doesn't Work in Version 1.0.1b In-Reply-To: References: Message-ID: The commit From: "Dr. Stephen Henson" Date: Fri, 1 Apr 2011 15:46:03 +0000 Subject: [PATCH] Add additional OPENSSL_init() handling add dummy call to (hopefully) ensure OPENSSL_init() is always linked into an application. https://github.com/openssl/openssl/commit/c4acfb1fd049f52fb074b103be01cab5cf5c04f8 seems to have broken CRYPTO_set_mem_functions. After this commit, CRYPTO_set_mem_functions() calls OPENSSL_init(), which calls CRYPTO_malloc(), which sets `allow_customize` to 0, which is then checked by CRYPTO_set_mem_functions(), which then returns without doing anything. See also earlier reports http://openssl.6102.n7.nabble.com/CRYPTO-set-mem-functions-Doesn-t-Work-in-Version-1-0-1b-td46745.html http://bugs.python.org/msg191610 The death test program #include #include #include void * my_alloc(size_t n) { abort(); } void my_free(void *p) { abort(); } void * my_realloc(void *p, size_t n) { abort(); } int main(int argc, const char **argv) { const SSL_METHOD *method; SSL_CTX *ctx; CRYPTO_set_mem_functions(my_alloc, my_realloc, my_free); SSL_library_init(); method = SSLv23_client_method(); ctx = SSL_CTX_new(method); printf("Got ctx %p\n", ctx); return 0; } aborts as expected on Ubuntu 10.04 with openssl0.9.8k, but blithely prints a ctx with openssl 1.0.*. The bug is probably not present in openssl-1.1.0-pre5, as the offending code was removed by https://github.com/openssl/openssl/commit/bbd86bf5424a611cb6b77a3a17fc522931c4dcb8 but a fix for 1.0.0 and 1.0.1 would be much appreciated. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4559 Please log in as guest with password guest if prompted From rt at openssl.org Fri Jun 3 17:08:08 2016 From: rt at openssl.org (Rich Salz via RT) Date: Fri, 03 Jun 2016 17:08:08 +0000 Subject: [openssl-dev] [openssl.org #4559] bug: CRYPTO_set_mem_functions() Doesn't Work in Version 1.0.1b In-Reply-To: References: Message-ID: Sorry, but 0.9.8 and 1.0.0 are end of life and getting no updates and 1.0.1 is only getting security fixes at this time. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4559 Please log in as guest with password guest if prompted From rt at openssl.org Fri Jun 3 17:23:15 2016 From: rt at openssl.org (Dan Kegel via RT) Date: Fri, 03 Jun 2016 17:23:15 +0000 Subject: [openssl-dev] [openssl.org #4559] bug: CRYPTO_set_mem_functions() Doesn't Work in Version 1.0.1b In-Reply-To: References: Message-ID: 1.02 then. (0.9.8 is fine. I'm ok with 1.0.0/1.0.1 remaining broken.) On Fri, Jun 3, 2016 at 10:08 AM, Rich Salz via RT wrote: > Sorry, but 0.9.8 and 1.0.0 are end of life and getting no updates and 1.0.1 is > only getting security fixes at this time. > > -- > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4559 > Please log in as guest with password guest if prompted > -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4559 Please log in as guest with password guest if prompted From uri at ll.mit.edu Fri Jun 3 17:36:07 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Fri, 3 Jun 2016 17:36:07 +0000 Subject: [openssl-dev] [openssl.org #4559] bug: CRYPTO_set_mem_functions() Doesn't Work in Version 1.0.1b In-Reply-To: References: Message-ID: On 6/3/16, 13:23 , "openssl-dev on behalf of Dan Kegel via RT" wrote: >1.02 then. (0.9.8 is fine. I'm ok with 1.0.0/1.0.1 remaining broken.) I compiled your death program, and confirm that it does abort on 1.0.2h. So presumably no fix is necessary there: $clang -I/opt/local/include -o t t.c -L/opt/local/lib -lssl -lcrypto $ ./t Abort trap: 6 >On Fri, Jun 3, 2016 at 10:08 AM, Rich Salz via RT wrote: >> Sorry, but 0.9.8 and 1.0.0 are end of life and getting no updates and >>1.0.1 is >> only getting security fixes at this time. >> >> -- >> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4559 >> Please log in as guest with password guest if prompted -------------- 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 Fri Jun 3 19:38:38 2016 From: rt at openssl.org (Rich Salz via RT) Date: Fri, 03 Jun 2016 19:38:38 +0000 Subject: [openssl-dev] [openssl.org #3580] [PATCH] Print correct help message (according to configure) In-Reply-To: <1414056845-22175-1-git-send-email-Matthieu.Crapet@ingenico.com> References: <1414056845-22175-1-git-send-email-Matthieu.Crapet@ingenico.com> Message-ID: time has passed... nobody looked at this, sorry. fixed earlier by disabling those protocol versions :) -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3580 Please log in as guest with password guest if prompted From rt at openssl.org Fri Jun 3 19:57:42 2016 From: rt at openssl.org (Matt Caswell via RT) Date: Fri, 03 Jun 2016 19:57:42 +0000 Subject: [openssl-dev] [openssl.org #3198] [PATCH] Fix missing NULL pointer checks and memory leaks in crypto/asn1 files In-Reply-To: <4C6658EA-B8F0-4002-AA4F-E02D8FF6389A@elis.ugent.be> References: <4C6658EA-B8F0-4002-AA4F-E02D8FF6389A@elis.ugent.be> Message-ID: The last patches from this have now been applied so closing this ticket. Thanks! Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3198 Please log in as guest with password guest if prompted From sfhacker at hotmail.com Sat Jun 4 09:50:14 2016 From: sfhacker at hotmail.com (Sergio NNX) Date: Sat, 4 Jun 2016 19:50:14 +1000 Subject: [openssl-dev] [OpenSSL][1.0.2h] Memory leaks - CAPI engine to blame? In-Reply-To: References: <5343CAC0.2010103@gmail.com>, <574F1805.9080203@gmail.com>, , Message-ID: > Works for me with mingw 32-bit: > > ALL OCSP TESTS SUCCESSFUL > Test X509v3_check_* > ../util/shlib_wrap.sh ./v3nametest > ../util/shlib_wrap.sh ./heartbeat_test > Test constant time utilites > ../util/shlib_wrap.sh ./constant_time_test > Testing constant time operations... > ok (ran 1908 tests) > test_verify_extra > ../util/shlib_wrap.sh ./verify_extra_test > PASS > test_clienthello > ../util/shlib_wrap.sh ./clienthellotest > test_sslv2conftest > ../util/shlib_wrap.sh ./sslv2conftest > SSLv2 CONF Test number 0 > SSLv2 CONF Test number 1 > SSLv2 CONF test: PASSED > make[1]: Leaving directory `/c/src/openssl-1.0.2h/test' > OPENSSL_CONF=apps/openssl.cnf util/opensslwrap.sh version -a > OpenSSL 1.0.2h-fips 3 May 2016 > built on: reproducible build, date unspecified > platform: mingw > options: bn(64,32) rc4(8x,mmx) des(ptr,risc1,16,long) idea(int) > blowfish(idx) > compiler: gcc -I. -I.. -I../include -DOPENSSL_THREADS -D_MT -DDSO_WIN32 > -DL_ENDIAN -DWIN32_LEAN_AND_MEAN -fomit-frame-pointer -O3 -march=i486 > -Wall -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL > _IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m > -I/usr/local/ssl/fips-2.0/include -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM > -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM > -DGHASH_ASM > OPENSSLDIR: "/usr/local/ssl" > > Thanks for your email. Can I ask you to try one more time? Can you build OpenSSL from source including the CAPI engine and then run the tests again? Make sure the CAPI engine gets built (e.g. openssl engine command) I suspect the memory leaks come from there! I just built it again *without* this option 'enable-capieng' and the memory leaks are gone! Are there any patches available? Thanks again. ... ... ALL OCSP TESTS SUCCESSFUL Test X509v3_check_* ../util/shlib_wrap.sh ./v3nametest ../util/shlib_wrap.sh ./heartbeat_test Test constant time utilites ../util/shlib_wrap.sh ./constant_time_test Testing constant time operations... ok (ran 1908 tests) test_verify_extra ../util/shlib_wrap.sh ./verify_extra_test PASS test_clienthello ../util/shlib_wrap.sh ./clienthellotest test_sslv2conftest ../util/shlib_wrap.sh ./sslv2conftest SSLv2 CONF Test number 0 SSLv2 CONF Test number 1 SSLv2 CONF test: PASSED make[1]: Leaving directory `/src/openssl-1.0.2h/test' OPENSSL_CONF=apps/openssl.cnf util/opensslwrap.sh version -a OpenSSL 1.0.2h-fips 3 May 2016 built on: reproducible build, date unspecified platform: mingw options: bn(64,32) rc4(8x,mmx) des(ptr,risc1,16,long) idea(int) blowfish(idx) compiler: /mingw/bin/gcc.exe -I. -I.. -I../include -DZLIB -DOPENSSL_THREADS -D_ MT -DDSO_WIN32 -DL_ENDIAN -DWIN32_LEAN_AND_MEAN -DWINVER=0x0501 -D_WIN32_WINNT=0 x0501 -D_WIN32_IE=0x0501 -DPTW32_STATIC_LIB -O0 -pipe -mms-bitfields -fno-builti n -march=i686 -mtune=i686 -fomit-frame-pointer -Wall -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -I/mingw/includ e -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ ASM -DWHIRLPOOL_ASM -DGHASH_ASM OPENSSLDIR: "C:/OpenSSL" -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Sat Jun 4 12:17:49 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sat, 04 Jun 2016 12:17:49 +0000 Subject: [openssl-dev] [openssl.org #3895] fprintf in ssl library In-Reply-To: References: Message-ID: fprintf remove from ssl; the ones in crypto are just debugging. closing this. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3895 Please log in as guest with password guest if prompted From rt at openssl.org Sat Jun 4 13:03:37 2016 From: rt at openssl.org (Steffen Nurpmeso via RT) Date: Sat, 04 Jun 2016 13:03:37 +0000 Subject: [openssl-dev] [openssl.org #4556] Unknown: mysterious perl(1) error during [master:8d054a5] installation process In-Reply-To: <20160604130402._6evpCtkW%steffen@sdaoden.eu> References: <20160602135552.e8rIjE0Hl%steffen@sdaoden.eu> <20160604130402._6evpCtkW%steffen@sdaoden.eu> Message-ID: I hope i don't "open" this one! Richard Levitte via RT wrote: |On Thu Jun 02 15:50:31 2016, steffen at sdaoden.eu wrote: |> I have never seen something like this: |> |> Parser.c: loadable library and perl binaries are mismatched (got |> handshake key 0xdb00080, needed 0xdb80080) I should have added that is happened during HTML creation / installation at first, sorry for that! install ./doc/ssl/SSL_set_verify_result.pod -> /home/steffen/usr/opt/.ssl-1.1.0/share/doc/openssl/html/man3/SSL_set_verify_result.html Parser.c: loadable library and perl binaries are mismatched (got handshake key 0xdb00080, needed 0xdb80080) install ./doc/ssl/SSL_shutdown.pod -> /home/steffen/usr/opt/.ssl-1.1.0/share/doc/openssl/html/man3/SSL_shutdown.html Parser.c: loadable library and perl binaries are mismatched (got handshake key 0xdb00080, needed 0xdb80080) install ./doc/ssl/SSL_state_string.pod -> /home/steffen/usr/opt/.ssl-1.1.0/share/doc/openssl/html/man3/SSL_state_string.html Parser.c: loadable library and perl binaries are mismatched (got handshake key 0xdb00080, needed 0xdb80080) |> This is v5.24 on a Linux system, and it flawless afaik. | |Are you sure that you don't have perl modules that you installed separately |with an earlier perl version? You may need to update those. An incredible amount thereof! You are using HTML::Parser? HTML::Parser 3.7100 3.7200 |Either way, this is not an OpenSSL issue, it's a perl one. Closing th\ |is ticket. Sorry for the noise! Please don't mind. Ciao. --steffen -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4556 Please log in as guest with password guest if prompted From steffen at sdaoden.eu Sat Jun 4 13:04:02 2016 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Sat, 04 Jun 2016 15:04:02 +0200 Subject: [openssl-dev] [openssl.org #4556] Unknown: mysterious perl(1) error during [master:8d054a5] installation process In-Reply-To: References: <20160602135552.e8rIjE0Hl%steffen@sdaoden.eu> Message-ID: <20160604130402._6evpCtkW%steffen@sdaoden.eu> I hope i don't "open" this one! Richard Levitte via RT wrote: |On Thu Jun 02 15:50:31 2016, steffen at sdaoden.eu wrote: |> I have never seen something like this: |> |> Parser.c: loadable library and perl binaries are mismatched (got |> handshake key 0xdb00080, needed 0xdb80080) I should have added that is happened during HTML creation / installation at first, sorry for that! install ./doc/ssl/SSL_set_verify_result.pod -> /home/steffen/usr/opt/.ssl-1.1.0/share/doc/openssl/html/man3/SSL_set_verify_result.html Parser.c: loadable library and perl binaries are mismatched (got handshake key 0xdb00080, needed 0xdb80080) install ./doc/ssl/SSL_shutdown.pod -> /home/steffen/usr/opt/.ssl-1.1.0/share/doc/openssl/html/man3/SSL_shutdown.html Parser.c: loadable library and perl binaries are mismatched (got handshake key 0xdb00080, needed 0xdb80080) install ./doc/ssl/SSL_state_string.pod -> /home/steffen/usr/opt/.ssl-1.1.0/share/doc/openssl/html/man3/SSL_state_string.html Parser.c: loadable library and perl binaries are mismatched (got handshake key 0xdb00080, needed 0xdb80080) |> This is v5.24 on a Linux system, and it flawless afaik. | |Are you sure that you don't have perl modules that you installed separately |with an earlier perl version? You may need to update those. An incredible amount thereof! You are using HTML::Parser? HTML::Parser 3.7100 3.7200 |Either way, this is not an OpenSSL issue, it's a perl one. Closing th\ |is ticket. Sorry for the noise! Please don't mind. Ciao. --steffen From rt at openssl.org Sat Jun 4 13:18:13 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sat, 04 Jun 2016 13:18:13 +0000 Subject: [openssl-dev] [openssl.org #4556] Unknown: mysterious perl(1) error during [master:8d054a5] installation process In-Reply-To: <20160602135552.e8rIjE0Hl%steffen@sdaoden.eu> References: <20160602135552.e8rIjE0Hl%steffen@sdaoden.eu> Message-ID: No problem, Steffan. Re-closing.:) -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4556 Please log in as guest with password guest if prompted From rt at openssl.org Sun Jun 5 09:00:03 2016 From: rt at openssl.org (Sebastian Andrzej Siewior via RT) Date: Sun, 05 Jun 2016 09:00:03 +0000 Subject: [openssl-dev] [openssl.org #4548] s390x build problem In-Reply-To: <20160605085943.GA27543@thinki> References: <20160530195815.GA18832@roeckx.be> <0f31bcda-3c71-4ae2-7130-33b3a1d0d0e1@openssl.org> <20160601172458.GA5298@breakpoint.cc> <575034F7.2090507@openssl.org> <20160605085943.GA27543@thinki> Message-ID: On 2016-06-02 13:29:35 [+0000], Andy Polyakov via RT wrote: > Thanks!!! There is couple of problems with suggested modifications > though. First general comment. While 31-bit is arguably not very > fashionable, bugs are still reported at occasions. Important to keep in > mind that 31-bit build still requires z/Arch processor *and* highgprs > kernel feature, i.e. target is not s390 systems (note lack of x), but > 64-bit processor running 64-bit OS, just running legacy *process*. Goal > also is to minimize deviations and "parametrize", so that most of the > code is constantly "exposed" to assembler. That's what are those ${g} > things are and that's why #if clauses are limited to clearing most > significant 32 bits of registers. This means that suggestion to > introduce big #if in CRYPTO_memcmp is not considered favourable. > Adhering to non-extension instructions is. Another problem is with > suggested ltgr in chacha-s390x. It has to be "parametrized", i.e. look > as lt${g}r. Because in 31-bit build there is no guarantee that most > significant 32-bit of $len register are actually zero-ed. In other words > could you double-check attached patch instead? Thanks. Just tested and it compiles and the testsuite passes. Sebastian -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4548 Please log in as guest with password guest if prompted From rt at openssl.org Mon Jun 6 09:11:11 2016 From: rt at openssl.org (Andy Polyakov via RT) Date: Mon, 06 Jun 2016 09:11:11 +0000 Subject: [openssl-dev] [openssl.org #4548] s390x build problem In-Reply-To: <57553E2A.80207@openssl.org> References: <20160530195815.GA18832@roeckx.be> <0f31bcda-3c71-4ae2-7130-33b3a1d0d0e1@openssl.org> <575034F7.2090507@openssl.org> <20160605085943.GA27543@thinki> <57553E2A.80207@openssl.org> Message-ID: >> In other words >> could you double-check attached patch instead? > > Thanks. Just tested and it compiles and the testsuite passes. Committed. Thanks. Case is being dismissed. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4548 Please log in as guest with password guest if prompted From rt at openssl.org Mon Jun 6 16:23:00 2016 From: rt at openssl.org (Loic Etienne via RT) Date: Mon, 06 Jun 2016 16:23:00 +0000 Subject: [openssl-dev] [openssl.org #4560] BUG: openssl-1.0.2h, evp_enc.c, fips, use of uninitialized variable In-Reply-To: References: Message-ID: crypto/evp/evp_enc.c, EVP_CipherInit_ex, line 172 const EVP_CIPHER *fcipher; if (cipher) fcipher = evp_get_fips_cipher(cipher); if (fcipher) cipher = fcipher; return FIPS_cipherinit(ctx, cipher, key, iv, enc); problem: if (!cipher), fcipher is not initialized but used possible fix: const EVP_CIPHER *fcipher = evp_get_fips_cipher(cipher); return FIPS_cipherinit(ctx, fcipher ? fcipher : cipher, key, iv, enc); -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4560 Please log in as guest with password guest if prompted From rt at openssl.org Mon Jun 6 18:26:50 2016 From: rt at openssl.org (Loic Etienne via RT) Date: Mon, 06 Jun 2016 18:26:50 +0000 Subject: [openssl-dev] [openssl.org #4561] BUG: openssl-1.0.2h, evp_enc.c, non-portable bitwise operation In-Reply-To: References: Message-ID: crypto/evp/evp_enc.c, EVP_EncryptUpdate line 337: inl & (ctx->block_mask) line 367: inl & (bl - 1) /* with bl = ctx->cipher->block_size */ Instead, the more portable inl % ctx->cipher->block_size should be used; or, alternatively, unsigned integers should be used. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4561 Please log in as guest with password guest if prompted From rt at openssl.org Tue Jun 7 19:22:00 2016 From: rt at openssl.org (Matt Caswell via RT) Date: Tue, 07 Jun 2016 19:22:00 +0000 Subject: [openssl-dev] [openssl.org #4496] [PATCH] ssl_cert: use the recommended minimum hash from RFC 5480 for EC In-Reply-To: <20160402135602.GA3269@breakpoint.cc> References: <20160402135602.GA3269@breakpoint.cc> Message-ID: On Sat Apr 02 14:05:50 2016, sebastian at breakpoint.cc wrote: > A TLS1.2 connetion with openssl server and gnutls-cli using a > SECP384R1 > key ends up with SHA256 as the hash algorithm for signing the key > exchange. > This is because gnutls sends the hash algorithms from weak to strong > and by default client's preference is used. > > gnutls complains about this situation: > |<1>| The hash size used in signature (32) is less than the expected > (48) Really gnutls should not offer algorithms that it is not prepared to accept. Also if sha256 with p256 is considered acceptable security, why wouldn't sha256 with p384 be? OpenSSL is obeying RFC5246 7.4.1.4.1: Each SignatureAndHashAlgorithm value lists a single hash/signature pair that the client is willing to verify. The values are indicated in descending order of preference. So I don't think this is an OpenSSL bug. Closing this ticket. Matt > > The complaint is based on the recommendation in RFC 5480, section 4. > Security Considerations. There two ways to fix it: > - Using > -sigalgs > "ECDSA+SHA384:ECDSA+SHA512:ECDSA+SHA256:ECDSA+SHA224:ECDSA+SHA1" > -serverpref > The weaker algorithms > > - The following patch which eliminates SHA256+SHA224 from the list of > possible candidates. SHA1 is still available if left out in -sigalgs > and nothing else matches. > > Signed-off-by: Sebastian Andrzej Siewior > --- > ssl/ssl_cert.c | 19 +++++++++++++++++++ > 1 file changed, 19 insertions(+) > > diff --git a/ssl/ssl_cert.c b/ssl/ssl_cert.c > index 4081ebe4ffbd..7d00ad3182f5 100644 > --- a/ssl/ssl_cert.c > +++ b/ssl/ssl_cert.c > @@ -1135,6 +1135,25 @@ static int ssl_security_default_callback(const > SSL *s, const SSL_CTX *ctx, int o > if (level >= 3) > return 0; > break; > +#ifndef OPENSSL_NO_EC > + case SSL_SECOP_SIGALG_SHARED: > + if (s && s->cert && s->cert->key && s->cert->key->privatekey) > { > + EVP_PKEY *skey = s->cert->key->privatekey; > + > + /* > + * RFC 5480 Section 4, Security Considerations. > + * For a curve with keysize of 384 bits (secp384r1) we > + * allow SHA-384 and higher > + */ > + if (EVP_PKEY_id(skey) == EVP_PKEY_EC) { > + if (EVP_PKEY_bits(skey) > (bits * 2)) > + return 0; > + } > + } > + if (bits < minbits) > + return 0; > + break; > +#endif > default: > if (bits < minbits) > return 0; -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4496 Please log in as guest with password guest if prompted From rt at openssl.org Tue Jun 7 21:04:57 2016 From: rt at openssl.org (Matt Caswell via RT) Date: Tue, 07 Jun 2016 21:04:57 +0000 Subject: [openssl-dev] [openssl.org #4501] bug in BN_mod_word In-Reply-To: References: Message-ID: On Thu Apr 07 11:44:09 2016, peter.chernyshev at gmail.com wrote: > Hello! > BN part program > > BN_ULONG BN_mod_word (const BIGNUM * a, BN_ULONG w); > > does not work properly on 64-bit machine with some w> 2 ^ 32, although > declared as BN_ULONG (64 bits). Fixed in commit e82fd1b4 (1.0.2) and 37258dad (1.1.0). Thanks for the report. Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4501 Please log in as guest with password guest if prompted From rt at openssl.org Tue Jun 7 21:11:05 2016 From: rt at openssl.org (Matt Caswell via RT) Date: Tue, 07 Jun 2016 21:11:05 +0000 Subject: [openssl-dev] [openssl.org #4395] OpenSSL doesn't reject out-of-context empty records In-Reply-To: References: Message-ID: On Mon Mar 07 22:27:23 2016, davidben at google.com wrote: > ssl3_get_record silently discards empty records without much context, > which > means OpenSSL will happily accept, e.g., empty app data records > mid-handshake or empty records of bogus type. They get silently > discarded > and never returned to the caller, so this is harmless, just a little > odd. Fixed in commit 255cfeac. I also added a test for this in 4f0c475. Thanks David. Closing. Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4395 Please log in as guest with password guest if prompted From rt at openssl.org Wed Jun 8 01:02:58 2016 From: rt at openssl.org (Brian Smith via RT) Date: Wed, 08 Jun 2016 01:02:58 +0000 Subject: [openssl-dev] [openssl.org #4362] chacha-x86.pl has stricter aliasing requirements than other files In-Reply-To: References: Message-ID: Brian Smith wrote: > It seems that 32-bit ARM has the same limitation as x86 that the input and > output pointers must match or the input and output buffers must not overlap > at all. I'm not sure which ARM code path (NEON or non-NEON, or both) has > this issue. Just to follow up on this: I think this might actually be a QEMU ARM (32-bit) emulator bug, or a configuration issue on my part. In one version of the QEMU emulator, I have no trouble. But, in another, newer, version of the QEMU emulator, I get results like this for BoringSSL's chacha_test (modified to print all the results before failing): Mismatch at length 64 with in-place offset 1. Mismatch at length 64 with in-place offset 2. Mismatch at length 64 with in-place offset 5. Mismatch at length 64 with in-place offset 6. Mismatch at length 64 with in-place offset 9. Notice, in particular, that it only happens when the input length is 64, and only for specific offsets. Like I said, I consistently get these failures on the Android emulator but not in a newer version of QEMU. It doesn't make any difference whether NEON is enabled or disabled; I believe this is because the ARM code only uses NEON if there are at least 3 blocks. Anyway, I see in the ARM chacha code that there is a special case when the length is 64, so it might be worth double-checking that code. Just FYI. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4362 Please log in as guest with password guest if prompted From brian at briansmith.org Wed Jun 8 01:18:09 2016 From: brian at briansmith.org (Brian Smith) Date: Tue, 7 Jun 2016 15:18:09 -1000 Subject: [openssl-dev] Removing gcm128_context->H for non-1-bit builds Message-ID: I noticed that the `H` member of `gcm128_context` seems to be unnecessary for builds that aren't using the 1-bit GCM math. Since this member is large (128-bits) and some applications may have lots of GCM contexts relative to the amount of memory they have, I think it would be great to only put the `H` member into the structure when the 1-bit math is used. I tried to write a patch to do this myself, but I got stuck, because the assembly language code does pointer math assuming that the `H` member (which it doesn't use, AFAICT) is there. And, I can't quite understand the assembly language code well enough to adjust all the offsets to make the code work with `H` removed. Could somebody adjust who understand the assembly code (probably Andy) modify it to use symbolic names for the offsets that are used to access Xi, H, Htable? If so, then I can write the patch to conditionally exclude `H` on platforms that don't need it after `CRYPTO_gcm128_init` finishes executing. Also, I wonder how important it is to keep the 1-bit math code? It seems pretty much every platform have optimized code that uses 4-bit or 8-bit math. Thanks, Brian -- https://briansmith.org/ From brian at briansmith.org Wed Jun 8 01:22:31 2016 From: brian at briansmith.org (Brian Smith) Date: Tue, 7 Jun 2016 15:22:31 -1000 Subject: [openssl-dev] Syncing OpenSSL and BoringSSL mont ASM code In-Reply-To: <27003f6c-a765-2c05-2c03-8eedc4969f52@openssl.org> References: <27003f6c-a765-2c05-2c03-8eedc4969f52@openssl.org> Message-ID: Andy Polyakov wrote: >> 1. Please >> see https://boringssl.googlesource.com/boringssl/+/75b833cc819a9d189adb0fdd56327bee600ff9e9. >> >> I think it would be good for OpenSSL to work with Google to integrate >> this patch. > > Will be looked into... Awesome! Besides the functions that Google changed, I think it is also necessary to change the other implementations of `bn_mul_mont` (including the C implementation) and also `BN_from_montgomery_word`. >> 2. Is the `__chkstk` code that was added [1] to `bn_mul_mont` really >> necessary? > > The SEGV that is mentioned in the commit message and commentary was > actually observed and reported. Well, it's not called SEGV on Windows, > but equivalent has same devastating effect, i.e. application crash. It > takes super-long RSA key, longer than you'd normally use, so it's not > something that a lot of users risk suffering from. But the problem is > real nevertheless. Thanks for clarifying this. I agree that it seems like a good thing to do. This is a very large `alloca` happening in the asm code, which is probably surprising for people reading the code. Maybe it would be a good idea to move the alloca out into the calling function so that it is clear that a *lot* of stack space is being used, potentially. Cheers, Brian -- https://briansmith.org/ From brian at briansmith.org Wed Jun 8 01:38:25 2016 From: brian at briansmith.org (Brian Smith) Date: Tue, 7 Jun 2016 15:38:25 -1000 Subject: [openssl-dev] Why is `volatile` used in MOD_EXP_CTIME_COPY_FROM_PREBUF? In-Reply-To: References: Message-ID: Andy Polyakov wrote: >Brian Smith wrote: >> See >> https://github.com/openssl/openssl/commit/d6482a82bc2228327aa4ba98aeeecd9979542a31#diff-3aca3afd18ad75a8f6a09a9860bc6ef5R631 >> >> + volatile BN_ULONG *table = (volatile BN_ULONG *)buf; >> >> Why is `volatile` used here? Is it to work around the effective type >> (strict aliasing) violations or for some other reason? > > Isn't it obvious? Volatile is there to discourage compiler from > reordering loads from the the table. I mean concern is that if reordered > in specific manner loads might give away the information we are trying > to conceal. Sorry, maybe these things are obvious to many people but they're not so obvious to me. I saw that after I posted this email, you added a comment that says something similar to what you wrote above. But, just to be absolutely clear: the concern is that the compiler might notice, "hey, this code is scanning this input array in a weird way. I can redo the math (in a way that will result in non-constant-time-access to the buffers containing secrets) so that this is much faster." So, maybe, it is not so much the order of the accesses that matter, but rather that the compiler might choose to do different math that arrives at the same results, but with different timing? >> I think it would >> be good to document this, or better, find a way to avoid needing to use >> `volatile` in the first place. > > Well, the only guaranteed way is to implement it in assembly. Note that > on most popular/relevant platform it *is* implemented in assembly. Yes, understood. And, in general, pepole should be using blinding for RSA and avoiding the other algorithms that use this code. Thanks for taking the time to answer my questions! I appreciate it. Cheers, Brian -- https://briansmith.org/ From brian at briansmith.org Wed Jun 8 01:48:15 2016 From: brian at briansmith.org (Brian Smith) Date: Tue, 7 Jun 2016 15:48:15 -1000 Subject: [openssl-dev] Making assembly language optimizations working on Cortex-M3 In-Reply-To: <738e4039-092b-9a64-01b6-c60aab0a5769@openssl.org> References: <55C4DC74.6060900@openssl.org> <55C873B8.9060602@openssl.org> <56056D20.9020806@openssl.org> <56b00a41-ed5f-4998-b0fb-55a6a39e4544@openssl.org> <738e4039-092b-9a64-01b6-c60aab0a5769@openssl.org> Message-ID: Andy Polyakov wrote: >> > Cortex-M platforms are so limited that every bit of performance and >> > space savings matters. So, I think it is definitely worthwhile to >> > support the non-NEON ARMv7-M configuration. One easy way to do this >> > would be to avoid building NEON code when __TARGET_PROFILE_M is defined. >> >> I don't see no __TARGET_PROFILE_M defined by gcc >> >> >> I see. I didn't realize that GCC didn't emulate this ARM compiler >> feature. Never mind. > > But gcc defines __ARM_ARCH_7M__, which can be used to e.g. Thanks. That's useful to know. >> I can try to make a patch to bring BoringSSL's OPENSSL_STATIC_ARMCAP >> mechanism to OpenSSL, if you think that is an OK approach. > > I don't understand. Original question was about conditional *omission* > of NEON code (which incidentally means even omission of run-time > switches), while BoringSSL's OPENSSL_STATIC_ARMCAP is about *keeping* > NEON as well as run-time switch *code*, just setting OPENSSL_armcap_P to > a chosen value at compile time... I mean it looks like we somehow > started to talk about different things... When I wrote "care to make > suggestion" I was thinking about going through all #if __ARM_ARCH__>=7 > and complementing some of them with !defined(something_M)... > Compiler might remove dead code it would generate itself, but it still > won't omit anything from assembly module. Linker takes them in as > monolithic blocks. If the target is Cortex-M4, there is no NEON. So then, with the OPENSSL_STATIC_ARMCAP, we won't set define OPENSSL_STATIC_ARMCAP_NEON and so that bit of the armcap variable won't be set. I think what you're trying to say is that, if we just stop there, then all the NEON code will still get linked in. That's true. But, what I mean is that we should then also change all the tests of the NEON bit of OPENSSL_armcap_P (and, more generally, all tests of OPENSSL_armcap_P) to use code that the C compiler can do constant propagation and dead code elimination on. We can do this, for example, by defining `OPENSSL_armcap_P` to be a macro that can be seen to have a constant compile-time value, when using the OPENSSL_STATIC_ARMCAP mechanism. And/or, we can surround the relevant code with `#if !defined(OPENSSL_STATIC_ARMCAP ) || defined(OPENSSL_STATIC_ARMCAP_NEON)`, etc. This latter technique would (IIUC) work even in the assembly language files. In this way, if we know at build time that NEON will be available, we can avoid compiling/linking the non-NEON code. Conversely, if we know that NEON will NOT be available, we can avoid compiling/linking the NEON code. I hope this clarifies my suggestion. Cheers, Brian -- https://briansmith.org/ From brian at briansmith.org Wed Jun 8 02:11:17 2016 From: brian at briansmith.org (Brian Smith) Date: Tue, 7 Jun 2016 16:11:17 -1000 Subject: [openssl-dev] Making assembly language optimizations working onCortex-M3 In-Reply-To: References: <55C4DC74.6060900@openssl.org> <55C873B8.9060602@openssl.org> <56056D20.9020806@openssl.org> <56b00a41-ed5f-4998-b0fb-55a6a39e4544@openssl.org> <738e4039-092b-9a64-01b6-c60aab0a5769@openssl.org> Message-ID: Peter Waltenberg wrote: > IF you are in the situation where you are compiling for a space > constrained embedded processor then hopefully your engineers also have > enough smarts to fix the code. I'd also point out that a lot of dev. setups > for embedded aren't actually compiled on the target machine either so > auto-detection at build time isn't that sensible anyway. > The BoringSSL works as follows: 1. The person building the code passes -DOPENSSL_STATIC_ARMCAP and some other flags like -DOPENSSL_STATIC_ARMCAP_NEON, to indicate which features are available on the target. 2. When OPENSSL_STATIC_ARMCAP is defined, the runtime detection of features is disabled. 3. When OPENSSL_STATIC_ARMCAP is defined, OPENSSL_armcap_P is fixed to a value based on which of DOPENSSL_STATIC_ARMCAP_NEON, etc. are defined. 4. When OPENSSL_STATIC_ARMCAP isn't defined, then everything works like it currently does; i.e. features are detected at runtime. The idea is that, instead having to go in and manually edit the code for each different target system, one can just define these flags and the code will auto-configure itself at build-time. > The problem here is you can't have both and having the capability switch > at runtime depending on hardware quirks is the better option for the > majority of users. > That's usually true, but the topic of this thread is about how to get OpenSSL working well on Cortex-M microcontrollers. In those situations, we cannot really afford the dynamic detection or the many different implementations of the same algorithm to exist in the final image. Cheers, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From pwalten at au1.ibm.com Wed Jun 8 02:02:25 2016 From: pwalten at au1.ibm.com (Peter Waltenberg) Date: Wed, 8 Jun 2016 12:02:25 +1000 Subject: [openssl-dev] Making assembly language optimizations working onCortex-M3 In-Reply-To: References: <55C4DC74.6060900@openssl.org> <55C873B8.9060602@openssl.org> <56056D20.9020806@openssl.org> <56b00a41-ed5f-4998-b0fb-55a6a39e4544@openssl.org> <738e4039-092b-9a64-01b6-c60aab0a5769@openssl.org> Message-ID: That may not be a good idea. The vast majority of OpenSSL in use isn't targetted at a specific processor variant. It's compiled by an OS vendor and then installed on whatever. IF you are in the situation where you are compiling for a space constrained embedded processor then hopefully your engineers also have enough smarts to fix the code. I'd also point out that a lot of dev. setups for embedded aren't actually compiled on the target machine either so auto-detection at build time isn't that sensible anyway. The problem here is you can't have both and having the capability switch at runtime depending on hardware quirks is the better option for the majority of users. You certainly don't want to mess with the runtime OPENSSL_armcap_P as that likely breaks 'the rest of the world' (tm) Peter From: Brian Smith To: openssl-dev at openssl.org Date: 08/06/2016 11:49 Subject: Re: [openssl-dev] Making assembly language optimizations working on Cortex-M3 Sent by: "openssl-dev" Andy Polyakov wrote: >> > Cortex-M platforms are so limited that every bit of performance and >> > space savings matters. So, I think it is definitely worthwhile to >> > support the non-NEON ARMv7-M configuration. One easy way to do this >> > would be to avoid building NEON code when __TARGET_PROFILE_M is defined. >> >> I don't see no __TARGET_PROFILE_M defined by gcc >> >> >> I see. I didn't realize that GCC didn't emulate this ARM compiler >> feature. Never mind. > > But gcc defines __ARM_ARCH_7M__, which can be used to e.g. Thanks. That's useful to know. >> I can try to make a patch to bring BoringSSL's OPENSSL_STATIC_ARMCAP >> mechanism to OpenSSL, if you think that is an OK approach. > > I don't understand. Original question was about conditional *omission* > of NEON code (which incidentally means even omission of run-time > switches), while BoringSSL's OPENSSL_STATIC_ARMCAP is about *keeping* > NEON as well as run-time switch *code*, just setting OPENSSL_armcap_P to > a chosen value at compile time... I mean it looks like we somehow > started to talk about different things... When I wrote "care to make > suggestion" I was thinking about going through all #if __ARM_ARCH__>=7 > and complementing some of them with !defined(something_M)... > Compiler might remove dead code it would generate itself, but it still > won't omit anything from assembly module. Linker takes them in as > monolithic blocks. If the target is Cortex-M4, there is no NEON. So then, with the OPENSSL_STATIC_ARMCAP, we won't set define OPENSSL_STATIC_ARMCAP_NEON and so that bit of the armcap variable won't be set. I think what you're trying to say is that, if we just stop there, then all the NEON code will still get linked in. That's true. But, what I mean is that we should then also change all the tests of the NEON bit of OPENSSL_armcap_P (and, more generally, all tests of OPENSSL_armcap_P) to use code that the C compiler can do constant propagation and dead code elimination on. We can do this, for example, by defining `OPENSSL_armcap_P` to be a macro that can be seen to have a constant compile-time value, when using the OPENSSL_STATIC_ARMCAP mechanism. And/or, we can surround the relevant code with `#if !defined(OPENSSL_STATIC_ARMCAP ) || defined(OPENSSL_STATIC_ARMCAP_NEON)`, etc. This latter technique would (IIUC) work even in the assembly language files. In this way, if we know at build time that NEON will be available, we can avoid compiling/linking the non-NEON code. Conversely, if we know that NEON will NOT be available, we can avoid compiling/linking the NEON code. I hope this clarifies my suggestion. Cheers, Brian -- https://briansmith.org/ -- 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 appro at openssl.org Wed Jun 8 08:50:30 2016 From: appro at openssl.org (Andy Polyakov) Date: Wed, 8 Jun 2016 10:50:30 +0200 Subject: [openssl-dev] Why is `volatile` used in MOD_EXP_CTIME_COPY_FROM_PREBUF? In-Reply-To: References: Message-ID: <5757DC56.3010307@openssl.org> >>> See >>> https://github.com/openssl/openssl/commit/d6482a82bc2228327aa4ba98aeeecd9979542a31#diff-3aca3afd18ad75a8f6a09a9860bc6ef5R631 >>> >>> + volatile BN_ULONG *table = (volatile BN_ULONG *)buf; >>> >>> Why is `volatile` used here? Is it to work around the effective type >>> (strict aliasing) violations or for some other reason? >> >> Isn't it obvious? Volatile is there to discourage compiler from >> reordering loads from the the table. I mean concern is that if reordered >> in specific manner loads might give away the information we are trying >> to conceal. > > Sorry, maybe these things are obvious to many people but they're not > so obvious to me. I saw that after I posted this email, you added a > comment that says something similar to what you wrote above. But, just > to be absolutely clear: the concern is that the compiler might notice, > "hey, this code is scanning this input array in a weird way. I can > redo the math (in a way that will result in non-constant-time-access > to the buffers containing secrets) so that this is much faster." So, > maybe, it is not so much the order of the accesses that matter, but > rather that the compiler might choose to do different math that > arrives at the same results, but with different timing? Well, it's all about timing *variation* depending on attacker's activity. But it's not really about making timing independent on attacker's activity, but making it independent on secret material. I mean it *may* depend on attacker's activity, but this whichever dependency may not depend on secret material. And it may not depend on it during operation either. I mean it's not enough to make overall time independent, but even each intermediate step. 'volatile' formally obliges compiler to actually perform all the references (none can be omitted, that would be catastrophic scenario) and even preserve their order (concern is that compiler would regroup in manner that would allow attacker to trace the execution which in turn might give away information). From hkario at redhat.com Wed Jun 8 10:25:51 2016 From: hkario at redhat.com (Hubert Kario) Date: Wed, 08 Jun 2016 12:25:51 +0200 Subject: [openssl-dev] [openssl.org #4496] [PATCH] ssl_cert: use the recommended minimum hash from RFC 5480 for EC In-Reply-To: References: <20160402135602.GA3269@breakpoint.cc> Message-ID: <1919944.vPkLuAKbNu@pintsize.usersys.redhat.com> On Tuesday 07 June 2016 19:22:00 Matt Caswell via RT wrote: > On Sat Apr 02 14:05:50 2016, sebastian at breakpoint.cc wrote: > > A TLS1.2 connetion with openssl server and gnutls-cli using a > > SECP384R1 > > key ends up with SHA256 as the hash algorithm for signing the key > > exchange. > > This is because gnutls sends the hash algorithms from weak to strong > > and by default client's preference is used. > > > > gnutls complains about this situation: > > |<1>| The hash size used in signature (32) is less than the expected > > (48) it complains, but does it abort connection? -- 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 matt at openssl.org Wed Jun 8 10:29:32 2016 From: matt at openssl.org (Matt Caswell) Date: Wed, 8 Jun 2016 11:29:32 +0100 Subject: [openssl-dev] [openssl.org #4496] [PATCH] ssl_cert: use the recommended minimum hash from RFC 5480 for EC In-Reply-To: <1919944.vPkLuAKbNu@pintsize.usersys.redhat.com> References: <20160402135602.GA3269@breakpoint.cc> <1919944.vPkLuAKbNu@pintsize.usersys.redhat.com> Message-ID: <5757F38C.6050103@openssl.org> On 08/06/16 11:25, Hubert Kario wrote: > On Tuesday 07 June 2016 19:22:00 Matt Caswell via RT wrote: >> On Sat Apr 02 14:05:50 2016, sebastian at breakpoint.cc wrote: >>> A TLS1.2 connetion with openssl server and gnutls-cli using a >>> SECP384R1 >>> key ends up with SHA256 as the hash algorithm for signing the key >>> exchange. >>> This is because gnutls sends the hash algorithms from weak to strong >>> and by default client's preference is used. >>> >>> gnutls complains about this situation: >>> |<1>| The hash size used in signature (32) is less than the expected >>> (48) > > it complains, but does it abort connection? FYI, there is a (long!) discussion on this issue here: https://github.com/openssl/openssl/pull/1046 Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From appro at openssl.org Wed Jun 8 10:40:40 2016 From: appro at openssl.org (Andy Polyakov) Date: Wed, 8 Jun 2016 12:40:40 +0200 Subject: [openssl-dev] Removing gcm128_context->H for non-1-bit builds In-Reply-To: References: Message-ID: <5757F628.7090107@openssl.org> > I noticed that the `H` member of `gcm128_context` seems to be > unnecessary for builds that aren't using the 1-bit GCM math. Since > this member is large (128-bits) and some applications may have lots of > GCM contexts relative to the amount of memory they have, I think it > would be great to only put the `H` member into the structure when the > 1-bit math is used. Not true. It is actually used in s390x assembly module. And I mean both H and Htable. This is because hardware-assisted single multiplication is not faster than pure software. In practical terms it means that Htable is used when you need to perform single multiplication, and H is used when you process multiple input blocks in one go. > I tried to write a patch to do this myself, but I got stuck, because > the assembly language code does pointer math assuming that the `H` > member (which it doesn't use, AFAICT) is there. And, I can't quite > understand the assembly language code well enough to adjust all the > offsets to make the code work with `H` removed. > > Could somebody adjust who understand the assembly code (probably Andy) > modify it to use symbolic names for the offsets that are used to > access Xi, H, Htable? If so, then I can write the patch to > conditionally exclude `H` on platforms that don't need it after > `CRYPTO_gcm128_init` finishes executing. In cases other than s390x it's likely to be optimization thing. I mean as you tend to use all the registers you are likely to find it beneficial to discard Xi and use Htable to address both. But going the line of taking into consideration all corner cases is a stretch and should be weighed against 16 out of ~380[!] bytes waste. I'd say it's not worth it. One can argue that "the most popular embedded three-letter platform" deserves this 4% space optimization [by being so popular], but then question would be if OpenSSL can actually execute in such constrained environment where 4% per GCM context (i.e. something that itself is percentage of something else) makes a difference. Aren't we likely to be talking about ripping out single component and using in the said environment? But then question is why this specific case would have to complicate maintenance for OpenSSL as whole? In other words I'd vote for saying no to omitting H. However, I can tell that assembly module for "the most popular embedded three-letter platform" does *not* depend on relative position of Xi, H and Htable. One can *probably* discuss that it would be appropriate to *facilitate* omission of H in context *other than* OpenSSL by avoiding H during most of the setup procedure. See attached patch for example. But do note that I'm not saying that it works or suggesting to include it right away, I only want to show what *might* be matter of discussion. > Also, I wonder how important it is to keep the 1-bit math code? Look at it as insurance. The moment they come and say table-driven approach is no-go, we have 1-bit code to switch to. From appro at openssl.org Wed Jun 8 10:45:01 2016 From: appro at openssl.org (Andy Polyakov) Date: Wed, 8 Jun 2016 12:45:01 +0200 Subject: [openssl-dev] Removing gcm128_context->H for non-1-bit builds In-Reply-To: <5757F628.7090107@openssl.org> References: <5757F628.7090107@openssl.org> Message-ID: <5757F72D.2060007@openssl.org> > One can *probably* discuss > that it would be appropriate to *facilitate* omission of H in context > *other than* OpenSSL by avoiding H during most of the setup procedure. > See attached patch for example. But do note that I'm not saying that it > works or suggesting to include it right away, I only want to show what > *might* be matter of discussion. Missed the patch... -------------- next part -------------- A non-text attachment was scrubbed... Name: gcm128.diff Type: text/x-patch Size: 4127 bytes Desc: not available URL: From brian at briansmith.org Wed Jun 8 11:51:20 2016 From: brian at briansmith.org (Brian Smith) Date: Wed, 8 Jun 2016 01:51:20 -1000 Subject: [openssl-dev] Removing gcm128_context->H for non-1-bit builds In-Reply-To: <5757F628.7090107@openssl.org> References: <5757F628.7090107@openssl.org> Message-ID: On Wed, Jun 8, 2016 at 12:40 AM, Andy Polyakov wrote: >> I noticed that the `H` member of `gcm128_context` seems to be >> unnecessary for builds that aren't using the 1-bit GCM math. > > Not true. It is actually used in s390x assembly module. And I mean both > H and Htable. I see. I admit I didn't look at the s390x code, mostly because I can't fit one in my small apartment. >> Could somebody adjust who understand the assembly code (probably Andy) >> modify it to use symbolic names for the offsets that are used to >> access Xi, H, Htable? If so, then I can write the patch to >> conditionally exclude `H` on platforms that don't need it after >> `CRYPTO_gcm128_init` finishes executing. > But going the > line of taking into consideration all corner cases is a stretch and > should be weighed against 16 out of ~380[!] bytes waste. I'd say it's > not worth it. I see it both as an *optimization* and also a way to ensure *correctness*. In particular, if the code doesn't expect H to be there in configurations that don't use H, then some tricks that people might use (in particular, a trick I am using) becomes safer. In particular, notice that in the gcm128_context structure, there are three kinds of state (again, only talking about non-s390x, non-1-bit platforms): 1. State that is only used in the _init function: H. 2. State that needs to be preserved in between authenticated-and-encrypted messages. This is `Htable`, `EK0`, `gmult`, `ghash`, `block`, etc. 3. State that needs to be preserved only between the time you start an authenticated-and-encrypted message and the time you end it. This includes `len`, `EKi`, `mres`, `ares`, etc. currently. In theory this could also include `gmult`, `ghash` and `block`, if the code were refactored to recomputed them for each message and/or if things like the OPENSSL_STATIC_ARMCAP-type optimization allowed one to omit them from the structure completely in some configurations where there is no way they could vary at runtime. Also, Htable is 256 bytes on its own (on the platforms I care about), but actually in some platforms/configurations not all of Htable is used. In my code, after I call the _init function, I extract out all the numbers in category #2 and store them in my per-connection context structure on. Then, when I need to encrypt/decrypt a message, I construct a full gcm128_context *on the stack*, zero it out, and then fill in the values from category #2. Then I encrypt/decrypt the message, and then throw away the gcm128_context. > One can argue that "the most popular embedded three-letter > platform" deserves this 4% space optimization [by being so popular], but > then question would be if OpenSSL can actually execute in such > constrained environment where 4% per GCM context (i.e. something that > itself is percentage of something else) makes a difference. Aren't we > likely to be talking about ripping out single component and using in the > said environment? But then question is why this specific case would have > to complicate maintenance for OpenSSL as whole? In other words, there are *lots* of bytes in gcm128_context that could be thrown away in between messages, if one really needed to save memory. And then the size of `H` does matter quite a bit more as a percentage of the size of this inter-message state. And, also, whether or not `H` belongs in category #1 or category #2 is important for correctness. Thus, my suggestion in this thread is an attempt to clarify the code to make it more obvious that it is in category #2 (besides 1-bit-mult and s390x platforms). Note, in contrast, Poly1305 only requires 32 bytes of state to be preserved between messages. My goal is to bring the GCM inter-message state storage requirements closer to this 32 bytes. > However, I can tell that assembly module > for "the most popular embedded three-letter platform" does *not* depend > on relative position of Xi, H and Htable. One can *probably* discuss > that it would be appropriate to *facilitate* omission of H in context > *other than* OpenSSL by avoiding H during most of the setup procedure. > See attached patch for example. But do note that I'm not saying that it > works or suggesting to include it right away, I only want to show what > *might* be matter of discussion. Nice. Thanks for the patch. That is actually very similar to what I've done in my experiments. But, I was also trying to get it to work on x86 and x86-64, where the relative position does matter. The x86/x86-64 code is where I got confused about the math in the assembler modules. >> Also, I wonder how important it is to keep the 1-bit math code? > > Look at it as insurance. The moment they come and say table-driven > approach is no-go, we have 1-bit code to switch to. Understood. Thanks a ton! Cheers, Brian -- https://briansmith.org/ From brian at briansmith.org Wed Jun 8 12:11:14 2016 From: brian at briansmith.org (Brian Smith) Date: Wed, 8 Jun 2016 02:11:14 -1000 Subject: [openssl-dev] Notes on stitched AESNI-GCM implementation details Message-ID: In the course of reviewing the code for the stitched AESNI-GCM code, a group of people found it difficult to understand some aspects of how the code works. After spending some time studying the code, I wrote these notes: https://boringssl.googlesource.com/boringssl/+/2477adcf6236c3040a291ad1bfd53f525e1af96d%5E%21/ Feel free to incorporate these notes into OpenSSL if you find them useful. Cheers, Brian -- https://briansmith.org/ From rsalz at akamai.com Wed Jun 8 13:54:01 2016 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 8 Jun 2016 13:54:01 +0000 Subject: [openssl-dev] Making assembly language optimizations working onCortex-M3 In-Reply-To: References: <55C4DC74.6060900@openssl.org> <55C873B8.9060602@openssl.org> <56056D20.9020806@openssl.org> <56b00a41-ed5f-4998-b0fb-55a6a39e4544@openssl.org> <738e4039-092b-9a64-01b6-c60aab0a5769@openssl.org> Message-ID: <083b7a6689f346d98216b4dd47762076@usma1ex-dag1mb1.msg.corp.akamai.com> > That's usually true, but the topic of this thread is about how to get OpenSSL working well on Cortex-M microcontrollers. In those situations, we cannot really afford the dynamic detection or the many different implementations of the same algorithm to exist in the final image. Other trade-offs to consider are the work involved and the ongoing maintenance, and to make sure that no other platforms become "pessimized." You know guys know this, but want to make it explicit to the list. From rt at openssl.org Wed Jun 8 16:02:39 2016 From: rt at openssl.org (Matt Caswell via RT) Date: Wed, 08 Jun 2016 16:02:39 +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: References: <56C9C1CC.50406@kippdata.de> Message-ID: On Tue May 24 13:53:07 2016, steve wrote: > On Sun Feb 21 13:55:35 2016, rainer.jung at kippdata.de wrote: > > Running the Apache test suite for Apache 2.4 with OpenSSL 1.1.0 > > adjustments, I get > > > > Can you please check to see if this issue is still present in the latest > OpenSSL 1.1.0? Hi Rainer Can this ticket be closed now? Matt -- 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 Wed Jun 8 16:04:28 2016 From: rt at openssl.org (Matt Caswell via RT) Date: Wed, 08 Jun 2016 16:04:28 +0000 Subject: [openssl-dev] [openssl.org #4434] Gentoo 13, x86_64: 4 failed self tests In-Reply-To: References: Message-ID: On Wed Jun 01 22:20:38 2016, matt wrote: > Hi Jeff > > Please could you try the attached patch? Any update on this? Thanks Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4434 Please log in as guest with password guest if prompted From rt at openssl.org Wed Jun 8 22:09:02 2016 From: rt at openssl.org (Matt Caswell via RT) Date: Wed, 08 Jun 2016 22:09:02 +0000 Subject: [openssl-dev] [openssl.org #4480] Ubuntu 14 (x86_64): Compile errors and warnings when using "no-asm -ansi" In-Reply-To: References: Message-ID: I applied the original roll up patch. I wasn't keen on adding all the __STRICT_ANSI__ ifdefs from the later patch. That seems excessive to me for little benefit - we are generally trying to reduce the ifdef code as much as possible. I also didn't add the __WORDSIZE bit. I believe that symbol is an internal compiler symbol and shouldn't be used. Closing this ticket. Thanks for the patch. Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4480 Please log in as guest with password guest if prompted From rt at openssl.org Wed Jun 8 22:09:33 2016 From: rt at openssl.org (Matt Caswell via RT) Date: Wed, 08 Jun 2016 22:09:33 +0000 Subject: [openssl-dev] [openssl.org #4479] OS X 10.8 (x86_64): Compile errors when using "no-asm -ansi" In-Reply-To: References: Message-ID: Status as per ticket 4480. Closing this ticket. Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4479 Please log in as guest with password guest if prompted From rt at openssl.org Wed Jun 8 22:23:27 2016 From: rt at openssl.org (Matt Caswell via RT) Date: Wed, 08 Jun 2016 22:23:27 +0000 Subject: [openssl-dev] [openssl.org #4456] Fedora 1, i386: error: field `next_timeout` has incomplete type In-Reply-To: References: Message-ID: On Tue May 31 16:49:23 2016, rsalz wrote: > Re-Ping Jeff to take a look and see if things are fixed now. Ping Jeff. Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4456 Please log in as guest with password guest if prompted From rt at openssl.org Thu Jun 9 22:00:46 2016 From: rt at openssl.org (=?UTF-8?B?RW1pbGlhIEvDpHNwZXI=?= via RT) Date: Thu, 09 Jun 2016 22:00:46 +0000 Subject: [openssl-dev] [openssl.org #4242] OpenSSL ECC coordinate functions accept invalid curve points In-Reply-To: <20160115123059.2bf5ae32@pc1> References: <20160115123059.2bf5ae32@pc1> Message-ID: Done in 1e2012b7ff4a5f12273446b281775faa5c8a1858, thanks for the nudge. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4242 Please log in as guest with password guest if prompted From rt at openssl.org Thu Jun 9 22:16:02 2016 From: rt at openssl.org (Matt Caswell via RT) Date: Thu, 09 Jun 2016 22:16:02 +0000 Subject: [openssl-dev] [openssl.org #4561] BUG: openssl-1.0.2h, evp_enc.c, non-portable bitwise operation In-Reply-To: References: Message-ID: On Mon Jun 06 18:26:50 2016, loic.etienne at qnective.com wrote: > crypto/evp/evp_enc.c, EVP_EncryptUpdate > line 337: inl & (ctx->block_mask) > line 367: inl & (bl - 1) /* with bl = ctx->cipher->block_size */ Why do you consider this a problem? Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4561 Please log in as guest with password guest if prompted From rt at openssl.org Thu Jun 9 22:42:24 2016 From: rt at openssl.org (Matt Caswell via RT) Date: Thu, 09 Jun 2016 22:42:24 +0000 Subject: [openssl-dev] [openssl.org #3720] Patch for "Increment SSL session miss counter appropriately" In-Reply-To: References: Message-ID: Patch applied - thanks. Closing. Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3720 Please log in as guest with password guest if prompted From brian at briansmith.org Fri Jun 10 00:09:35 2016 From: brian at briansmith.org (Brian Smith) Date: Thu, 9 Jun 2016 14:09:35 -1000 Subject: [openssl-dev] Stitched AES-NI AES-GCM code & AVX2 Message-ID: Hi, I see that the stitched AES-NI AES-GCM code will be used if : gctx->ctr==aesni_ctr32_encrypt_blocks && \ gctx->gcm.ghash==gcm_ghash_avx) In gcm128, I see that it decides to use gcm_ghash_avx if: /* AVX+MOVBE */ if (((OPENSSL_ia32cap_P[1] >> 22) & 0x41) == 0x41) { But, I think the stitched AES-NI AES-GCM code requires AVX2, not just AVX. So, I think that to condition to execute the stitched code should be changed to also test the AVX2 flag. Maybe in practice there are no processors that have AVX and MOVBE but which don't have AVX2. But, better safe than sorry. Cheers, Brian -- https://briansmith.org/ From ben at links.org Fri Jun 10 08:29:40 2016 From: ben at links.org (Ben Laurie) Date: Fri, 10 Jun 2016 09:29:40 +0100 Subject: [openssl-dev] Out-of-tree build? Message-ID: If I try to do one, I get: WARNING: there are indications that another build was made in the source directory. This build may have picked up artifacts from that build, the safest course of action is to clean the source directory and redo this configuration. even though I have just done make clean in the source directory. From matt.hart at hotmail.co.uk Fri Jun 10 09:00:02 2016 From: matt.hart at hotmail.co.uk (Matt Hart) Date: Fri, 10 Jun 2016 02:00:02 -0700 (MST) Subject: [openssl-dev] CNG support for OpenSSL CAPI Engine In-Reply-To: <1463561176095-66193.post@n7.nabble.com> References: <1463561176095-66193.post@n7.nabble.com> Message-ID: <1465549202357-66604.post@n7.nabble.com> Hi, I took the CAPI engine and extended it to give preference to NCrypt, otherwise to revert to Crypto API. Implemented for RSA so far (no DSA or ECC support though BoringSSL have done some ECC work for Windows I could look at). Tested with RSA, on CNG and on Crypto API based systems. I tried to make unintrusive changes in CAPI: a) Extended CAPI_KEY struct to include NCrypt handle support. b) capi_get_pkey - NCrypt support for reading an RSA public key blob and extracting algorithm ids. c) capi_rsa_sign - NCrypt support. Easier for NCrypt, just one call as NCrypt signature is big endian. d) capi_get_key_CNG: new function that prefers to acquire a CNG style handle via CryptAcquireCertificatePrivateKey. e) capi_get_key_cert: Invokes capi_get_key_CNG(). If that fails reverts to original code to acquire a Crypto handle. [Note: NCrypt calls are only invoked if CryptAcquireCertificatePrivateKey returned an NCrypt handle which can never happen on Windows XP or Windows Srver 2003. So no need to wrap NCrypt calls in GetModuleHandle/GetProcAddress helper code aka BoringSSL style]. Apologies for my ignorance but what's the process submitting code to OpenSSL for consideration? Matt -- View this message in context: http://openssl.6102.n7.nabble.com/CNG-support-for-OpenSSL-CAPI-Engine-tp66193p66604.html Sent from the OpenSSL - Dev mailing list archive at Nabble.com. From matt at openssl.org Fri Jun 10 10:12:28 2016 From: matt at openssl.org (Matt Caswell) Date: Fri, 10 Jun 2016 11:12:28 +0100 Subject: [openssl-dev] CNG support for OpenSSL CAPI Engine In-Reply-To: <1465549202357-66604.post@n7.nabble.com> References: <1463561176095-66193.post@n7.nabble.com> <1465549202357-66604.post@n7.nabble.com> Message-ID: <575A928C.7050906@openssl.org> On 10/06/16 10:00, Matt Hart wrote: > Hi, > > I took the CAPI engine and extended it to give preference to NCrypt, > otherwise to revert to Crypto API. Implemented for RSA so far (no DSA or ECC > support though BoringSSL have done some ECC work for Windows I could look > at). Tested with RSA, on CNG and on Crypto API based systems. I tried to > make unintrusive changes in CAPI: > > a) Extended CAPI_KEY struct to include NCrypt handle support. > b) capi_get_pkey - NCrypt support for reading an RSA public key blob and > extracting algorithm ids. > c) capi_rsa_sign - NCrypt support. Easier for NCrypt, just one call as > NCrypt signature is big endian. > d) capi_get_key_CNG: new function that prefers to acquire a CNG style handle > via CryptAcquireCertificatePrivateKey. > e) capi_get_key_cert: Invokes capi_get_key_CNG(). If that fails reverts to > original code to acquire a Crypto handle. > > [Note: NCrypt calls are only invoked if CryptAcquireCertificatePrivateKey > returned an NCrypt handle which can never happen on Windows XP or Windows > Srver 2003. So no need to wrap NCrypt calls in > GetModuleHandle/GetProcAddress helper code aka BoringSSL style]. > > Apologies for my ignorance but what's the process submitting code to OpenSSL > for consideration? Sounds interesting! The process is documented here: https://github.com/openssl/openssl/blob/master/CONTRIBUTING Note that this file has been updated recently, so use the very latest master version above. A small word of warning: the team is fully focussed on the 1.1.0 release at the moment. That release is in feature freeze so your patch won't be considered for that. It's unlikely your patch will receive much attention until we're passed the 1.1.0 release. Matt From levitte at openssl.org Fri Jun 10 10:27:30 2016 From: levitte at openssl.org (Richard Levitte) Date: Fri, 10 Jun 2016 12:27:30 +0200 (CEST) Subject: [openssl-dev] Out-of-tree build? In-Reply-To: References: Message-ID: <20160610.122730.1309125281390986138.levitte@openssl.org> In message on Fri, 10 Jun 2016 09:29:40 +0100, Ben Laurie said: ben> If I try to do one, I get: ben> ben> WARNING: there are indications that another build was made in the source ben> directory. This build may have picked up artifacts from that build, the ben> safest course of action is to clean the source directory and redo this ben> configuration. ben> ben> even though I have just done make clean in the source directory. 'make clean' doesn't remove everything (it doesn't remove stuff produced by Configure), 'git clean -dfx' removes the last vestiges. It's possible that we'd do well with a 'make distclean' Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From rt at openssl.org Fri Jun 10 13:02:57 2016 From: rt at openssl.org (Alexander Zaika via RT) Date: Fri, 10 Jun 2016 13:02:57 +0000 Subject: [openssl-dev] [openssl.org #4562] Possible bug in OPENSSL_config - ignore input parameter In-Reply-To: <575A9CAB.2080500@ua7.net> References: <575A9CAB.2080500@ua7.net> Message-ID: Hello Looks like OPENSSL_config have a bug as result users can't set alternative path to openssl.cnf file. If you take a look on implementation of void OPENSSL_config(const char *config_name) it call a CONF_modules_load_file(NULL, config_name, CONF_MFLAGS_DEFAULT_SECTION | CONF_MFLAGS_IGNORE_MISSING_FILE); As you can see "config_name" put to "CONF_modules_load_file" as second argument, but if you take a look on: int CONF_modules_load_file(const char *filename, const char *appname, unsigned long flags) Looks like CONF_modules_load_file expected config file name as FIRST argument (instead of second). Best Regards Alex -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4562 Please log in as guest with password guest if prompted From dkg at fifthhorseman.net Fri Jun 10 13:58:31 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 10 Jun 2016 09:58:31 -0400 Subject: [openssl-dev] Out-of-tree build? In-Reply-To: <20160610.122730.1309125281390986138.levitte@openssl.org> References: <20160610.122730.1309125281390986138.levitte@openssl.org> Message-ID: <87k2hxb0xk.fsf@alice.fifthhorseman.net> On Fri 2016-06-10 06:27:30 -0400, Richard Levitte wrote: > 'make clean' doesn't remove everything (it doesn't remove stuff > produced by Configure), 'git clean -dfx' removes the last vestiges. > > It's possible that we'd do well with a 'make distclean' yes, please! For systems that build from distributed tarballs, "git clean" isn't really an option. --dkg From rt at openssl.org Fri Jun 10 14:51:29 2016 From: rt at openssl.org (Matt Caswell via RT) Date: Fri, 10 Jun 2016 14:51:29 +0000 Subject: [openssl-dev] [openssl.org #1051] SSL_CTX_set_default_paths In-Reply-To: References: Message-ID: Fixed in f5de06aae. Closing. Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=1051 Please log in as guest with password guest if prompted From rt at openssl.org Fri Jun 10 16:37:44 2016 From: rt at openssl.org (Matt Caswell via RT) Date: Fri, 10 Jun 2016 16:37:44 +0000 Subject: [openssl-dev] [openssl.org #4562] Possible bug in OPENSSL_config - ignore input parameter In-Reply-To: <575A9CAB.2080500@ua7.net> References: <575A9CAB.2080500@ua7.net> Message-ID: On Fri Jun 10 13:02:57 2016, zaz at ua7.net wrote: > Hello > > Looks like OPENSSL_config have a bug as result users can't set > alternative path to openssl.cnf file. > If you take a look on implementation of void OPENSSL_config(const char > *config_name) it call a > CONF_modules_load_file(NULL, config_name, CONF_MFLAGS_DEFAULT_SECTION | > CONF_MFLAGS_IGNORE_MISSING_FILE); > As you can see "config_name" put to "CONF_modules_load_file" as second > argument, but if you take a look on: > int CONF_modules_load_file(const char *filename, const char *appname, > unsigned long flags) > > Looks like CONF_modules_load_file expected config file name as FIRST > argument (instead of second). This actually looks to me like a documentation error. The parameter to OPENSSL_config() is not *intended* to be a filename at all - it has never worked that way, and if you read the original commit messages you can see that was never the intention (it is the application name within the config file). The original documentation was a little unclear, but never actually said that it was a filename. It then got "cleaned up" in commit 14d3b76be to what it is now (which is wrong). So, I think the actual fix is to correct the documentation. We should also probably make it more obvious that it is deprecated in 1.1.0 (it does say it on the page but you have to read half of it before you realise). Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4562 Please log in as guest with password guest if prompted From rt at openssl.org Fri Jun 10 18:27:24 2016 From: rt at openssl.org (Rich Salz via RT) Date: Fri, 10 Jun 2016 18:27:24 +0000 Subject: [openssl-dev] [openssl.org #2461] Windows: Crypto DllMain() invokes getenv() CRT function In-Reply-To: <1607359977.200109.1298714274543.JavaMail.mail@webmail04> References: <6271EDAEBD5248338978851A69379610@IANLAPTOP> <1685732330.196419.1298670612211.JavaMail.mail@webmail04> <281C4EEAC2C842D0B55135314F6C7152@IANLAPTOP> <564444028.196521.1298671225100.JavaMail.mail@webmail04> <1607359977.200109.1298714274543.JavaMail.mail@webmail04> Message-ID: commit 84af71a916d0bfce4dde135e4a5fe60d75f4940c Author: Richard Levitte Date: Tue Mar 29 16:48:02 2016 +0200 Break out DllMain from crypto/cryptlib.c and use it in shared libs only Reviewed-by: Andy Polyakov -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2461 Please log in as guest with password guest if prompted From rt at openssl.org Fri Jun 10 18:35:05 2016 From: rt at openssl.org (Rich Salz via RT) Date: Fri, 10 Jun 2016 18:35:05 +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: Look at the undocumented functions CRYPTO_cts128_decrypt, CRYPTO_cts128_encrypt, CRYPTO_cts128_decrypt_block CRYPTO_cts128_encrypt_block. Do they do what's needed? -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=1482 Please log in as guest with password guest if prompted From rt at openssl.org Fri Jun 10 18:37:31 2016 From: rt at openssl.org (Rich Salz via RT) Date: Fri, 10 Jun 2016 18:37:31 +0000 Subject: [openssl-dev] [openssl.org #2750] [BUG] spec file doesn't properly build for lib64 In-Reply-To: <1330735041.91092.YahooMailNeo@web112612.mail.gq1.yahoo.com> References: <1330735041.91092.YahooMailNeo@web112612.mail.gq1.yahoo.com> Message-ID: Removed the .spec file from master. :) -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2750 Please log in as guest with password guest if prompted From rt at openssl.org Fri Jun 10 18:48:21 2016 From: rt at openssl.org (Rich Salz via RT) Date: Fri, 10 Jun 2016 18:48:21 +0000 Subject: [openssl-dev] [openssl.org #2216] OBJ_NAME_* and EVP_PBE_*interfaces are not MT-safe In-Reply-To: <4BB49820.7070005@Sun.COM> References: <4BB49820.7070005@Sun.COM> Message-ID: Yes, those API's cannot be called simultaneously from multiple threads. Closing ticket. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2216 Please log in as guest with password guest if prompted From rt at openssl.org Fri Jun 10 18:50:47 2016 From: rt at openssl.org (Rich Salz via RT) Date: Fri, 10 Jun 2016 18:50:47 +0000 Subject: [openssl-dev] [openssl.org #2760] possible bug report: DSA_verify() doesn't correctly account for len In-Reply-To: <6218EBA14241FD40A4094C1C4F45E5CD38F2461731@SYNC.rti.com> References: <6218EBA14241FD40A4094C1C4F45E5CD38F2461731@SYNC.rti.com> Message-ID: The documentation was fixed some time ago. The "type" param to DSS_sign and DSS_verify is ignored. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2760 Please log in as guest with password guest if prompted From rt at openssl.org Fri Jun 10 18:58:41 2016 From: rt at openssl.org (Rich Salz via RT) Date: Fri, 10 Jun 2016 18:58:41 +0000 Subject: [openssl-dev] [openssl.org #2782] BUG report: RSA private key serializer In-Reply-To: References: Message-ID: There is no bug here. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2782 Please log in as guest with password guest if prompted From rt at openssl.org Fri Jun 10 19:39:13 2016 From: rt at openssl.org (Rich Salz via RT) Date: Fri, 10 Jun 2016 19:39:13 +0000 Subject: [openssl-dev] [openssl.org #4467] SSL_Connect crashed In-Reply-To: References: Message-ID: Any update on this, or can/should we close this ticket? -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4467 Please log in as guest with password guest if prompted From rt at openssl.org Fri Jun 10 19:42:39 2016 From: rt at openssl.org (Rich Salz via RT) Date: Fri, 10 Jun 2016 19:42:39 +0000 Subject: [openssl-dev] [openssl.org #4523] Failure - make test In-Reply-To: References: Message-ID: Local environment issue; closing ticket. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4523 Please log in as guest with password guest if prompted From rt at openssl.org Fri Jun 10 19:43:30 2016 From: rt at openssl.org (Rich Salz via RT) Date: Fri, 10 Jun 2016 19:43:30 +0000 Subject: [openssl-dev] [openssl.org #4545] Crash in crypto/rand/md_rand.c In-Reply-To: References: Message-ID: Can you test against a recent master, it has some rand bugfixes that might address this. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4545 Please log in as guest with password guest if prompted From rt at openssl.org Fri Jun 10 19:53:17 2016 From: rt at openssl.org (Rich Salz via RT) Date: Fri, 10 Jun 2016 19:53:17 +0000 Subject: [openssl-dev] [openssl.org #2758] Bug in use of CRYPTO_ex_data In-Reply-To: <1871084491.842.1331335547676.JavaMail.mtrx@yhhb27> References: <1871084491.842.1331335547676.JavaMail.mtrx@yhhb27> Message-ID: The code is correct; void* can be cast to anything, including void**. It's up to the dup function to do the right thing. Just like the compar parameter to qsort :) -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2758 Please log in as guest with password guest if prompted From appro at openssl.org Sat Jun 11 17:08:31 2016 From: appro at openssl.org (Andy Polyakov) Date: Sat, 11 Jun 2016 19:08:31 +0200 Subject: [openssl-dev] Removing gcm128_context->H for non-1-bit builds In-Reply-To: References: <5757F628.7090107@openssl.org> Message-ID: <575C458F.6020008@openssl.org> >>> Could somebody adjust who understand the assembly code (probably Andy) >>> modify it to use symbolic names for the offsets that are used to >>> access Xi, H, Htable? If so, then I can write the patch to >>> conditionally exclude `H` on platforms that don't need it after >>> `CRYPTO_gcm128_init` finishes executing. > >> But going the >> line of taking into consideration all corner cases is a stretch and >> should be weighed against 16 out of ~380[!] bytes waste. I'd say it's >> not worth it. > > I see it both as an *optimization* and also a way to ensure > *correctness*. In particular, if the code doesn't expect H to be there > in configurations that don't use H, then some tricks that people might > use (in particular, a trick I am using) becomes safer. > > In particular, notice that in the gcm128_context structure, there are > three kinds of state (again, only talking about non-s390x, non-1-bit > platforms): > > 1. State that is only used in the _init function: H. > > 2. State that needs to be preserved in between > authenticated-and-encrypted messages. This is `Htable`, `EK0`, > `gmult`, `ghash`, `block`, etc. > > 3. State that needs to be preserved only between the time you start an > authenticated-and-encrypted message and the time you end it. This > includes `len`, `EKi`, `mres`, `ares`, etc. currently. In theory this > could also include `gmult`, `ghash` and `block`, if the code were > refactored to recomputed them for each message and/or if things like > the OPENSSL_STATIC_ARMCAP-type optimization allowed one to omit them > from the structure completely in some configurations where there is no > way they could vary at runtime. Also, Htable is 256 bytes on its own > (on the platforms I care about), but actually in some > platforms/configurations not all of Htable is used. > > In my code, after I call the _init function, I extract out all the > numbers in category #2 and store them in my per-connection context > structure on. Then, when I need to encrypt/decrypt a message, I > construct a full gcm128_context *on the stack*, zero it out, and then > fill in the values from category #2. Then I encrypt/decrypt the > message, and then throw away the gcm128_context. In other words we *are* talking about super-custom code with very special needs. As already mentioned, it would be next to impossible to justify customization of OpenSSL to accommodate overly specific requirements. And given above description it shouldn't be actually needed, not even previously posted patch facilitating omission of H should be required. I mean given knowledge about cases when H is not used, you can omit it from your compressed state and leave it zeroed on stack, right? *Or* [given that memory is seemingly at premium] you can choose to preserve H in your private structure, omit Htable[!] and initialize the latter in on-stack structure on per-call basis, per call to *your* super-custom subroutine that is. But in case you choose to omit H, here is "manifest". With exception for s390x and c64xplus none of the modes/asm/ghash-*.pl modules use H or are even dependent on relative position of Xi, H and Htable. s390x module depends on relative position of H and Htable and does use both. c64xplus module is dependent on relative position of H and Htable but uses H alone, i.e. Htable is not used at all and space is wasted. Then there is modes/asm/aesni-gcm-x86_64.pl, which does rely on relative position of all three fields, Xi, H and Htable (offsets relative Xi are hard-coded), but it does not use H. It might be appropriate to mention that *historically* modes/adm/ghash-armv4.pl *was* dependent on relative position of H and Htable and was using H alone in NEON code path, but not anymore. From appro at openssl.org Sat Jun 11 19:38:50 2016 From: appro at openssl.org (Andy Polyakov) Date: Sat, 11 Jun 2016 21:38:50 +0200 Subject: [openssl-dev] Stitched AES-NI AES-GCM code & AVX2 In-Reply-To: References: Message-ID: <861ab26c-50c0-17f6-52f2-9e21ea1791fa@openssl.org> Hi, > I see that the stitched AES-NI AES-GCM code will be used if : > > gctx->ctr==aesni_ctr32_encrypt_blocks && \ > gctx->gcm.ghash==gcm_ghash_avx) > > In gcm128, I see that it decides to use gcm_ghash_avx if: > > /* AVX+MOVBE */ > if (((OPENSSL_ia32cap_P[1] >> 22) & 0x41) == 0x41) { > > But, I think the stitched AES-NI AES-GCM code requires AVX2, not just > AVX. No, it doesn't. It requires exactly AVX+MOVBE. > Maybe in practice there are no processors that have AVX and MOVBE but > which don't have AVX2. But, better safe than sorry. While this is the case in practice, there are no AVX2 instructions in aesni-gcm-x86_64 module, check for CPU capabilities is correct. For reference, simplest way to verify this is to run xed from Intel SDE, which disassembles object files annotating each instruction by ISA extension. From brian at briansmith.org Sat Jun 11 19:44:38 2016 From: brian at briansmith.org (Brian Smith) Date: Sat, 11 Jun 2016 09:44:38 -1000 Subject: [openssl-dev] Stitched AES-NI AES-GCM code & AVX2 In-Reply-To: <861ab26c-50c0-17f6-52f2-9e21ea1791fa@openssl.org> References: <861ab26c-50c0-17f6-52f2-9e21ea1791fa@openssl.org> Message-ID: Andy Polyakov wrote: >> But, I think the stitched AES-NI AES-GCM code requires AVX2, not just >> AVX. > > No, it doesn't. It requires exactly AVX+MOVBE. I see. I was confused because the code says: if ($avx>1) {{{ I had been thinking the whole time that "$avx > 1" means that AVX2 is required. Thanks for the correction. Cheers, Brian From brian at briansmith.org Sat Jun 11 19:54:39 2016 From: brian at briansmith.org (Brian Smith) Date: Sat, 11 Jun 2016 09:54:39 -1000 Subject: [openssl-dev] Removing gcm128_context->H for non-1-bit builds In-Reply-To: <575C458F.6020008@openssl.org> References: <5757F628.7090107@openssl.org> <575C458F.6020008@openssl.org> Message-ID: Andy Polyakov wrote: > In other words we *are* talking about super-custom code with very > special needs. As already mentioned, it would be next to impossible to > justify customization of OpenSSL to accommodate overly specific > requirements. And given above description it shouldn't be actually > needed, not even previously posted patch facilitating omission of H > should be required. I mean given knowledge about cases when H is not > used, you can omit it from your compressed state and leave it zeroed on > stack, right? *Or* [given that memory is seemingly at premium] you can > choose to preserve H in your private structure, omit Htable[!] and > initialize the latter in on-stack structure on per-call basis, per call > to *your* super-custom subroutine that is. Yes. Or, one could even through away everything in the GCM context and restart everything from the raw key, which would make it more like the Poly1305 code. > But in case you choose to omit H, here is "manifest". Thanks! That is very helpful. Cheers, Brian From appro at openssl.org Sat Jun 11 20:11:22 2016 From: appro at openssl.org (Andy Polyakov) Date: Sat, 11 Jun 2016 22:11:22 +0200 Subject: [openssl-dev] Stitched AES-NI AES-GCM code & AVX2 In-Reply-To: References: <861ab26c-50c0-17f6-52f2-9e21ea1791fa@openssl.org> Message-ID: <8f7f84ec-d833-f7c0-4db9-d88a7fbc5eb5@openssl.org> >>> But, I think the stitched AES-NI AES-GCM code requires AVX2, not just >>> AVX. >> >> No, it doesn't. It requires exactly AVX+MOVBE. > > I see. I was confused because the code says: > > if ($avx>1) {{{ > > I had been thinking the whole time that "$avx > 1" means that AVX2 is required. There is certain heuristics to whole thing. 'if ($avx>1)', it's used because it *happens* to work. Look at it as "support for MOVBE was *incidentally* added at same time as for AVX2 to *assembler*". [Well, it still might a bug, i.e. it could have been 'if ($avx)'.] From rt at openssl.org Sat Jun 11 23:47:27 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sat, 11 Jun 2016 23:47:27 +0000 Subject: [openssl-dev] [openssl.org #3078] Makefile: install rule builds components In-Reply-To: References: Message-ID: fixed in 1.1. Not fixing in 1.0.2 -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3078 Please log in as guest with password guest if prompted From rt at openssl.org Sat Jun 11 23:50:23 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sat, 11 Jun 2016 23:50:23 +0000 Subject: [openssl-dev] [openssl.org #3864] OS390 Bug: Make fails In-Reply-To: References: Message-ID: os390 builds work in 1.1 not backporting fix as it's a new build system. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3864 Please log in as guest with password guest if prompted From rt at openssl.org Sat Jun 11 23:51:56 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sat, 11 Jun 2016 23:51:56 +0000 Subject: [openssl-dev] [openssl.org #3819] make openssl-1.0.2a failed on Solaris 10 i86pc In-Reply-To: References: Message-ID: No reply to suggested patch, old system, closing ticket. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3819 Please log in as guest with password guest if prompted From rt at openssl.org Sat Jun 11 23:53:54 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sat, 11 Jun 2016 23:53:54 +0000 Subject: [openssl-dev] [openssl.org #3091] ms\ntdll.mak bug In-Reply-To: References: Message-ID: fixed (if it was an error) with new build system for 1.1 closing ticket. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3091 Please log in as guest with password guest if prompted From rt at openssl.org Sat Jun 11 23:57:36 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sat, 11 Jun 2016 23:57:36 +0000 Subject: [openssl-dev] [openssl.org #3105] [PATCH] config matches OUT with full os/compiler line In-Reply-To: References: Message-ID: Believe fixed in 1.1 with new build system. Please re-open if not. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3105 Please log in as guest with password guest if prompted From rt at openssl.org Sat Jun 11 23:58:44 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sat, 11 Jun 2016 23:58:44 +0000 Subject: [openssl-dev] [openssl.org #3099] bug report In-Reply-To: References: Message-ID: cannot reproduce this, closing ticket. please re-open if still an issue. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3099 Please log in as guest with password guest if prompted From rt at openssl.org Sun Jun 12 00:00:33 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 12 Jun 2016 00:00:33 +0000 Subject: [openssl-dev] [openssl.org #3163] [PATCH] DSTU-4145-2002 engine implementation In-Reply-To: References: Message-ID: Closing this. Waiting for PR with the new OID's that are needed for the external engine. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3163 Please log in as guest with password guest if prompted From rt at openssl.org Sun Jun 12 01:12:35 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 12 Jun 2016 01:12:35 +0000 Subject: [openssl-dev] [openssl.org #3231] default ciphers include insecure export cipher suites In-Reply-To: References: Message-ID: So LOW is now empty, and medium shows only 128/168 bit ciphers and DEFAULT shows nothing smaller than 128. Closing this. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3231 Please log in as guest with password guest if prompted From rt at openssl.org Sun Jun 12 01:14:06 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 12 Jun 2016 01:14:06 +0000 Subject: [openssl-dev] [openssl.org #3458] PATCH: ensure debug builds with GCC include -g3 -ggdb In-Reply-To: References: Message-ID: I believe this is fixed in master; "./config -d" adds the right debug flags. Please re-open if not. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3458 Please log in as guest with password guest if prompted From rt at openssl.org Sun Jun 12 11:55:43 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 12 Jun 2016 11:55:43 +0000 Subject: [openssl-dev] [openssl.org #3053] [PATCH] Check for null pointer in cms envelopedData In-Reply-To: References: Message-ID: OpenSSL_1_0_2-stable 63b2499 RT3053: Check for NULL before dereferencing master 6b36028 RT3053: Check for NULL before dereferencing Author: Phillip Hellewell Date: Sat Jun 11 20:04:21 2016 -0400 RT3053: Check for NULL before dereferencing Reviewed-by: Tim Hudson -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3053 Please log in as guest with password guest if prompted From rt at openssl.org Sun Jun 12 12:46:25 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 12 Jun 2016 12:46:25 +0000 Subject: [openssl-dev] [openssl.org #4022] Support for RFC 6066 in OpenSSL In-Reply-To: References: Message-ID: Duplicate of RT 3591 -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4022 Please log in as guest with password guest if prompted From rt at openssl.org Sun Jun 12 12:49:19 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 12 Jun 2016 12:49:19 +0000 Subject: [openssl-dev] [openssl.org #2749] SSL_shutdown() doesn't need to ever return 0 In-Reply-To: <4F511FE4.5030704@proofpoint.com> References: <4F511FE4.5030704@proofpoint.com> Message-ID: It could return zero, even if now it doesn't and I'm not sure that's true. Closing ticket. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2749 Please log in as guest with password guest if prompted From rt at openssl.org Sun Jun 12 12:52:08 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 12 Jun 2016 12:52:08 +0000 Subject: [openssl-dev] [openssl.org #2823] Bug: FTBFS compiling openssl 1.01c with musl libc In-Reply-To: <20120521231900.72a65231@newbook> References: <20120521231900.72a65231@newbook> Message-ID: 1.0.1 only gets security fixes. If this is still an issue with 1.0.2 or 1.1, please open a new issue. (Sorry it took so long to get around to looking at this.) -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2823 Please log in as guest with password guest if prompted From rt at openssl.org Sun Jun 12 12:55:02 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 12 Jun 2016 12:55:02 +0000 Subject: [openssl-dev] [openssl.org #2759] SSL_read / SSL_ERROR_WANT_READ / ENOTCONN infinite loop In-Reply-To: <4F4C2732.1050605@proofpoint.com> References: <4F4C2732.1050605@proofpoint.com> Message-ID: applied in master, commit a3ef2c16792ccbf65ef9861e0df6e7c277bcf770 thank you! -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2759 Please log in as guest with password guest if prompted From rt at openssl.org Sun Jun 12 12:56:31 2016 From: rt at openssl.org (Simon Richter via RT) Date: Sun, 12 Jun 2016 12:56:31 +0000 Subject: [openssl-dev] [openssl.org #4563] OpenSSL 1.0.2 branch: mem.obj : error LNK2001: unresolved external symbol _cleanse_ctr In-Reply-To: <575D5A24.4010309@hogyros.de> References: <575D5A24.4010309@hogyros.de> Message-ID: Hi, the 1.0.2 branch fails to compile in the VC-WIN32 configuration: mem.obj : error LNK2001: unresolved external symbol _cleanse_ctr Full log available at http://ci.kicad-pcb.org/job/windows-openssl-msvc/cpu=x86,label=windows/376/consoleFull Simon -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4563 Please log in as guest with password guest if prompted From rt at openssl.org Sun Jun 12 13:15:09 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 12 Jun 2016 13:15:09 +0000 Subject: [openssl-dev] [openssl.org #2650] major ssl read/ write performance improvement - updated In-Reply-To: <1323027674.14673.YahooMailNeo@web45413.mail.sp1.yahoo.com> References: <1323027674.14673.YahooMailNeo@web45413.mail.sp1.yahoo.com> Message-ID: Sorry it took so long to look at this. The code has changed significantly since then, including making the structures opaque. Please open a new ticker (or GitHub pull request) against current sources if this is still an issue. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2650 Please log in as guest with password guest if prompted From rt at openssl.org Sun Jun 12 13:21:05 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 12 Jun 2016 13:21:05 +0000 Subject: [openssl-dev] [openssl.org #3219] OpenSSL - AES in SSLv3. In-Reply-To: References: Message-ID: We are not going to fix this. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3219 Please log in as guest with password guest if prompted From rt at openssl.org Sun Jun 12 17:12:57 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 12 Jun 2016 17:12:57 +0000 Subject: [openssl-dev] [openssl.org #3171] integer undefined behaviors In-Reply-To: <52831A28.70504@cs.utah.edu> References: <52831A28.70504@cs.utah.edu> Message-ID: Already fixed. We use clang sanitizers often, but if you find other bugs like this, please open a new ticket. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3171 Please log in as guest with password guest if prompted From rt at openssl.org Sun Jun 12 17:19:13 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 12 Jun 2016 17:19:13 +0000 Subject: [openssl-dev] [openssl.org #3129] Openssl not clearing session ticket upon handshake failure In-Reply-To: <52374B10.3050408@proofpoint.com> References: <52374B10.3050408@proofpoint.com> Message-ID: This hasn't been shown to be repeatable, and it's not clear where the bug is. Closing the ticket. Sorry for taking so long to get around to this. Please open a new ticket if you can isolate the issue. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3129 Please log in as guest with password guest if prompted From rt at openssl.org Sun Jun 12 17:23:55 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 12 Jun 2016 17:23:55 +0000 Subject: [openssl-dev] [openssl.org #3215] [bug report] SSLv23 connection fails but SSLv3 works In-Reply-To: <20140106132658.3a36e42c2e66fa5e7f712ee8@aol.com> References: <20140106132658.3a36e42c2e66fa5e7f712ee8@aol.com> Message-ID: Sorry it has taken to long to review this. SSLv2 is dead and SSLv3 is strongly dis-recommended. Closing this ticket. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3215 Please log in as guest with password guest if prompted From rt at openssl.org Sun Jun 12 17:32:11 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 12 Jun 2016 17:32:11 +0000 Subject: [openssl-dev] [openssl.org #3236] support for DNSSEC in openssl In-Reply-To: <29DCC7A4-8586-427E-B844-0F0CB7DDB276@elstel.org> References: <29DCC7A4-8586-427E-B844-0F0CB7DDB276@elstel.org> Message-ID: There does not seem to be anything for OpenSSL to do here; it's about DNS libraries calling openssl to generate and/or verify signatures? -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3236 Please log in as guest with password guest if prompted From rt at openssl.org Sun Jun 12 17:38:38 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 12 Jun 2016 17:38:38 +0000 Subject: [openssl-dev] [openssl.org #3297] XXX_process_heartbeat() not checking return value of OPENSSL_malloc() In-Reply-To: References: Message-ID: As if that was the only bug :) Fixed. It's dtls-only now anway. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3297 Please log in as guest with password guest if prompted From rt at openssl.org Sun Jun 12 17:47:21 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 12 Jun 2016 17:47:21 +0000 Subject: [openssl-dev] [openssl.org #3424] Misaligned pointers for buffers cast to a size_t* In-Reply-To: References: Message-ID: it's online on the FAQ now. closing this ticket as documenting it was the only thing still to be done. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3424 Please log in as guest with password guest if prompted From rt at openssl.org Sun Jun 12 17:48:33 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 12 Jun 2016 17:48:33 +0000 Subject: [openssl-dev] [openssl.org #3550] patch In-Reply-To: References: Message-ID: seems to be user/environment error. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3550 Please log in as guest with password guest if prompted From rt at openssl.org Sun Jun 12 17:49:52 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 12 Jun 2016 17:49:52 +0000 Subject: [openssl-dev] [openssl.org #3528] [PATCH] ssl: SSL_MODE_ASYNC_KEY_EX In-Reply-To: References: Message-ID: async stuff is in master. please open new issue if there are problems with the implementation. -- 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 Sun Jun 12 17:51:30 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 12 Jun 2016 17:51:30 +0000 Subject: [openssl-dev] [openssl.org #3498] RE: AW: Platform query In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7185A846BA1@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7185A4D2FE8@USMBX1.msg.corp.akamai.com> <1XK8ol-25QoGO0@fwd30.aul.t-online.de> <53F5C434.9070207@free.fr> <2A0EFB9C05D0164E98F19BB0AF3708C7185A846BA1@USMBX1.msg.corp.akamai.com> Message-ID: WinCE is no longer supported. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3498 Please log in as guest with password guest if prompted From rt at openssl.org Sun Jun 12 18:11:29 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 12 Jun 2016 18:11:29 +0000 Subject: [openssl-dev] [openssl.org #3666] [PATCH] build with no-ts fails In-Reply-To: References: Message-ID: this was fixed some time ago. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3666 Please log in as guest with password guest if prompted From rt at openssl.org Sun Jun 12 18:14:56 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 12 Jun 2016 18:14:56 +0000 Subject: [openssl-dev] [openssl.org #3716] Patch for setting preferred cipher list In-Reply-To: <5CB97CA4-EABF-4C31-884D-82C30B93E396@akamai.com> References: <5CB97CA4-EABF-4C31-884D-82C30B93E396@akamai.com> Message-ID: Not doing this :) Neither should Akamai :) -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3716 Please log in as guest with password guest if prompted From rt at openssl.org Sun Jun 12 18:16:55 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 12 Jun 2016 18:16:55 +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: A change to openssl, not the fips canister, was described. no more fips work going on at this time. closing ticket. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3713 Please log in as guest with password guest if prompted From rt at openssl.org Sun Jun 12 18:18:33 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 12 Jun 2016 18:18:33 +0000 Subject: [openssl-dev] [openssl.org #3715] Possible bug in openssl 64 bit version In-Reply-To: References: Message-ID: The issue is that windows was re-writing the files when copied to different places depending on local environment settings. closing ticket. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3715 Please log in as guest with password guest if prompted From rt at openssl.org Sun Jun 12 18:21:32 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 12 Jun 2016 18:21:32 +0000 Subject: [openssl-dev] [openssl.org #3618] Authority Information Access support In-Reply-To: <201412010815.04303.arekm@maven.pl> References: <201412010815.04303.arekm@maven.pl> Message-ID: We are not going to fetch certs at run-time because of the i/o issues (mentioned in the ticket) and the security concerns. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3618 Please log in as guest with password guest if prompted From xoloki at gmail.com Sun Jun 12 19:44:20 2016 From: xoloki at gmail.com (Joey Yandle) Date: Sun, 12 Jun 2016 12:44:20 -0700 Subject: [openssl-dev] [openssl.org #4563] OpenSSL 1.0.2 branch: mem.obj : error LNK2001: unresolved external symbol _cleanse_ctr In-Reply-To: References: <575D5A24.4010309@hogyros.de> Message-ID: Looking over your logs, you appear to be configuring with no-asm, then calling do_ms. Does it work when you configure with asm and call do_nasm? The do_ms target doesn't get much attention these days. On Jun 12, 2016 5:56 AM, "Simon Richter via RT" wrote: > Hi, > > the 1.0.2 branch fails to compile in the VC-WIN32 configuration: > > mem.obj : error LNK2001: unresolved external symbol _cleanse_ctr > > Full log available at > > > http://ci.kicad-pcb.org/job/windows-openssl-msvc/cpu=x86,label=windows/376/consoleFull > > Simon > > > -- > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4563 > 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 Sun Jun 12 19:44:33 2016 From: rt at openssl.org (Joey Yandle via RT) Date: Sun, 12 Jun 2016 19:44:33 +0000 Subject: [openssl-dev] [openssl.org #4563] OpenSSL 1.0.2 branch: mem.obj : error LNK2001: unresolved external symbol _cleanse_ctr In-Reply-To: References: <575D5A24.4010309@hogyros.de> Message-ID: Looking over your logs, you appear to be configuring with no-asm, then calling do_ms. Does it work when you configure with asm and call do_nasm? The do_ms target doesn't get much attention these days. On Jun 12, 2016 5:56 AM, "Simon Richter via RT" wrote: > Hi, > > the 1.0.2 branch fails to compile in the VC-WIN32 configuration: > > mem.obj : error LNK2001: unresolved external symbol _cleanse_ctr > > Full log available at > > > http://ci.kicad-pcb.org/job/windows-openssl-msvc/cpu=x86,label=windows/376/consoleFull > > Simon > > > -- > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4563 > 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=4563 Please log in as guest with password guest if prompted From rt at openssl.org Sun Jun 12 19:52:35 2016 From: rt at openssl.org (Andy Polyakov via RT) Date: Sun, 12 Jun 2016 19:52:35 +0000 Subject: [openssl-dev] [openssl.org #4563] OpenSSL 1.0.2 branch: mem.obj : error LNK2001: unresolved external symbol _cleanse_ctr In-Reply-To: <09afbc74-ff3c-edbc-d5db-51d932910e3e@openssl.org> References: <575D5A24.4010309@hogyros.de> <09afbc74-ff3c-edbc-d5db-51d932910e3e@openssl.org> Message-ID: > Looking over your logs, you appear to be configuring with no-asm, "no-asm" is the culprit here, but problem is not reporter's but mine. mem_clr.c was updated, but build was not tested with no-asm. Fix is upcoming. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4563 Please log in as guest with password guest if prompted From rt at openssl.org Sun Jun 12 20:55:05 2016 From: rt at openssl.org (Elmar Stellnberger via RT) Date: Sun, 12 Jun 2016 20:55:05 +0000 Subject: [openssl-dev] [openssl.org #3236] support for DNSSEC in openssl In-Reply-To: <57aad5ab-1bfb-c792-e25c-88d480e014e8@elstel.org> References: <29DCC7A4-8586-427E-B844-0F0CB7DDB276@elstel.org> <57aad5ab-1bfb-c792-e25c-88d480e014e8@elstel.org> Message-ID: Hi; that of course does not make sense without additional DANE support; - that one of course needs to be implemented in OpenSSL. Am 2016-06-12 um 19:32 schrieb Rich Salz via RT: > There does not seem to be anything for OpenSSL to do here; it's about DNS > libraries calling openssl to generate and/or verify signatures? > -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3236 Please log in as guest with password guest if prompted From rt at openssl.org Sun Jun 12 21:10:39 2016 From: rt at openssl.org (Simon Richter via RT) Date: Sun, 12 Jun 2016 21:10:39 +0000 Subject: [openssl-dev] [openssl.org #4563] OpenSSL 1.0.2 branch: mem.obj : error LNK2001: unresolved external symbol _cleanse_ctr In-Reply-To: <575DCFBC.50401@hogyros.de> References: <575D5A24.4010309@hogyros.de> <575DCFBC.50401@hogyros.de> Message-ID: Hi, On 12.06.2016 21:44, Joey Yandle via RT wrote: > Looking over your logs, you appear to be configuring with no-asm, then > calling do_ms. Does it work when you configure with asm and call do_nasm? I'd have to deploy nasm to the autobuilders then. Simon -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4563 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: From rt at openssl.org Sun Jun 12 21:49:56 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 12 Jun 2016 21:49:56 +0000 Subject: [openssl-dev] [openssl.org #3236] support for DNSSEC in openssl In-Reply-To: <29DCC7A4-8586-427E-B844-0F0CB7DDB276@elstel.org> References: <29DCC7A4-8586-427E-B844-0F0CB7DDB276@elstel.org> Message-ID: And DANE support is in 1.1/master. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3236 Please log in as guest with password guest if prompted From rt at openssl.org Sun Jun 12 22:49:44 2016 From: rt at openssl.org (Simon Richter via RT) Date: Sun, 12 Jun 2016 22:49:44 +0000 Subject: [openssl-dev] [openssl.org #4563] OpenSSL 1.0.2 branch: mem.obj : error LNK2001: unresolved external symbol _cleanse_ctr In-Reply-To: <575DE6F9.7070501@hogyros.de> References: <575D5A24.4010309@hogyros.de> <09afbc74-ff3c-edbc-d5db-51d932910e3e@openssl.org> <575DE6F9.7070501@hogyros.de> Message-ID: Hi, On 12.06.2016 21:52, Andy Polyakov via RT wrote: > "no-asm" is the culprit here, but problem is not reporter's but mine. > mem_clr.c was updated, but build was not tested with no-asm. Fix is > upcoming. That error is gone, but now it complains about "_OPENSSL_hexstr2buf" being missing. Is that a related problem, or something else? Log: http://ci.kicad-pcb.org/job/windows-openssl-msvc/cpu=x86,label=windows/381/consoleFull Simon -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4563 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: From sshock at gmail.com Mon Jun 13 00:40:41 2016 From: sshock at gmail.com (Phillip Hellewell) Date: Sun, 12 Jun 2016 18:40:41 -0600 Subject: [openssl-dev] [openssl.org #3053] [PATCH] Check for null pointer in cms envelopedData In-Reply-To: References: Message-ID: Wow, only 3 years to apply the simplest patch you have ever seen. Well, better late than never... :) Phillip On Sun, Jun 12, 2016 at 5:55 AM, Rich Salz via RT wrote: > OpenSSL_1_0_2-stable 63b2499 RT3053: Check for NULL before dereferencing > > master 6b36028 RT3053: Check for NULL before dereferencing > > Author: Phillip Hellewell > Date: Sat Jun 11 20:04:21 2016 -0400 > > RT3053: Check for NULL before dereferencing > > Reviewed-by: Tim Hudson > > -- > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3053 > Please log in as guest with password guest if prompted > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Mon Jun 13 00:41:12 2016 From: rt at openssl.org (Phillip Hellewell via RT) Date: Mon, 13 Jun 2016 00:41:12 +0000 Subject: [openssl-dev] [openssl.org #3053] [PATCH] Check for null pointer in cms envelopedData In-Reply-To: References: Message-ID: Wow, only 3 years to apply the simplest patch you have ever seen. Well, better late than never... :) Phillip On Sun, Jun 12, 2016 at 5:55 AM, Rich Salz via RT wrote: > OpenSSL_1_0_2-stable 63b2499 RT3053: Check for NULL before dereferencing > > master 6b36028 RT3053: Check for NULL before dereferencing > > Author: Phillip Hellewell > Date: Sat Jun 11 20:04:21 2016 -0400 > > RT3053: Check for NULL before dereferencing > > Reviewed-by: Tim Hudson > > -- > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3053 > Please log in as guest with password guest if prompted > > -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3053 Please log in as guest with password guest if prompted From rt at openssl.org Mon Jun 13 01:32:48 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 13 Jun 2016 01:32:48 +0000 Subject: [openssl-dev] [openssl.org #4563] OpenSSL 1.0.2 branch: mem.obj : error LNK2001: unresolved external symbol _cleanse_ctr In-Reply-To: <575D5A24.4010309@hogyros.de> References: <575D5A24.4010309@hogyros.de> Message-ID: Fixed by Andy in commit 6397ac585d6d4101be0fb742ac0db5074bd4e8a6 -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4563 Please log in as guest with password guest if prompted From rt at openssl.org Mon Jun 13 02:06:16 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 13 Jun 2016 02:06:16 +0000 Subject: [openssl-dev] [openssl.org #3983] unresolved external (___iob_func) with 1.0.1p using VS2015 In-Reply-To: References: Message-ID: 1.0.1 is only getting security fixes. in this case, it appears that the source is too old to use with recent VS. Sorry. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3983 Please log in as guest with password guest if prompted From rt at openssl.org Mon Jun 13 02:10:49 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 13 Jun 2016 02:10:49 +0000 Subject: [openssl-dev] [openssl.org #3946] Enhancement request: Add support for RFC 5816 In-Reply-To: <544B0DD62A64C1448B2DA253C011414619231811EB@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> References: <544B0DD62A64C1448B2DA253C011414619231811EB@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> Message-ID: This is tracked in https://github.com/openssl/openssl/pull/771 and will happen after 1.1 -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3946 Please log in as guest with password guest if prompted From rt at openssl.org Mon Jun 13 02:26:59 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 13 Jun 2016 02:26:59 +0000 Subject: [openssl-dev] [openssl.org #3949] Bug: PKCS_final.7 not installed In-Reply-To: <20150721142323.sXk4lrxX-lEA%sdaoden@yandex.com> References: <20150721142323.sXk4lrxX-lEA%sdaoden@yandex.com> Message-ID: The website stuff should be working, not sure what else (if anythiung) there is here. Please re-open ticket with more info if necessary. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3949 Please log in as guest with password guest if prompted From rt at openssl.org Mon Jun 13 02:58:52 2016 From: rt at openssl.org (Stephen Henson via RT) Date: Mon, 13 Jun 2016 02:58:52 +0000 Subject: [openssl-dev] [openssl.org #4554] Bug: psk argument of the s_client/s_server command strips leading zero bytes. In-Reply-To: <5750202B.6020300@adder.com> References: <5750202B.6020300@adder.com> Message-ID: Fixed now, 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=4554 Please log in as guest with password guest if prompted From rt at openssl.org Mon Jun 13 07:43:59 2016 From: rt at openssl.org (Elmar Stellnberger via RT) Date: Mon, 13 Jun 2016 07:43:59 +0000 Subject: [openssl-dev] [openssl.org #3236] support for DNSSEC in openssl In-Reply-To: <564a7bf3-9643-993c-00c9-2b6f86bbde78@elstel.org> References: <29DCC7A4-8586-427E-B844-0F0CB7DDB276@elstel.org> <564a7bf3-9643-993c-00c9-2b6f86bbde78@elstel.org> Message-ID: Am 2016-06-12 um 23:49 schrieb Rich Salz via RT: > And DANE support is in 1.1/master. > Ok, thanks; will have to upgrade ... -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3236 Please log in as guest with password guest if prompted From rt at openssl.org Mon Jun 13 08:04:11 2016 From: rt at openssl.org (Matt Caswell via RT) Date: Mon, 13 Jun 2016 08:04:11 +0000 Subject: [openssl-dev] [openssl.org #4558] Performance issue with DTLS packet reassembly In-Reply-To: <933e3679-12fc-409c-a5e6-2cd0d1293951@default> References: <933e3679-12fc-409c-a5e6-2cd0d1293951@default> Message-ID: On Thu Jun 02 23:24:44 2016, paul.dale at oracle.com wrote: > The DTLS packet reassembly code has a performance problem that could > result in a DoS attack being possible. > > > > The DTLS packet reassembly uses the data structure defined in > ssl/pqueue.c for the purpose (it is the only user of this data > structure that I can find). This source file implements a priority > queue using a singly linked list. This means O(n^2) worst case > complexity, where n is the number of fragments. A better, and in fact > optimal, solution would be to use a heap for the purpose giving O(n > log n) worst case complexity. Doing this would prevent a potential > DoS attack. > > > > The attack would consist of fragmenting the DTLS stream into as many > small packets as possible and sending them in sequential order. Each > fragment will require a complete traversal of the list to be added. > Continue sending these as long as the DoS is wanted. For reference, > changing the list search method or ordering won't prevent such an > attack, it just means a different packet ordering is required. > > > > Tim Hudson suggested I submit this even though I haven't been able to > find time to craft a patch. This will require some significant rework of the pqueue code. This ticket is currently against the 1.1.0 milestone, but realistically that kind of change isn't going to happen in that timeframe, so pushing to post 1.1.0. Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4558 Please log in as guest with password guest if prompted From rt at openssl.org Mon Jun 13 08:05:29 2016 From: rt at openssl.org (Matt Caswell via RT) Date: Mon, 13 Jun 2016 08:05:29 +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: References: <56C9C1CC.50406@kippdata.de> Message-ID: On Wed Jun 08 16:02:39 2016, matt wrote: > On Tue May 24 13:53:07 2016, steve wrote: > > On Sun Feb 21 13:55:35 2016, rainer.jung at kippdata.de wrote: > > > Running the Apache test suite for Apache 2.4 with OpenSSL 1.1.0 > > > adjustments, I get > > > > > > > Can you please check to see if this issue is still present in the latest > > OpenSSL 1.1.0? > > Hi Rainer > > Can this ticket be closed now? No response from OP, so assuming this is no longer an issue. Please open a new ticket if it is. Closing. Matt -- 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 Mon Jun 13 09:37:59 2016 From: rt at openssl.org (Loic Etienne via RT) Date: Mon, 13 Jun 2016 09:37:59 +0000 Subject: [openssl-dev] [openssl.org #4561] BUG: openssl-1.0.2h, evp_enc.c, non-portable bitwise operation In-Reply-To: References: , Message-ID: My claim about portability issues was wrong (sorry): The C-standard ensures that positive values are handled in the two's complement system, indeed. However, inl % block_size == inl & (block_size-1) is true if and only if block_size is a power of two, which happens to be true under the current implementation, but may change in the future. If block_size should be 48, then 48 % block_size == 0, but 48 & (block_size-1) == 32. For this reason and for stylistic reasons, it may be worth considering to use consistently inl % ctx->block_size instead of inl & ctx->block_mask and int & (bl-1). Then the member block_mask could probably be removed. Otherwise, an OPENSSL_assert or an appropriate comment may document the essential precondition that block_size is a power of two. Cheers, Loic ________________________________ From: Matt Caswell via RT Sent: Friday, June 10, 2016 12:16:02 AM To: Loic Etienne Cc: openssl-dev at openssl.org Subject: [openssl.org #4561] BUG: openssl-1.0.2h, evp_enc.c, non-portable bitwise operation On Mon Jun 06 18:26:50 2016, loic.etienne at qnective.com wrote: > crypto/evp/evp_enc.c, EVP_EncryptUpdate > line 337: inl & (ctx->block_mask) > line 367: inl & (bl - 1) /* with bl = ctx->cipher->block_size */ Why do you consider this a problem? Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4561 Please log in as guest with password guest if prompted -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4561 Please log in as guest with password guest if prompted From rt at openssl.org Mon Jun 13 10:40:35 2016 From: rt at openssl.org (Andy Polyakov via RT) Date: Mon, 13 Jun 2016 10:40:35 +0000 Subject: [openssl-dev] [openssl.org #3100] [patch] remove some useless code in BN_uadd In-Reply-To: References: Message-ID: bn_add.c was modernized in https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=7d6284057b66458f6c99bd65ba67377d63411090 and suggested modifications were "accumulated". Case is being dismissed. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3100 Please log in as guest with password guest if prompted From rt at openssl.org Mon Jun 13 13:19:27 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 13 Jun 2016 13:19:27 +0000 Subject: [openssl-dev] [openssl.org #3809] [enhancement request] add critical to basicContraints in openssl.cnf In-Reply-To: References: Message-ID: yeah, about time we fixed this. :) commit a7be575 in master. thanks. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3809 Please log in as guest with password guest if prompted From rt at openssl.org Mon Jun 13 13:36:41 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 13 Jun 2016 13:36:41 +0000 Subject: [openssl-dev] [openssl.org #4560] BUG: openssl-1.0.2h, evp_enc.c, fips, use of uninitialized variable In-Reply-To: References: Message-ID: commit beb4c45c the if() test could be removed since that code is inside a larger "if (cipher" block, but this is minimal. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4560 Please log in as guest with password guest if prompted From rt at openssl.org Mon Jun 13 14:54:23 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 13 Jun 2016 14:54:23 +0000 Subject: [openssl-dev] [openssl.org #3723] Patch to add short name "Email" to "emailAddress" object In-Reply-To: <82A0649D-764B-4716-945C-04A50AA4CB67@akamai.com> References: <82A0649D-764B-4716-945C-04A50AA4CB67@akamai.com> Message-ID: OP says it can be closed, so we will. Open a new PR if desired. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3723 Please log in as guest with password guest if prompted From rt at openssl.org Mon Jun 13 15:03:14 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 13 Jun 2016 15:03:14 +0000 Subject: [openssl-dev] [openssl.org #3680] NULL pointer dereference in tls1_check_chain (ssl/t1_lib.c) In-Reply-To: References: Message-ID: Sorry for the delay in looking at this. It appears that the function has evolved quite a bit, and I cannot find a code path where cpk is not set. If i'm wrong, please re-open the ticket with some more info. Thanks. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3680 Please log in as guest with password guest if prompted From davidben at google.com Mon Jun 13 16:15:53 2016 From: davidben at google.com (David Benjamin) Date: Mon, 13 Jun 2016 16:15:53 +0000 Subject: [openssl-dev] [openssl.org #4558] Performance issue with DTLS packet reassembly In-Reply-To: References: <933e3679-12fc-409c-a5e6-2cd0d1293951@default> Message-ID: On Mon, Jun 13, 2016 at 4:04 AM Matt Caswell via RT wrote: > On Thu Jun 02 23:24:44 2016, paul.dale at oracle.com wrote: > > The DTLS packet reassembly code has a performance problem that could > > result in a DoS attack being possible. > > > > > > > > The DTLS packet reassembly uses the data structure defined in > > ssl/pqueue.c for the purpose (it is the only user of this data > > structure that I can find). This source file implements a priority > > queue using a singly linked list. This means O(n^2) worst case > > complexity, where n is the number of fragments. A better, and in fact > > optimal, solution would be to use a heap for the purpose giving O(n > > log n) worst case complexity. Doing this would prevent a potential > > DoS attack. > > > > > > > > The attack would consist of fragmenting the DTLS stream into as many > > small packets as possible and sending them in sequential order. Each > > fragment will require a complete traversal of the list to be added. > > Continue sending these as long as the DoS is wanted. For reference, > > changing the list search method or ordering won't prevent such an > > attack, it just means a different packet ordering is required. > > > > > > > > Tim Hudson suggested I submit this even though I haven't been able to > > find time to craft a patch. > Were you able to reproduce this performance problem? Note that N is at most 10 here. Assuming the DTLS packet reassembly code manages its queue correctly (It's rather buggy, but I forget if this was one of its problems. I eventually gave up trying to digest it and rewrote it from scratch on our end.), this check will ensure the queue size is tightly bounded: https://git.openssl.org/gitweb/?p=openssl.git;a=blob;f=ssl/statem/statem_dtls.c;h=d75483af6d40ad4c6ed9137eba8a7382a3b0ef0a;hb=HEAD#l634 It could probably be brought down a hair further too. There's no need to buffer more than the maximum number of messages in a supported handshake flight. (pqueue is still a silly data structure to be using here. A fixed-size ring buffer would be better. Or just a boring array since memmove on 10 pointers is cheap. But it's not hugely important.) David -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Mon Jun 13 16:16:18 2016 From: rt at openssl.org (David Benjamin via RT) Date: Mon, 13 Jun 2016 16:16:18 +0000 Subject: [openssl-dev] [openssl.org #4558] Performance issue with DTLS packet reassembly In-Reply-To: References: <933e3679-12fc-409c-a5e6-2cd0d1293951@default> Message-ID: On Mon, Jun 13, 2016 at 4:04 AM Matt Caswell via RT wrote: > On Thu Jun 02 23:24:44 2016, paul.dale at oracle.com wrote: > > The DTLS packet reassembly code has a performance problem that could > > result in a DoS attack being possible. > > > > > > > > The DTLS packet reassembly uses the data structure defined in > > ssl/pqueue.c for the purpose (it is the only user of this data > > structure that I can find). This source file implements a priority > > queue using a singly linked list. This means O(n^2) worst case > > complexity, where n is the number of fragments. A better, and in fact > > optimal, solution would be to use a heap for the purpose giving O(n > > log n) worst case complexity. Doing this would prevent a potential > > DoS attack. > > > > > > > > The attack would consist of fragmenting the DTLS stream into as many > > small packets as possible and sending them in sequential order. Each > > fragment will require a complete traversal of the list to be added. > > Continue sending these as long as the DoS is wanted. For reference, > > changing the list search method or ordering won't prevent such an > > attack, it just means a different packet ordering is required. > > > > > > > > Tim Hudson suggested I submit this even though I haven't been able to > > find time to craft a patch. > Were you able to reproduce this performance problem? Note that N is at most 10 here. Assuming the DTLS packet reassembly code manages its queue correctly (It's rather buggy, but I forget if this was one of its problems. I eventually gave up trying to digest it and rewrote it from scratch on our end.), this check will ensure the queue size is tightly bounded: https://git.openssl.org/gitweb/?p=openssl.git;a=blob;f=ssl/statem/statem_dtls.c;h=d75483af6d40ad4c6ed9137eba8a7382a3b0ef0a;hb=HEAD#l634 It could probably be brought down a hair further too. There's no need to buffer more than the maximum number of messages in a supported handshake flight. (pqueue is still a silly data structure to be using here. A fixed-size ring buffer would be better. Or just a boring array since memmove on 10 pointers is cheap. But it's not hugely important.) David -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4558 Please log in as guest with password guest if prompted From rt at openssl.org Mon Jun 13 16:32:20 2016 From: rt at openssl.org (Matt Caswell via RT) Date: Mon, 13 Jun 2016 16:32:20 +0000 Subject: [openssl-dev] [openssl.org #4434] Gentoo 13, x86_64: 4 failed self tests In-Reply-To: References: Message-ID: On Wed Jun 01 22:20:38 2016, matt wrote: > Hi Jeff > > Please could you try the attached patch? Jeff confirmed to me that the patch solved the problem. Pushed as commit 25b9d11c0. Closing ticket. Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4434 Please log in as guest with password guest if prompted From rt at openssl.org Mon Jun 13 16:37:59 2016 From: rt at openssl.org (Matt Caswell via RT) Date: Mon, 13 Jun 2016 16:37:59 +0000 Subject: [openssl-dev] [openssl.org #597] SSL_set_session() problem (?) In-Reply-To: <20030413135931.GA26118@fermat.math.technion.ac.il> References: <20030413135931.GA26118@fermat.math.technion.ac.il> Message-ID: Fixed in commit e70656cf1c. Closing ticket. Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=597 Please log in as guest with password guest if prompted From rt at openssl.org Mon Jun 13 17:36:39 2016 From: rt at openssl.org (Quanah Gibson-Mount via RT) Date: Mon, 13 Jun 2016 17:36:39 +0000 Subject: [openssl-dev] [openssl.org #4564] BUG: Deadlock in OpenSSL with OpenSSL 1.0.1j and later (including 1.0.2h) with multiple long lived connections In-Reply-To: References: Message-ID: Since moving to the OpenSSL 1.0.1+ series, we've been experiencing sporadic deadlocks in OpenLDAP inside of OpenSSL. I'm not sure exactly when the problem was introduced, but we never encountered it with the 1.0.0 series, and 1.0.1j was what we moved to when we switched to the 1.0.1 series. To reproduce the problem: a) Deploy OpenLDAP with 3-node Multi-master or greater using persistent connections. StartTLS should be used as a part of the replication agreement configuration. The issue only occurs if there are 2+ replication agreements per master node, thus the requirements for 3-node multimaster or greater. b) Let time pass. Eventually, slapd will grind to a complete halt. Alternatively, after some period of time, shut down slapd, and it will lock up in OpenSSL. netstat does not show any sockets with queued data waiting. Unfortuantely, I can't give greater detail than this because I'm not sure how to check if we've entered the error state or not. However, given enough time, the problem is 100% producible (I.e., if I leave OpenLDAP running long enough). Again, this never occurs in a 2-node MMR setup, where there is only a single long-lived replication agreement. A backtrace of slapd that's locked up during shutdown shows that multiple threads are waiting to read bytes that it believes it never received. This this backtrace, for example, thread 4 is waiting for other threads to finish so it can complete the shutdown of slapd. Threads 2 & 3 are both waiting to read bytes on the socket: Thread 4 (Thread 0x7f146ac9d700 (LWP 16805)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 No locals. #1 0x00007f3c70fe8171 in ldap_pvt_thread_cond_wait (cond=0x1fa0038, mutex=0x1fa0010) at thr_posix.c:277 No locals. #2 0x00007f3c70fe63c2 in ldap_pvt_thread_pool_destroy (tpool=0x7618c0 , run_pending=1) at tpool.c:817 pool = 0x1f763c0 pptr = 0x1f763c0 pq = 0x1fa0000 task = 0x7f3c716a61c8 i = 0 #3 0x0000000000438967 in slapd_daemon_task (ptr=0x1d7bce8) at daemon.c:2829 l = 3 last_idle_check = 1464372736 ebadf = 0 tid = 0 #4 0x00007f3c70552184 in start_thread (arg=0x7f146ac9d700) at pthread_create.c:312 __res = pd = 0x7f146ac9d700 now = unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139725667686144, -1093867468031317215, 0, 0, 139725667686848, 139725667686144, 1078920827726146337, 1056426161274956577}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = pagesize_m1 = sp = freesize = __PRETTY_FUNCTION__ = "start_thread" #5 0x00007f3c7027f37d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 No locals. Thread 3 (Thread 0x7f1468498700 (LWP 16810)): #0 0x00007f3c705593ad in read () at ../sysdeps/unix/syscall-template.S:81 No locals. #1 0x00007f3c70dd2435 in sb_stream_read (sbiod=0x5d36630, buf=0x5a3c057, len=433) at sockbuf.c:490D0D __PRETTY_FUNCTION__ = "sb_stream_read" #2 0x00007f3c70dd2e56 in sb_debug_read (sbiod=0x5d36d20, buf=0x5a3c057, len=433) at sockbuf.c:829 ret = 79 ebuf = "PjIh\024\177\000\000\017\000\000\000\000\000\000\000`\016\000\000\000\000\000\000'\000\000\000\000\000\000\000\250\062H\004\000\000\000\000'\000\000\000\000\000\000\000\240\361H\004\000\000\000\000P\026u\016\000\000\000\000\000\001\000\000\000\000\000\000\001\350#p<\177\000\000\000\000\000\000\000\000\000\0006364\037\000\000\000\000\000\000\006\000\000\000\000\000\000\000hxIh\t\000\000\000\300lIh\024\177\000\000\220jIh\024\177\000" #3 0x00007f3c7101ebd1 in tlso_bio_read (b=0x5a93110, buf=0x5a3c057 "\004\areqType1\b\004\006modify02\004\005reqDN1)\004'uid=gtillman,ou=people,dc=zimbra,dc=com0\201\317\004\006reqMod1\201\304\004:zimbraAuthTokens:- 1988626989|1464372357970|8.7.0_RC1_1601\004\063entryCSN:= 20160527182235.762156Z#000000#003#000000\004."..., len=433) at tls_o.c:721 p = 0x5a6caa0 ret = 79 #4 0x00007f3c6f19988b in BIO_read () from /opt/zimbra/common/lib/libcrypto.so.1.0.0 No symbol table info available. #5 0x00007f3c6f501ffc in ssl3_read_n () from /opt/zimbra/common/lib/libssl.so.1.0.0 No symbol table info available. #6 0x00007f3c6f503ebf in ssl3_read_bytes () from /opt/zimbra/common/lib/libssl.so.1.0.0 No symbol table info available. #7 0x00007f3c6f50033b in ssl3_read () from /opt/zimbra/common/lib/libssl.so.1.0.0 No symbol table info available. #8 0x00007f3c7101f093 in tlso_sb_read (sbiod=0x5d382e0, buf=0xcb4f93f, len=8) at tls_o.c:881 p = 0x5a6caa0 ret = 635655159814 err = 28 __PRETTY_FUNCTION__ = "tlso_sb_read" #9 0x00007f3c70dd2e56 in sb_debug_read (sbiod=0x5d37800, buf=0xcb4f93f, len=8) at sockbuf.c:829 ret = 0 ebuf = "\000\000\000\000\000\000\000\000\300\211Ih\024\177\000\000\000\207Ih\024\177\000\000\000\000\000\000\000\000\000\000pmIh\024\177\000\000v\202\376p<\177\000\000\000\000\000\000\000\000\000\000\240h%h\024\177\000\000]-K\000\000\000\000\000\300{Ih\024\177\000\000\240mIh\000\000\000\000v\202\376p<\177\000\000\000\000\000\000\000\000\000\000\320mIh\024\177\000\000]-K\000\000\000\000\000\300{Ih\024\177\000" #10 0x00007f3c70dd2291 in ber_int_sb_read (sb=0x5d363c0, buf=0xcb4f93f, len=8) at sockbuf.c:423 ret = 0 __PRETTY_FUNCTION__ = "ber_int_sb_read" #11 0x00007f3c70dcebbf in ber_get_next (sb=0x5d363c0, len=0x7f1468496f00, ber=0xcb4f930) at io.c:532 sblen = 8 buf = "\000\000\000\000\000\000" tlen = 0 __PRETTY_FUNCTION__ = "ber_get_next" #12 0x00007f3c70fea22f in try_read1msg (ld=0x5d36d50, msgid=3, all=0, lc=0x3d9b320, result=0x7f1468497190) at result.c:491 ber = 0xcb4f930 newmsg = 0x0 l = 0x0 prev = 0x0 id = 0 tag = 0 len = 0 foundit = 0 lr = 0x0 tmplr = 0x0 dummy_lr = {lr_msgid = 0, lr_status = 0, lr_refcnt = 0, lr_outrefcnt = 0, lr_abandoned = 0, lr_origid = 0, lr_parentcnt = 0, lr_res_msgtype = 0, lr_res_errno = 0, lr_res_error = 0x0, lr_res_matched = 0x0, lr_ber = 0x0, lr_conn = 0x0, lr_dn = {bv_len = 0, bv_val = 0x0}, lr_parent = 0x0, lr_child = 0x0, lr_refnext = 0x0, lr_prev =x0x0, lr_next = 0x0} tmpber = {ber_opts = {lbo_valid = -12608, lbo_options = 474, lbo_debug = 0}, ber_tag = 5341050, ber_len = 0, ber_usertag = 5014619, ber_buf = 0x0, ber_ptr = 0x0, ber_end = 0x0, ber_sos_ptr = 0x574963a4 , ber_rwptr = 0x0, ber_memctx = 0x67} rc = 0 refer_cnt = 0 hadref = 0 simple_request = 0 err = 0 lderr = 0 __PRETTY_FUNCTION__ = "try_read1msg" A%A#13 0x00007f3c70fe9e53 in wait4msg (ld=0x5d36d50, msgid=3, all=0, timeout=0x7f14684971f0, result=0x7f1468497190) at result.c:362 lnext = 0x0 serviced = 1 lc_ready = 1 rc = -2 tv = {tv_sec = 0, tv_usec = 0} tv0 = {tv_sec = 0, tv_usec = 0} start_time_tv = {tv_sec = 1464427439, tv_usec = 944352} tvp = 0x7f14684970a0 lc = 0x3d9b320 __PRETTY_FUNCTION__ = "wait4msg" #14 0x00007f3c70fe9574 in ldap_result (ld=0x5d36d50, msgid=3, all=0, timeout=0x7f14684971f0, result=0x7f1468497190) at result.c:117 rc = 0 __PRETTY_FUNCTION__ = "ldap_result" #15 0x00000000004bd6b2 in do_syncrep2 (op=0x7f1468497720, si=0x1dacec0) at syncrepl.c:841 berbuf = { buffer = "\002\000\001", '\000' , "\340\220\234\r\000\000\000\000\b\221\234\r\000\000\000\000\b\221\234\r", '\000' , "\240<\004", '\000' , "\370\201\376p<\177\000\000\300\211Ih\024\177\000\000`\003v\000\000\000\000\000\200sIh \024\175C5C000\000\370\201\376p<\177\000\000\070wIh\024\177\000\000ȓ\237\005\000\000\000\000\360sIh\024\177\000\000W\331\000q<\177\000\000\300sIh\024\177\000\000\034tIh\024\177\000\000\001\000\000\000\001\000\000\000P"..., ialign = 65538, lalign = 65538, falign = 9.18382988e-41, dalign = 3.2380074297143616e-319, palign = 0x10002 } ber = 0x7f14684972d0 msg = 0x0 syncCookie = {ctxcsn = 0x0, sids = 0x0, numcsns = 0, rid = 0, octet_str = {bv_len = 0, bv_val = 0x0}, sid = 0, sc_next = {stqe_next = 0x0}} syncCookie_req = {ctxcsn = 0x0, sids = 0x0, numcsns = 0, rid = 101, octet_str = {bv_len = 15, bv_val = 0xcaa5460 "rid=101,sid=004"}, sid = 4, sc_next = {stqe_next D D 0x0}} rc = 0 err = 0 modlist = 0x0 m = 1 tout_p = 0x7f14684971f0 tout = {tv_sec = 0, tv_usec = 0} refreshDeletes = 0 empty = "empty" __PRETTY_FUNCTION__ = "do_syncrep2" #16 0x00000000004bdebc in do_syncrepl (ctx=0x7f1468497bc0, arg=0x1d8b220) at syncrepl.c:1561 rtask = 0x1d8b220 si = 0x1dacec0 conn = {c_struct_state = SLAP_C_UNINITIALIZED, c_conn_state = SLAP_C_INVALID, c_conn_idx = -1, c_sd = 0, c_close_reason = 0x0, c_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' , __align = 0}, c_sb = 0x0, c_starttime = 0, c_activitytime = 0, c_connid = 18446744073709551615, c_peer_domain = {bv_len = 0, bv_val = 0x4f9b70 ""}, c_peer_name = {bv_len = 0, bv_val = 0x4f9b70 ""}, c_listener = 0x501d00 , c_sasl_bind_mech = {bv_len = 0, bv_val = 0x0}, c_sasl_dn = {bv_len = 0, bv_val = 0x0}, c_sasl_authz_dn = {bv_len = 0, bv_val = 0x0}, c_authz_backend = 0x0, c_authz_cookie = 0x0, c_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 0, bv_val = 0x0}, sai_ndn = {bv_len = 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, c_protocol = 0, c_ops = {stqh_first = 0x0, stqh_last = 0x0}, c_pending_ops = { stqh_first = 0x0, stqh_last = 0x0}, c_write1_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = { __prev = 0x0, __next = 0x0}}, __size = '\000' , __align = 0}, c_write1_cv = {__data %3{_B__lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0, __nwaiters = 0, __broadcast_seq = 0}, __size = '\000' , __align = 0}, c_write2_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' , __align = 0}, c_write2_cv = { __data = {__lock = 0, __futex = 0,_t_total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0, __nwaiters = 0, __broadcast_seq = 0}, __size = '\000' , __align = 0}, c_currentber = 0x0, c_writers = 0, c_writing = 0 '\000', c_sasl_bind_in_progress = 0 '\000', c_writewaiter = 0 '\000', c__t_tls = 0 '\000', c_needs_tls_accept = 0 '\000', c_sasl_layers = 0 '\000', c_sasl_done = 0 '\000', c_sasl_authctx = 0x0, c_sasl_sockctx = 0x0, c_sasl_extra = 0x0, c_sasl_bindop = 0x0, c_pagedresults_state = {ps_be = 0x0, ps_size = 0, ps_count = 0, ps_cookie = 0, ps_cookieval = {bv_len = 0, bv_val = 0x0}}, c_n_ops_received = 0, c_n_ops_executing = 0, c_n_ops_pending = 0, c_n_ops_completed = 0, c_n_get = 0, c_n_read = 0, c_n_write = 0, c_extensions = 0x0, c_clientfunc = 0x0, c_clientarg = 0x0, c_send_ldap_result = 0x452d9a , c_send_search_entry = 0x453c11 , c_send_search_reference = 0x455ec7 , c_send_ldap_extended = 0x4536fa , c_send_ldap_intermediate = 0x4539fc } opbuf = {ob_op = {o_hdr = 0x7f1468497890, o_tag = 102, o_time = 1464427428, o_tincr = 740798, o_bd = 0x1fa7740, o_req_dn = {bv_len = 39, bv_val = 0xdd2ab50 ""}, o_req_ndn = { bv_len = 39, bv_val = 0xbfb1600 "\260a\301\f"}, o_request = {oq_add = {rs_modlist = 0xfc28980, rs_e = 0x0}, oq_bind = {rb_method = 264407424, rb_cred = {bv_len = 0, bv_val = 0x0}, rb_edn = {bv_len = 0, bv_val3D3D 0x0}, rb_ssf = 0, rb_mech = {bv_len = 0, bv_val = 0x0}}, oq_compare = {rs_ava = 0xfc28980}, oq_modify = {rs_mods = { rs_modlist = 0xfc28980, rs_no_opattrs = 0 '\000'}, rs_increment = 0}, oq_modrdn = {rs_mods = {rs_modlist = 0xfc28980, rs_no_opattrs = 0 '\000'}, rs_deleteoldrdn = 0, rs_newrdn = {bv_len = 0, bv_val = 0x0}, rs_nnewrdn = {bv_len = 0, bv_val = 0x0}, rs_newSup = 0x0, rs_nnewSup = 0x0}, oq_search = {rs_scope = 264407424, rs_deref = 0, rs_slimit = 0, rs_tlimit = 0, rs_limit = 0x0, rs_attrsonly = 0, rs_attrs = 0x0, rs_filter = 0x0, rs_filterstr = {bv_len = 0, bv_val = 0x0}}, oq_abandon = { rs_msgid = 264407424}, oq_cancel = {rs_msgid = 264407424}, oq_extended = {rs_reqoid = {bv_len = 264407424, bv_val = 0x0}, rs_flags = 0, rs_reqdata = 0x0}, oq_pwdexop = { rs_extended = {rs_reqoid = {bv_len = 264407424, bv_val = 0x0}, rs_flags = 0, rs_reqdata = 0x0}, rs_old = {bv_len = 0, bv_val = 0x0}, rs_new = {bv_len = 0, bv_val = 0x0}, rs_mods = 0x0, rs_modtail = 0x0}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 0 '\000', o_is_auth_check = 0 '\000', o_dont_replicate = 0 '\000', o_acl_priv = ACL_NONE, o_nocaching = 0 '\000', o_delete_glue_parent = 0 '\000', o_no_schema_check = 1 '\001', o_no_subordinate_glue = 0 '\000', o_ctrlflag = '\000' , "\002", '\000' , o_controls = 0x7f14684979d8, o_authz = {sai_method D D 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 9, bv_val = 0x23e8a60 "cn=config"}, sai_ndn = {bv_len = 9, bv_val = 0x23e8a80 "cn=config"}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x7f1468496f70, o_ctrls = 0x0, o_csn = {bv_len = 0, bv_val = 0x0}, o_private = 0x0, o_extra = { slh_first = 0x0}, o_next = {stqe_next = 0x0}}, ob_hdr = {oh_opid = 0, oh_connid = 101,hoh_conn = 0x7f1468497460, oh_msgid = 0, oh_protocol = 0, oh_tid = 139725625722624, oh_threadctx = 0x7f1468497bc0, oh_tmpmemctx = 0x43ca000, oh_tmpmfuncs = 0x75e3c0 , oh_counters = 0x7618e0 , oh_log_prefix = "conn=-1 op=0", '\000' }, ob_controls = {0x0 , 0x7f1468497240, 0x0 }} op = 0x7f1468497720 rc = 0 dostop = 0 s = 19 i = 1 defer = 1 fail = 0 freeinfo = 0 be = 0x1fa7740 #17 0x000000000043c3ae in connection_read_thread (ctx=0x7f1468497bc0, argv=0x13) at connection.c:1273 rc = 0 cri = {op = 0x0, func = 0x4bd8b4 , arg = 0x1d8b220, ctx = 0x7f1468497bc0, nullop = 0} %3= 19 #18 0x00007f3c70fe6a75 in ldap_int_thread_pool_wrapper (xpool=0x1fa0000) at tpool.c:956 pq = 0x1fa0000 pool = 0x1f763c0 task = 0x3db4520 work_list = 0x1fa0070 ctx = {utu_pq = 0x1fa0000, ltu_id = 139725625722624, ltu_key = {{ltk_key = 0x4b2d5d , ltk_data = 0x43ca000, ltk_free = 0x4b2b82 }, { ltk_key = 0x1f83300, ltk_data = 0x44ce000, ltk_free = 0x7f3c6bb23f12 }, {ltk_key = 0x7f3c6bb18ec6 , ltk_data = 0x47d8000, ltk_free = 0x7f3c6bb18ea3 }, {ltk_key = 0x7f3c6bb1589f , ltk_data = 0x44d8000, ltk_free = 0x7f3c6bb15857 }, { A0A ltk_key = 0x1f82c00, ltk_data = 0x44cfa00, ltk_free = 0x7f3c6bb23f12 }, {ltk_key = 0x43b82b , ltk_data = 0x1f83c00, ltk_free = 0x43b67d }, {ltk_key = 0x457375 , ltk_data = 0x2562d00, ltk_free = 0x4572c8 }, {ltk_key = 0x0, ltk_data = 0x602d600, ltk_free = 0x0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x0} }} kctx = 0x0 i = 32 keyslot = 875 hash = 521230187 pool_lock = 0 freeme = 0 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #19 0x00007f3c70552184 in start_thread (arg=0x7f1468498700) at pthread_create.c:312 __res = pd = 0x7f1468498700 now = unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139725625722624, -1093867468031317215, 0, 0, 139725625723328, 139725625722624, 1078926329042381601, 1056426161274956577}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = pagesize_m1 = sp = freesize = __PRETTY_FUNCTION__ = "start_thread" #20 0x00007f3c7027f37d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 No locals. Thread 2 (Thread 0x7f1467c97700 (LWP 16812)): #0 0x00007f3c705593ad in read () at ../sysdeps/unix/syscall-template.S:81 No locals. #1 0x00007f3c70dd2435 in sb_stream_read (sbiod=0x3dac8b0, buf=0x23cc1a8, len=96) at sockbuf.c:493 __PRETTY_FUNCTION__ = "sb_stream_read" #2 0x00007f3c70dd2e56 in sb_debug_read (sbiod=0x3dac850, buf=0x23cc1a8, len=96) at sockbuf.c:829 ret = 416 ebuf = "PZ\311g\024\177\000\000\017\000\000\000\000\000\000\000`\016\000\000\000\000\000\000'\000\000\000\000\000\000\000\230\264\343\005\000\000\000\000'\000\000\000\000\000\000\000P~\344\005\000\000\000\000 at C5Cru\016\000\000\000\000\000\001\000\000\000\000\000\000\001\350#p<\177\000\000\000\000\000\000\000\000\000\000\364\037\000\000\000\000\000\000\006\000\000\000\000\000\000\000hh\311g\n\000\000\000\300\\\311g\024\177\000\000\220Z\311g\024\177\000" #3 0x00007f3c7101ebd1 in tlso_bio_read (b=0x244b2d0, buf=0x23cc1a8 "\240F0D\004\030\061.3.6.1.4.1.4203.1.9.1.2\004(0&\n\001\001\004\020\004@\320&\270\206\020\065\223\244\347B\322ף\327\004\017rid=102,sid=001췫\272\005\324a`\346\343\373\335\062\065\223\a\363\363Sv\003\003\003\003\063.1.9.1.2\004(0&\n\001\001\004\020\003\362\377\004\270\206\020\065\223\236\347B\322ף\327\004\017rid=102,sid=001\027ל{\026g\264\262\210\331U]\330#\020u\241ʂ\206\b\b\b\b\b\b\b\b\bntryCSN:= 20160527182329"..., len=96% a at tls_o.c:721 p = 0x3da51e0 ret = 416 #4 0x00007f3c6f19988b in BIO_read () from /opt/zimbra/common/lib/libcrypto.so.1.0.0 No symbol table info available. #5 0x00007f3c6f501ffc in ssl3_read_n () from /opt/zimbra/common/lib/libssl.so.0.0.0 No symbol table info available. #6 0x00007f3c6f503ebf in ssl3_read_bytes () from /opt/zimbra/common/lib/libssl.so.1.0.0 No symbol table info available. #7 0x00007f3c6f50033b in ssl3_read () from /opt/zimbra/common/lib/libssl.so.1.0.0 No symbol table info available. #8 0x00007f3c7101f093 in tlso_sb_read (sbiod=0x3dac820, buf=0xd93bc7f, len=8) at tls_o.c:881 p = 0x3da51e0 ret = 631360192517 err = 27 __PRETTY_FUNCTION__ = "tlso_sb_read" #9 0x00007f3c70dd2e56 in sb_debug_read (sbiod=0x3dac880, buf=0xd93bc7f, len=8) at sockbuf.c:829 ret = 0 ebuf = "\000\000\000\000\000\000\000\000\300y\311g\024\177\000\000\000w\311g\024\177\000\000\000\000\000\000\000\000\000\000p]\311g\024\177\0%0\000v\202\376p<\177\000\000\000\000\000\000\000\000\000\000\240]\311g\024\177\000\000]-K\000\000\000\000\000\300k\311g\024\177\000\000\240]\311g\000\000\000\000v\202\376p<\177\000\000\000\000\000\000\000\000\000\000\320]\311g\024\177\000\000]-K\000\000\0%0\000\000\300k\311g\024\177\000" #10 0x00007f3c70dd2291 in ber_int_sb_read (sb=0x3dabc80, buf=0xd93bc7f, len=8) at sockbuf.c:423 ret = 0 __PRETTY_FUNCTION__ = "ber_int_sb_read" #11 0x00007f3c70dcebbf in ber_get_next (sb=0x3dabc80, len=7x7f1467c95f00, ber=0xd93bc70) at io.c:532 sblen = 8 buf = "\000\000\000\000\000\000" tlen = 0 __PRETTY_FUNCTION__ = "ber_get_next" #12 0x00007f3c70fea22f in try_read1msg (ld=0x3dabc50, msgid=3, all=0, lc=0x1f7d960, result=0x7f1467c96190) at result.c:491 ber = 0xd93bc70 newmsg = 0x0 l = 0x0 prev = 0x0 id = 0 tag = 0 len = 0 foundit = 0 lr = 0x0 tmplr = 0x0 dummy_lr = {lr_msgid = 0, lr_status = 0, lr_refcnt = 0, lr_outrefcnt = 0, lr_abandoned = 0, lr_origid = 0, lr_parentcnt = 0, lr_res_msgtype = 0, lr_res_errno = 0, lr_res_error = 0x0, lr_res_matched = 0x0, lr_ber = 0x0, lr_conn = 0x0, lr_dn = {bv_len = 0, bv_val = 0x0}, lr_parent = 0x0, lr_child = 0x0, lr_refnext = 0x0, lr_prev = 0x0, lr_next = 0x0} tmpber = {ber_opts = {lbo_valid = -11904, lbo_options = 474, lbo_debug = 0}, ber_tag = 5341050, ber_len = 0, ber_usertag = 5014619, ber_buf = 0x0, ber_ptr = 0x0, ber_end = 0%0, ber_sos_ptr = 0x5748c3eb , ber_rwptr = 0x0, ber_memctx = 0x67} rc = 0 refer_cnt = 0 hadref = 0 simple_request = 0 err = 0 lderr = 0 % __PRETTY_FUNCTION__ = "try_read1msg" #13 0x00007f3c70fe9e53 in wait4msg (ld=0x3dabc50, msgid=3, all=0, timeout=0x7f1467c961f0, result=0x7f1467c96190) at result.c:362 lnext = 0x0 serviced = 1 lc_ready = 1 rc = -2 tv = {tv_sec = 0, tv_usec = 0} tv0 = {tv_sec = 0, tv_usec = 0} start_time_tv = {tv_sec = 1464386543, tv_usec = 695070} tvp = 0x7f1467c960a0 lc = 0x1f7d960 __PRETTY_FUNCTION__ = "wait4msg" #14 0x007f7f3c70fe9574 in ldap_result (ld=0x3dabc50, msgid=3, all=0, timeout=0x7f1467c961f0, result=0x7f1467c96190) at result.c:117 rc = 0 __PRETTY_FUNCTION__ = "ldap_result" #15 0x00000000004bd6b2 in do_syncrep2 (op=0x7f1467c96720, si=0x1dad180) at syncrepl.c:841 berbuf = { buffer = "\002\000\001", '\000' , "\200\060\207\r\000\000\000\000\250\060\207\r\000\000\000\000\250\060\207\r", '\000' , "\200\267<\004", '\000' , "\370\201\376p<\177\000\000\300y\311g\024\177\000\000`\003v\000\000\000\000\000\200c\311g\024\177\000\000\370\201\376p<\177\000\000\070g\311g\024\177\000\000\310y\370\001\000\000\000\000\360c\311g\024\177\000\000W\331\000q<\177\000\000\300c\311g\024\177\000\000\034d\311g\024\177\000\000\001\000\000\000\001\000\000\000"..., ialign = 65538, lalign = 65538, falign = 9.18382988e-41, dalign = 3.2380074297143616e-319, palign = 0x10002 } ber = 0x7f1467c962d0D%0 msg = 0x0 syncCookie = {ctxcsn = 0x0, sids = 0x0, numcsns = 0, rid = 0, octet_str = {bv_len = 0, bv_val = 0x0}, sid = 0, sc_next = {stqe_next = 0x0}} syncCookie_req = {ctxcsn = 0x0, sids = 0x0, numcsns = 0, rid = 102, octet_str = {bv_len = 15, bv_val = 0xc2faf30 "rid=102,sid=001"}, sid = 1, sc_next = {stqe_next = 0x0}} rc = 0 err = 0 modlist = 0x0 m = 1 tout_p = 0x7f1467c961f0 tout = {tv_sec = 0,v_v_usec = 0} refreshDeletes = 0 empty = "empty" __PRETTY_FUNCTION__ = "do_syncrep2" #16 0x00000000004bdebc in do_syncrepl (ctx=0x7f1467c96bc0, arg=0x1d8b130) at syncrepl.c:1561 rtask = 0x1d8b130 si = 0x1dad180 A0A conn = {c_struct_state = SLAP_C_UNINITIALIZED, c_conn_state = SLAP_C_INVALID, c_conn_idx = -1, c_sd = 0, c_close_reason = 0x0, c_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' , __align = 0}, c_sb = 0x0, c_starttime = 0, c_activitytime = 0, c_connid = 18446744073709551615, c_peer_domain = {bv_len = 0, bv_val = 0x4f9b70 ""}, c_peer_name = {bv_len = 0, bv_val = 0x4f9b70 ""}, c_listener = 0x501d00 , c_sasl_bind_mech = {bv_len = 0, bv_val = 0x0}, c_sasl_dn = {bv_len = 0, bv_val = 0x0}, c_sasl_authz_dn = {bv_len = 0, bv_val = 0x0}, c_authz_backend = 0x0, c_authz_cookie = 0x0, c_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 0, bv_val = 0x0}, sai_ndn = {bv_len = 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, c_protocol = 0, c_ops = {stqh_first = 0x0, stqh_last = 0x0}, c_pending_ops = { stqh_first = 0x0, stqh_last = 0x0}, c_write1_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = { __prev = 0x0, __next = 0x0}}, __size = '\000' , __align = 0}, c_write1_cv = {__data = {__lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0, __nwaiters = 0, __broadcast_seq =%0}, __size = '\000' , __align = 0}, c_write2_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' , __align = 0}, c_write2_cv = { __data = {__lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0, __nwaiters = 0, __broadcast_seq = 0}, __size = '\000' , __align = 0}, c_currentber 0x0x0, c_writers = 0, c_writing = 0 '\000', c_sasl_bind_in_progress = 0 '\000', c_writewaiter = 0 '\000', c_is_tls = 0 '\000', c_needs_tls_accept = 0 '\000', c_sasl_layers = 0 '\000', c_sasl_done = 0 '\000', c_sasl_authctx = 0x0, c_sasl_sockctx = 0x0, c_sasl_extra = 0x0, c_sasl_bindop = 0x0, c_pagedresults_state = {ps_be = 0x0, ps_size = 0, ps_count = 0, ps_cookie = 0, ps_cookieval = {bv_len = 0, bv_val = 0x0}}, c_n_ops_received = 0, c_n_ops_executing = 0, c_n_ops_pending = 0, c_n_ops_completed = 0, c_n_get = 0, c_n_read = 0, c_n_write = 0, c_extensions = 0x0, c_clientfunc = 0x0, c_clientarg = 0x0, c_send_ldap_result = 0x452d9a , c_send_search_entry = 0x453c11 , c_send_search_reference = 0x455ec7 , c_send_ldap_extended = 0x4536fa , c_send_ldap_intermediate = 0x4539fc } opbuf = {ob_op = {o_hdr = 0x7f1467c96890, o_tag = 102, o_time = 1464386539, o_tincr = 697802, o_bd = 0x1fa7740, o_req_dn = {bv_len = 39, bv_val = 0xfad64e0 ""}, o_req_ndn = { bv_len = 39, bv_val = 0xfb76000 "`\246\030\f"}, o_request = {oq_add = {rs_modlist = 0xfb25200, rs_e = 0x0}, oq_bind = {rb_method = 263344640, rb_cred = {bv_len = 0, bv_val = 0x0}, rb_edn = {bv_len = 0, bv_val = 0x0}, rb_ssf = 0, rb_mech = {bv_len = 0, bv_val = 0x0}}, oq_compare = {rs_ava = 0xfb25200}, oq_modify = {rs_mods = { rs_modlist = 0xfb25200, rs_no_opattrs = 0 '\000'}, rs_increment = 0}, oq_modrdn = {rs_mods = {rs_modlist = 0xfb25200, rs_no_opattrs = 0 '\000'}, rs_deleteoldrdn = 0, rs_newrdn = {bv_len = 0, bv_val = 0x0}, rs_nnewrdn = {bv_len = 0, bv_val = 0x0}, rs_newSup = 0x0, rs_nnewSup = 0x0}, oq_search = {rs_scope = 263344640, rs_deref = 0, rs_slimit = 0, rs_tlimit = 0, rs_limit = 0x0, rs_attrsonly = 0, rs_attrs = 0x0, rs_filter = 0x0, rs_filterstr = {bv_len = 0, bv_val = 0x0}}, oq_abandon = { rs_msgid = 263344640}, oq_cancel = {rs_msgid = 263344640}, oq_extended = {rs_reqoid = {bv_len = 263344640, bv_val = 0x0}, rs_flags = 0, rs_reqdata = 0x0}, oq_pwdexop = { rs_extended = {rs_reqoid = {bv_len = 263344640, bv_val = 0x0}C C rs_flags = 0, rs_reqdata = 0x0}, rs_old = {bv_len = 0, bv_val = 0x0}, rs_new = {bv_len = 0, bv_val = 0x0}, rs_mods = 0x0, rs_modtail = 0x0}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 0 '\000', o_is_auth_check = 0 '\000', o_dont_replicate = 0 '\000', o_acl_priv = ACL_NONE, o_nocaching = 0 '\000', o_delete_glue_parent = 0 '\000', o_no_schema_check = 1 '\001', o_no_subordinate_glue = 0 '\000', o_ctrlflag = '\000' , "\002", '\000' , o_controls = 0x7f1467c969d8, o_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 9, bv_val = 0x23e8a60 "cn=config"}, sai_ndn = {bv_len = 9, bv_val = 0x23e8a80 "cn=config"}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x7f1467c95f70, o_ctrls = 0x0, o_csn = {bv_len = 0, bv_val = 0x0}, o_private = 0x0, o_extra = { slh_first = 0x0}, o_next = {stqe_next = 0x0}}, ob_hdr = {oh_opid = 0, oh_connid = 102, oh_conn = 0x7f1467c96460, oh_msgid = 0, oh_protocol = 0, oh_tid = 139725617329920, oh_threadctx = 0x7f1467c96bc0, oh_tmpmemctx = 0x43cb780, oh_tmpmfuncs = 0x75e3c0 , oh_counters = 0x7618e0 , oh_log_prefix = "conn=-1 op=0", '\000' }, ob_controls = {0x0 , 0x7f1467c96240, 0x0 }} op = 0x7f1467c96720 rc = 0 dostop = 0 s = 15 i = 1 defer = 1 fail = 0 freeinfo = 0 be = 0x1fa7740 #17 0x000000000043c3ae in connection_read_thread (ctx=0x7f1467c96bc0, argv=0xf) at connection.c:1273 rc = 0 cri = {op = 0x0, func = 0x4bd8b4 , arg = 0x1d8b130, ctx = 0x7f1467c96bc0, nullop = 0} s = 15 #18 0x00007f3c70fe6a75 in ldap_int_thread_pool_wrapper (xpool=0x1fa0000) at tpool.c:956 pq = 0x1fa0000 pool = 0x1f763c0 task = 0x3db4500 work_list = 0x1fa0070 ctx = {ltu_pq = 0x1fa0000, ltu_id = 139725617329920, ltu_key = {{ltk_key = 0x4b2d5d , ltk_data = 0x43cb780, ltk_free = 0x4b2b82 }, { ltk_key = 0x1f82c00, ltk_data = 0x5ee4000, ltk_free = 0x7f3c6bb23f12 }, {ltk_key = 0x43b82b , ltk_data = 0x25ec700, ltk_free = 0x43b67d }, {ltk_key = 0x457375 , ltk_data = 0x25621c0, ltfreeee = 0x4572c8 }, {ltk_key = 0x1f83300, ltk_data = 0x5eea800, ltk_free = 0x7f3c6bb23f12 }, {ltk_key = 0x7f3c6bb18ec6 , ltk_data = 0xafae000, ltk_free = 0x7f3c6bb18ea3 }, {ltk_key = 0x7f3c6bb1589f , ltk_data = 0xacae000, ltk_free = 0x7f3c6bb15857 }, { ltk_key = 0x0, ltk_data = 0x5a17200, ltk_free = 0x0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x0} }} kctx = 0x0 i = 32 keyslot = 410 hash = 616821146 pool_lock = 0 freeme = 0 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #19 0x00007f3c70552184 in start_thread (arg=0x7f1467c97700) at pthread_create.c:312 __res = pd = 0x7f1467c97700 now = unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139725617329920, -1093867468031317215, 0, 0, 139725617330624, 139725617329920, 1078896641691560737, 1056426161274956577}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = pagesize_m1 = sp = freesize = __PRETTY_FUNCTION__ = "start_thread" #20 0x00007f3c7027f37d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 No locals. Thread 1 (Thread 0x7f3c71694780 (LWP 16804)): #0 0x00007f3c7055365b in pthread_join (threadid=139725667686144, thread_return=0x0) at pthread_join.c:92 _tid = 16805 _buffer = {__routine = 0x7f3c70553590 , __arg = 0x7f146ac9dd28, __canceltype = 1791612672, __prev = 0x0} oldtype = 0 pd = 0x7f146ac9d700 self = 0x7f3c71694780 result = 0 #1 0x00007f3c70fe80b2 in ldap_pvt_thread_join (thread=139725667686144, thread_return=0x0) at thr_posix.c:197 No locals. #2 0x0000000000438cc0 in slapd_daemon () at daemon.c:2910 i = 0 rc = 0 #3 0x0000000000414ce1 in main (argc=9, argv=0x7ffe003b02b8) at main.c:1017 i = 9 no_detach = 0 rc = 0 urls = 0x1d8a000 "ldap://ldap02e.zimbra.com:389 ldaps://ldap02e.zimbra.com:636 ldapi:///" username = 0x1d7a010 "root" groupname = 0x0 sandbox = 0x0 syslogUser = 128 pid = 0 waitfds = {10, 11} g_argc = 9 g_argv = 0x7ffe003b02b8 configfile = 0x0 configdir = 0x1d82020 "/opt/zimbra/data/ldap/config" serverName = 0x7ffe003b0d78 "slapd" serverMode = 1 scp = 0x0 scp_entry = 0x0 debug_unknowns = 0x0 syslog_unknowns = 0x0 serverNamePrefix = 0x4f9608 "" l = 739235890461816576 slapd_pid_file_unlink = 1 slapd_args_file_unlink = 1 firstopt = 0 __PRETTY_FUNCTION__ = "main" (gdb) -- Quanah Gibson-Mount Platform Architect Manager, Systems Team Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4564 Please log in as guest with password guest if prompted From rt at openssl.org Mon Jun 13 18:51:28 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 13 Jun 2016 18:51:28 +0000 Subject: [openssl-dev] [openssl.org #2969] bug/enchancement request In-Reply-To: References: Message-ID: sorry to take so long to look at this. believe fixed in 1.1. open a new ticket if not. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2969 Please log in as guest with password guest if prompted From rt at openssl.org Mon Jun 13 18:51:33 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 13 Jun 2016 18:51:33 +0000 Subject: [openssl-dev] [openssl.org #2969] bug/enchancement request In-Reply-To: References: Message-ID: sorry to take so long to look at this. believe fixed in 1.1. open a new ticket if not. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2969 Please log in as guest with password guest if prompted From rt at openssl.org Mon Jun 13 19:15:18 2016 From: rt at openssl.org (noloader@gmail.com via RT) Date: Mon, 13 Jun 2016 19:15:18 +0000 Subject: [openssl-dev] [openssl.org #4434] Gentoo 13, x86_64: 4 failed self tests In-Reply-To: References: Message-ID: On Mon, Jun 13, 2016 at 12:32 PM, Matt Caswell via RT wrote: > On Wed Jun 01 22:20:38 2016, matt wrote: >> Hi Jeff >> >> Please could you try the attached patch? > > > Jeff confirmed to me that the patch solved the problem. Pushed as commit > 25b9d11c0. Confirmed. Its a good, clean patch. It detects the [odd] condition and and acts appropriately. In my mind's eye, that's a successful self test. I think the project should keep it as a PASS. Jeff -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4434 Please log in as guest with password guest if prompted From rt at openssl.org Mon Jun 13 20:12:19 2016 From: rt at openssl.org (noloader@gmail.com via RT) Date: Mon, 13 Jun 2016 20:12:19 +0000 Subject: [openssl-dev] [openssl.org #4565] Fatal error: Command failed for target `link_shlib.solaris' In-Reply-To: References: Message-ID: Just pulled latest source (Camellia changes): $ git rev-parse HEAD 96d06c213d5a2c1af42dd3b5d7bcc4a65df90738 Config OK, Make fails at. Verified twice: SHOBJECTS="./libcrypto.a "; ( :; LIBDEPS="${LIBDEPS:--lresolv -lsocket -lnsl -ldl}"; SHAREDCMD="${SHAREDCMD:-gcc}"; SHAREDFLAGS="${SHAREDFLAGS:--DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -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/engines\"" -m64 -Wall -DL_ENDIAN -O3 -pthread -DFILIO_H -Wa,--noexecstack -fPIC -m64 -shared -static-libgcc}"; LIBPATH=`for x in $LIBDEPS; do echo $x; done | sed -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_LIBRARY_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_shlib.solaris' Current working directory /export/home/jwalton/openssl *** Error code 1 make: Fatal error: Command failed for target `libcrypto.so' ********** $ ./config Operating system: i86pc-whatever-solaris2 Configuring for solaris64-x86_64-gcc Configuring OpenSSL version 1.1.0-pre6-dev (0x0x10100006L) no-asan [default] OPENSSL_NO_ASAN (skip dir) no-crypto-mdebug [default] OPENSSL_NO_CRYPTO_MDEBUG (skip dir) no-crypto-mdebug-backtrace [default] 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-fuzz-afl [default] OPENSSL_NO_FUZZ_AFL (skip dir) no-fuzz-libfuzzer [default] OPENSSL_NO_FUZZ_LIBFUZZER (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-ssl-trace [default] OPENSSL_NO_SSL_TRACE (skip dir) no-ssl3 [default] OPENSSL_NO_SSL3 (skip dir) no-ssl3-method [default] OPENSSL_NO_SSL3_METHOD (skip dir) no-ubsan [default] OPENSSL_NO_UBSAN (skip dir) no-unit-test [default] OPENSSL_NO_UNIT_TEST (skip dir) no-weak-ssl-ciphers [default] OPENSSL_NO_WEAK_SSL_CIPHERS (skip dir) no-zlib [default] no-zlib-dynamic [default] Configuring for solaris64-x86_64-gcc CC =gcc CFLAG =-m64 -Wall -DL_ENDIAN -O3 -pthread -DFILIO_H -Wa,--noexecstack SHARED_CFLAG =-fPIC DEFINES =DSO_DLFCN HAVE_DLFCN_H NDEBUG OPENSSL_THREADS OPENSSL_NO_STATIC_ENGINE OPENSSL_PIC 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 =-lresolv -lsocket -lnsl -ldl APPS_OBJ = CPUID_OBJ =x86_64cpuid.o UPLINK_OBJ = 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 BLAKE2_OBJ = PROCESSOR = RANLIB =ranlib ARFLAGS = PERL =/usr/local/bin/perl SIXTY_FOUR_BIT_LONG mode Configured for solaris64-x86_64-gcc. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4565 Please log in as guest with password guest if prompted From rt at openssl.org Mon Jun 13 20:22:20 2016 From: rt at openssl.org (Stuart Kemp via RT) Date: Mon, 13 Jun 2016 20:22:20 +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: <5B5209CB698EEC4D9710CEF6A83600EE35A82A76@prvxmb03.microfocus.com> References: <54DC8E6A0200002800011D4C@prv-mh.provo.novell.com> <56B1E88A.40902@openssl.org> <5B5209CB698EEC4D9710CEF6A83600EE35A82A76@prvxmb03.microfocus.com> Message-ID: This works. Code compiles fine now, using openssl-1.0.2h.tar.gz and openssl-fips-ecp-2.0.10.tar.gz, and all FIPS self-tests complete with 0 errors. -----Original Message----- From: Andy Polyakov via RT [mailto:rt at openssl.org] Sent: Wednesday, February 03, 2016 5:46 AM To: Stuart Kemp Cc: openssl-dev at openssl.org Subject: Re: [openssl-dev] [openssl.org #3699] openssl-1.0.2, fips sparc multiply defined _sparcv9_vis1_instrument_bus, _sparcv9_vis1_instrument_bus2 >> 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. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3699 Please log in as guest with password guest if prompted From rt at openssl.org Mon Jun 13 20:46:10 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 13 Jun 2016 20:46:10 +0000 Subject: [openssl-dev] [openssl.org #2337] [PATCH] Openssl asm BN/AES/SHA1 acceleration for SH4 and MIPS32 In-Reply-To: <201009110226.37780.vincent.labie75@gmail.com> References: <201009110226.37780.vincent.labie75@gmail.com> Message-ID: We don't have SH hardware, and the MIPS code is already more improved. Sorry we took so long to get to this. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2337 Please log in as guest with password guest if prompted From rt at openssl.org Mon Jun 13 20:50:08 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 13 Jun 2016 20:50:08 +0000 Subject: [openssl-dev] [openssl.org #3922] Bug: EVP_get_digestbynid() does not support ECDSA In-Reply-To: <5587E336.4030209@siemens.com> References: <5587E336.4030209@siemens.com> Message-ID: Ah, the endless confusion of cipher vs signature NID's :) closing ticket. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3922 Please log in as guest with password guest if prompted From rt at openssl.org Mon Jun 13 20:54:46 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 13 Jun 2016 20:54:46 +0000 Subject: [openssl-dev] [openssl.org #3299] Allow setting custom cipher strings in the openssl config file. In-Reply-To: <1397037306.28964.10.camel@dhcp-2-127.brq.redhat.com> References: <1397037306.28964.10.camel@dhcp-2-127.brq.redhat.com> Message-ID: This is recorded here: https://github.com/openssl/openssl/pull/192 Closing ticket just to remove duplication, the PR has not been merged. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3299 Please log in as guest with password guest if prompted From levitte at openssl.org Mon Jun 13 21:00:20 2016 From: levitte at openssl.org (Richard Levitte) Date: Mon, 13 Jun 2016 23:00:20 +0200 (CEST) Subject: [openssl-dev] Out-of-tree build? In-Reply-To: <87k2hxb0xk.fsf@alice.fifthhorseman.net> References: <20160610.122730.1309125281390986138.levitte@openssl.org> <87k2hxb0xk.fsf@alice.fifthhorseman.net> Message-ID: <20160613.230020.30284621135803940.levitte@openssl.org> In message <87k2hxb0xk.fsf at alice.fifthhorseman.net> on Fri, 10 Jun 2016 09:58:31 -0400, Daniel Kahn Gillmor said: dkg> On Fri 2016-06-10 06:27:30 -0400, Richard Levitte wrote: dkg> > 'make clean' doesn't remove everything (it doesn't remove stuff dkg> > produced by Configure), 'git clean -dfx' removes the last vestiges. dkg> > dkg> > It's possible that we'd do well with a 'make distclean' dkg> dkg> yes, please! For systems that build from distributed tarballs, "git dkg> clean" isn't really an option. Working on it. -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From rt at openssl.org Mon Jun 13 21:59:27 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Mon, 13 Jun 2016 21:59:27 +0000 Subject: [openssl-dev] [openssl.org #3772] Bug: Only ActivePerl could be used to build on Windows In-Reply-To: References: Message-ID: Apologies for the delay before responding. I believe we have fixed that by replacing 'chomp' with 's|\R$||' in the master branch. It this is still an issue, please open a new ticket. Cheers, Richard On Mon Mar 30 07:51:29 2015, esadovoi at eniks.com wrote: > It is well known issue with build on Windows: It requires ActivePerl > to > correctly create configuration. > Every other Perl implementation fails to execute correctly. The reason > it > fails outlined in this report: > https://github.com/openssl/openssl/issues/174 > Although it is stated that only cloned code exhibits this behavior I > believe > it also happens when Git or Strawberry Perl is being used for build of > official releases. > > As suggested in the comments adding $/= "\r\n"; line to Perl script > fixes this > issue for every other Perl implementation. > I've successfully built openssl with Perl distributed with Git as well > as > Strawberry Perl. -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3772 Please log in as guest with password guest if prompted From rt at openssl.org Mon Jun 13 22:10:05 2016 From: rt at openssl.org (paul.dale@oracle.com via RT) Date: Mon, 13 Jun 2016 22:10:05 +0000 Subject: [openssl-dev] [openssl.org #4558] Performance issue with DTLS packet reassembly In-Reply-To: <1dc5a132-718e-4a15-b8ff-aa691e8ae54b@default> References: <933e3679-12fc-409c-a5e6-2cd0d1293951@default> <1dc5a132-718e-4a15-b8ff-aa691e8ae54b@default> Message-ID: No, I didn't create an exploit. If the number of packets is limited to something that small, there won't be an issue. It still seems like pqueue out to be excised from the source base and replace with something simpler. Regards, Pauli -- Oracle Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia -----Original Message----- From: David Benjamin via RT [mailto:rt at openssl.org] Sent: Tuesday, 14 June 2016 2:16 AM To: Paul Dale Cc: openssl-dev at openssl.org Subject: Re: [openssl-dev] [openssl.org #4558] Performance issue with DTLS packet reassembly On Mon, Jun 13, 2016 at 4:04 AM Matt Caswell via RT wrote: > On Thu Jun 02 23:24:44 2016, paul.dale at oracle.com wrote: > > The DTLS packet reassembly code has a performance problem that could > > result in a DoS attack being possible. > > > > > > > > The DTLS packet reassembly uses the data structure defined in > > ssl/pqueue.c for the purpose (it is the only user of this data > > structure that I can find). This source file implements a priority > > queue using a singly linked list. This means O(n^2) worst case > > complexity, where n is the number of fragments. A better, and in > > fact optimal, solution would be to use a heap for the purpose giving > > O(n log n) worst case complexity. Doing this would prevent a > > potential DoS attack. > > > > > > > > The attack would consist of fragmenting the DTLS stream into as many > > small packets as possible and sending them in sequential order. Each > > fragment will require a complete traversal of the list to be added. > > Continue sending these as long as the DoS is wanted. For reference, > > changing the list search method or ordering won't prevent such an > > attack, it just means a different packet ordering is required. > > > > > > > > Tim Hudson suggested I submit this even though I haven't been able > > to find time to craft a patch. > Were you able to reproduce this performance problem? Note that N is at most 10 here. Assuming the DTLS packet reassembly code manages its queue correctly (It's rather buggy, but I forget if this was one of its problems. I eventually gave up trying to digest it and rewrote it from scratch on our end.), this check will ensure the queue size is tightly bounded: https://git.openssl.org/gitweb/?p=openssl.git;a=blob;f=ssl/statem/statem_dtls.c;h=d75483af6d40ad4c6ed9137eba8a7382a3b0ef0a;hb=HEAD#l634 It could probably be brought down a hair further too. There's no need to buffer more than the maximum number of messages in a supported handshake flight. (pqueue is still a silly data structure to be using here. A fixed-size ring buffer would be better. Or just a boring array since memmove on 10 pointers is cheap. But it's not hugely important.) David -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4558 Please log in as guest with password guest if prompted -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4558 Please log in as guest with password guest if prompted From rt at openssl.org Mon Jun 13 22:34:01 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 13 Jun 2016 22:34:01 +0000 Subject: [openssl-dev] [openssl.org #3454] remove OPENSSL_SYS_WIN constraint for EC_GFp_nistp224_method() In-Reply-To: <53C3A875.6020303@go-forward.net> References: <53C3A875.6020303@go-forward.net> Message-ID: fixed in master with commit b4b576d thanks! -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3454 Please log in as guest with password guest if prompted From rt at openssl.org Tue Jun 14 00:37:25 2016 From: rt at openssl.org (noloader@gmail.com via RT) Date: Tue, 14 Jun 2016 00:37:25 +0000 Subject: [openssl-dev] [openssl.org #4566] Re: Fatal error: Command failed for target `link_shlib.solaris' In-Reply-To: References: Message-ID: Close. It looks like it was cleared with Commit 5ec84dd75f7965942a55ef5382aa34b8417336c5. On Mon, Jun 13, 2016 at 4:12 PM, Jeffrey Walton wrote: > Just pulled latest source (Camellia changes): > > $ git rev-parse HEAD > 96d06c213d5a2c1af42dd3b5d7bcc4a65df90738 > > Config OK, Make fails at. Verified twice: > > SHOBJECTS="./libcrypto.a "; ( :; LIBDEPS="${LIBDEPS:--lresolv > -lsocket -lnsl -ldl}"; SHAREDCMD="${SHAREDCMD:-gcc}"; > SHAREDFLAGS="${SHAREDFLAGS:--DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG > -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -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/engines\"" -m64 -Wall -DL_ENDIAN -O3 > -pthread -DFILIO_H -Wa,--noexecstack -fPIC -m64 -shared > -static-libgcc}"; LIBPATH=`for x in $LIBDEPS; do echo $x; done | sed > -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_LIBRARY_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_shlib.solaris' > Current working directory /export/home/jwalton/openssl > *** Error code 1 > make: Fatal error: Command failed for target `libcrypto.so' > > ********** > > $ ./config > Operating system: i86pc-whatever-solaris2 > Configuring for solaris64-x86_64-gcc > Configuring OpenSSL version 1.1.0-pre6-dev (0x0x10100006L) > no-asan [default] OPENSSL_NO_ASAN (skip dir) > no-crypto-mdebug [default] OPENSSL_NO_CRYPTO_MDEBUG (skip dir) > no-crypto-mdebug-backtrace [default] > 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-fuzz-afl [default] OPENSSL_NO_FUZZ_AFL (skip dir) > no-fuzz-libfuzzer [default] OPENSSL_NO_FUZZ_LIBFUZZER (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-ssl-trace [default] OPENSSL_NO_SSL_TRACE (skip dir) > no-ssl3 [default] OPENSSL_NO_SSL3 (skip dir) > no-ssl3-method [default] OPENSSL_NO_SSL3_METHOD (skip dir) > no-ubsan [default] OPENSSL_NO_UBSAN (skip dir) > no-unit-test [default] OPENSSL_NO_UNIT_TEST (skip dir) > no-weak-ssl-ciphers [default] OPENSSL_NO_WEAK_SSL_CIPHERS (skip dir) > no-zlib [default] > no-zlib-dynamic [default] > Configuring for solaris64-x86_64-gcc > CC =gcc > CFLAG =-m64 -Wall -DL_ENDIAN -O3 -pthread -DFILIO_H -Wa,--noexecstack > SHARED_CFLAG =-fPIC > DEFINES =DSO_DLFCN HAVE_DLFCN_H NDEBUG OPENSSL_THREADS > OPENSSL_NO_STATIC_ENGINE OPENSSL_PIC 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 =-lresolv -lsocket -lnsl -ldl > APPS_OBJ = > CPUID_OBJ =x86_64cpuid.o > UPLINK_OBJ = > 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 > BLAKE2_OBJ = > PROCESSOR = > RANLIB =ranlib > ARFLAGS = > PERL =/usr/local/bin/perl > > SIXTY_FOUR_BIT_LONG mode > > Configured for solaris64-x86_64-gcc. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4566 Please log in as guest with password guest if prompted From rt at openssl.org Tue Jun 14 00:56:06 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 14 Jun 2016 00:56:06 +0000 Subject: [openssl-dev] [openssl.org #4566] Re: Fatal error: Command failed for target `link_shlib.solaris' In-Reply-To: References: Message-ID: closing as requested by OP -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4566 Please log in as guest with password guest if prompted From rt at openssl.org Tue Jun 14 07:24:31 2016 From: rt at openssl.org (noloader@gmail.com via RT) Date: Tue, 14 Jun 2016 07:24:31 +0000 Subject: [openssl-dev] [openssl.org #4567] Configure does not honor CFLAGS In-Reply-To: References: Message-ID: Working from latest sources. I'm trying to build a "debug" configuration with both -DNDEBUG (I don't want asserts firing) and -g3 (I want the symbolic constants). $ ./config no-asm -g3 -O0 -fno-omit-frame-pointer Operating system: i86pc-whatever-solaris2 Configuring for solaris64-x86_64-gcc Configuring OpenSSL version 1.1.0-pre6-dev (0x0x10100006L) ... CC =gcc CFLAG =-m64 -Wall -DL_ENDIAN -O3 -pthread -DFILIO_H -g3 -O0 -fno-omit-frame-pointer ... And: $ export CFLAGS="-DNDEBUG -g3 -O0" $ ./config Operating system: i86pc-whatever-solaris2 Configuring for solaris64-x86_64-gcc Configuring OpenSSL version 1.1.0-pre6-dev (0x0x10100006L) ... CC =gcc CFLAG =-m64 -Wall -DL_ENDIAN -O3 -pthread -DFILIO_H -Wa,--noexecstack SHARED_CFLAG =-fPIC ... -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4567 Please log in as guest with password guest if prompted From rt at openssl.org Tue Jun 14 07:33:23 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Tue, 14 Jun 2016 07:33:23 +0000 Subject: [openssl-dev] [openssl.org #4567] Configure does not honor CFLAGS In-Reply-To: References: Message-ID: Is this enough to satisfy you? ./config -DNDEBUG -g3 -O0 On Tue Jun 14 07:24:31 2016, noloader at gmail.com wrote: > Working from latest sources. I'm trying to build a "debug" > configuration with both -DNDEBUG (I don't want asserts firing) and -g3 > (I want the symbolic constants). > > $ ./config no-asm -g3 -O0 -fno-omit-frame-pointer > Operating system: i86pc-whatever-solaris2 > Configuring for solaris64-x86_64-gcc > Configuring OpenSSL version 1.1.0-pre6-dev (0x0x10100006L) > ... > CC =gcc > CFLAG =-m64 -Wall -DL_ENDIAN -O3 -pthread -DFILIO_H -g3 -O0 > -fno-omit-frame-pointer > ... > > > And: > > $ export CFLAGS="-DNDEBUG -g3 -O0" > $ ./config > Operating system: i86pc-whatever-solaris2 > Configuring for solaris64-x86_64-gcc > Configuring OpenSSL version 1.1.0-pre6-dev (0x0x10100006L) > ... > CC =gcc > CFLAG =-m64 -Wall -DL_ENDIAN -O3 -pthread -DFILIO_H -Wa,-- > noexecstack > SHARED_CFLAG =-fPIC > ... -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4567 Please log in as guest with password guest if prompted From rt at openssl.org Tue Jun 14 07:35:11 2016 From: rt at openssl.org (noloader@gmail.com via RT) Date: Tue, 14 Jun 2016 07:35:11 +0000 Subject: [openssl-dev] [openssl.org #4567] Configure does not honor CFLAGS In-Reply-To: References: Message-ID: On Tue, Jun 14, 2016 at 3:33 AM, Richard Levitte via RT wrote: > Is this enough to satisfy you? > > ./config -DNDEBUG -g3 -O0 Yes, that would be good. no-asm and no-omit-frame-pointer on x86 may be good choices, too. Jeff > On Tue Jun 14 07:24:31 2016, noloader at gmail.com wrote: >> Working from latest sources. I'm trying to build a "debug" >> configuration with both -DNDEBUG (I don't want asserts firing) and -g3 >> (I want the symbolic constants). >> >> $ ./config no-asm -g3 -O0 -fno-omit-frame-pointer >> Operating system: i86pc-whatever-solaris2 >> Configuring for solaris64-x86_64-gcc >> Configuring OpenSSL version 1.1.0-pre6-dev (0x0x10100006L) >> ... >> CC =gcc >> CFLAG =-m64 -Wall -DL_ENDIAN -O3 -pthread -DFILIO_H -g3 -O0 >> -fno-omit-frame-pointer >> ... >> >> >> And: >> >> $ export CFLAGS="-DNDEBUG -g3 -O0" >> $ ./config >> Operating system: i86pc-whatever-solaris2 >> Configuring for solaris64-x86_64-gcc >> Configuring OpenSSL version 1.1.0-pre6-dev (0x0x10100006L) >> ... >> CC =gcc >> CFLAG =-m64 -Wall -DL_ENDIAN -O3 -pthread -DFILIO_H -Wa,-- >> noexecstack >> SHARED_CFLAG =-fPIC >> ... -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4567 Please log in as guest with password guest if prompted From rt at openssl.org Tue Jun 14 07:43:06 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Tue, 14 Jun 2016 07:43:06 +0000 Subject: [openssl-dev] [openssl.org #4567] Configure does not honor CFLAGS In-Reply-To: References: Message-ID: Cool. That closes this ticket. BTW, you're right, we don't honor a CFLAGS env var. We never did. We take the cflags on the configuration command line. Cheers, Richard On Tue Jun 14 07:35:11 2016, noloader at gmail.com wrote: > On Tue, Jun 14, 2016 at 3:33 AM, Richard Levitte via RT > wrote: > > Is this enough to satisfy you? > > > > ./config -DNDEBUG -g3 -O0 > > Yes, that would be good. > > no-asm and no-omit-frame-pointer on x86 may be good choices, too. > > Jeff > > > On Tue Jun 14 07:24:31 2016, noloader at gmail.com wrote: > >> Working from latest sources. I'm trying to build a "debug" > >> configuration with both -DNDEBUG (I don't want asserts firing) and > >> -g3 > >> (I want the symbolic constants). > >> > >> $ ./config no-asm -g3 -O0 -fno-omit-frame-pointer > >> Operating system: i86pc-whatever-solaris2 > >> Configuring for solaris64-x86_64-gcc > >> Configuring OpenSSL version 1.1.0-pre6-dev (0x0x10100006L) > >> ... > >> CC =gcc > >> CFLAG =-m64 -Wall -DL_ENDIAN -O3 -pthread -DFILIO_H -g3 -O0 > >> -fno-omit-frame-pointer > >> ... > >> > >> > >> And: > >> > >> $ export CFLAGS="-DNDEBUG -g3 -O0" > >> $ ./config > >> Operating system: i86pc-whatever-solaris2 > >> Configuring for solaris64-x86_64-gcc > >> Configuring OpenSSL version 1.1.0-pre6-dev (0x0x10100006L) > >> ... > >> CC =gcc > >> CFLAG =-m64 -Wall -DL_ENDIAN -O3 -pthread -DFILIO_H -Wa,-- > >> noexecstack > >> SHARED_CFLAG =-fPIC > >> ... -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4567 Please log in as guest with password guest if prompted From rt at openssl.org Tue Jun 14 07:48:46 2016 From: rt at openssl.org (noloader@gmail.com via RT) Date: Tue, 14 Jun 2016 07:48:46 +0000 Subject: [openssl-dev] [openssl.org #4567] Configure does not honor CFLAGS In-Reply-To: References: Message-ID: On Tue, Jun 14, 2016 at 3:43 AM, Richard Levitte via RT wrote: > Cool. That closes this ticket. Thank you very much. > BTW, you're right, we don't honor a CFLAGS env var. We never did. We take the > cflags on the configuration command line. There's always hope. Its eternal :) Jeff -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4567 Please log in as guest with password guest if prompted From rt at openssl.org Tue Jun 14 09:43:42 2016 From: rt at openssl.org (Matt Caswell via RT) Date: Tue, 14 Jun 2016 09:43:42 +0000 Subject: [openssl-dev] [openssl.org #2388] out-of-date comment for renegotiation handling In-Reply-To: <4CF94155.30202@oracle.com> References: <4CF94155.30202@oracle.com> Message-ID: Fixed in commit e7653f3bab. Closing ticket. Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2388 Please log in as guest with password guest if prompted From rt at openssl.org Tue Jun 14 15:26:49 2016 From: rt at openssl.org (Loic Etienne via RT) Date: Tue, 14 Jun 2016 15:26:49 +0000 Subject: [openssl-dev] [openssl.org #4568] Enhancement request: Capability vector accessor function for arm and ppc In-Reply-To: References: Message-ID: For arm and ppc, define functions corresponding to unsigned long *OPENSSL_ia32cap(), returning a pointer to the capability vector, or NULL on an unsuitable architecture: unsigned int *OPENSSL_armcap_loc(); unsigned int *OPENSSL_ppccap_loc(); Otherwise, an extern declaration of OPENSSL_armcap_P (or OPENSSL_ppccap_P) is required, depending on the architecture, which has to be detected by other means. This is inconvenient. Furthermore, arm_arch.h and ppc_arch.h not available in the deployed include folder, making a declaration mismatch possible. Further architectures may be considered as well. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4568 Please log in as guest with password guest if prompted From rt at openssl.org Tue Jun 14 15:42:50 2016 From: rt at openssl.org (Loic Etienne via RT) Date: Tue, 14 Jun 2016 15:42:50 +0000 Subject: [openssl-dev] [openssl.org #4569] Enhancement request: Macros for x86 capability bits In-Reply-To: References: Message-ID: For x86, define macros for capability bits (like for arm and pcc), according to https://www.openssl.org/docs/manmaster/crypto/OPENSSL_ia32cap.html: #define X86_TSCNT (1UL << 4 ) #define X86_CLFLUSH (1UL << 19) #define X86_RC4PATH (1UL << 20) #define X86_MMX (1UL << 23) #define X86_FXSR (1UL << 24) #define X86_SSE (1UL << 25) #define X86_SSE2 (1UL << 26) #define X86_HTHREAD (1UL << 28) #define X86_INTELCPU (1UL << 30) #define X86_PCLMULQDQ (1UL << 33) #define X86_SSSE3 (1UL << 41) #define X86_AMDXOP (1UL << 43) #define X86_MOVBE (1UL << 54) #define X86_AESNI (1UL << 57) #define X86_XSAVE (1UL << 58) #define X86_OSXSAVE (1UL << 59) #define X86_AVX (1UL << 60) #define X86_RDRAND (1UL << 62) -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4569 Please log in as guest with password guest if prompted From rt at openssl.org Tue Jun 14 15:43:27 2016 From: rt at openssl.org (Loic Etienne via RT) Date: Tue, 14 Jun 2016 15:43:27 +0000 Subject: [openssl-dev] [openssl.org #4570] Enhancement request: Configuration option no-hw-aes In-Reply-To: References: Message-ID: Define a configuration option no-hw-aes. No aes processor instruction should be compiled if one of the configuration options no-hw or no-hw-aes is given. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4570 Please log in as guest with password guest if prompted From rt at openssl.org Tue Jun 14 15:57:43 2016 From: rt at openssl.org (Stuart Kemp via RT) Date: Tue, 14 Jun 2016 15:57:43 +0000 Subject: [openssl-dev] [openssl.org #3699] Resolved: openssl-1.0.2, fips sparc multiply defined _sparcv9_vis1_instrument_bus, _sparcv9_vis1_instrument_bus2 In-Reply-To: <5B5209CB698EEC4D9710CEF6A83600EE35A82B84@prvxmb03.microfocus.com> References: <5B5209CB698EEC4D9710CEF6A83600EE35A82B84@prvxmb03.microfocus.com> Message-ID: Will this change be merged into the latest 1.0.2 and/or 1.1.0 branches? -----Original Message----- From: Rich Salz via RT [mailto:rt at openssl.org] Sent: Monday, June 13, 2016 3:27 PM To: Stuart Kemp Subject: [openssl.org #3699] Resolved: openssl-1.0.2, fips sparc multiply defined _sparcv9_vis1_instrument_bus, _sparcv9_vis1_instrument_bus2 According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3699 Please log in as guest with password guest if prompted -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3699 Please log in as guest with password guest if prompted From rt at openssl.org Tue Jun 14 16:24:39 2016 From: rt at openssl.org (Maciej Grzymkowski via RT) Date: Tue, 14 Jun 2016 16:24:39 +0000 Subject: [openssl-dev] [openssl.org #4571] SegFault when OBJ_create is called from multiple threads (despite setting up locking_function) In-Reply-To: References: Message-ID: Hi, I may, or may not, stumbled upon an issue with OpenSSL multihreading when calling OBJ_create to define a new extension. Briefly, calling below code from several threads at once - despite setting up of locking functions - may cause segmentation fault due to supposedly double free/corruption. char CUSTOM_EXTENSION_OID_VALUE[] = "1.2.345.678901.2.3.4"; OBJ_create(CUSTOM_EXTENSION_OID_VALUE, "customExtension", "Custom Extension"); Though this may not be a recommended set of calls to be executed over and over again, I'd expect proper locking_function to guard against critical failures. The error is output when the crash happens as: *** Error in `./openssl_object_add_segfault_test': double free or corruption (fasttop): 0x00007f50ac002620 *** gdb used to look at the dumped core reveals: (gdb) bt #0 0x00007f50feea8cc9 in __GI_raise (sig=sig at entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x00007f50feeac0d8 in __GI_abort () at abort.c:89 #2 0x00007f50feee5394 in __libc_message (do_abort=do_abort at entry=1, fmt=fmt at entry=0x7f50feff3b28 "*** Error in `%s': %s: 0x%s ***\n") at ../sysdeps/posix/libc_fatal.c:175 #3 0x00007f50feef166e in malloc_printerr (ptr=, str=0x7f50feff3cf0 "double free or corruption (fasttop)", action=1) at malloc.c:4996 #4 _int_free (av=, p=, have_lock=0) at malloc.c:3840 #5 0x000000000044a12d in CRYPTO_free () #6 0x000000000044d921 in OBJ_add_object () #7 0x000000000044ebcd in OBJ_create () #8 0x000000000040364c in run()::{lambda()#1}::operator()() const () OpenSSL versions tested were: openssl-1.0.1t, openssl-1.0.1s and openssl-1.0.2h.Above or similar occurred on all the tested versions. I've noticed the behaviour on Ubuntu 14.04, using gcc 4.8.4, compiling C++11 code. I first noticed the issue using clang, so I suppose compiler is irrelevant. I do have a minimal example (just a main, initOpenSSL and runThreads functions, 70 lines of code + a Makefile) reproducing the issue. I am not sure if emailing them here is the right way, if it is please let me know and I'll paste it in. Kind regards, Maciej -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4571 Please log in as guest with password guest if prompted From rt at openssl.org Tue Jun 14 16:41:02 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Tue, 14 Jun 2016 16:41:02 +0000 Subject: [openssl-dev] [openssl.org #4568] Enhancement request: Capability vector accessor function for arm and ppc In-Reply-To: <59c104f5cd044a8fb0aa2dd6f931b941@usma1ex-dag1mb1.msg.corp.akamai.com> References: <59c104f5cd044a8fb0aa2dd6f931b941@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: Doesn't it make more sense to have a single API that returns the platform-specific flags? -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4568 Please log in as guest with password guest if prompted From rt at openssl.org Tue Jun 14 16:44:01 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 14 Jun 2016 16:44:01 +0000 Subject: [openssl-dev] [openssl.org #4571] SegFault when OBJ_create is called from multiple threads (despite setting up locking_function) In-Reply-To: References: Message-ID: No, these routines are not guaranteed to be thread-safe. Sorry. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4571 Please log in as guest with password guest if prompted From rt at openssl.org Tue Jun 14 16:46:56 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 14 Jun 2016 16:46:56 +0000 Subject: [openssl-dev] [openssl.org #4562] Possible bug in OPENSSL_config - ignore input parameter In-Reply-To: <575A9CAB.2080500@ua7.net> References: <575A9CAB.2080500@ua7.net> Message-ID: Documentation fixed in 1.0.2 (commit dd8a1f2).Also fix in master (commit cda3ae5), which also renamed the variables from config_file to appname, etc., in the source code. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4562 Please log in as guest with password guest if prompted From rt at openssl.org Tue Jun 14 17:14:45 2016 From: rt at openssl.org (Maciej Grzymkowski via RT) Date: Tue, 14 Jun 2016 17:14:45 +0000 Subject: [openssl-dev] [openssl.org #4571] SegFault when OBJ_create is called from multiple threads (despite setting up locking_function) In-Reply-To: References: Message-ID: That's fine with me, though, it might bite someone in the future. Is there any documentation or site listing which funcs would be thread-safe? (if this is offtopic, please let me know, and we'll simply end the thread) On Tue, Jun 14, 2016 at 6:44 PM, Rich Salz via RT wrote: > No, these routines are not guaranteed to be thread-safe. Sorry. > > -- > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4571 > Please log in as guest with password guest if prompted > > -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4571 Please log in as guest with password guest if prompted From rt at openssl.org Tue Jun 14 17:18:22 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Tue, 14 Jun 2016 17:18:22 +0000 Subject: [openssl-dev] [openssl.org #4571] SegFault when OBJ_create is called from multiple threads (despite setting up locking_function) In-Reply-To: References: Message-ID: > That's fine with me, though, it might bite someone in the future. Is there any > documentation or site listing which funcs would be thread-safe? (if this is > offtopic, please let me know, and we'll simply end the thread) Please take it to openssl-dev mailing list. It's a good discussion to have! -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4571 Please log in as guest with password guest if prompted From rt at openssl.org Tue Jun 14 17:43:36 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 14 Jun 2016 17:43:36 +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: It will be in 1.0.2 shortly. It's not relevant for 1.1 which doesn't support FIPS. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3699 Please log in as guest with password guest if prompted From rt at openssl.org Tue Jun 14 17:55:44 2016 From: rt at openssl.org (Andy Polyakov via RT) Date: Tue, 14 Jun 2016 17:55:44 +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: <71e0f373-a51b-3a49-e94b-853c2e14cc6f@openssl.org> References: <54DC8E6A0200002800011D4C@prv-mh.provo.novell.com> <71e0f373-a51b-3a49-e94b-853c2e14cc6f@openssl.org> Message-ID: > It will be in 1.0.2 shortly. Applied to 1.0.2. > It's not relevant for 1.1 which doesn't support FIPS. Because current 2.x version of FIPS module won't be supported with 1.1, so that solution in 1.1 would have to be different. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3699 Please log in as guest with password guest if prompted From rt at openssl.org Tue Jun 14 19:06:07 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 14 Jun 2016 19:06:07 +0000 Subject: [openssl-dev] [openssl.org #4546] bug: misleading docs for EVP_*{Cipher, Encrypt, Decrypt}Final() functions in release branch In-Reply-To: <20160529212142.GA32264@bell> References: <20160529212142.GA32264@bell> Message-ID: commit 95fb422 pushed to 1.0.2 thanks! -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4546 Please log in as guest with password guest if prompted From rt at openssl.org Tue Jun 14 20:08:34 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 14 Jun 2016 20:08:34 +0000 Subject: [openssl-dev] [openssl.org #4507] Bugs due to missing error handling In-Reply-To: <570B0086.7030208@cs.columbia.edu> References: <570B0086.7030208@cs.columbia.edu> Message-ID: fixed some time ago. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4507 Please log in as guest with password guest if prompted From rt at openssl.org Tue Jun 14 20:30:09 2016 From: rt at openssl.org (David Benjamin via RT) Date: Tue, 14 Jun 2016 20:30:09 +0000 Subject: [openssl-dev] [openssl.org #4572] SSL_set_bio and friends In-Reply-To: References: Message-ID: I recently made some changes around BoringSSL's SSL_set_bio, etc. which you all might be interested in. The BIO management has two weird behaviors right now: 1. The existence of bbio is leaked in the public API when it should be an implementation detail. (Otherwise you're stuck with it for DTLS where it's really messy.) SSL_get_wbio will return it, and SSL_set_bio messes up when the bbio is active. 2. SSL_set_bio's object ownership story is a mess. It also doesn't quite work. This crashes: SSL_set_fd(ssl, 1); SSL_set_rfd(ssl, 2); But this does not: SSL_set_fd(ssl, 1); SSL_set_wfd(ssl, 2); Not that anyone would do such a thing, but the asymmetry is off. For 1, I made this change: https://boringssl.googlesource.com/boringssl/+/2f87112b963fe9dee6a75b23a8dae45000001063%5E%21/ SSL_get_wbio now always returns the true wbio. BIO_set_bio is aware of bbio and behaves accordingly. Then for 2, I wrote this test: https://boringssl.googlesource.com/boringssl/+/5c0fb889a1348ecaa5691f6139f9d60a610f2129%5E%21/ And then made this change: https://boringssl.googlesource.com/boringssl/+/f715c423224a292d79ba0e3df373c828fbae29f7%5E%21/ [Plus comment typo fix] Releasing ssl->{rbio,wbio} is now much more straight-forward. All the ownership quirks are left in SSL_set_bio. It's messy, but it's the best option I found which preserves the existing calling patterns. The different cases reflect the desired behavior inherently having a lot of cases. For OpenSSL master, I believe it'd also work to add an s->rbio != s->wbio check to SSL_set_rbio, but I think those are worse semantics for SSL_set_{rbio,wbio}. They are new APIs, so, before it's too late, give them clear semantics like "SSL_set_rbio takes ownership of its argument", consistent with "set0" functions, rather than a mix of "set0" and "set1". David -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4572 Please log in as guest with password guest if prompted From rt at openssl.org Tue Jun 14 20:31:20 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 14 Jun 2016 20:31:20 +0000 Subject: [openssl-dev] [openssl.org #4223] fix request for OpenSSL (not version specific) In-Reply-To: <201601071928.u07JSJN2021708@d03av04.boulder.ibm.com> References: <201601071928.u07JSJN2021708@d03av04.boulder.ibm.com> Message-ID: TANDEM is not a supported platform. Sorry. You could make up a dummy file, like in /usr/local/include/sys, and add that -I flag. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4223 Please log in as guest with password guest if prompted From rt at openssl.org Tue Jun 14 20:34:15 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 14 Jun 2016 20:34:15 +0000 Subject: [openssl-dev] [openssl.org #4259] Bug: Apparent memory leak in kssl.c In-Reply-To: <0D659A5A3F184B459470CC3DFE7A4CE12FDAFA40@MTK-SMS-XCH02.digi.com> References: <0D659A5A3F184B459470CC3DFE7A4CE12FDAFA40@MTK-SMS-XCH02.digi.com> Message-ID: Seems to have been fixed some time ago. thanks. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4259 Please log in as guest with password guest if prompted From rt at openssl.org Tue Jun 14 20:37:19 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 14 Jun 2016 20:37:19 +0000 Subject: [openssl-dev] [openssl.org #4349] Pull request for bilinear pairings In-Reply-To: References: Message-ID: See the PR for all information; don't need a duplicate ticket now. (Esp since this is post-1.1) -- 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 Tue Jun 14 20:38:52 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 14 Jun 2016 20:38:52 +0000 Subject: [openssl-dev] [openssl.org #4205] Improve the default TLS session ticket key In-Reply-To: <1451082436.2231057.476360850.74E50237@webmail.messagingengine.com> References: <1451082436.2231057.476360850.74E50237@webmail.messagingengine.com> Message-ID: We don't need an RT ticket that matches a GH issue or PR. Especially for post-1.1 things :) -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4205 Please log in as guest with password guest if prompted From rt at openssl.org Tue Jun 14 20:42:36 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 14 Jun 2016 20:42:36 +0000 Subject: [openssl-dev] [openssl.org #4038] SSLv2 session reuse is broken on the 1.0.2 branch In-Reply-To: <55F32FC6.1030705@akamai.com> References: <55F32FC6.1030705@akamai.com> Message-ID: SSLv2 is not supported any more. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4038 Please log in as guest with password guest if prompted From rt at openssl.org Tue Jun 14 21:07:52 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 14 Jun 2016 21:07:52 +0000 Subject: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash function (let's kill md5sum!) In-Reply-To: References: Message-ID: done. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3897 Please log in as guest with password guest if prompted From rt at openssl.org Tue Jun 14 21:08:34 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 14 Jun 2016 21:08:34 +0000 Subject: [openssl-dev] [openssl.org #3898] Bug fix: missing line from trunk crypto/comp/comp_lcl.h In-Reply-To: References: Message-ID: fixed awhile ago, thanks. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3898 Please log in as guest with password guest if prompted From rt at openssl.org Tue Jun 14 21:42:33 2016 From: rt at openssl.org (Cleveland Watson via RT) Date: Tue, 14 Jun 2016 21:42:33 +0000 Subject: [openssl-dev] [openssl.org #4223] fix request for OpenSSL (not version specific) In-Reply-To: References: <201601071928.u07JSJN2021708@d03av04.boulder.ibm.com> Message-ID: Rich, thank you for your reply. We have a workaround, so we'll just continue using it. Best Regards, Cleve Watson From: Rich Salz via RT To: Cleveland Watson/Dallas/IBM at IBMUS Cc: openssl-dev at openssl.org Date: 06/14/2016 03:31 PM Subject: [openssl.org #4223] fix request for OpenSSL (not version specific) TANDEM is not a supported platform. Sorry. You could make up a dummy file, like in /usr/local/include/sys, and add that -I flag. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4223 Please log in as guest with password guest if prompted -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4223 Please log in as guest with password guest if prompted From rt at openssl.org Tue Jun 14 22:22:04 2016 From: rt at openssl.org (Matt Caswell via RT) Date: Tue, 14 Jun 2016 22:22:04 +0000 Subject: [openssl-dev] [openssl.org #4038] SSLv2 session reuse is broken on the 1.0.2 branch In-Reply-To: References: <55F32FC6.1030705@akamai.com> Message-ID: On Tue Jun 14 20:42:36 2016, rsalz wrote: > SSLv2 is not supported any more. Ummmm....yes it is on the 1.0.2 branch? It is off by default though. Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4038 Please log in as guest with password guest if prompted From rt at openssl.org Wed Jun 15 01:10:28 2016 From: rt at openssl.org (paul.dale@oracle.com via RT) Date: Wed, 15 Jun 2016 01:10:28 +0000 Subject: [openssl-dev] [openssl.org #4573] BUG -- Documentation issue with RAND_add in rand.pod In-Reply-To: References: Message-ID: The doc/crypto/rand.pod file incorrectly documents the prototype for the RAND_add function. The last argument is a double not an int. It is correctly documented in the doc/crypto/RAND_add.pod file. Fix attached. Pauli -- Oracle Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4573 Please log in as guest with password guest if prompted -------------- next part -------------- diff --git a/doc/crypto/rand.pod b/doc/crypto/rand.pod index 76ec0b6..80c6f3a 100644 --- a/doc/crypto/rand.pod +++ b/doc/crypto/rand.pod @@ -14,7 +14,7 @@ rand - pseudo-random number generator int RAND_pseudo_bytes(unsigned char *buf, int num); void RAND_seed(const void *buf, int num); - void RAND_add(const void *buf, int num, int entropy); + void RAND_add(const void *buf, int num, double entropy); int RAND_status(void); int RAND_load_file(const char *file, long max_bytes); From rt at openssl.org Wed Jun 15 08:32:38 2016 From: rt at openssl.org (Loic Etienne via RT) Date: Wed, 15 Jun 2016 08:32:38 +0000 Subject: [openssl-dev] [openssl.org #4568] Enhancement request: Capability vector accessor function for arm and ppc In-Reply-To: References: <59c104f5cd044a8fb0aa2dd6f931b941@usma1ex-dag1mb1.msg.corp.akamai.com>, Message-ID: Identifying the bits relevant to openssl for each architecture and making them available through architecture-independent functions (getter and setters) would be very convenient, indeed. At the risk that future architectures do not fit into the pattern defined today. If this approach is implemented, I suggest a copy of original capability vector to be kept, for the setter to fail if a bit is tentatively set on an unsuitable processor (otherwise, subsequent cryptographic operations affected by the bit in question would fail anyway). Thus a setter could return the previous value (0 or 1) on success, and -1 on failure. I think that implementing the architecture specific functions suggested in this ticket is easy and already useful. Defining architecture-independent functions probably requires more hard thinking, and could be done in a later step. ________________________________ From: Salz, Rich via RT Sent: Tuesday, June 14, 2016 6:41:02 PM To: Loic Etienne Cc: openssl-dev at openssl.org Subject: RE: [openssl-dev] [openssl.org #4568] Enhancement request: Capability vector accessor function for arm and ppc Doesn't it make more sense to have a single API that returns the platform-specific flags? -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4568 Please log in as guest with password guest if prompted -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4568 Please log in as guest with password guest if prompted From rt at openssl.org Wed Jun 15 12:09:28 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Wed, 15 Jun 2016 12:09:28 +0000 Subject: [openssl-dev] [openssl.org #4038] SSLv2 session reuse is broken on the 1.0.2 branch In-Reply-To: References: <55F32FC6.1030705@akamai.com> Message-ID: So are we still fixing SSLv2 bugs? Or are they too low on the priority list? -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4038 Please log in as guest with password guest if prompted From matt at openssl.org Wed Jun 15 12:44:48 2016 From: matt at openssl.org (Matt Caswell) Date: Wed, 15 Jun 2016 13:44:48 +0100 Subject: [openssl-dev] [openssl.org #4038] SSLv2 session reuse is broken on the 1.0.2 branch In-Reply-To: References: <55F32FC6.1030705@akamai.com> Message-ID: <57614DC0.1080703@openssl.org> On 15/06/16 13:09, Salz, Rich via RT wrote: > So are we still fixing SSLv2 bugs? Or are they too low on the priority list? They're certainly low priority, but we are still fixing them. Matt From rt at openssl.org Wed Jun 15 13:31:41 2016 From: rt at openssl.org (Short, Todd via RT) Date: Wed, 15 Jun 2016 13:31:41 +0000 Subject: [openssl-dev] [openssl.org #4074] [PATCH] Fixes for when PSK, SRP, SRTP and DTLS1 are disabled In-Reply-To: References: Message-ID: This has been resolved master, and can be closed. -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4074 Please log in as guest with password guest if prompted From rt at openssl.org Wed Jun 15 13:33:43 2016 From: rt at openssl.org (Short, Todd via RT) Date: Wed, 15 Jun 2016 13:33:43 +0000 Subject: [openssl-dev] [openssl.org #3724] In-Reply-To: <799DD931-AF8F-4569-8988-C6070069631A@akamai.com> References: <799DD931-AF8F-4569-8988-C6070069631A@akamai.com> Message-ID: The new async feature in master/1.1.0 makes complete breaks this patch. This can probably be closed. -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3724 Please log in as guest with password guest if prompted From rt at openssl.org Wed Jun 15 13:35:38 2016 From: rt at openssl.org (Short, Todd via RT) Date: Wed, 15 Jun 2016 13:35:38 +0000 Subject: [openssl-dev] [openssl.org #3729] In-Reply-To: <510821DA-7AE1-4984-B746-9B086530542D@akamai.com> References: <510821DA-7AE1-4984-B746-9B086530542D@akamai.com> Message-ID: The changes to master/1.1.0 for pipelining completely break this patch. So, there?s little point in trying to add this. -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3729 Please log in as guest with password guest if prompted From rt at openssl.org Wed Jun 15 13:39:38 2016 From: rt at openssl.org (Short, Todd via RT) Date: Wed, 15 Jun 2016 13:39:38 +0000 Subject: [openssl-dev] [openssl.org #3877] In-Reply-To: <5BE900F9-1B23-4DD1-AF81-79C56D09C5F6@akamai.com> References: <5BE900F9-1B23-4DD1-AF81-79C56D09C5F6@akamai.com> Message-ID: This could be closed, as it?s now on GitHub: https://github.com/openssl/openssl/pull/941 -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3877 Please log in as guest with password guest if prompted From rt at openssl.org Wed Jun 15 13:40:12 2016 From: rt at openssl.org (Short, Todd via RT) Date: Wed, 15 Jun 2016 13:40:12 +0000 Subject: [openssl-dev] [openssl.org #3867] In-Reply-To: References: <5BE900F9-1B23-4DD1-AF81-79C56D09C5F6@akamai.com> Message-ID: This could be closed, as it?s now on GitHub: https://github.com/openssl/openssl/pull/941 -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3867 Please log in as guest with password guest if prompted From rt at openssl.org Wed Jun 15 13:41:06 2016 From: rt at openssl.org (Short, Todd via RT) Date: Wed, 15 Jun 2016 13:41:06 +0000 Subject: [openssl-dev] [openssl.org #3722] In-Reply-To: <486DE61B-F15C-4772-BBB0-8F3132E0EC80@akamai.com> References: <486DE61B-F15C-4772-BBB0-8F3132E0EC80@akamai.com> Message-ID: This could be closed, as it?s now on GitHub: https://github.com/openssl/openssl/pull/946 -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3722 Please log in as guest with password guest if prompted From rt at openssl.org Wed Jun 15 13:42:18 2016 From: rt at openssl.org (Short, Todd via RT) Date: Wed, 15 Jun 2016 13:42:18 +0000 Subject: [openssl-dev] [openssl.org #3780] In-Reply-To: References: Message-ID: The async changes on master/1.1.0 obsolete this patch. -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3780 Please log in as guest with password guest if prompted From bkaduk at akamai.com Wed Jun 15 13:47:38 2016 From: bkaduk at akamai.com (Kaduk, Ben) Date: Wed, 15 Jun 2016 13:47:38 +0000 Subject: [openssl-dev] [openssl.org #4038] SSLv2 session reuse is broken on the 1.0.2 branch In-Reply-To: References: <55F32FC6.1030705@akamai.com> Message-ID: <6131FD08-84E3-4003-B02C-A285BEBBA99F@akamai.com> We are patched locally and don?t really need the patch integrated upstream; I mostly just wanted to note the issue in the bugtracker in case someone else ran into it. -Ben On 6/15/16, 08:09, "Salz, Rich via RT" wrote: >So are we still fixing SSLv2 bugs? Or are they too low on the priority list? > > >-- >Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4038 >Please log in as guest with password guest if prompted > > From rt at openssl.org Wed Jun 15 13:47:47 2016 From: rt at openssl.org (Kaduk, Ben via RT) Date: Wed, 15 Jun 2016 13:47:47 +0000 Subject: [openssl-dev] [openssl.org #4038] SSLv2 session reuse is broken on the 1.0.2 branch In-Reply-To: <6131FD08-84E3-4003-B02C-A285BEBBA99F@akamai.com> References: <55F32FC6.1030705@akamai.com> <6131FD08-84E3-4003-B02C-A285BEBBA99F@akamai.com> Message-ID: We are patched locally and don?t really need the patch integrated upstream; I mostly just wanted to note the issue in the bugtracker in case someone else ran into it. -Ben On 6/15/16, 08:09, "Salz, Rich via RT" wrote: >So are we still fixing SSLv2 bugs? Or are they too low on the priority list? > > >-- >Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4038 >Please log in as guest with password guest if prompted > > -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4038 Please log in as guest with password guest if prompted From rt at openssl.org Wed Jun 15 13:49:15 2016 From: rt at openssl.org (Rich Salz via RT) Date: Wed, 15 Jun 2016 13:49:15 +0000 Subject: [openssl-dev] [openssl.org #3729] Patch to add support for iovec-based IO in OpenSSL In-Reply-To: References: <82A0649D-764B-4716-945C-04A50AA4CB67@akamai.com> Message-ID: I like the idea; let's keep it open for the future. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3729 Please log in as guest with password guest if prompted From rsalz at akamai.com Wed Jun 15 13:51:37 2016 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 15 Jun 2016 13:51:37 +0000 Subject: [openssl-dev] [openssl.org #4038] SSLv2 session reuse is broken on the 1.0.2 branch In-Reply-To: <6131FD08-84E3-4003-B02C-A285BEBBA99F@akamai.com> References: <55F32FC6.1030705@akamai.com> <6131FD08-84E3-4003-B02C-A285BEBBA99F@akamai.com> Message-ID: <517293a373e54ca6a330055ec3ca2ee6@usma1ex-dag1mb1.msg.corp.akamai.com> I think OpenSSL needs to decide if SSLv2 bugs will be getting fixed. Matt and I disagree :) From rt at openssl.org Wed Jun 15 14:03:25 2016 From: rt at openssl.org (Short, Todd via RT) Date: Wed, 15 Jun 2016 14:03:25 +0000 Subject: [openssl-dev] [openssl.org #3882] In-Reply-To: <1FF8BAE0-CF37-44DF-819A-857C62441608@akamai.com> References: <1FF8BAE0-CF37-44DF-819A-857C62441608@akamai.com> Message-ID: Based on discussion, it does not appear as this will be fixed, and requires an unusual set of circumstances for it to happen. It can probably be closed. -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3882 Please log in as guest with password guest if prompted From rt at openssl.org Wed Jun 15 14:22:15 2016 From: rt at openssl.org (Rich Salz via RT) Date: Wed, 15 Jun 2016 14:22:15 +0000 Subject: [openssl-dev] [openssl.org #3875] [PATCH] Add external X509_STORE to SSL_CTX In-Reply-To: <007C934D-7A2C-47A2-94B2-B681EED65F4E@akamai.com> References: <007C934D-7A2C-47A2-94B2-B681EED65F4E@akamai.com> Message-ID: This can be done with the (now finally documented) EXDATA facility. Closing this ticket. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3875 Please log in as guest with password guest if prompted From rt at openssl.org Wed Jun 15 14:52:43 2016 From: rt at openssl.org (Rich Salz via RT) Date: Wed, 15 Jun 2016 14:52:43 +0000 Subject: [openssl-dev] [openssl.org #4487] Dirty compile under Windows 7 and MSVC 2012 (four to six non-trivial) In-Reply-To: References: Message-ID: Believe fixed. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4487 Please log in as guest with password guest if prompted From rt at openssl.org Wed Jun 15 15:01:35 2016 From: rt at openssl.org (Rich Salz via RT) Date: Wed, 15 Jun 2016 15:01:35 +0000 Subject: [openssl-dev] [openssl.org #4362] chacha-x86.pl has stricter aliasing requirements than other files In-Reply-To: References: Message-ID: I think for now, we just note this in the documentation: behavior for overlapping buffers, and even in-place buffers, is not defined. It's like memcpy() vs memmove(). -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4362 Please log in as guest with password guest if prompted From rt at openssl.org Wed Jun 15 15:09:23 2016 From: rt at openssl.org (Loic Etienne via RT) Date: Wed, 15 Jun 2016 15:09:23 +0000 Subject: [openssl-dev] [openssl.org #4568] Enhancement request: Capability vector accessor function for arm and ppc In-Reply-To: References: <59c104f5cd044a8fb0aa2dd6f931b941@usma1ex-dag1mb1.msg.corp.akamai.com>, , Message-ID: Two more observations. OPENSSL_ia32cap_loc() alters the underlying OPENSSL_ia32cap_P, the bits not fitting into the expected integer size being zeroed. I do not know if it is practically relevant, but it is strange that a read has side effects. It would be a good reason for dedicated, architecture independent setters and getters. The documentation (https://www.openssl.org/docs/man1.0.2/crypto/OPENSSL_ia32cap.html) says: unsigned int *OPENSSL_ia32cap_loc(void) it should say: unsigned long *OPENSSL_ia32cap_loc(void) like in openssl-1.0.2h/crypto/crypto.h ________________________________ From: Loic Etienne Sent: Wednesday, June 15, 2016 10:17:17 AM To: rt at openssl.org Cc: openssl-dev at openssl.org Subject: Re: [openssl-dev] [openssl.org #4568] Enhancement request: Capability vector accessor function for arm and ppc Identifying the bits relevant to openssl for each architecture and making them available through architecture-independent functions (getter and setters) would be very convenient, indeed. At the risk that future architectures do not fit into the pattern defined today. If this approach is implemented, I suggest a copy of original capability vector to be kept, for the setter to fail if a bit is tentatively set on an unsuitable processor (otherwise, subsequent cryptographic operations affected by the bit in question would fail anyway). Thus a setter could return the previous value (0 or 1) on success, and -1 on failure. I think that implementing the architecture specific functions suggested in this ticket is easy and already useful. Defining architecture-independent functions probably requires more hard thinking, and could be done in a later step. ________________________________ From: Salz, Rich via RT Sent: Tuesday, June 14, 2016 6:41:02 PM To: Loic Etienne Cc: openssl-dev at openssl.org Subject: RE: [openssl-dev] [openssl.org #4568] Enhancement request: Capability vector accessor function for arm and ppc Doesn't it make more sense to have a single API that returns the platform-specific flags? -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4568 Please log in as guest with password guest if prompted -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4568 Please log in as guest with password guest if prompted From rt at openssl.org Wed Jun 15 15:19:18 2016 From: rt at openssl.org (Rich Salz via RT) Date: Wed, 15 Jun 2016 15:19:18 +0000 Subject: [openssl-dev] [openssl.org #3882] [BUGFIX] lh_SSL_SESSION_delete() not checked In-Reply-To: References: Message-ID: It appears to be defensive programming against a buggy compare routine. So closing this as requested. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3882 Please log in as guest with password guest if prompted From dkg at fifthhorseman.net Wed Jun 15 15:31:24 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 15 Jun 2016 11:31:24 -0400 Subject: [openssl-dev] [openssl.org #4038] SSLv2 session reuse is broken on the 1.0.2 branch In-Reply-To: <517293a373e54ca6a330055ec3ca2ee6@usma1ex-dag1mb1.msg.corp.akamai.com> References: <55F32FC6.1030705@akamai.com> <6131FD08-84E3-4003-B02C-A285BEBBA99F@akamai.com> <517293a373e54ca6a330055ec3ca2ee6@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <87k2hqzcxf.fsf@alice.fifthhorseman.net> On Wed 2016-06-15 09:51:37 -0400, Salz, Rich wrote: > I think OpenSSL needs to decide if SSLv2 bugs will be getting fixed. > Matt and I disagree :) Isn't the existence of SSLv2 a bug? ;) --dkg From rt at openssl.org Wed Jun 15 15:33:27 2016 From: rt at openssl.org (Rich Salz via RT) Date: Wed, 15 Jun 2016 15:33:27 +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: Re-closing this; nobody on the team is interested. Kurt also pointed out some concerns. -- 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 Wed Jun 15 15:33:53 2016 From: matt at openssl.org (Matt Caswell) Date: Wed, 15 Jun 2016 16:33:53 +0100 Subject: [openssl-dev] [openssl.org #4038] SSLv2 session reuse is broken on the 1.0.2 branch In-Reply-To: <87k2hqzcxf.fsf@alice.fifthhorseman.net> References: <55F32FC6.1030705@akamai.com> <6131FD08-84E3-4003-B02C-A285BEBBA99F@akamai.com> <517293a373e54ca6a330055ec3ca2ee6@usma1ex-dag1mb1.msg.corp.akamai.com> <87k2hqzcxf.fsf@alice.fifthhorseman.net> Message-ID: <57617561.2090408@openssl.org> On 15/06/16 16:31, Daniel Kahn Gillmor wrote: > On Wed 2016-06-15 09:51:37 -0400, Salz, Rich wrote: >> I think OpenSSL needs to decide if SSLv2 bugs will be getting fixed. >> Matt and I disagree :) > > Isn't the existence of SSLv2 a bug? ;) Fixed in OpenSSL 1.1.0 :-) Matt From rt at openssl.org Wed Jun 15 15:41:48 2016 From: rt at openssl.org (David Benjamin via RT) Date: Wed, 15 Jun 2016 15:41:48 +0000 Subject: [openssl-dev] [openssl.org #4362] chacha-x86.pl has stricter aliasing requirements than other files In-Reply-To: References: Message-ID: I don't think that will work. The SSL code uses in-place buffers extensively, so in == out definitely needs to be defined. The question is only whether out < in is also acceptable. Either way, for BoringSSL, I've gone ahead and tightened our aliasing constraints to forbid out < in and require equality, so that we don't have to keep chasing down discrepancies in the assembly code in advance of a decision being made here. (I think there is something to be said for being able to in-place-ish decrypt a structure with a record header and write the output without the header, but perhaps this use case is not worth the cost---I see the numbers went down slightly for chacha-x86.pl. Then again, most other files manage it naturally. It's a decision you all will need to make.) David On Wed, Jun 15, 2016 at 11:01 AM Rich Salz via RT wrote: > I think for now, we just note this in the documentation: behavior for > overlapping buffers, and even in-place buffers, is not defined. > > It's like memcpy() vs memmove(). > > -- > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4362 > Please log in as guest with password guest if prompted > > -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4362 Please log in as guest with password guest if prompted From rt at openssl.org Wed Jun 15 15:44:11 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Wed, 15 Jun 2016 15:44:11 +0000 Subject: [openssl-dev] [openssl.org #4362] chacha-x86.pl has stricter aliasing requirements than other files In-Reply-To: <4f870ad8f5a54029a19a32ba43d77c0b@usma1ex-dag1mb1.msg.corp.akamai.com> References: <4f870ad8f5a54029a19a32ba43d77c0b@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: Not defined means we make no guarantees. OpenSSL can depend on what it knows to be true. In the next release we can revisit this. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4362 Please log in as guest with password guest if prompted From rt at openssl.org Wed Jun 15 17:20:00 2016 From: rt at openssl.org (Susan Hinrichs via RT) Date: Wed, 15 Jun 2016 17:20:00 +0000 Subject: [openssl-dev] [openssl.org #4574] Crash introduced in openssl 1.0.2 for non-blocking calls to SSL_write that change the write size In-Reply-To: <209223839.2976369.1466007614442.JavaMail.yahoo@mail.yahoo.com> References: <209223839.2976369.1466007614442.JavaMail.yahoo.ref@mail.yahoo.com> <209223839.2976369.1466007614442.JavaMail.yahoo@mail.yahoo.com> Message-ID: >From the Apache Traffic Server community, we have observed a new crash moving from openssl 1.0.1 to openssl 1.0.2.? The issue from our perspective is discussed in https://issues.apache.org/jira/browse/TS-4424.? The last couple comments are relevant to openssl. Specifically, we are using a non-blocking socket.? When we us the dynamic record feature, we might call SSL_write() after a NEEDS_WRITE failure with a different write size.? As defined, this should cause an error.? Evidently this failure happened rarely enough that no one noticed it.? We will fix this error of usage within ATS. But with openssl 1.0.2 instead of getting an error failure, we get an core dump.? Looking at openssl 1.0.2h in ssl/s3_pkt.c and comparing that to the openssl 1.0.1m version.? We see in ssl3_write_bytes() on line 686, the value of tot can get incremented after the change in write size had been checked for on line 670.? So when we call do_ssl3_write on line 830, the tot offset is way off the end of the buffer either causing an immediate ASAN error or an eventual memory error. It appears that in open 1.0.1 the ssl3_write_pending call was in do_ssl3_write() and so did not impact the buffer offset. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4574 Please log in as guest with password guest if prompted From rt at openssl.org Wed Jun 15 17:42:58 2016 From: rt at openssl.org (Rich Salz via RT) Date: Wed, 15 Jun 2016 17:42:58 +0000 Subject: [openssl-dev] [openssl.org #4526] bug: use of ExitProcess on Windows platforms, 1.0.2g In-Reply-To: References: Message-ID: OpenSSL_1_0_2-stable 75f9068 RT4526: Call TerminateProcess, not ExitProcess master 9c1a9cc RT4526: Call TerminateProcess, not ExitProcess Author: Rich Salz Date: Tue Jun 14 16:19:37 2016 -0400 RT4526: Call TerminateProcess, not ExitProcess Reviewed-by: Richard Levitte -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4526 Please log in as guest with password guest if prompted From rt at openssl.org Wed Jun 15 20:31:45 2016 From: rt at openssl.org (Rich Salz via RT) Date: Wed, 15 Jun 2016 20:31:45 +0000 Subject: [openssl-dev] [openssl.org #4346] poly1305-x86.pl's AVX2 code In-Reply-To: References: Message-ID: Some better comments on pre- and post-conditions would be useful. But the fix (the second one) has been commit'd Closing ticket. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4346 Please log in as guest with password guest if prompted From vm.rod25 at gmail.com Wed Jun 15 23:05:04 2016 From: vm.rod25 at gmail.com (Victor Rodriguez) Date: Wed, 15 Jun 2016 18:05:04 -0500 Subject: [openssl-dev] Split libcrypto.so for coreutils optimization Message-ID: HI team I am enabeling the optimized coreutils sha*sum utils as metioned in this thread: https://lists.clearlinux.org/pipermail/dev/2016-April/000278.html However the libcrypto.so.1.0.0 is too heavy for our base distro ( 2.2MB ) I am looking for a way to make a patch for our distro ( clearlinux) to split it and provide %files lib %{_libdir}/libcrypto.so.1.0.0 %{_libdir}/libcryptosum.so.1.0.0 %{_libdir}/libssl.so.1.0.0 I am reading th code , but I can not find a clear path where to split it Any help is more than welcome Regards Victor Rodriguez From rt at openssl.org Thu Jun 16 01:42:23 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 16 Jun 2016 01:42:23 +0000 Subject: [openssl-dev] [openssl.org #4574] Crash introduced in openssl 1.0.2 for non-blocking calls to SSL_write that change the write size In-Reply-To: <209223839.2976369.1466007614442.JavaMail.yahoo@mail.yahoo.com> References: <209223839.2976369.1466007614442.JavaMail.yahoo.ref@mail.yahoo.com> <209223839.2976369.1466007614442.JavaMail.yahoo@mail.yahoo.com> Message-ID: Please look at the WARNINGS section in SSL_write.pod; you must call it with the exact same arguments (it has been there sincethe turn of the century :). -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4574 Please log in as guest with password guest if prompted From rsalz at akamai.com Thu Jun 16 01:48:24 2016 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 16 Jun 2016 01:48:24 +0000 Subject: [openssl-dev] [openssl.org #4558] Performance issue with DTLS packet reassembly In-Reply-To: References: <933e3679-12fc-409c-a5e6-2cd0d1293951@default> <1dc5a132-718e-4a15-b8ff-aa691e8ae54b@default> Message-ID: > It still seems like pqueue out to be excised from the source base and replace > with something simpler. Agree. Could you go to Github and open an issue on this? From rt at openssl.org Thu Jun 16 01:48:36 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Thu, 16 Jun 2016 01:48:36 +0000 Subject: [openssl-dev] [openssl.org #4558] Performance issue with DTLS packet reassembly In-Reply-To: References: <933e3679-12fc-409c-a5e6-2cd0d1293951@default> <1dc5a132-718e-4a15-b8ff-aa691e8ae54b@default> Message-ID: > It still seems like pqueue out to be excised from the source base and replace > with something simpler. Agree. Could you go to Github and open an issue on this? -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4558 Please log in as guest with password guest if prompted From rt at openssl.org Thu Jun 16 02:03:53 2016 From: rt at openssl.org (Susan Hinrichs via RT) Date: Thu, 16 Jun 2016 02:03:53 +0000 Subject: [openssl-dev] [openssl.org #4574] Crash introduced in openssl 1.0.2 for non-blocking calls to SSL_write that change the write size In-Reply-To: <1980683959.3276029.1466042585036.JavaMail.yahoo@mail.yahoo.com> References: <209223839.2976369.1466007614442.JavaMail.yahoo.ref@mail.yahoo.com> <209223839.2976369.1466007614442.JavaMail.yahoo@mail.yahoo.com> <1980683959.3276029.1466042585036.JavaMail.yahoo@mail.yahoo.com> Message-ID: Yes, I realize that this is an error in API use on our part, and we will adjust our logic. ?? I just filed this issue because what was an error return in 1.0.1 has become a seg fault in 1.0.2, and it looks like the segfault could be avoided with minor effort, which I noted in the bug description. On Wednesday, June 15, 2016 8:43 PM, Rich Salz via RT wrote: Please look at the WARNINGS section in SSL_write.pod; you must call it with the exact same arguments (it has been there sincethe turn of the century :). -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4574 Please log in as guest with password guest if prompted -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4574 Please log in as guest with password guest if prompted From rt at openssl.org Thu Jun 16 02:29:23 2016 From: rt at openssl.org (Simon Richter via RT) Date: Thu, 16 Jun 2016 02:29:23 +0000 Subject: [openssl-dev] [openssl.org #4575] 1.0.2 stable branch: .\apps\speed.c(335): error C2065: 'err': undeclared identifier In-Reply-To: <57620EE9.6000509@hogyros.de> References: <57620EE9.6000509@hogyros.de> Message-ID: Hi, the 1.0.2 branch fails to compile on VC-WIN32: .\apps\speed.c(335): error C2065: 'err': undeclared identifier The responsible commit is https://github.com/openssl/openssl/commit/75f90688fb2dec0f897cad8be8b92be725c5016b - ExitProcess(ret); + TerminateProcess(GetCurrentProcess(), err); Simon -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4575 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: From levitte at openssl.org Thu Jun 16 05:26:17 2016 From: levitte at openssl.org (Richard Levitte) Date: Thu, 16 Jun 2016 07:26:17 +0200 (CEST) Subject: [openssl-dev] Split libcrypto.so for coreutils optimization In-Reply-To: References: Message-ID: <20160616.072617.2191086974517077586.levitte@openssl.org> In message on Wed, 15 Jun 2016 18:05:04 -0500, Victor Rodriguez said: vm.rod25> HI team vm.rod25> vm.rod25> I am enabeling the optimized coreutils sha*sum utils as metioned in vm.rod25> this thread: vm.rod25> vm.rod25> https://lists.clearlinux.org/pipermail/dev/2016-April/000278.html vm.rod25> vm.rod25> However the libcrypto.so.1.0.0 is too heavy for our base distro ( 2.2MB ) vm.rod25> vm.rod25> I am looking for a way to make a patch for our distro ( clearlinux) to vm.rod25> split it and provide vm.rod25> vm.rod25> %files lib vm.rod25> %{_libdir}/libcrypto.so.1.0.0 vm.rod25> %{_libdir}/libcryptosum.so.1.0.0 vm.rod25> %{_libdir}/libssl.so.1.0.0 vm.rod25> vm.rod25> I am reading th code , but I can not find a clear path where to split it vm.rod25> vm.rod25> Any help is more than welcome First of all, there's a question of dependency. Do you intend to have libcrypto.so depend on libcryptosum.so, or do you want libcryptosum.so to be an entirely separate library, not to be mixed with libssl.so and libcrypto.so? Either way, the place to look into is crypto/sha/Makefile for OpenSSL 1.0.2 series or older, or crypto/sha/build.info for the upcoming 1.1.0 series. You'd have to change the name of the library that the source is going to be compiled into, or for a completely separate libcryptosum, you'll have to do a bit of duplication so the same object files get placed in both libraries, libcrypto and libcryptosum. There's a bit more work to do to complete this scheme, but there's at least your starting point. The API is declared in include/openssl/sha.h Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From rt at openssl.org Thu Jun 16 05:35:51 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Thu, 16 Jun 2016 05:35:51 +0000 Subject: [openssl-dev] [openssl.org #4575] 1.0.2 stable branch: .\apps\speed.c(335): error C2065: 'err': undeclared identifier In-Reply-To: <57620EE9.6000509@hogyros.de> References: <57620EE9.6000509@hogyros.de> Message-ID: Thanks. Fixup currently in https://github.com/openssl/openssl/pull/1220, pending approval. Cheers, Richard On Thu Jun 16 02:29:22 2016, Simon.Richter at hogyros.de wrote: > Hi, > > the 1.0.2 branch fails to compile on VC-WIN32: > > .\apps\speed.c(335): error C2065: 'err': undeclared identifier > > The responsible commit is > > https://github.com/openssl/openssl/commit/75f90688fb2dec0f897cad8be8b92be725c5016b > > - ExitProcess(ret); > + TerminateProcess(GetCurrentProcess(), err); > > Simon -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4575 Please log in as guest with password guest if prompted From rt at openssl.org Thu Jun 16 10:41:16 2016 From: rt at openssl.org (Mick Saxton via RT) Date: Thu, 16 Jun 2016 10:41:16 +0000 Subject: [openssl-dev] [openssl.org #4545] Crash in crypto/rand/md_rand.c In-Reply-To: References: Message-ID: Hi Rich Sorry for delay in responding ? it takes longer to say that an intermittent problem doesn?t exist than to see it happen once. I have tested against latest master (15 June) and the v1.1-pre5 ? so far both are looking good. As a control, I went back and retested with v1.0.2h on the same hardware and it exhibited the problem within 3-5 passes of my tests. (each pass is approx. 110K connections ). The later software has not exhibited this fault after 50 passes. Hope this helps. Thanks Mick From: Rich Salz via RT [mailto:rt at openssl.org] Sent: 10 June 2016 20:44 To: Mick Saxton Cc: openssl-dev at openssl.org Subject: [openssl.org #4545] Crash in crypto/rand/md_rand.c Can you test against a recent master, it has some rand bugfixes that might address this. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4545 Please log in as guest with password guest if prompted ________________________________ Legal Notice: This email is intended only for the person(s) to whom it is addressed. If you are not an intended recipient and have received this message in error, please notify the sender immediately by replying to this email or calling +44(0) 2083269015 (UK) or +1 866 592 4214 (USA). This email and any attachments may be privileged and/or confidential. The unauthorized use, disclosure, copying or printing of any information it contains is strictly prohibited. The opinions expressed in this email are those of the author and do not necessarily represent the views of 1E Ltd. Nothing in this email will operate to bind 1E to any order or other contract. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4545 Please log in as guest with password guest if prompted From rt at openssl.org Thu Jun 16 11:30:11 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 16 Jun 2016 11:30:11 +0000 Subject: [openssl-dev] [openssl.org #4573] BUG -- Documentation issue with RAND_add in rand.pod In-Reply-To: References: Message-ID: commit d9e6d77 pushed to 1.0.2 branch (was already fixed in master). Thanks. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4573 Please log in as guest with password guest if prompted From rt at openssl.org Thu Jun 16 11:31:29 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 16 Jun 2016 11:31:29 +0000 Subject: [openssl-dev] [openssl.org #4545] Crash in crypto/rand/md_rand.c In-Reply-To: References: Message-ID: Thanks Mick. I'll close this ticket; if it shows up again, please open a new one. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4545 Please log in as guest with password guest if prompted From rt at openssl.org Thu Jun 16 11:43:34 2016 From: rt at openssl.org (Mick Saxton via RT) Date: Thu, 16 Jun 2016 11:43:34 +0000 Subject: [openssl-dev] [openssl.org #4545] Resolved: Crash in crypto/rand/md_rand.c In-Reply-To: References: Message-ID: Hi Rich I may be confused but as I see it. it is not really resolved in v1.0.2 branch? (or will it be in the next v1.0.2 release?) ? it just will be when v1.1 becomes available. But I don?t know when that will be. Mick From: Rich Salz via RT [mailto:rt at openssl.org] Sent: 16 June 2016 12:31 To: Mick Saxton Subject: [openssl.org #4545] Resolved: Crash in crypto/rand/md_rand.c According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4545 Please log in as guest with password guest if prompted ________________________________ Legal Notice: This email is intended only for the person(s) to whom it is addressed. If you are not an intended recipient and have received this message in error, please notify the sender immediately by replying to this email or calling +44(0) 2083269015 (UK) or +1 866 592 4214 (USA). This email and any attachments may be privileged and/or confidential. The unauthorized use, disclosure, copying or printing of any information it contains is strictly prohibited. The opinions expressed in this email are those of the author and do not necessarily represent the views of 1E Ltd. Nothing in this email will operate to bind 1E to any order or other contract. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4545 Please log in as guest with password guest if prompted From rt at openssl.org Thu Jun 16 11:58:16 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Thu, 16 Jun 2016 11:58:16 +0000 Subject: [openssl-dev] [openssl.org #4545] Resolved: Crash in crypto/rand/md_rand.c In-Reply-To: <3ab46e4f11c14ac58261076bfd6d2bce@usma1ex-dag1mb1.msg.corp.akamai.com> References: <3ab46e4f11c14ac58261076bfd6d2bce@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: Ah, didn't realize you needed it in 1.0.2; will backport shortl. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4545 Please log in as guest with password guest if prompted From cata.vasile at nxp.com Thu Jun 16 14:06:04 2016 From: cata.vasile at nxp.com (Catalin Vasile) Date: Thu, 16 Jun 2016 14:06:04 +0000 Subject: [openssl-dev] [HMAC] reusing the session objects Message-ID: Hi, I am trying to make a user space app with the following behaviour: 1. alocate and initialize hmac (precompute key's hash, i_key_pad[1] and o_key_pad[1]) 2.?generate hmac for an input 3. generate hmac for another input, without having to redo the precomputations 4. generate hmac for another input, without having to redo the precomputations 5. generate hmac for another input, without having to redo the precomputations 6. generate hmac for another input, without having to redo the precomputations ... $(N-1). generate hmac for another input, without having to redo the precomputations $N. cleanup state objects. I would like the same effect like calling: 2. digest0 = HMAC(EVP_some_hash_function(), key, key_len, data0, data0_size, NULL, NULL); 3. digest1 = HMAC(EVP_some_hash_function(), key, key_len, data1, data1_size, NULL, NULL); 4. digest2 = HMAC(EVP_some_hash_function(), key, key_len, data2, data2_size, NULL, NULL); 5. digest3 = HMAC(EVP_some_hash_function(), key, key_len, data3, data3_size, NULL, NULL); 6. digest4 = HMAC(EVP_some_hash_function(), key, key_len, data4, data4_size, NULL, NULL); ... $(N-1). digest5 = HMAC(EVP_some_hash_function(), key, key_len, data5, data5_size, NULL, NULL); But without making the app recompute the key's hash, i_key_pad[1] and o_key_pad[1] every time. Does calling a series of HMAC_Init_ex(), HMAC_Update(), HMAC_Final(), with the "key" and "md" parameters for HMAC_Init_ex() set to NULL achieve the same result as above? The series would look like this: 1. Allocate_state_objects(); HMAC_Init_ex(..., key, ..., md, ...); 2.?HMAC_Init_ex(..., NULL, ..., NULL, ...), HMAC_Update(..., data0, ...), HMAC_Final(..., digest0, ...) 3. HMAC_Init_ex(..., NULL, ..., NULL, ..., HMAC_Update(..., data1, ...), HMAC_Final(..., digest1, ...) 4. HMAC_Init_ex(..., NULL, ..., NULL, ...), HMAC_Update(..., data2, ...), HMAC_Final(..., digest2, ...) 5. HMAC_Init_ex(..., NULL, ..., NULL, ...), HMAC_Update(..., data3, ...), HMAC_Final(..., digest3, ...) 6. HMAC_Init_ex(..., NULL, ..., NULL, ...), HMAC_Update(..., data4, ...), HMAC_Final(..., digest4, ...) ... $(N-1). HMAC_Init_ex(..., NULL, ..., NULL, ...), HMAC_Update(..., data5, ...), HMAC_Final(..., digest5, ...) $N. Release_state_objects(); Catalin Vasile [1] https://en.wikipedia.org/wiki/Hash-based_message_authentication_code#Implementation From Chris.Gallup at software.dell.com Thu Jun 16 16:27:05 2016 From: Chris.Gallup at software.dell.com (Chris Gallup) Date: Thu, 16 Jun 2016 16:27:05 +0000 Subject: [openssl-dev] unsubscribe Message-ID: <0B1ECA0586B7BF49AB74EFBE8AF0E7920C2A1361@ALVMBXW01.prod.quest.corp> Please unsubscribe me Thanks you Chris Gallup CSSA CSSP MSCAsecurity DCSE Security Systems Engineer - NY & CT Dell Security Solutions Mobile +1-917-969-1649 Chris.Gallup at Software.Dell.com Connect with me on Linkedin [cid:image001.png at 01D1C7CA.63CD1180] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 33341 bytes Desc: image001.png URL: From rt at openssl.org Thu Jun 16 16:44:17 2016 From: rt at openssl.org (Matt Caswell via RT) Date: Thu, 16 Jun 2016 16:44:17 +0000 Subject: [openssl-dev] [openssl.org #4526] bug: use of ExitProcess on Windows platforms, 1.0.2g In-Reply-To: References: Message-ID: On Wed Jun 15 17:42:58 2016, rsalz wrote: > OpenSSL_1_0_2-stable 75f9068 RT4526: Call TerminateProcess, not ExitProcess > master 9c1a9cc RT4526: Call TerminateProcess, not ExitProcess > > Author: Rich Salz > Date: Tue Jun 14 16:19:37 2016 -0400 > > RT4526: Call TerminateProcess, not ExitProcess > > Reviewed-by: Richard Levitte I just reverted this commit. We need to take another look at this, so reopening this ticket. Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4526 Please log in as guest with password guest if prompted From rt at openssl.org Thu Jun 16 17:25:45 2016 From: rt at openssl.org (Simon via RT) Date: Thu, 16 Jun 2016 17:25:45 +0000 Subject: [openssl-dev] [openssl.org #4576] X25519, ECPKParameters_print In-Reply-To: <5762DE99.2060401@le-huit.fr> References: <5762DE99.2060401@le-huit.fr> Message-ID: Hi, It is not possible to print parameters of the elliptic curve X25519 from the command line: openssl ecparam -name X25519 -noout -text -param_enc explicit Nothing is printed. openssl version: OpenSSL 1.1.0-pre6-dev xx XXX xxxx built from git source: commit b84e12266f85156f58804ff94ea110890f13b52d First explanation: ECPKParameters_print cannot call "get parameter" functions because there are not defined in the method list of X25519. The curve coefficient used in the curve25519 methods is not useful because it uses a strange representation. The solution is not simple because curve25519 is a Montgomery curve: B.y^2 = x^3 + A.x^2 + x mod p With A=486662 (decimal) B=1 (decimal) p=(2^255)-19 (decimal) If the function ECPKParameters_print prints this information as others prime curves, it will be *confused* because in the others prime curves A and B are coefficients of a short Weierstrass curve: y^2 = x^3 + A.x + B That is different than a Montgomery curve. It exists a short Weierstrass curve isomorphic with curve25519. I thinks protocols use coordinates of point on the Montgomery curve so it will be also *confused* to print the isomorphic short Weierstrass curve parameters. Before found a proper method to print A and B, it should be easy to print p, order, co-factor and generator coordinates: p = 2^255 - 19 (decimal) Order (of the generator) = 2^252 + 27742317777372353535851937790883648493 (decimal) Cofactor = 8 (decimal) Simon. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4576 Please log in as guest with password guest if prompted From rt at openssl.org Thu Jun 16 17:35:36 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Thu, 16 Jun 2016 17:35:36 +0000 Subject: [openssl-dev] [openssl.org #4576] X25519, ECPKParameters_print In-Reply-To: References: <5762DE99.2060401@le-huit.fr> Message-ID: I don't think this will get fixed for 1.1 -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4576 Please log in as guest with password guest if prompted From rt at openssl.org Thu Jun 16 18:13:19 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 16 Jun 2016 18:13:19 +0000 Subject: [openssl-dev] [openssl.org #4575] 1.0.2 stable branch: .\apps\speed.c(335): error C2065: 'err': undeclared identifier In-Reply-To: <57620EE9.6000509@hogyros.de> References: <57620EE9.6000509@hogyros.de> Message-ID: commit done, reverted. closing ticket. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4575 Please log in as guest with password guest if prompted From rt at openssl.org Thu Jun 16 18:14:06 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 16 Jun 2016 18:14:06 +0000 Subject: [openssl-dev] [openssl.org #4574] Crash introduced in openssl 1.0.2 for non-blocking calls to SSL_write that change the write size In-Reply-To: <209223839.2976369.1466007614442.JavaMail.yahoo@mail.yahoo.com> References: <209223839.2976369.1466007614442.JavaMail.yahoo.ref@mail.yahoo.com> <209223839.2976369.1466007614442.JavaMail.yahoo@mail.yahoo.com> Message-ID: One could make the case that returning an error code let this problem sit there for a long time. Crashing made it get fixed quickly :) -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4574 Please log in as guest with password guest if prompted From rt at openssl.org Thu Jun 16 18:15:48 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 16 Jun 2016 18:15:48 +0000 Subject: [openssl-dev] [openssl.org #4570] Enhancement request: Configuration option no-hw-aes In-Reply-To: References: Message-ID: On Tue Jun 14 15:43:26 2016, loic.etienne at qnective.com wrote: > Define a configuration option no-hw-aes. > No aes processor instruction should be compiled if one of the > configuration options no-hw or no-hw-aes is given. Why doesn't existing run-time checking work for you? -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4570 Please log in as guest with password guest if prompted From rt at openssl.org Thu Jun 16 18:40:44 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 16 Jun 2016 18:40:44 +0000 Subject: [openssl-dev] [openssl.org #4545] Crash in crypto/rand/md_rand.c In-Reply-To: References: Message-ID: commit d0a2bb1f94e26c2e7b44676e9b739c23ad763a79 just pushed to 1.0.2 closing ticket. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4545 Please log in as guest with password guest if prompted From uri at ll.mit.edu Thu Jun 16 18:42:17 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Thu, 16 Jun 2016 18:42:17 +0000 Subject: [openssl-dev] Current github 1.1-pre: installation broken (doc symlinks) Message-ID: link /Users/ur20980/src/openssl-1.1/share/doc/openssl/html/man3/MD5_Final.html -> /Users/ur20980/src/openssl-1.1/share/doc/openssl/html/man3/MD5.html MD5_Final.html => MD5.html install ./doc/crypto/MDC2_Init.pod -> /Users/ur20980/src/openssl-1.1/share/doc/openssl/html/man3/MDC2_Init.html /bin/sh: /Users/ur20980/src/openssl-1.1/share/doc/openssl/html/man3/MDC2_Init.html: Too many levels of symbolic links make: *** [install_html_docs] Error 1 -- Regards, Uri Blumenthal -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4324 bytes Desc: not available URL: From levitte at openssl.org Thu Jun 16 19:02:49 2016 From: levitte at openssl.org (Richard Levitte) Date: Thu, 16 Jun 2016 21:02:49 +0200 (CEST) Subject: [openssl-dev] Current github 1.1-pre: installation broken (doc symlinks) In-Reply-To: References: Message-ID: <20160616.210249.581717180360727681.levitte@openssl.org> In message on Thu, 16 Jun 2016 18:42:17 +0000, "Blumenthal, Uri - 0553 - MITLL" said: uri> link uri> /Users/ur20980/src/openssl-1.1/share/doc/openssl/html/man3/MD5_Final.html uri> -> /Users/ur20980/src/openssl-1.1/share/doc/openssl/html/man3/MD5.html uri> MD5_Final.html => MD5.html uri> install ./doc/crypto/MDC2_Init.pod -> uri> /Users/ur20980/src/openssl-1.1/share/doc/openssl/html/man3/MDC2_Init.html uri> /bin/sh: uri> /Users/ur20980/src/openssl-1.1/share/doc/openssl/html/man3/MDC2_Init.html: uri> Too many levels of symbolic links uri> make: *** [install_html_docs] Error 1 I suggest you do this first: rm -rf /Users/ur20980/src/openssl-1.1/share/doc/openssl There's a bit of documentation restructuring going on, so you probably have old clutter that disturbs the process. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From rt at openssl.org Thu Jun 16 20:01:48 2016 From: rt at openssl.org (David Benjamin via RT) Date: Thu, 16 Jun 2016 20:01:48 +0000 Subject: [openssl-dev] [openssl.org #4577] X509_LU_RETRY and X509_LU_FAIL are slightly confused In-Reply-To: References: Message-ID: Hey folks, It seems the X509_LU_* values (now an X509_LOOKUP_TYPE enum in master) are slightly confused. See this commit message and diff for details: https://boringssl.googlesource.com/boringssl/+/da7f0c65efb72556f8fc92e460e6c90cd1b1add7%5E%21/ The relevant point is that X509_LU_RETRY doesn't work and has never worked since SSLeay. The free of an uninitialized pointer seems to have gotten fixed as a consequence of how X509_OBJECT was opaquified, but the current_method = j bug is still there. It's possible that's all that's needed to fix it, but I doubt it. (Come to think of it, I bet aae41f8c54257d9fa6904d3a9aa09c5db6cefd0d destroyed any hope of X509_LU_RETRY ever working again...) I would propose that you all do something similar to the BoringSSL change above, especially since 1.1.0 is allowed to break API. Remove X509_LU_RETRY support and both error enums completely. X509_LOOKUP_TYPE is now just a type enum (then you can remove the default cases added in bca3f06b84de3c0b428724ac535995064c54aee3). The functions in question just return 0/1 (or -1/0/1, but I think the less error-prone 0/1 is generally better). David PS: It appears bca3f06b84de3c0b428724ac535995064c54aee3 removed X509_LU_PKEY without removing X509_OBJECT.data.pkey. That too can probably go. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4577 Please log in as guest with password guest if prompted From uri at ll.mit.edu Thu Jun 16 20:40:31 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Thu, 16 Jun 2016 20:40:31 +0000 Subject: [openssl-dev] Current github 1.1-pre: installation broken (doc symlinks) In-Reply-To: <20160616.210249.581717180360727681.levitte@openssl.org> References: <20160616.210249.581717180360727681.levitte@openssl.org> Message-ID: On 6/16/16, 15:02 , "openssl-dev on behalf of Richard Levitte" wrote: >In message on Thu, 16 Jun 2016 18:42:17 >+0000, "Blumenthal, Uri - 0553 - MITLL" said: >uri> /bin/sh: >uri> >/Users/ur20980/src/openssl-1.1/share/doc/openssl/html/man3/MDC2_Init.html: >uri> Too many levels of symbolic links >uri> make: *** [install_html_docs] Error 1 > >I suggest you do this first: > >rm -rf /Users/ur20980/src/openssl-1.1/share/doc/openssl > >There's a bit of documentation restructuring going on, so you probably >have old clutter that disturbs the process. You nailed it. Thank you! -------------- 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 Fri Jun 17 09:12:25 2016 From: rt at openssl.org (Matt Caswell via RT) Date: Fri, 17 Jun 2016 09:12:25 +0000 Subject: [openssl-dev] [openssl.org #4565] Fatal error: Command failed for target `link_shlib.solaris' In-Reply-To: References: Message-ID: This is fixed in latest master. Closing. Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4565 Please log in as guest with password guest if prompted From rt at openssl.org Fri Jun 17 10:17:29 2016 From: rt at openssl.org (Matt Caswell via RT) Date: Fri, 17 Jun 2016 10:17:29 +0000 Subject: [openssl-dev] [openssl.org #4456] Fedora 1, i386: error: field `next_timeout` has incomplete type In-Reply-To: References: Message-ID: Jeff has confirmed that this issue has been fixed in latest master. Closing this ticket. Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4456 Please log in as guest with password guest if prompted From rt at openssl.org Fri Jun 17 10:17:45 2016 From: rt at openssl.org (Loic Etienne via RT) Date: Fri, 17 Jun 2016 10:17:45 +0000 Subject: [openssl-dev] [openssl.org #4570] Enhancement request: Configuration option no-hw-aes In-Reply-To: References: , Message-ID: Run-time checking works for x86, but not for arm (OPENSSL_armcap_P is hidden, I still have to try over environment variables, which are not as flexible for arm as for x86). Anyway, it would be helpful to exclude hardware aes instructions at compile-time: 1) Runtime checking is error prone (openssl and code using openssl evolve) 2) Proving to a customer (or convincing myself) that no such instructions will ever be used is much easier if such instructions are not even compiled I guess that some of the already existing no-xxx configuration options have been introduced for similar reasons. ________________________________ From: Rich Salz via RT Sent: Thursday, June 16, 2016 8:15:48 PM To: Loic Etienne Cc: openssl-dev at openssl.org Subject: [openssl.org #4570] Enhancement request: Configuration option no-hw-aes On Tue Jun 14 15:43:26 2016, loic.etienne at qnective.com wrote: > Define a configuration option no-hw-aes. > No aes processor instruction should be compiled if one of the > configuration options no-hw or no-hw-aes is given. Why doesn't existing run-time checking work for you? -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4570 Please log in as guest with password guest if prompted -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4570 Please log in as guest with password guest if prompted From alibekj at yahoo.com Fri Jun 17 11:48:23 2016 From: alibekj at yahoo.com (Alibek Joraev) Date: Fri, 17 Jun 2016 11:48:23 +0000 (UTC) Subject: [openssl-dev] Latest Open SSL and old FIP module References: <1146634681.4866604.1466164103644.JavaMail.yahoo.ref@mail.yahoo.com> Message-ID: <1146634681.4866604.1466164103644.JavaMail.yahoo@mail.yahoo.com> Currently, I use 1.0.1 series (with current one being 1.0.1t) of OpenSSL with OpenSSL FIPS module version 2.0.2.as 1.0.1 version nears its long term support, I would like to upgrade to OpenSSL 1.0.2h, but keep existing 2.0.2 FIPS module. I can see that latest OpenSSL 1.0.2h is posted together with FIPS module 2.0.12. is OpenSSL 1.0.2h compatible with older FIPS modules? or do I also have to upgrade to newest FIPS module? thank you in advance. regards,AJ. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Fri Jun 17 12:46:41 2016 From: rt at openssl.org (Andy Polyakov via RT) Date: Fri, 17 Jun 2016 12:46:41 +0000 Subject: [openssl-dev] [openssl.org #4570] Enhancement request: Configuration option no-hw-aes In-Reply-To: <5763F12E.5050707@openssl.org> References: <5763F12E.5050707@openssl.org> Message-ID: > Run-time checking works for x86, but not for arm (OPENSSL_armcap_P is > hidden, I still have to try over environment variables, which are not > as flexible for arm as for x86). > > > Anyway, it would be helpful to exclude hardware aes instructions at > compile-time: > > 1) Runtime checking is error prone (openssl and code using openssl > evolve) How is it error-prone? Or more specifically have you ever ran into situation when it was *detected* incorrectly so that it resulted in application *crash*? > 2) Proving to a customer (or convincing myself) that no such > instructions will ever be used is much easier if such instructions > are not even compiled Then why just aes instructions? There is a number of code-paths that are selected at run-time that are dependent on processor capability detection. If aes instructions are considered "too fancy", there is no reason to consider *any* alternative code path as less "fancy". > I guess that some of the already existing no-xxx configuration > options have been introduced for similar reasons. no-asm. I'd argue that this ticket can be closed. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4570 Please log in as guest with password guest if prompted From marquess at openssl.com Fri Jun 17 12:48:38 2016 From: marquess at openssl.com (Steve Marquess) Date: Fri, 17 Jun 2016 08:48:38 -0400 Subject: [openssl-dev] Latest Open SSL and old FIP module In-Reply-To: <1146634681.4866604.1466164103644.JavaMail.yahoo@mail.yahoo.com> References: <1146634681.4866604.1466164103644.JavaMail.yahoo.ref@mail.yahoo.com> <1146634681.4866604.1466164103644.JavaMail.yahoo@mail.yahoo.com> Message-ID: <5763F1A6.3030704@openssl.com> On 06/17/2016 07:48 AM, Alibek Joraev wrote: > Currently, I use 1.0.1 series (with current one being 1.0.1t) of OpenSSL > with OpenSSL FIPS module version 2.0.2. > as 1.0.1 version nears its long term support, I would like to upgrade to > OpenSSL 1.0.2h, but keep existing 2.0.2 FIPS module. > > I can see that latest OpenSSL 1.0.2h is posted together with FIPS module > 2.0.12. > > is OpenSSL 1.0.2h compatible with older FIPS modules? or do I also have > to upgrade to newest FIPS module? > > ... All revisions of OpenSSL 1.0.2 are compatible with all revisions of the OpenSSL FIPS Object Module 2.0. So you can keep your existing 2.0.2 FIPS module and upgrade from 1.0.1 to 1.0.2. Note that in general there is no advantage to upgrading to newer FIPS module revisions (e.g. from 2.0.2 to 2.0.12) as in general we're not allowed to do bugfixes or feature enhancements; the newer revisions are not "better" in the sense usually expected for open source software. The exception to that statement is a feature enhancement of sorts, the removal of Dual EC DRBG that occurred at 2.0.6. If completely removing Dual EC DRBG matters to you[1] then you can upgrade to any revision 2.0.6+, all of which will work for any platform supported by 2.0.2. If you're upgrading you might as well go straight to 2.0.12[2], while realizing you'll always be a revision or three behind (2.0.13 is in the works). Also please note that at some point you'll want or need to upgrade to OpenSSL 1.1, for which no FIPS 140 support is currently available or planned at anything beyond the wistful thinking stage. -Steve M. [1] why you might: http://veridicalsystems.com/blog/immutability-of-fips/ [2] Unless, sigh, your platform(s) of interest are listed only for the #1747 or #2473 validations which stop at revision 2.0.10, in which case that's the newest FIPS module revision with the magical pixie dust of FIPS righteousness, even though the latest revision (2.0.12) functionally supports all platforms for all validations. -- 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 Fri Jun 17 12:48:53 2016 From: rt at openssl.org (Matt Caswell via RT) Date: Fri, 17 Jun 2016 12:48:53 +0000 Subject: [openssl-dev] [openssl.org #4572] SSL_set_bio and friends In-Reply-To: <5763F1B4.8010000@openssl.org> References: <5763F1B4.8010000@openssl.org> Message-ID: On 14/06/16 21:30, David Benjamin via RT wrote: > For OpenSSL master, I believe it'd also work to add an s->rbio != s->wbio > check to SSL_set_rbio, but I think those are worse semantics for > SSL_set_{rbio,wbio}. They are new APIs, so, before it's too late, give them > clear semantics like "SSL_set_rbio takes ownership of its argument", > consistent with "set0" functions, rather than a mix of "set0" and "set1". These look like good changes. I'm wondering whether we should actually rename SSL_set_rbio() and SSL_set_wbio() to SSL_set0_rbio() and SSL_set0_wbio() - especially since they are new to 1.1.0 so not released yet. *Possibly* we could also rename SSL_set_bio() to SSL_set0_bio() with a deprecated compatibility macro. Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4572 Please log in as guest with password guest if prompted From alibekj at yahoo.com Fri Jun 17 13:01:42 2016 From: alibekj at yahoo.com (Alibek Joraev) Date: Fri, 17 Jun 2016 13:01:42 +0000 (UTC) Subject: [openssl-dev] Latest Open SSL and old FIP module In-Reply-To: <5763F1A6.3030704@openssl.com> References: <1146634681.4866604.1466164103644.JavaMail.yahoo.ref@mail.yahoo.com> <1146634681.4866604.1466164103644.JavaMail.yahoo@mail.yahoo.com> <5763F1A6.3030704@openssl.com> Message-ID: <1545478517.4920700.1466168502848.JavaMail.yahoo@mail.yahoo.com> Thank you for your reply and detailed explanation ! :)now everything is clear for me. regards,AJ From: Steve Marquess To: openssl-dev at openssl.org Sent: Friday, 17 June 2016, 13:48 Subject: Re: [openssl-dev] Latest Open SSL and old FIP module On 06/17/2016 07:48 AM, Alibek Joraev wrote: > Currently, I use 1.0.1 series (with current one being 1.0.1t) of OpenSSL > with OpenSSL FIPS module version 2.0.2. > as 1.0.1 version nears its long term support, I would like to upgrade to > OpenSSL 1.0.2h, but keep existing 2.0.2 FIPS module. > > I can see that latest OpenSSL 1.0.2h is posted together with FIPS module > 2.0.12. > > is OpenSSL 1.0.2h compatible with older FIPS modules? or do I also have > to upgrade to newest FIPS module? > > ... All revisions of OpenSSL 1.0.2 are compatible with all revisions of the OpenSSL FIPS Object Module 2.0. So you can keep your existing 2.0.2 FIPS module and upgrade from 1.0.1 to 1.0.2. Note that in general there is no advantage to upgrading to newer FIPS module revisions (e.g. from 2.0.2 to 2.0.12) as in general we're not allowed to do bugfixes or feature enhancements; the newer revisions are not "better" in the sense usually expected for open source software. The exception to that statement is a feature enhancement of sorts, the removal of Dual EC DRBG that occurred at 2.0.6. If completely removing Dual EC DRBG matters to you[1] then you can upgrade to any revision 2.0.6+, all of which will work for any platform supported by 2.0.2. If you're upgrading you might as well go straight to 2.0.12[2], while realizing you'll always be a revision or three behind (2.0.13 is in the works). Also please note that at some point you'll want or need to upgrade to OpenSSL 1.1, for which no FIPS 140 support is currently available or planned at anything beyond the wistful thinking stage. -Steve M. [1] why you might: http://veridicalsystems.com/blog/immutability-of-fips/ [2] Unless, sigh, your platform(s) of interest are listed only for the #1747 or #2473 validations which stop at revision 2.0.10, in which case that's the newest FIPS module revision with the magical pixie dust of FIPS righteousness, even though the latest revision (2.0.12) functionally supports all platforms for all validations. -- 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 -- 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 Jun 17 13:32:19 2016 From: rt at openssl.org (Andy Polyakov via RT) Date: Fri, 17 Jun 2016 13:32:19 +0000 Subject: [openssl-dev] [openssl.org #4568] Enhancement request: Capability vector accessor function for arm and ppc In-Reply-To: <5763FBE3.3080403@openssl.org> References: <59c104f5cd044a8fb0aa2dd6f931b941@usma1ex-dag1mb1.msg.corp.akamai.com> <5763FBE3.3080403@openssl.org> Message-ID: > Two more observations. > > OPENSSL_ia32cap_loc() alters the underlying OPENSSL_ia32cap_P, the bits not fitting into the expected integer size being zeroed. I do not know if it is practically relevant, but it is strange that a read has side effects. It would be a good reason for dedicated, architecture independent setters and getters. > > The documentation (https://www.openssl.org/docs/man1.0.2/crypto/OPENSSL_ia32cap.html) says: > unsigned int *OPENSSL_ia32cap_loc(void) > it should say: > unsigned long *OPENSSL_ia32cap_loc(void) > like in openssl-1.0.2h/crypto/crypto.h No. It was 'int' upon initial release of 1.0.0 and has to remain same throughout all 1.0.x releases. Mentioned zeroing also has everything to do with it, i.e. with maintaining backward compatible behaviour within line of binary compatible releases. Rationale is that application should be given same control throughout *all* 1.0.x releases. Or in other words *if* application chooses to manipulate capability vector it will have same granularity as in 1.0.0. Note that in master branch words beyond 1st are not zeroed, don't have to. One can argue that it could be re-declared as long in master. Well, that declaration is shared between 32- and 64-bit builds, and having long would introduce ambiguity. Yes, one can argue that it's already ambiguous since OPENSSL_ia32cap.pod effectively describes 64-bit values. One has to recognize that original reason for exposing OPENSS_ia32cap_loc() was that binary *could* end up in situation when processor capability vector doesn't match OS capability. More specifically cpuid could say "this is SSE2-capable processor" but attempt to perform SSE2 operation on %xmm register could trigger invalid instruction exception nevertheless. Note that this can't happen with later register extensions like %ymm and %zmm, because one can detect even OS support. But back to OPENSSL_ia32cap_loc in master context. Actually one can as well proclaim that such old systems are no longer supported and omit OPENSSL_ia32cap_loc altogether. Naturally leaving setting environment variable alone as the only way to affect result of capability detection. This is really meant to be used for overly specific testing and debugging. And for this reason it doesn't really have to be pretty... -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4568 Please log in as guest with password guest if prompted From rt at openssl.org Fri Jun 17 13:58:27 2016 From: rt at openssl.org (Loic Etienne via RT) Date: Fri, 17 Jun 2016 13:58:27 +0000 Subject: [openssl-dev] [openssl.org #4568] Enhancement request: Capability vector accessor function for arm and ppc In-Reply-To: References: <59c104f5cd044a8fb0aa2dd6f931b941@usma1ex-dag1mb1.msg.corp.akamai.com> <5763FBE3.3080403@openssl.org>, Message-ID: Thanks for the explanations. In the code I am working with, I see: $ sed -n '657p' openssl-1.0.2h/crypto/cryptlib.c unsigned long *OPENSSL_ia32cap_loc(void) You may want to verify it. I happen to be using features introduced for testing and debugging, without knowing it. For debatable reasons, but it is my assignment to avoid aes-ni instructions. Maybe I will have to adapt openssl slightly, for instance making the capability vectors global (instead of hidden); or not to use the EVP interfaces. ________________________________ From: Andy Polyakov via RT Sent: Friday, June 17, 2016 3:32:19 PM To: Loic Etienne Cc: openssl-dev at openssl.org Subject: Re: [openssl-dev] [openssl.org #4568] Enhancement request: Capability vector accessor function for arm and ppc > Two more observations. > > OPENSSL_ia32cap_loc() alters the underlying OPENSSL_ia32cap_P, the bits not fitting into the expected integer size being zeroed. I do not know if it is practically relevant, but it is strange that a read has side effects. It would be a good reason for dedicated, architecture independent setters and getters. > > The documentation (https://www.openssl.org/docs/man1.0.2/crypto/OPENSSL_ia32cap.html) says: > unsigned int *OPENSSL_ia32cap_loc(void) > it should say: > unsigned long *OPENSSL_ia32cap_loc(void) > like in openssl-1.0.2h/crypto/crypto.h No. It was 'int' upon initial release of 1.0.0 and has to remain same throughout all 1.0.x releases. Mentioned zeroing also has everything to do with it, i.e. with maintaining backward compatible behaviour within line of binary compatible releases. Rationale is that application should be given same control throughout *all* 1.0.x releases. Or in other words *if* application chooses to manipulate capability vector it will have same granularity as in 1.0.0. Note that in master branch words beyond 1st are not zeroed, don't have to. One can argue that it could be re-declared as long in master. Well, that declaration is shared between 32- and 64-bit builds, and having long would introduce ambiguity. Yes, one can argue that it's already ambiguous since OPENSSL_ia32cap.pod effectively describes 64-bit values. One has to recognize that original reason for exposing OPENSS_ia32cap_loc() was that binary *could* end up in situation when processor capability vector doesn't match OS capability. More specifically cpuid could say "this is SSE2-capable processor" but attempt to perform SSE2 operation on %xmm register could trigger invalid instruction exception nevertheless. Note that this can't happen with later register extensions like %ymm and %zmm, because one can detect even OS support. But back to OPENSSL_ia32cap_loc in master context. Actually one can as well proclaim that such old systems are no longer supported and omit OPENSSL_ia32cap_loc altogether. Naturally leaving setting environment variable alone as the only way to affect result of capability detection. This is really meant to be used for overly specific testing and debugging. And for this reason it doesn't really have to be pretty... -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4568 Please log in as guest with password guest if prompted -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4568 Please log in as guest with password guest if prompted From rt at openssl.org Fri Jun 17 14:14:08 2016 From: rt at openssl.org (David Benjamin via RT) Date: Fri, 17 Jun 2016 14:14:08 +0000 Subject: [openssl-dev] [openssl.org #4572] SSL_set_bio and friends In-Reply-To: References: <5763F1B4.8010000@openssl.org> Message-ID: On Fri, Jun 17, 2016 at 8:48 AM Matt Caswell via RT wrote: > > > On 14/06/16 21:30, David Benjamin via RT wrote: > > For OpenSSL master, I believe it'd also work to add an s->rbio != s->wbio > > check to SSL_set_rbio, but I think those are worse semantics for > > SSL_set_{rbio,wbio}. They are new APIs, so, before it's too late, give > them > > clear semantics like "SSL_set_rbio takes ownership of its argument", > > consistent with "set0" functions, rather than a mix of "set0" and "set1". > > These look like good changes. I'm wondering whether we should actually > rename SSL_set_rbio() and SSL_set_wbio() to SSL_set0_rbio() and > SSL_set0_wbio() - especially since they are new to 1.1.0 so not released > yet. > Sounds good to me. > *Possibly* we could also rename SSL_set_bio() to SSL_set0_bio() with a > deprecated compatibility macro. > I dunno, SSL_set_bio is kind of weird all around. :-) I suppose it is closer to a set0 than a set1, but set0 doesn't typically have all these no-op cases around taking ownership and such. > Matt > > > -- > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4572 > Please log in as guest with password guest if prompted > > -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4572 Please log in as guest with password guest if prompted From rt at openssl.org Fri Jun 17 14:22:46 2016 From: rt at openssl.org (Andy Polyakov via RT) Date: Fri, 17 Jun 2016 14:22:46 +0000 Subject: [openssl-dev] [openssl.org #4568] Enhancement request: Capability vector accessor function for arm and ppc In-Reply-To: <576407B5.405@openssl.org> References: <59c104f5cd044a8fb0aa2dd6f931b941@usma1ex-dag1mb1.msg.corp.akamai.com> <5763FBE3.3080403@openssl.org> <576407B5.405@openssl.org> Message-ID: > Thanks for the explanations. > > In the code I am working with, I see: > $ sed -n '657p' openssl-1.0.2h/crypto/cryptlib.c > unsigned long *OPENSSL_ia32cap_loc(void) > > You may want to verify it. Right! Sorry about confusion, my bad! It was long in 1.0.x and in became int in master. Anyway, point that it can't be changed in last-digit release remains, as well as reason for zeroing of most significant word[s] upon reference to OPENSSL_ia32cap_loc in 1.0.x. Yes, it's a bug in 1.0.2 OPENSSL_ia32cap.pod. > I happen to be using features introduced for testing and debugging, > without knowing it. For debatable reasons, but it is my assignment to > avoid aes-ni instructions. Maybe I will have to adapt openssl > slightly, for instance making the capability vectors global (instead > of hidden); or not to use the EVP interfaces. I suppose reply in RT#4570 applies even here. And just to clarify, "meant to be used for overly specific testing and debugging [hence doesn't have to be pretty]" naturally applies to all platforms with run-time switches. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4568 Please log in as guest with password guest if prompted From rt at openssl.org Fri Jun 17 14:38:12 2016 From: rt at openssl.org (Loic Etienne via RT) Date: Fri, 17 Jun 2016 14:38:12 +0000 Subject: [openssl-dev] [openssl.org #4570] Enhancement request: Configuration option no-hw-aes In-Reply-To: References: <5763F12E.5050707@openssl.org>, Message-ID: 1) Openssl works correctly (no crash, correct detection), as far as I can judge. By error-prone I mean, very defensively, that I (or others) could make a mistake, or that future versions of openssl could not work exactly the same way. 2) I would agree with your argumentation. But some customers want this anti-feature (no aes-ni), arguing that exactly those instruction are not trustworthy. And the customer is always right. There are already two similar options (which inspired the suggested no-hw-aes): no-hw, no-engines. But none of them excludes aes instructions, which is a bit misleading. Perhaps the documentation could be more explicit about that. no-asm is a possibility, indeed. At the price of the bit-slicing aes implementation and perhaps of some performance. A trade-off. But I understand that openssl cannot consider each and every wish. Such a no-hw-aes configuration option may be useful (at least for selling) to many other people, or not. Up to your judgment. Thanks for your attention anyway. ________________________________ From: Andy Polyakov via RT Sent: Friday, June 17, 2016 2:46:41 PM To: Loic Etienne Cc: openssl-dev at openssl.org Subject: Re: [openssl-dev] [openssl.org #4570] Enhancement request: Configuration option no-hw-aes > Run-time checking works for x86, but not for arm (OPENSSL_armcap_P is > hidden, I still have to try over environment variables, which are not > as flexible for arm as for x86). > > > Anyway, it would be helpful to exclude hardware aes instructions at > compile-time: > > 1) Runtime checking is error prone (openssl and code using openssl > evolve) How is it error-prone? Or more specifically have you ever ran into situation when it was *detected* incorrectly so that it resulted in application *crash*? > 2) Proving to a customer (or convincing myself) that no such > instructions will ever be used is much easier if such instructions > are not even compiled Then why just aes instructions? There is a number of code-paths that are selected at run-time that are dependent on processor capability detection. If aes instructions are considered "too fancy", there is no reason to consider *any* alternative code path as less "fancy". > I guess that some of the already existing no-xxx configuration > options have been introduced for similar reasons. no-asm. I'd argue that this ticket can be closed. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4570 Please log in as guest with password guest if prompted -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4570 Please log in as guest with password guest if prompted From rt at openssl.org Fri Jun 17 15:13:50 2016 From: rt at openssl.org (Andy Polyakov via RT) Date: Fri, 17 Jun 2016 15:13:50 +0000 Subject: [openssl-dev] [openssl.org #4570] Enhancement request: Configuration option no-hw-aes In-Reply-To: <576413AB.5040203@openssl.org> References: <5763F12E.5050707@openssl.org> <576413AB.5040203@openssl.org> Message-ID: > 1) Openssl works correctly (no crash, correct detection), as far as I > can judge. By error-prone I mean, very defensively, that I (or > others) could make a mistake, or that future versions of openssl > could not work exactly the same way. Well, this is effectively argument in favour of denying the control over capability vector[s]. I mean following this logic you should have no way to affect the outcome, not programmatically nor through environment variable. Because user can screw it up :-) > 2) I would agree with your argumentation. But some customers want > this anti-feature (no aes-ni), arguing that exactly those instruction > are not trustworthy. And the customer is always right. And following this logic no instruction is trustworthy, be it aesenc or any other, say pshufb used in bsaes, or even better example multiplication used in e.g. RSA. There is exactly as much proof of correctness of either. If you are concerned about using any specific instruction you should have bigger concern about using that processor at all. Or in other words if trusting a processor manufacturer is problematic, then you should manufacture own processor, with or without AES-NI, which OpenSSL will dutifully detect and abstain from calling procedures that would crash... I'd argue that even this ticket can be closed with "use no-asm" resolution. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4570 Please log in as guest with password guest if prompted From rt at openssl.org Fri Jun 17 16:14:17 2016 From: rt at openssl.org (Loic Etienne via RT) Date: Fri, 17 Jun 2016 16:14:17 +0000 Subject: [openssl-dev] [openssl.org #4570] Enhancement request: Configuration option no-hw-aes In-Reply-To: References: <5763F12E.5050707@openssl.org> <576413AB.5040203@openssl.org>, Message-ID: Your technical arguments are sound, indeed. ________________________________ From: Andy Polyakov via RT Sent: Friday, June 17, 2016 5:13:50 PM To: Loic Etienne Cc: openssl-dev at openssl.org Subject: Re: [openssl-dev] [openssl.org #4570] Enhancement request: Configuration option no-hw-aes > 1) Openssl works correctly (no crash, correct detection), as far as I > can judge. By error-prone I mean, very defensively, that I (or > others) could make a mistake, or that future versions of openssl > could not work exactly the same way. Well, this is effectively argument in favour of denying the control over capability vector[s]. I mean following this logic you should have no way to affect the outcome, not programmatically nor through environment variable. Because user can screw it up :-) > 2) I would agree with your argumentation. But some customers want > this anti-feature (no aes-ni), arguing that exactly those instruction > are not trustworthy. And the customer is always right. And following this logic no instruction is trustworthy, be it aesenc or any other, say pshufb used in bsaes, or even better example multiplication used in e.g. RSA. There is exactly as much proof of correctness of either. If you are concerned about using any specific instruction you should have bigger concern about using that processor at all. Or in other words if trusting a processor manufacturer is problematic, then you should manufacture own processor, with or without AES-NI, which OpenSSL will dutifully detect and abstain from calling procedures that would crash... I'd argue that even this ticket can be closed with "use no-asm" resolution. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4570 Please log in as guest with password guest if prompted -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4570 Please log in as guest with password guest if prompted From rt at openssl.org Fri Jun 17 17:29:11 2016 From: rt at openssl.org (Mick Saxton via RT) Date: Fri, 17 Jun 2016 17:29:11 +0000 Subject: [openssl-dev] [openssl.org #4545] Crash in crypto/rand/md_rand.c In-Reply-To: References: Message-ID: Hi Rich Many thanks for doing that ? unfortunately it is not the whole fix. I checked out the latest v1.0.2i-dev and built that but I still get the crash. I know the ticket is now ?closed? ? do you need me to reopen it? I am still convinced that I don?t get it with the ?master? build ? but that is v1.1 and even the build process is significantly different on Windows. One thing that I did notice is that CPU load seems lower on the v1.1 build which would be really great/ .. but it may be making this problem less obvious (frequent). Thanks Mick From: Rich Salz via RT [mailto:rt at openssl.org] Sent: 16 June 2016 19:41 To: Mick Saxton Cc: openssl-dev at openssl.org Subject: [openssl.org #4545] Crash in crypto/rand/md_rand.c commit d0a2bb1f94e26c2e7b44676e9b739c23ad763a79 just pushed to 1.0.2 closing ticket. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4545 Please log in as guest with password guest if prompted ________________________________ Legal Notice: This email is intended only for the person(s) to whom it is addressed. If you are not an intended recipient and have received this message in error, please notify the sender immediately by replying to this email or calling +44(0) 2083269015 (UK) or +1 866 592 4214 (USA). This email and any attachments may be privileged and/or confidential. The unauthorized use, disclosure, copying or printing of any information it contains is strictly prohibited. The opinions expressed in this email are those of the author and do not necessarily represent the views of 1E Ltd. Nothing in this email will operate to bind 1E to any order or other contract. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4545 Please log in as guest with password guest if prompted From rt at openssl.org Fri Jun 17 17:38:42 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Fri, 17 Jun 2016 17:38:42 +0000 Subject: [openssl-dev] [openssl.org #4545] Crash in crypto/rand/md_rand.c In-Reply-To: <35072fd31b3449448c51955e9de1fff6@usma1ex-dag1mb1.msg.corp.akamai.com> References: <35072fd31b3449448c51955e9de1fff6@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: Sending mail re-opens the ticket. Rats, wish it was fixed. Going to need something to more easily reproduce it, I guess. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4545 Please log in as guest with password guest if prompted From rt at openssl.org Fri Jun 17 18:43:05 2016 From: rt at openssl.org (Mick Saxton via RT) Date: Fri, 17 Jun 2016 18:43:05 +0000 Subject: [openssl-dev] [openssl.org #4545] Crash in crypto/rand/md_rand.c In-Reply-To: References: <35072fd31b3449448c51955e9de1fff6@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: Perhaps we should consider if there are any negative consequences to my solution? It does work. I am trying really hard to get contention but I am only seeing this problem in about 1 out of 100,000 successful TLSv1.2 connections On a heavily congested network. I require three machines to just to run the test that causes the failure. All we are trying to do is get a random number ? surely getting a slightly less random number is better than crashing? It could be that the problematic instances were going to disconnect anyway due to TCP/IP problems. Rather than my previous suggestion ? I am now suggesting:- So in ssleay_rand_add If ( j-k>0 ) MD_Update(&m, &(state[st_idx]), j ? k); And a similar fix in ssleay_rand_bytes This also avoids adding zero bytes to the hash ? which it does quite often. From: Salz, Rich via RT [mailto:rt at openssl.org] Sent: 17 June 2016 18:39 To: Mick Saxton Cc: openssl-dev at openssl.org Subject: RE: [openssl-dev] [openssl.org #4545] Crash in crypto/rand/md_rand.c Sending mail re-opens the ticket. Rats, wish it was fixed. Going to need something to more easily reproduce it, I guess. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4545 Please log in as guest with password guest if prompted ________________________________ Legal Notice: This email is intended only for the person(s) to whom it is addressed. If you are not an intended recipient and have received this message in error, please notify the sender immediately by replying to this email or calling +44(0) 2083269015 (UK) or +1 866 592 4214 (USA). This email and any attachments may be privileged and/or confidential. The unauthorized use, disclosure, copying or printing of any information it contains is strictly prohibited. The opinions expressed in this email are those of the author and do not necessarily represent the views of 1E Ltd. Nothing in this email will operate to bind 1E to any order or other contract. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4545 Please log in as guest with password guest if prompted From rt at openssl.org Fri Jun 17 19:56:42 2016 From: rt at openssl.org (Matt Caswell via RT) Date: Fri, 17 Jun 2016 19:56:42 +0000 Subject: [openssl-dev] [openssl.org #4545] Crash in crypto/rand/md_rand.c In-Reply-To: <576455F7.7060703@openssl.org> References: <35072fd31b3449448c51955e9de1fff6@usma1ex-dag1mb1.msg.corp.akamai.com> <576455F7.7060703@openssl.org> Message-ID: On 17/06/16 19:43, Mick Saxton via RT wrote: > Perhaps we should consider if there are any negative consequences to my solution? > It does work. > > I am trying really hard to get contention but I am only seeing this problem in about 1 out of 100,000 successful TLSv1.2 connections > On a heavily congested network. > I require three machines to just to run the test that causes the failure. > > All we are trying to do is get a random number ? surely getting a slightly less random number is better than crashing? > It could be that the problematic instances were going to disconnect anyway due to TCP/IP problems. > I think we need to try instrumenting the code to see if we can get some more information out. I will try and pull something together - but it might be Monday before I get the opportunity. Matt > > > Rather than my previous suggestion ? I am now suggesting:- > > So in ssleay_rand_add > > If ( j-k>0 ) MD_Update(&m, &(state[st_idx]), j ? k); > > And a similar fix in ssleay_rand_bytes > > > This also avoids adding zero bytes to the hash ? which it does quite often. > > > > > From: Salz, Rich via RT [mailto:rt at openssl.org] > Sent: 17 June 2016 18:39 > To: Mick Saxton > Cc: openssl-dev at openssl.org > Subject: RE: [openssl-dev] [openssl.org #4545] Crash in crypto/rand/md_rand.c > > Sending mail re-opens the ticket. > > Rats, wish it was fixed. Going to need something to more easily reproduce it, I guess. > > -- > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4545 > Please log in as guest with password guest if prompted > > ________________________________ > > > Legal Notice: This email is intended only for the person(s) to whom it is addressed. If you are not an intended recipient and have received this message in error, please notify the sender immediately by replying to this email or calling +44(0) 2083269015 (UK) or +1 866 592 4214 (USA). This email and any attachments may be privileged and/or confidential. The unauthorized use, disclosure, copying or printing of any information it contains is strictly prohibited. The opinions expressed in this email are those of the author and do not necessarily represent the views of 1E Ltd. Nothing in this email will operate to bind 1E to any order or other contract. > -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4545 Please log in as guest with password guest if prompted From rt at openssl.org Fri Jun 17 23:07:53 2016 From: rt at openssl.org (Matt Caswell via RT) Date: Fri, 17 Jun 2016 23:07:53 +0000 Subject: [openssl-dev] [openssl.org #4545] Crash in crypto/rand/md_rand.c In-Reply-To: <576482C1.8040808@openssl.org> References: <576455F7.7060703@openssl.org> <576482C1.8040808@openssl.org> Message-ID: On 17/06/16 20:56, Matt Caswell via RT wrote: > > > On 17/06/16 19:43, Mick Saxton via RT wrote: >> Perhaps we should consider if there are any negative consequences to my solution? >> It does work. >> >> I am trying really hard to get contention but I am only seeing this problem in about 1 out of 100,000 successful TLSv1.2 connections >> On a heavily congested network. >> I require three machines to just to run the test that causes the failure. >> >> All we are trying to do is get a random number ? surely getting a slightly less random number is better than crashing? >> It could be that the problematic instances were going to disconnect anyway due to TCP/IP problems. >> > > I think we need to try instrumenting the code to see if we can get some > more information out. I will try and pull something together - but it > might be Monday before I get the opportunity. I got to it quicker than I thought. Please see attached patch. Can you apply it to the latest git 1.0.2 version and re-run your test (capture stderr output). I'd like to see what we get. Also is this 32-bit or 64-bit Windows? Are you able to share your locking callback implementation? Thanks Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4545 Please log in as guest with password guest if prompted -------------- next part -------------- A non-text attachment was scrubbed... Name: md-rand-instrument.patch Type: text/x-patch Size: 2381 bytes Desc: not available URL: From rt at openssl.org Sat Jun 18 10:49:46 2016 From: rt at openssl.org (noloader@gmail.com via RT) Date: Sat, 18 Jun 2016 10:49:46 +0000 Subject: [openssl-dev] [openssl.org #4578] ARMv7a and failed self test In-Reply-To: References: Message-ID: The following is from a CubieBoard. I verified I performed a 'make clean' and 'git pull'. $ git rev-parse HEAD 13c03c8d6da334bb1cde6ce4133e7c75b3b76947 ********** using V=1: ../test/recipes/30-test_evp.t .............. 1..1 Test line 2163(aligned in-place): unexpected error VALUE_MISMATCH Expected: 000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F202122232425262728292A2B2C2D2E2F303132333435363738393A3B3C3D3E3F404142434445464748494A4B4C4D4E4F505152535455565758595A5B5C5D5E5F606162636465666768696A6B6C6D6E6F707172737475767778797A7B7C7D7E7F808182838485868788898A8B8C8D8E8F909192939495969798999A9B9C9D9E9FA0A1 Got: 000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F202122232425262728292A2B2C2D2E2F303132333435363738393A3B3C3D3E3F404142434445464748494A4B4C4D4E4F505152535455565758595A5B5C5D5E5F606162636465666768696A6B6C6D6E6F707172737475767778797A7B7C7D7E7F808182838485868788898A8B8C8D8E8FB1F82828C56DDBB8261932DB4DA50A020EE8 499 tests completed with 1 errors, 0 skipped ********** ( cd test; \ SRCTOP=../. \ BLDTOP=../. \ PERL="/usr/bin/perl" \ EXE_EXT= \ OPENSSL_ENGINES=.././engines \ /usr/bin/perl .././test/run_tests.pl ) ../test/recipes/01-test_abort.t ............ ok ../test/recipes/01-test_ordinals.t ......... ok ../test/recipes/01-test_symbol_presence.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_d2i.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_afalg.t ............ skipped: test_afalg not supported for this build ../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 18. # 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 ........... ok ../test/recipes/70-test_asyncio.t .......... ok ../test/recipes/70-test_clienthello.t ...... ok ../test/recipes/70-test_packet.t ........... ok ../test/recipes/70-test_sslcertstatus.t .... ok ../test/recipes/70-test_sslextension.t ..... ok ../test/recipes/70-test_sslrecords.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_cipherlist.t ....... ok ../test/recipes/80-test_cms.t .............. ok ../test/recipes/80-test_ct.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_new.t .......... ok ../test/recipes/80-test_ssl_old.t .......... ok ../test/recipes/80-test_ssl_test_ctx.t ..... ok ../test/recipes/80-test_tsa.t .............. ok ../test/recipes/80-test_x509aux.t .......... ok ../test/recipes/90-test_async.t ............ ok ../test/recipes/90-test_bioprint.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_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_sslapi.t ........... ok ../test/recipes/90-test_threads.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 Files=80, Tests=414, 241 wallclock secs ( 1.60 usr 0.53 sys + 183.14 cusr 23.44 csys = 208.71 CPU) Result: FAIL Failed 1/80 test programs. 1/414 subtests failed. make: *** [tests] Error 255 -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4578 Please log in as guest with password guest if prompted From rt at openssl.org Sat Jun 18 14:05:39 2016 From: rt at openssl.org (Andy Polyakov via RT) Date: Sat, 18 Jun 2016 14:05:39 +0000 Subject: [openssl-dev] [openssl.org #4578] ARMv7a and failed self test In-Reply-To: <5765552D.3030800@openssl.org> References: <5765552D.3030800@openssl.org> Message-ID: > The following is from a CubieBoard. I verified I performed a 'make > clean' and 'git pull'. > > $ git rev-parse HEAD > 13c03c8d6da334bb1cde6ce4133e7c75b3b76947 > > ********** > > using V=1: > > ../test/recipes/30-test_evp.t .............. > 1..1 > Test line 2163(aligned in-place): unexpected error VALUE_MISMATCH > Expected: 000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F202122232425262728292A2B2C2D2E2F303132333435363738393A3B3C3D3E3F404142434445464748494A4B4C4D4E4F505152535455565758595A5B5C5D5E5F606162636465666768696A6B6C6D6E6F707172737475767778797A7B7C7D7E7F808182838485868788898A8B8C8D8E8F909192939495969798999A9B9C9D9E9FA0A1 > Got: 000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F202122232425262728292A2B2C2D2E2F303132333435363738393A3B3C3D3E3F404142434445464748494A4B4C4D4E4F505152535455565758595A5B5C5D5E5F606162636465666768696A6B6C6D6E6F707172737475767778797A7B7C7D7E7F808182838485868788898A8B8C8D8E8FB1F82828C56DDBB8261932DB4DA50A020EE8 > 499 tests completed with 1 errors, 0 skipped Please double-check attached patches. Only first one is required to fix the problem, second is kind of clean-up thing... -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4578 Please log in as guest with password guest if prompted -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-aes-asm-bsaes-armv7.pl-fix-XTS-decrypt-test-failure.patch Type: text/x-patch Size: 762 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-aes-asm-bsaes-armv7.pl-omit-redundant-stores-in-XTS-.patch Type: text/x-patch Size: 3133 bytes Desc: not available URL: From rt at openssl.org Sat Jun 18 14:39:07 2016 From: rt at openssl.org (Matt Caswell via RT) Date: Sat, 18 Jun 2016 14:39:07 +0000 Subject: [openssl-dev] [openssl.org #4378] Multiple warnings under OpenBSD 5.7/64-bit In-Reply-To: References: Message-ID: Fixed in latest master. There are a few spurious warning left that I did not fix. They look like cases of the compiler being overly picky IMO. Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4378 Please log in as guest with password guest if prompted From rt at openssl.org Sat Jun 18 14:46:42 2016 From: rt at openssl.org (noloader@gmail.com via RT) Date: Sat, 18 Jun 2016 14:46:42 +0000 Subject: [openssl-dev] [openssl.org #4578] ARMv7a and failed self test In-Reply-To: References: <5765552D.3030800@openssl.org> Message-ID: >> ../test/recipes/30-test_evp.t .............. >> 1..1 >> Test line 2163(aligned in-place): unexpected error VALUE_MISMATCH >> Expected: 000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F202122232425262728292A2B2C2D2E2F303132333435363738393A3B3C3D3E3F404142434445464748494A4B4C4D4E4F505152535455565758595A5B5C5D5E5F606162636465666768696A6B6C6D6E6F707172737475767778797A7B7C7D7E7F808182838485868788898A8B8C8D8E8F909192939495969798999A9B9C9D9E9FA0A1 >> Got: 000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F202122232425262728292A2B2C2D2E2F303132333435363738393A3B3C3D3E3F404142434445464748494A4B4C4D4E4F505152535455565758595A5B5C5D5E5F606162636465666768696A6B6C6D6E6F707172737475767778797A7B7C7D7E7F808182838485868788898A8B8C8D8E8FB1F82828C56DDBB8261932DB4DA50A020EE8 >> 499 tests completed with 1 errors, 0 skipped > > Please double-check attached patches. Only first one is required to fix > the problem, second is kind of clean-up thing... I applied both patches at once (i.e., did not test separately). test_evp tested OK: ../test/recipes/30-test_engine.t ........... ok ../test/recipes/30-test_evp.t .............. ok ../test/recipes/30-test_evp_extra.t ........ ok Jeff -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4578 Please log in as guest with password guest if prompted From rt at openssl.org Mon Jun 20 01:53:28 2016 From: rt at openssl.org (Ty Baen-Price via RT) Date: Mon, 20 Jun 2016 01:53:28 +0000 Subject: [openssl-dev] [openssl.org #4526] bug: use of ExitProcess on Windows platforms, 1.0.2g In-Reply-To: References: Message-ID: Hi! I just looked on GitHub and I see the reason you reverted the change is that TerminateProcess is asynchronous. That is technically true, but I think it's probably synchronous "enough" for your purposes, since a call to TerminateProcess suspends execution of all threads in the target process. This means it's really only asynchronous if you're calling TerminateProcess one some *other* process. If you're calling TerminateProcess on your own process, you'll never return from the TerminateProcess call. Regards, Ty -----Original Message----- From: Matt Caswell via RT [mailto:rt at openssl.org] Sent: Friday, 17 June 2016 4:44 AM To: Ty Baen-Price Cc: openssl-dev at openssl.org Subject: [openssl.org #4526] bug: use of ExitProcess on Windows platforms, 1.0.2g On Wed Jun 15 17:42:58 2016, rsalz wrote: > OpenSSL_1_0_2-stable 75f9068 RT4526: Call TerminateProcess, not > ExitProcess master 9c1a9cc RT4526: Call TerminateProcess, not > ExitProcess > > Author: Rich Salz > Date: Tue Jun 14 16:19:37 2016 -0400 > > RT4526: Call TerminateProcess, not ExitProcess > > Reviewed-by: Richard Levitte I just reverted this commit. We need to take another look at this, so reopening this ticket. Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4526 Please log in as guest with password guest if prompted -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4526 Please log in as guest with password guest if prompted From rt at openssl.org Mon Jun 20 07:31:39 2016 From: rt at openssl.org (Matt Caswell via RT) Date: Mon, 20 Jun 2016 07:31:39 +0000 Subject: [openssl-dev] [openssl.org #4561] BUG: openssl-1.0.2h, evp_enc.c, non-portable bitwise operation In-Reply-To: References: , Message-ID: On Mon Jun 13 09:37:59 2016, loic.etienne at qnective.com wrote: > My claim about portability issues was wrong (sorry): The C-standard > ensures that positive values are handled in the two's complement > system, indeed. > > However, inl % block_size == inl & (block_size-1) is true if and only > if block_size is a power of two, which happens to be true under the > current implementation, but may change in the future. I think if that assumption is probably in multiple places in the code. I don't think this is worth fixing at this stage. Closing this ticket. Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4561 Please log in as guest with password guest if prompted From rt at openssl.org Mon Jun 20 09:49:15 2016 From: rt at openssl.org (Mick Saxton via RT) Date: Mon, 20 Jun 2016 09:49:15 +0000 Subject: [openssl-dev] [openssl.org #4545] Crash in crypto/rand/md_rand.c In-Reply-To: References: <576455F7.7060703@openssl.org> <576482C1.8040808@openssl.org> Message-ID: I modified your patch to also catch the similar problem in ssleay_rand_bytes. Results from the instrumented tests attached. These tests were run on 64-bit Windows 7. I have not specified a locking callback so will be using the default ? could this be the problem? Each thread has it?s own SSL_ctx and each connection is only ever serviced by the same thread. It looks like state_index is going outside of the expected range. This is possible if one or more threads do state_index += num_ceil; and then another thread reads it before if ( state_index > state_num ) state_index %= st_num.; Thanks for your help From: Matt Caswell via RT [mailto:rt at openssl.org] Sent: 18 June 2016 00:08 To: Mick Saxton Cc: openssl-dev at openssl.org Subject: Re: [openssl-dev] [openssl.org #4545] Crash in crypto/rand/md_rand.c On 17/06/16 20:56, Matt Caswell via RT wrote: > > > On 17/06/16 19:43, Mick Saxton via RT wrote: >> Perhaps we should consider if there are any negative consequences to my solution? >> It does work. >> >> I am trying really hard to get contention but I am only seeing this problem in about 1 out of 100,000 successful TLSv1.2 connections >> On a heavily congested network. >> I require three machines to just to run the test that causes the failure. >> >> All we are trying to do is get a random number ? surely getting a slightly less random number is better than crashing? >> It could be that the problematic instances were going to disconnect anyway due to TCP/IP problems. >> > > I think we need to try instrumenting the code to see if we can get some > more information out. I will try and pull something together - but it > might be Monday before I get the opportunity. I got to it quicker than I thought. Please see attached patch. Can you apply it to the latest git 1.0.2 version and re-run your test (capture stderr output). I'd like to see what we get. Also is this 32-bit or 64-bit Windows? Are you able to share your locking callback implementation? Thanks Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4545 Please log in as guest with password guest if prompted ________________________________ Legal Notice: This email is intended only for the person(s) to whom it is addressed. If you are not an intended recipient and have received this message in error, please notify the sender immediately by replying to this email or calling +44(0) 2083269015 (UK) or +1 866 592 4214 (USA). This email and any attachments may be privileged and/or confidential. The unauthorized use, disclosure, copying or printing of any information it contains is strictly prohibited. The opinions expressed in this email are those of the author and do not necessarily represent the views of 1E Ltd. Nothing in this email will operate to bind 1E to any order or other contract. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4545 Please log in as guest with password guest if prompted -------------- next part -------------- MD_RAND ERROR: ssleay_rand_add: k == 35, j == 4, st_idx == 1054, state_num == 1023, do_not_lock 0, crypto_lock_rand == 0, locking_threadid == 3204, thisthreadid == 2756 MD_RAND ERROR: ssleay_rand_add: k == 35, j == 4, st_idx == 1054, state_num == 1023, do_not_lock 0, crypto_lock_rand == 0, locking_threadid == 3204, thisthreadid == 2756 MD_RAND ERROR: ssleay_rand_bytes: k == 23, j == 10, st_idx == 1036, state_num == 1023, do_not_lock N/A, crypto_lock_rand == 0, locking_threadid == 8176, thisthreadid == 8176 From rt at openssl.org Mon Jun 20 10:00:42 2016 From: rt at openssl.org (Matt Caswell via RT) Date: Mon, 20 Jun 2016 10:00:42 +0000 Subject: [openssl-dev] [openssl.org #4545] Crash in crypto/rand/md_rand.c In-Reply-To: <5767BEC6.8060206@openssl.org> References: <576482C1.8040808@openssl.org> <5767BEC6.8060206@openssl.org> Message-ID: On 20/06/16 10:49, Mick Saxton via RT wrote: > I modified your patch to also catch the similar problem in ssleay_rand_bytes. > Results from the instrumented tests attached. > > These tests were run on 64-bit Windows 7. > I have not specified a locking callback so will be using the default ? could this be the problem? Ahhh!!! Yes!!! https://www.openssl.org/docs/faq.html#PROG1 >From the "threads" man page: https://www.openssl.org/docs/man1.0.2/crypto/threads.html "OpenSSL can safely be used in multi-threaded applications provided that at least two callback functions are set, locking_function and threadid_func. locking_function(int mode, int n, const char *file, int line) is needed to perform locking on shared data structures. (Note that OpenSSL uses a number of global data structures that will be implicitly shared whenever multiple threads use OpenSSL.) Multi-threaded applications will crash at random if it is not set." In version 1.1.0 (not released yet) this requirement has gone - but this is still needed for all released versions. Matt > > Each thread has it?s own SSL_ctx and each connection is only ever serviced by the same thread. > > It looks like state_index is going outside of the expected range. > > This is possible if one or more threads do > state_index += num_ceil; > > and then another thread reads it before > if ( state_index > state_num ) > state_index %= st_num.; > > Thanks for your help > > > From: Matt Caswell via RT [mailto:rt at openssl.org] > Sent: 18 June 2016 00:08 > To: Mick Saxton > Cc: openssl-dev at openssl.org > Subject: Re: [openssl-dev] [openssl.org #4545] Crash in crypto/rand/md_rand.c > > > > On 17/06/16 20:56, Matt Caswell via RT wrote: >> >> >> On 17/06/16 19:43, Mick Saxton via RT wrote: >>> Perhaps we should consider if there are any negative consequences to my solution? >>> It does work. >>> >>> I am trying really hard to get contention but I am only seeing this problem in about 1 out of 100,000 successful TLSv1.2 connections >>> On a heavily congested network. >>> I require three machines to just to run the test that causes the failure. >>> >>> All we are trying to do is get a random number ? surely getting a slightly less random number is better than crashing? >>> It could be that the problematic instances were going to disconnect anyway due to TCP/IP problems. >>> >> >> I think we need to try instrumenting the code to see if we can get some >> more information out. I will try and pull something together - but it >> might be Monday before I get the opportunity. > > I got to it quicker than I thought. Please see attached patch. Can you > apply it to the latest git 1.0.2 version and re-run your test (capture > stderr output). I'd like to see what we get. > > Also is this 32-bit or 64-bit Windows? Are you able to share your > locking callback implementation? > > Thanks > > Matt > > > -- > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4545 > Please log in as guest with password guest if prompted > > ________________________________ > > > Legal Notice: This email is intended only for the person(s) to whom it is addressed. If you are not an intended recipient and have received this message in error, please notify the sender immediately by replying to this email or calling +44(0) 2083269015 (UK) or +1 866 592 4214 (USA). This email and any attachments may be privileged and/or confidential. The unauthorized use, disclosure, copying or printing of any information it contains is strictly prohibited. The opinions expressed in this email are those of the author and do not necessarily represent the views of 1E Ltd. Nothing in this email will operate to bind 1E to any order or other contract. > > > -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4545 Please log in as guest with password guest if prompted From rt at openssl.org Mon Jun 20 10:35:01 2016 From: rt at openssl.org (Andy Polyakov via RT) Date: Mon, 20 Jun 2016 10:35:01 +0000 Subject: [openssl-dev] [openssl.org #4578] ARMv7a and failed self test In-Reply-To: <5767C6D5.6030303@openssl.org> References: <5765552D.3030800@openssl.org> <5767C6D5.6030303@openssl.org> Message-ID: >>> ../test/recipes/30-test_evp.t .............. >>> 1..1 >>> Test line 2163(aligned in-place): unexpected error VALUE_MISMATCH >>> Expected: 000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F202122232425262728292A2B2C2D2E2F303132333435363738393A3B3C3D3E3F404142434445464748494A4B4C4D4E4F505152535455565758595A5B5C5D5E5F606162636465666768696A6B6C6D6E6F707172737475767778797A7B7C7D7E7F808182838485868788898A8B8C8D8E8F909192939495969798999A9B9C9D9E9FA0A1 >>> Got: 000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F202122232425262728292A2B2C2D2E2F303132333435363738393A3B3C3D3E3F404142434445464748494A4B4C4D4E4F505152535455565758595A5B5C5D5E5F606162636465666768696A6B6C6D6E6F707172737475767778797A7B7C7D7E7F808182838485868788898A8B8C8D8E8FB1F82828C56DDBB8261932DB4DA50A020EE8 >>> 499 tests completed with 1 errors, 0 skipped >> >> Please double-check attached patches. Only first one is required to fix >> the problem, second is kind of clean-up thing... > > I applied both patches at once (i.e., did not test separately). > > test_evp tested OK: > > ../test/recipes/30-test_engine.t ........... ok > ../test/recipes/30-test_evp.t .............. ok > ../test/recipes/30-test_evp_extra.t ........ ok Thank you. Case is being closed. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4578 Please log in as guest with password guest if prompted From rt at openssl.org Mon Jun 20 13:26:15 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 20 Jun 2016 13:26:15 +0000 Subject: [openssl-dev] [openssl.org #3136] [PATCH] get rid of extra space when printing -subject and -issuer in x509 In-Reply-To: <524D59A3.40207@gmail.com> References: <524D59A3.40207@gmail.com> Message-ID: commit fb0303f in master. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3136 Please log in as guest with password guest if prompted From rt at openssl.org Mon Jun 20 15:44:58 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 20 Jun 2016 15:44:58 +0000 Subject: [openssl-dev] [openssl.org #4381] [PATCH] Missing Sanity Check for OBJ_nid2obj() in OpenSSL-1.0.2g In-Reply-To: References: Message-ID: this is a "can't happen" kind of thing. If you pass in a NID_xxx value, you MUST get back the object. They are two tables built in-sync. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4381 Please log in as guest with password guest if prompted From rt at openssl.org Mon Jun 20 16:02:49 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 20 Jun 2016 16:02:49 +0000 Subject: [openssl-dev] [openssl.org #3728] Question: does "sslv3" in log mean we're using SSLv3? In-Reply-To: <781cf2c732224d059e15892145113496@mercmbx58d.na.SAS.com> References: <781cf2c732224d059e15892145113496@mercmbx58d.na.SAS.com> Message-ID: There are no plans, at this point, to change the names used in logging. If you think it's worthwhile, please open a *github issue* for this. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3728 Please log in as guest with password guest if prompted From rt at openssl.org Mon Jun 20 16:05:58 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 20 Jun 2016 16:05:58 +0000 Subject: [openssl-dev] [openssl.org #3844] FW: regarding shared library for openssl -1.0.2a In-Reply-To: References: Message-ID: A local environment/compiler issue that we cannot address. No activity in years on this. closing ticket. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3844 Please log in as guest with password guest if prompted From rt at openssl.org Mon Jun 20 16:18:47 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 20 Jun 2016 16:18:47 +0000 Subject: [openssl-dev] [openssl.org #3868] [PATCH] Add SSL_get0_peer_certificate() In-Reply-To: <865493D4-E0A4-433C-99D4-7B73984DF58D@akamai.com> References: <865493D4-E0A4-433C-99D4-7B73984DF58D@akamai.com> Message-ID: Is this needed? Can your get0 function just call get and decrement the refcount? -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3868 Please log in as guest with password guest if prompted From rt at openssl.org Mon Jun 20 16:21:59 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 20 Jun 2016 16:21:59 +0000 Subject: [openssl-dev] [openssl.org #3918] check return value of EC_POINT_mul In-Reply-To: References: Message-ID: GOST is now a separate engine. Ping Dmitry :) -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3918 Please log in as guest with password guest if prompted From rt at openssl.org Mon Jun 20 16:23:50 2016 From: rt at openssl.org (Short, Todd via RT) Date: Mon, 20 Jun 2016 16:23:50 +0000 Subject: [openssl-dev] [openssl.org #3868] [PATCH] Add SSL_get0_peer_certificate() In-Reply-To: <58861BDB-B576-454F-9694-0D947CB57654@akamai.com> References: <865493D4-E0A4-433C-99D4-7B73984DF58D@akamai.com> <58861BDB-B576-454F-9694-0D947CB57654@akamai.com> Message-ID: Not strictly necessary; mostly convenience. Decrementing the pointer usually requires doing the corresponding free, which really shouldn?t do anything but decrement the refcount if you just got it. -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." On Jun 20, 2016, at 12:18 PM, Rich Salz via RT > wrote: Is this needed? Can your get0 function just call get and decrement the refcount? -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3868 Please log in as guest with password guest if prompted -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3868 Please log in as guest with password guest if prompted From rt at openssl.org Mon Jun 20 16:25:14 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 20 Jun 2016 16:25:14 +0000 Subject: [openssl-dev] [openssl.org #3868] [PATCH] Add SSL_get0_peer_certificate() In-Reply-To: <865493D4-E0A4-433C-99D4-7B73984DF58D@akamai.com> References: <865493D4-E0A4-433C-99D4-7B73984DF58D@akamai.com> Message-ID: There will be no free since you've got the SSL lifetime. and esp for 1.1 which uses atomics, closing this. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3868 Please log in as guest with password guest if prompted From rt at openssl.org Mon Jun 20 16:27:22 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 20 Jun 2016 16:27:22 +0000 Subject: [openssl-dev] [openssl.org #4469] Openssl linker errors In-Reply-To: References: Message-ID: You have turned off so many things, that some files are not compiled. Try building without all your no-xxx flags. You don't need to turn them all off, the patents are expired. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4469 Please log in as guest with password guest if prompted From rt at openssl.org Mon Jun 20 16:28:03 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 20 Jun 2016 16:28:03 +0000 Subject: [openssl-dev] [openssl.org #4570] Enhancement request: Configuration option no-hw-aes In-Reply-To: References: Message-ID: Thanks for the discussion; closing this ticket. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4570 Please log in as guest with password guest if prompted From rt at openssl.org Mon Jun 20 16:36:21 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 20 Jun 2016 16:36:21 +0000 Subject: [openssl-dev] [openssl.org #4416] 1.0.1s makes porting to HP-UX much harder than before In-Reply-To: <20160311151614.125857bc@pc09.procura.nl> References: <20160311151614.125857bc@pc09.procura.nl> Message-ID: Discussion happened in https://github.com/openssl/openssl/issues/806 (which looks like it can be c losed). Closing this ticket. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4416 Please log in as guest with password guest if prompted From rt at openssl.org Mon Jun 20 17:50:17 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 20 Jun 2016 17:50:17 +0000 Subject: [openssl-dev] [openssl.org #3934] [PATCH] test: use _DEFAULT_SOURCE with newer glibc versions In-Reply-To: <1436507746-2476-1-git-send-email-vapier@gentoo.org> References: <1436507746-2476-1-git-send-email-vapier@gentoo.org> Message-ID: looks like someone already fixed this. closing ticket. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3934 Please log in as guest with password guest if prompted From rt at openssl.org Mon Jun 20 18:03:45 2016 From: rt at openssl.org (=?UTF-8?B?T251ciBUQcWeTElPxJ5MVQ==?= via RT) Date: Mon, 20 Jun 2016 18:03:45 +0000 Subject: [openssl-dev] [openssl.org #4579] Bug - libcrypto.a null pointer dereference bug In-Reply-To: References: Message-ID: Operating System Version: Distributor ID: Ubuntu Description: Ubuntu 14.04.3 LTS Release: 14.04 Codename: trusty Linux 3.19.0-28-generic OpenSSL Version : openssl-1.0.1t Critical Function : X509_verify (); And: 0x080e15ef in X509_verify (a=a at entry=0x0, r=r at entry=0x0) at x_all.c:75 75 if (X509_ALGOR_cmp(a->sig_alg, a->cert_info->signature)) Author: Onur TA?LIO?LU Thanks All -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4579 Please log in as guest with password guest if prompted From rt at openssl.org Mon Jun 20 18:08:27 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 20 Jun 2016 18:08:27 +0000 Subject: [openssl-dev] [openssl.org #4579] Bug - libcrypto.a null pointer dereference bug In-Reply-To: References: Message-ID: 1.0.1 is end of life and only getting bugfixes now. If you can reproduce this on 1.0.2 or master, please open a new ticket. We also need more information, cannot reproduce this issue here. Thanks. closing ticket. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4579 Please log in as guest with password guest if prompted From rt at openssl.org Mon Jun 20 18:25:08 2016 From: rt at openssl.org (=?UTF-8?B?T251ciBUQcWeTElPxJ5MVQ==?= via RT) Date: Mon, 20 Jun 2016 18:25:08 +0000 Subject: [openssl-dev] [openssl.org #4579] Bug - libcrypto.a null pointer dereference bug In-Reply-To: References: Message-ID: Ok, i will try 1.0.2t version and open new ticket. Thanks. 2016-06-20 21:08 GMT+03:00 Rich Salz via RT : > 1.0.1 is end of life and only getting bugfixes now. > If you can reproduce this on 1.0.2 or master, please open a new ticket. > We also need more information, cannot reproduce this issue here. > Thanks. closing ticket. > > -- > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4579 > Please log in as guest with password guest if prompted > > -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4579 Please log in as guest with password guest if prompted From rt at openssl.org Mon Jun 20 18:37:24 2016 From: rt at openssl.org (=?UTF-8?B?T251ciBUQcWeTElPxJ5MVQ==?= via RT) Date: Mon, 20 Jun 2016 18:37:24 +0000 Subject: [openssl-dev] [openssl.org #4579] Bug - libcrypto.a null pointer dereference bug In-Reply-To: References: Message-ID: 1.0.2t version crashed in same place. Operating System Version: Distributor ID: Ubuntu Description: Ubuntu 14.04.3 LTS Release: 14.04 Codename: trusty Linux 3.19.0-28-generic OpenSSL Version : openssl-1.0.1t Critical Function : X509_verify (); And: 0x080e15ef in X509_verify (a=a at entry=0x0, r=r at entry=0x0) at x_all.c:75 75 if (X509_ALGOR_cmp(a->sig_alg, a->cert_info->signature)) Author: Onur TA?LIO?LU 2016-06-20 21:24 GMT+03:00 Onur TA?LIO?LU : > Ok, i will try 1.0.2t version and open new ticket. > > Thanks. > > 2016-06-20 21:08 GMT+03:00 Rich Salz via RT : > >> 1.0.1 is end of life and only getting bugfixes now. >> If you can reproduce this on 1.0.2 or master, please open a new ticket. >> We also need more information, cannot reproduce this issue here. >> Thanks. closing ticket. >> >> -- >> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4579 >> Please log in as guest with password guest if prompted >> >> > -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4579 Please log in as guest with password guest if prompted From rt at openssl.org Mon Jun 20 18:39:13 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Mon, 20 Jun 2016 18:39:13 +0000 Subject: [openssl-dev] [openssl.org #4579] Bug - libcrypto.a null pointer dereference bug In-Reply-To: <92c9bc5437e746c78f2140b9cfa685f4@usma1ex-dag1mb1.msg.corp.akamai.com> References: <92c9bc5437e746c78f2140b9cfa685f4@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: Need more information, like a full backtrace and how to reproduce it. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4579 Please log in as guest with password guest if prompted From rt at openssl.org Mon Jun 20 18:44:17 2016 From: rt at openssl.org (=?UTF-8?B?T251ciBUQcWeTElPxJ5MVQ==?= via RT) Date: Mon, 20 Jun 2016 18:44:17 +0000 Subject: [openssl-dev] [openssl.org #4579] Bug - libcrypto.a null pointer dereference bug In-Reply-To: References: <92c9bc5437e746c78f2140b9cfa685f4@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: I have a simple code; #include #include #include #include int verify_cert(const char* pem_c_str) { BIO *bio_mem = BIO_new(BIO_s_mem()); BIO_puts(bio_mem, pem_c_str); X509 * x509 = PEM_read_bio_X509(bio_mem, NULL, NULL, NULL); EVP_PKEY *pkey=X509_get_pubkey(x509); int r= X509_verify(x509, pkey); EVP_PKEY_free(pkey); BIO_free(bio_mem); X509_free(x509); return r; } int main(int argc, char **argv) { OpenSSL_add_all_algorithms(); FILE* fd = NULL; char publicKey[4000]; memset(publicKey,'\0',sizeof(publicKey)); fd = fopen(argv[1],"rw+"); fread(publicKey,1,4000,fd); fseek(fd,1,SEEK_CUR); fclose(fd); verify_cert(publicKey); EVP_cleanup(); } and i have a simple public key: -----BEGINCERTIFICATE----- MIIDIjCCAgoCCQCE8H4/ymXyrzANBgkqhkiG9w0BAQUFADBTMQswCQYDVQQGEwJV UzENMAsGA1UECAwEVXRhaDENMAsGA1UEBwwET3JlbTEQMA4GA1UECgwHT3JnTmFt ZTEUMBIGA1UEAwwLZXhhbXBsZS5jb20wHhcNMTMwNDEwMjIxMjE5WhcNMTQwNDEw MjIxMjE5WjBTMQswCQYDVQQGEwJVUzENMAsGA1UECAwEVXRhaDENMAsGA1UEBwwE T3JlbTEQMA4GA1UECgwHT3JnTmFtZTEUMBIGA1UEAwwLZXhhbXBsZS5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCuzA1sONmXPc6aMt+cZExA37OZ kpVlfMCQUy8tTvqSs81F0DeTUGqq8ACdXT9iMlvENQ04xrtTEHPJcY93cAsaLowX 6pB1y1F+8Jj+rrOwmKjBM9EI0/M9TCS94IGqTcPwgQt1d+XOZ+EdL63SkTQtNFHH hGs+g9Q+zeSM0uD7WgVxJPWezjnzQUis4j9ICXwMpuAMcmTqmxSqTzOQZAINJ9Hv sazPMVKs+JPEZvCfP0r61d1C8WLE7QF4nmdmWUTaBO+92piqQSeF7rK3bWmCxJNX 8BFQd6h8g4XviMrybSwzf3JgM2Wxw27Vo9EADZ5Om8EjNPvB2UIbAokCOBN7AgMB AAEwDQYJKoZIhvcNAQEFBQADggEBAHhm2J8+Dg91S1b/i9LEpn41QSMpyyonzxqo o45CzJAuV5qN6x7FMBXB+1e+Na4Qn5K/8fJ8Z2M6jIO2MD+gB+ftVY830aN8cm+i /Cu/iUgB9kaSDLBUZvwu2uSEyDFwdxgmF5jK2BECNTP5A99WtL3w0dE60w5Bq23L Ivzd7XZF1orR9gJYOGHNK2s3S1vJQLBRvfRi78wfl25jyaZ2JWKGguFpQq1zJkrY PeCGvx+54fTOTi1PZcL4+xYfA//dvB1DnlHwpNSKnWkcNI5VK6IpDfBlh4ZjB3I3 h6v6zOyvgOcvTXBHmzPsfMym1AmFNTv9/bRlwrKUlGGPaRwSEKU= -----END CERTIFICATE----- my program have a one input. When i give input a public key. Program crashed. 2016-06-20 21:39 GMT+03:00 Salz, Rich via RT : > Need more information, like a full backtrace and how to reproduce it. > > -- > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4579 > Please log in as guest with password guest if prompted > > -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4579 Please log in as guest with password guest if prompted From rt at openssl.org Mon Jun 20 18:59:09 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 20 Jun 2016 18:59:09 +0000 Subject: [openssl-dev] [openssl.org #4579] Bug - libcrypto.a null pointer dereference bug In-Reply-To: References: Message-ID: When I added this line: (if x509==NULL) { ERR_print_errors_fp(stderr); exit(1); } it complained 140259630204736:error:0906D06C:PEM routines:PEM_read_bio:no start line:crypto/pem/pem_lib.c:691:Expecting: CERTIFICATE When I fixed the file to say "BEGIN CERTIFICATE" (added a space) and changed the code to print the result of calling the verify routine, it all works. Closing ticket. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4579 Please log in as guest with password guest if prompted From rt at openssl.org Mon Jun 20 19:13:57 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 20 Jun 2016 19:13:57 +0000 Subject: [openssl-dev] [openssl.org #3925] [PATCH] Removed trailing semicolon from macro body of three function-like macros In-Reply-To: <1435136894-11007-1-git-send-email-Matthias.St.Pierre@ncp-e.com> References: <1435136894-11007-1-git-send-email-Matthias.St.Pierre@ncp-e.com> Message-ID: OpenSSL_1_0_2-stable commit 398260a; master commit 54f24e3 thanks. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3925 Please log in as guest with password guest if prompted From brian at briansmith.org Mon Jun 20 19:19:20 2016 From: brian at briansmith.org (Brian Smith) Date: Mon, 20 Jun 2016 09:19:20 -1000 Subject: [openssl-dev] Assembler warns about constants in poly1306-x86_64.pl Message-ID: Yasm 1.3.0 (Like nasm, but it embeds debug symbols into the asm code on Windows) reports: poly1305-x86_64.asm(456): warning : value does not fit in 32 bit field poly1305-x86_64.asm(459): warning : value does not fit in 32 bit field poly1305-x86_64.asm(1346): warning : value does not fit in 32 bit field poly1305-x86_64.asm(1349): warning : value does not fit in 32 bit field For these lines: and \$`-1<<31`,$d1 and \$`-1<<31`,$d2 and \$`-1<<31`,$d1 and \$`-1<<31`,$d2 I'm not sure what approach is preferable to silence these warnings though. Cheers, Brian -- https://briansmith.org/ From rt at openssl.org Mon Jun 20 19:37:42 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Mon, 20 Jun 2016 19:37:42 +0000 Subject: [openssl-dev] [openssl.org #1852] [BUG] Invalid Proxy Certificates Pass Validation In-Reply-To: References: <49A81357.30509@switch.ch> <20160202014435.GM4987@mournblade.imrryr.org> Message-ID: On Tue Feb 02 01:44:47 2016, openssl-dev at openssl.org wrote: > 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. This has now been fixed in master, along with a pc pathlength checking bug fix. The backport to 1.0.2 (and possibly 1.0.1) is still pending review. Cheers, Richard -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=1852 Please log in as guest with password guest if prompted From rt at openssl.org Mon Jun 20 20:33:52 2016 From: rt at openssl.org (=?UTF-8?B?T251ciBUQcWeTElPxJ5MVQ==?= via RT) Date: Mon, 20 Jun 2016 20:33:52 +0000 Subject: [openssl-dev] [openssl.org #4579] Bug - libcrypto.a null pointer dereference bug In-Reply-To: References: Message-ID: Yes, i know. I'am vulnerability researcher. Thanks. 2016-06-20 21:59 GMT+03:00 Rich Salz via RT : > When I added this line: > (if x509==NULL) { ERR_print_errors_fp(stderr); exit(1); } > it complained > 140259630204736:error:0906D06C:PEM routines:PEM_read_bio:no start > line:crypto/pem/pem_lib.c:691:Expecting: CERTIFICATE > > > When I fixed the file to say "BEGIN CERTIFICATE" (added a space) and > changed > the code to print the result of calling the verify routine, it all works. > > Closing ticket. > > -- > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4579 > Please log in as guest with password guest if prompted > > -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4579 Please log in as guest with password guest if prompted From rt at openssl.org Mon Jun 20 20:40:30 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 20 Jun 2016 20:40:30 +0000 Subject: [openssl-dev] [openssl.org #4376] pull request 785 In-Reply-To: References: Message-ID: There was some discussion over on the pull request thread, https://github.com/openssl/openssl/pull/785 And there the feeling was this is a new feature. Closing the ticket. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4376 Please log in as guest with password guest if prompted From rt at openssl.org Mon Jun 20 20:43:01 2016 From: rt at openssl.org (=?UTF-8?B?T251ciBUQcWeTElPxJ5MVQ==?= via RT) Date: Mon, 20 Jun 2016 20:43:01 +0000 Subject: [openssl-dev] [openssl.org #4579] Resolved: Bug - libcrypto.a null pointer dereference bug In-Reply-To: References: Message-ID: i have a different bug and a different place. There is again null pointer derefenrence. As it does not matter. 2016-06-20 23:35 GMT+03:00 Rich Salz via RT : > According to our records, your request has been resolved. If you have any > further questions or concerns, please respond to this message. > > -- > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4579 > Please log in as guest with password guest if prompted > > -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4579 Please log in as guest with password guest if prompted From rt at openssl.org Mon Jun 20 20:47:01 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 20 Jun 2016 20:47:01 +0000 Subject: [openssl-dev] [openssl.org #4398] BUG / 1.0.2g breaks CURL extension In-Reply-To: References: Message-ID: We believe this is fixed by the commit that viktor pointed out. Is this not true? What are folks asking OpenSSL to do? -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4398 Please log in as guest with password guest if prompted From rt at openssl.org Mon Jun 20 20:48:32 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 20 Jun 2016 20:48:32 +0000 Subject: [openssl-dev] [openssl.org #4579] Bug - libcrypto.a null pointer dereference bug In-Reply-To: References: Message-ID: You are not supposed to pass NULL into OpenSSL API's. Just like doing this will cause a crash strcpy(NULL, "hello") in a C program. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4579 Please log in as guest with password guest if prompted From rt at openssl.org Mon Jun 20 20:58:54 2016 From: rt at openssl.org (=?UTF-8?B?T251ciBUQcWeTElPxJ5MVQ==?= via RT) Date: Mon, 20 Jun 2016 20:58:54 +0000 Subject: [openssl-dev] [openssl.org #4579] Bug - libcrypto.a null pointer dereference bug In-Reply-To: References: Message-ID: I know. The register be NULL therefore crashing. it dont find address. I'am search overflow in openssl but I found it while searching for something else. 2016-06-20 23:48 GMT+03:00 Rich Salz via RT : > You are not supposed to pass NULL into OpenSSL API's. Just like doing this > will > cause a crash > strcpy(NULL, "hello") > in a C program. > > -- > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4579 > Please log in as guest with password guest if prompted > > -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4579 Please log in as guest with password guest if prompted From uri at ll.mit.edu Mon Jun 20 21:04:26 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Mon, 20 Jun 2016 21:04:26 +0000 Subject: [openssl-dev] [openssl.org #4579] Bug - libcrypto.a null pointer dereference bug In-Reply-To: References: Message-ID: On 6/20/16, 16:48 , "openssl-dev on behalf of Rich Salz via RT" wrote: >You are not supposed to pass NULL into OpenSSL API's. Just like doing >this will >cause a crash strcpy(NULL, "hello?) in a C program. Defensive programming is about handling gracefully the cases when the user/caller does something he ?is not supposed to do?. I don?t know if this is an exploitable bug, nor do I care to craft a threat model to assess how bad it could be - but this whole approach doesn?t sound endearing to me. Software that relies on its users doing only the right things?? Really? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5227 bytes Desc: not available URL: From rsalz at akamai.com Mon Jun 20 21:12:28 2016 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 20 Jun 2016 21:12:28 +0000 Subject: [openssl-dev] [openssl.org #4579] Bug - libcrypto.a null pointer dereference bug In-Reply-To: References: Message-ID: <9aac3603a5e448ada2cd689e550098d8@usma1ex-dag1mb1.msg.corp.akamai.com> > Defensive programming is about handling gracefully the cases when the > user/caller does something he ?is not supposed to do?. There is a limit. Should we return an error code that will most likely be ignored? Should the C library be defensive about fprintf, strcpy, etc., etc.? > Software that relies on its users doing only the right things?? Really? OpenSSL *is not* going to check for NULL parameters where you don't supply them. It never has (not universally) and it never will. If you want another language... .:) From uri at ll.mit.edu Mon Jun 20 21:27:17 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Mon, 20 Jun 2016 21:27:17 +0000 Subject: [openssl-dev] [openssl.org #4579] Bug - libcrypto.a null pointer dereference bug In-Reply-To: <9aac3603a5e448ada2cd689e550098d8@usma1ex-dag1mb1.msg.corp.akamai.com> References: <9aac3603a5e448ada2cd689e550098d8@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: On 6/20/16, 17:12 , "openssl-dev on behalf of Salz, Rich" wrote: >> Defensive programming is about handling gracefully the cases when the >> user/caller does something he ?is not supposed to do?. > >There is a limit. True. >Should we return an error code that will most likely be ignored? Yes, as long as you don?t crash... >Should the C library be defensive about fprintf, strcpy, etc., etc.? Heck, yes! There are reasons why sane programmers don?t use strcpy() nowadays. ;) >>Software that relies on its users doing only the right things?? Really? > >OpenSSL *is not* going to check for NULL parameters where you don't >supply them. Is the interface partitioned that well? Perhaps it?s my ignorance, but I didn?t think so. >It never has (not universally) and it never will. If you want another >language... .:) ;-) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5227 bytes Desc: not available URL: From rsalz at akamai.com Tue Jun 21 01:26:13 2016 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 21 Jun 2016 01:26:13 +0000 Subject: [openssl-dev] [openssl.org #4579] Bug - libcrypto.a null pointer dereference bug In-Reply-To: References: <9aac3603a5e448ada2cd689e550098d8@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <43a8808f3da44f94a992a2d8b28139e0@usma1ex-dag1mb1.msg.corp.akamai.com> We are not going to check for NULL pointers in all arguments. Ever. From rt at openssl.org Tue Jun 21 01:38:21 2016 From: rt at openssl.org (=?UTF-8?B?R8OhYm9yIFNURUZBTklL?= via RT) Date: Tue, 21 Jun 2016 01:38:21 +0000 Subject: [openssl-dev] [openssl.org #4580] "openssl verify -CAfile cacerts.pem cert.pem" fails if cacerts.pem is ordered in certain ways In-Reply-To: <7a5d26d9b69743928ebd3fe003cb7f60@XCHMBX1.NavNGo.local> References: <7a5d26d9b69743928ebd3fe003cb7f60@XCHMBX1.NavNGo.local> Message-ID: Dear OpenSSL developers, We recently experienced an issue with our internal Mercurial repositories where Mercurial will refuse to connect to the repository due to an SSL certificate error. The problem appeared to show up randomly on some machines, but not others. The repository is hosted on an SCM-Manager instance and served over https with a certificate signed by our internal root CA, which is in turn deployed to the machines on our network using Active Directory group policies. Recently, our IT department has pushed out a new root CA certificate through Active Directory. This CA is a renewal of the old one, with the validity time extended through 2021, and the signature algorithm changed to SHA256+RSA (was SHA1+RSA before), this was when the problem started happening. The old root CA was not revoked or uninstalled. I tracked down the issue to a problem with OpenSSL, which Mercurial uses for SSL support. Specifically, if OpenSSL is asked to verify an SSL certificate using a CA certificate store containing both a valid CA certificate and an expired one, both correct CA certs for the SSL one, it will _sometimes_ reject the certificate with the following error message: secondary.pem: CN = testing error 10 at 1 depth lookup:certificate has expired The behavior is dependent on the physical ordering of the CA certificates in the store. Specifically, if the only certificates in the store are the valid and expired CAs, then the error occurs only if the valid one comes first. With more than two certificates in the store, the behavior appears to be completely random (but shows up consistently for the same orderings). E.g. with two valid CAs and an expired one, all 3 signing the same SSL cert, the following orders work: older valid CA, expired CA, newer valid CA older valid CA, newer valid CA, expired CA newer valid CA, expired CA, older valid CA but these fail with "certificate has expired": expired CA, older valid CA, newer valid CA (logical ordering, this is the order in which Windows returns certificates deployed using AD) expired CA, newer valid CA, older valid CA newer valid CA, older valid CA, expired CA As a simple testcase, I created the following 3 PEM files: goodcacerts.pem: -----BEGIN CERTIFICATE----- MIIEwzCCAqugAwIBAgIEAwvYVTANBgkqhkiG9w0BAQsFADASMRAwDgYDVQQDEwd0 ZXN0aW5nMB4XDTA3MDcwNzA1MDcwN1oXDTA4MDcwNjA1MDcwN1owEjEQMA4GA1UE AxMHdGVzdGluZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAIHAVog+ GiK2M/QqsnCDTH4U9C2Bp47CEGNvHBWLVJh2ikfnpydmQUgo2JPeAn7UldRZKtS0 ORQt9mSvFdL9llxfbQVn4XnJM3GzKewQjrvBvBm0c9v99k37F0F0rlDrm1wWzs8C Jzw2xiBSeznpLWCWtOKvWy7P9kGNlN32xNNw7P9hSfMjwXeXICCWlj0nD1rngoyp jvrrobXGpZ+5gUUBg40AspLlN0bsaMjBSBmpFIZs7g9iPmVP4ANlzkPOwjLfXlk3 1CFef8F48NrlprjAzRAvSSgpixDCeYu/yjK+1IKCo1g9bYTVv41RlCs9f2Q6JjQ8 t/CtHkFnin6wKgnEQwpkwPd8DIRpgKzcYQkFym2kPolP1BPE6vvuLEwb2k1sokjQ U35HEL9UvLzhEPlIPqtzaOcV3eQb08GpLv8CihHHubtWXV4DIrkBHwLDwC9inM/l NSc3JefFy8I6BWxxzmXu8Wcvn9EsheJKswnJB+/0IgBuXT5RFdpBNCFRI/mdb33N bIpS27J7CZW3sbXT2UVMuYTU7862nymd0m/bY8PQHypqep0xCCzEd35qC4jaY+RA DJZQGRbEXfOkRGkxxzvES8m87pThT5SIJzutuiiufmbtlqdZWv+a3v/L+rpjIBet cRF2Sb44aTmc9RvAJ802s7XxlrYuyqy4D/MzAgMBAAGjITAfMB0GA1UdDgQWBBSY /19/f9b2cU+d4GT8hVS7LWD+ejANBgkqhkiG9w0BAQsFAAOCAgEAV+PnySD6Nkct SsohAvra8Xuski5ZwHfymAICRM9ZWD6s/2/7y652vegMw40wxW3ZeT7NTzoi+MiT LgYsbdu7upRGvS6dnB7ye8udOtIPhk/QPqDgH0SkxB2imeUaprX8EJUYFQX0AUd7 MAqMcqVFrpYo7xjXCxsWpWPzT6USsG9gjcSbWoukxIGmhlNvtKycSY3+L0HFZKyr mMHZxYsUxVyPKBwfhwQTC/RQccCNLRdW68eaJSjxrbFjkMCLtppGqKHfRr/KBMvf 7K5q52vZ2O324yVdQdQjPuLk84pyJmyZ8Ew48XK06ebHgbx+fBDsNYq27IU4GRm+ FMl/Rp0q/fxZ3CphBNBdyDRRIGzIJN4e3ocSeNDcQt6uD7h88D0FrCXrlkxYGW51 qvaxFmUXlAjuv0K2iRDzvVbP2A6JhB2PBUw/lkEDcy2WP0WctLdL/GVeatRTUlzw jxQRSi21Azwq9I4fqG/cwDDiWPGmyP2/xJoZROhky0zm/0A9mWEU9R7tB+FppZZN 3Un9HtSIRt30mqC1AgcIdiFlXpS5RiJElgIEuJVma3P2BxFK2glycy12UYy9gcOw VV9D2OrLNxKp9icmy/D2b9Z2udLji9jI0MIhl/xDlshsTtkDmOshgqnKIyNzF/gF 8fgqQZm0AezWcLtrnbFTSG2f6Rpdjec= -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIExTCCAq2gAwIBAgIEKKekeTANBgkqhkiG9w0BAQsFADASMRAwDgYDVQQDEwd0 ZXN0aW5nMCAXDTA3MTIzMTIzMDAwMFoYDzIwOTcwOTE2MjMwMDAwWjASMRAwDgYD VQQDEwd0ZXN0aW5nMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAgcBW iD4aIrYz9CqycINMfhT0LYGnjsIQY28cFYtUmHaKR+enJ2ZBSCjYk94CftSV1Fkq 1LQ5FC32ZK8V0v2WXF9tBWfheckzcbMp7BCOu8G8GbRz2/32TfsXQXSuUOubXBbO zwInPDbGIFJ7OektYJa04q9bLs/2QY2U3fbE03Ds/2FJ8yPBd5cgIJaWPScPWueC jKmO+uuhtcaln7mBRQGDjQCykuU3RuxoyMFIGakUhmzuD2I+ZU/gA2XOQ87CMt9e WTfUIV5/wXjw2uWmuMDNEC9JKCmLEMJ5i7/KMr7UgoKjWD1thNW/jVGUKz1/ZDom NDy38K0eQWeKfrAqCcRDCmTA93wMhGmArNxhCQXKbaQ+iU/UE8Tq++4sTBvaTWyi SNBTfkcQv1S8vOEQ+Ug+q3No5xXd5BvTwaku/wKKEce5u1ZdXgMiuQEfAsPAL2Kc z+U1Jzcl58XLwjoFbHHOZe7xZy+f0SyF4kqzCckH7/QiAG5dPlEV2kE0IVEj+Z1v fc1silLbsnsJlbextdPZRUy5hNTvzrafKZ3Sb9tjw9AfKmp6nTEILMR3fmoLiNpj 5EAMllAZFsRd86REaTHHO8RLybzulOFPlIgnO626KK5+Zu2Wp1la/5re/8v6umMg F61xEXZJvjhpOZz1G8AnzTaztfGWti7KrLgP8zMCAwEAAaMhMB8wHQYDVR0OBBYE FJj/X39/1vZxT53gZPyFVLstYP56MA0GCSqGSIb3DQEBCwUAA4ICAQBP1bWTxa0L UkBHMMBvnRkof+qE7hms/mJslKFVoYxD+fRoBKU2vPPCqYqbENwMGZtHxBQ2CZFU y4gUJQClrzqT1Pk5IcSVkAwe4RFQ7+IalITvyF0QRQZ1qaLvo893lBdQH2RfLyZG hFl6z+dPjWBvh8w9Oo/LpzyV1LEYd25LtPL3ZJsH5Xbh1RP2oESVkd/qacxat3kn ljmpxsuj4xJz1/VOin8xRJN97bz9kUO76Fs9ICCHSPunaVoYucCzuOG8JYPaIuUG 9I8ymNPDjcI48Gf+mxS4cs89NuSYGJ2CLB2/Knx2ViebcKnx79x62QmYco8vF5iK G08yGJ4E4J+ERj5j7EfnUfKFDUSowzt97l7cJ1hDOx8qoeWSbaQdC2PlF5NnBZLW mkCmMttlCs75V15Bw662AB1vGzEzKn79dTv2XsLOf7105Oq+0wgPH+iKXRYLYnDR s+uGTY5pCU5K37Uv4T7m761JDqkipMobhWSDjzaTI4LE8qmJGWb3jwmW4nZBZmrT FddmZyOMIQUpkLcNHea2ESdbFdo2JsUnfMGtY3XxAoeIW6+JYSBwlfjkpECM9gPH 4L27x01NmQL5yVxNHjN0EjittE/HHMXgntIRTYktjN5V8eZla85vwR72PSafUtpr x51x19J+pGfSpXRPO48tGi8+YUckS7qN4w== -----END CERTIFICATE----- badcacerts.pem: -----BEGIN CERTIFICATE----- MIIExTCCAq2gAwIBAgIEKKekeTANBgkqhkiG9w0BAQsFADASMRAwDgYDVQQDEwd0 ZXN0aW5nMCAXDTA3MTIzMTIzMDAwMFoYDzIwOTcwOTE2MjMwMDAwWjASMRAwDgYD VQQDEwd0ZXN0aW5nMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAgcBW iD4aIrYz9CqycINMfhT0LYGnjsIQY28cFYtUmHaKR+enJ2ZBSCjYk94CftSV1Fkq 1LQ5FC32ZK8V0v2WXF9tBWfheckzcbMp7BCOu8G8GbRz2/32TfsXQXSuUOubXBbO zwInPDbGIFJ7OektYJa04q9bLs/2QY2U3fbE03Ds/2FJ8yPBd5cgIJaWPScPWueC jKmO+uuhtcaln7mBRQGDjQCykuU3RuxoyMFIGakUhmzuD2I+ZU/gA2XOQ87CMt9e WTfUIV5/wXjw2uWmuMDNEC9JKCmLEMJ5i7/KMr7UgoKjWD1thNW/jVGUKz1/ZDom NDy38K0eQWeKfrAqCcRDCmTA93wMhGmArNxhCQXKbaQ+iU/UE8Tq++4sTBvaTWyi SNBTfkcQv1S8vOEQ+Ug+q3No5xXd5BvTwaku/wKKEce5u1ZdXgMiuQEfAsPAL2Kc z+U1Jzcl58XLwjoFbHHOZe7xZy+f0SyF4kqzCckH7/QiAG5dPlEV2kE0IVEj+Z1v fc1silLbsnsJlbextdPZRUy5hNTvzrafKZ3Sb9tjw9AfKmp6nTEILMR3fmoLiNpj 5EAMllAZFsRd86REaTHHO8RLybzulOFPlIgnO626KK5+Zu2Wp1la/5re/8v6umMg F61xEXZJvjhpOZz1G8AnzTaztfGWti7KrLgP8zMCAwEAAaMhMB8wHQYDVR0OBBYE FJj/X39/1vZxT53gZPyFVLstYP56MA0GCSqGSIb3DQEBCwUAA4ICAQBP1bWTxa0L UkBHMMBvnRkof+qE7hms/mJslKFVoYxD+fRoBKU2vPPCqYqbENwMGZtHxBQ2CZFU y4gUJQClrzqT1Pk5IcSVkAwe4RFQ7+IalITvyF0QRQZ1qaLvo893lBdQH2RfLyZG hFl6z+dPjWBvh8w9Oo/LpzyV1LEYd25LtPL3ZJsH5Xbh1RP2oESVkd/qacxat3kn ljmpxsuj4xJz1/VOin8xRJN97bz9kUO76Fs9ICCHSPunaVoYucCzuOG8JYPaIuUG 9I8ymNPDjcI48Gf+mxS4cs89NuSYGJ2CLB2/Knx2ViebcKnx79x62QmYco8vF5iK G08yGJ4E4J+ERj5j7EfnUfKFDUSowzt97l7cJ1hDOx8qoeWSbaQdC2PlF5NnBZLW mkCmMttlCs75V15Bw662AB1vGzEzKn79dTv2XsLOf7105Oq+0wgPH+iKXRYLYnDR s+uGTY5pCU5K37Uv4T7m761JDqkipMobhWSDjzaTI4LE8qmJGWb3jwmW4nZBZmrT FddmZyOMIQUpkLcNHea2ESdbFdo2JsUnfMGtY3XxAoeIW6+JYSBwlfjkpECM9gPH 4L27x01NmQL5yVxNHjN0EjittE/HHMXgntIRTYktjN5V8eZla85vwR72PSafUtpr x51x19J+pGfSpXRPO48tGi8+YUckS7qN4w== -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIEwzCCAqugAwIBAgIEAwvYVTANBgkqhkiG9w0BAQsFADASMRAwDgYDVQQDEwd0 ZXN0aW5nMB4XDTA3MDcwNzA1MDcwN1oXDTA4MDcwNjA1MDcwN1owEjEQMA4GA1UE AxMHdGVzdGluZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAIHAVog+ GiK2M/QqsnCDTH4U9C2Bp47CEGNvHBWLVJh2ikfnpydmQUgo2JPeAn7UldRZKtS0 ORQt9mSvFdL9llxfbQVn4XnJM3GzKewQjrvBvBm0c9v99k37F0F0rlDrm1wWzs8C Jzw2xiBSeznpLWCWtOKvWy7P9kGNlN32xNNw7P9hSfMjwXeXICCWlj0nD1rngoyp jvrrobXGpZ+5gUUBg40AspLlN0bsaMjBSBmpFIZs7g9iPmVP4ANlzkPOwjLfXlk3 1CFef8F48NrlprjAzRAvSSgpixDCeYu/yjK+1IKCo1g9bYTVv41RlCs9f2Q6JjQ8 t/CtHkFnin6wKgnEQwpkwPd8DIRpgKzcYQkFym2kPolP1BPE6vvuLEwb2k1sokjQ U35HEL9UvLzhEPlIPqtzaOcV3eQb08GpLv8CihHHubtWXV4DIrkBHwLDwC9inM/l NSc3JefFy8I6BWxxzmXu8Wcvn9EsheJKswnJB+/0IgBuXT5RFdpBNCFRI/mdb33N bIpS27J7CZW3sbXT2UVMuYTU7862nymd0m/bY8PQHypqep0xCCzEd35qC4jaY+RA DJZQGRbEXfOkRGkxxzvES8m87pThT5SIJzutuiiufmbtlqdZWv+a3v/L+rpjIBet cRF2Sb44aTmc9RvAJ802s7XxlrYuyqy4D/MzAgMBAAGjITAfMB0GA1UdDgQWBBSY /19/f9b2cU+d4GT8hVS7LWD+ejANBgkqhkiG9w0BAQsFAAOCAgEAV+PnySD6Nkct SsohAvra8Xuski5ZwHfymAICRM9ZWD6s/2/7y652vegMw40wxW3ZeT7NTzoi+MiT LgYsbdu7upRGvS6dnB7ye8udOtIPhk/QPqDgH0SkxB2imeUaprX8EJUYFQX0AUd7 MAqMcqVFrpYo7xjXCxsWpWPzT6USsG9gjcSbWoukxIGmhlNvtKycSY3+L0HFZKyr mMHZxYsUxVyPKBwfhwQTC/RQccCNLRdW68eaJSjxrbFjkMCLtppGqKHfRr/KBMvf 7K5q52vZ2O324yVdQdQjPuLk84pyJmyZ8Ew48XK06ebHgbx+fBDsNYq27IU4GRm+ FMl/Rp0q/fxZ3CphBNBdyDRRIGzIJN4e3ocSeNDcQt6uD7h88D0FrCXrlkxYGW51 qvaxFmUXlAjuv0K2iRDzvVbP2A6JhB2PBUw/lkEDcy2WP0WctLdL/GVeatRTUlzw jxQRSi21Azwq9I4fqG/cwDDiWPGmyP2/xJoZROhky0zm/0A9mWEU9R7tB+FppZZN 3Un9HtSIRt30mqC1AgcIdiFlXpS5RiJElgIEuJVma3P2BxFK2glycy12UYy9gcOw VV9D2OrLNxKp9icmy/D2b9Z2udLji9jI0MIhl/xDlshsTtkDmOshgqnKIyNzF/gF 8fgqQZm0AezWcLtrnbFTSG2f6Rpdjec= -----END CERTIFICATE----- site.pem: -----BEGIN CERTIFICATE----- MIIE5TCCAs2gAwIBAgIEBxm5gTANBgkqhkiG9w0BAQsFADASMRAwDgYDVQQDEwd0 ZXN0aW5nMB4XDTE2MDYyMDIwMDU1NVoXDTM4MTEyNDIwMDU1NVowEzERMA8GA1UE AxMIdGVzdGluZzIwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCfeSXR qF0VCSZ3cT6bnEP4BkVqnM09RI+Ycn/Oh5A/FGDqHc2T2OcdvkTU4KnuwPqShW5x gvNGSeHDBHyYcHzrcu/unyVgt8u/247g4egq/Ep8edNkSkdws5N9JTxwm74H31af ndSRYeyC2m2pwZx1sVd0gOK1NodlpP/hcm7NPrcAE6HFzkemzJrsCgxQFhWsRvba GlEA40ZhOjGvSKfAb2oCfpW5pFYx7kSI1ii/VfX8H7CU7ZJUmj7stuc0pXZvu11v FsssenVX7XBxBwrDDoJdjCeEz1zfl68P7QhuCLS541SgHg/ZQPSTyMsQlzhR05Z1 qaiP6oUFQSFvO7j3e6UbIgSxyXK1tRevbhwGLPBzfUgUzeKiRrMAkIDj1dC9NjK2 DAKO5VuvvQKhCLD21a5XhFMDjV1Ig2TUMMT1n55f4I6EXadcBXcBRPszZNzEgVRd lsNGmsESCQ60bdRAnzxbbuP3A7Ufi0ASljzu3wwNGlOoEGDR3aOl341GO5x7z/gB sMAaN0LqZnb3ACjKW6NE1jsYPWtW37y6xjnTliWA7wmcUoOZwYgwTOGuF+3lmyto vJT2XVnli3wWUT2TPh9t4MgGzYePYiinpem3S9Ylsw7JNR0r4EDqyLF+8r4+Wg2V AhpOKkzcOfRaxXjxWNiJ8CqLpb6E8P7p2cb1QwIDAQABo0IwQDAfBgNVHSMEGDAW gBSY/19/f9b2cU+d4GT8hVS7LWD+ejAdBgNVHQ4EFgQU/+XByYexoutQKmN8aKwm 9ihiokYwDQYJKoZIhvcNAQELBQADggIBADX9+ihl9fGZelPZ426NYBWHvhr2LjB2 gVVPQpGG53AD5HOSRD1Lf0atfOXWnM0DXqN15cEp4jhB5ui16Vp8dYbU+7TSMpjX W3emVBk09oHgYA23W8OSdi93rx5JARGKY36aY1Si79MnJ40mR3LlZqnx54IOujX0 k8kLEkZ+MzbZnxxYfupr8wqihAgpNFJCTuW7QT9tlHATdlUN1zsdh9RtPal4Wngi dKk/L02VvvCLLfs37HCf8X/D89YDCH6XvXYok2TdhOe0VIiaa1JB0e0G/4rraPqw e80FRr+5tEJFRMgG0QYgZo61l73UMNNB0MQ6xKN0UR6K9W05B7ILwAMiRyZFCJ9f E+voJix+IWNtb495XfQGKpc/ALK+ifCdo1s6gIdE3RtEMZAwkdDjut/wtjaDfH78 8HUYJwAyrfQERrX5InF6pC9i5GasUcFnrq3zgq2jjddNMCQVbPZYxiabXq0qwDho Mevk5tkPunZEfE3Npbb85vxPnn7z1uE3C6CDr0ZIRC2frlD6ShFqw6FhFQYnNvXd Phs8fKQEwPN/PSb46rY/iLbASMNvh14Ut971Ta4ZKW/JHemfeRPUzqCECbE0jiKq k5KEX5Ge7lLQ6i1q6jEPizR9z/HPbkkSNEIJN+UaTXW78i+0WGP8cLQIzGZFRNZB uxRMPjdZ/XpR -----END CERTIFICATE----- goodcacerts.pem and badcacerts.pem contain exactly the same certificates (only ordered differently), yet: C:\Users\gstefanik\Documents\buggycerts>openssl verify -CAfile goodcacerts.pem site.pem site.pem: OK C:\Users\gstefanik\Documents\buggycerts>openssl verify -CAfile badcacerts.pem site.pem site.pem: CN = testing error 10 at 1 depth lookup:certificate has expired OK Even worse, some 32-bit Windows builds of openssl actually crash when verifying using badcacerts.pem (e.g. https://indy.fulgan.com/SSL/openssl-1.0.2h-i386-win32.zip) Unfortunately I was not able to compile a 32-bit Windows build myself. Sincerely, G?bor Stefanik -------------------------------------------------------------------------- This message, including its attachments, is confidential. For more information please read NNG's email policy here: http://www.nng.com/emailpolicy/ By responding to this email you accept the email policy. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4580 Please log in as guest with password guest if prompted From rt at openssl.org Tue Jun 21 08:45:05 2016 From: rt at openssl.org (Thomas Brunnthaler via RT) Date: Tue, 21 Jun 2016 08:45:05 +0000 Subject: [openssl-dev] [openssl.org #4398] BUG / 1.0.2g breaks CURL extension In-Reply-To: References: Message-ID: In the meantime i use 1.0.2h which works good so far. Thank you. 2016-06-20 22:47 GMT+02:00 Rich Salz via RT : > We believe this is fixed by the commit that viktor pointed out. Is this not > true? What are folks asking OpenSSL to do? > > -- > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4398 > Please log in as guest with password guest if prompted > > -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4398 Please log in as guest with password guest if prompted From cristifati0 at gmail.com Tue Jun 21 09:39:35 2016 From: cristifati0 at gmail.com (Cristi Fati) Date: Tue, 21 Jun 2016 12:39:35 +0300 Subject: [openssl-dev] BUG - FIPS capable OpenSSL fails to build on Linux PPC64 Message-ID: Hi all, I am trying to build a FIPS (2.0.12) capable OpenSSL (1.0.2h) on PPC64 Linux (tried RH5 and SLES12), but it fails. Here's the config command and output for *openssl-fips*: *./config no-asm* Operating system: *ppc64-whatever-linux2* WARNING! If you wish to build 64-bit library, then you have to invoke './Configure linux-ppc64' *manually*. You have about 5 seconds to press Ctrl-C to abort. Auto Configuring fipsonly Auto Configuring fipsonly Configuring for linux-ppc Auto Configuring fipsonly Configuring for linux-ppc no-asm [option] OPENSSL_NO_ASM no-bf [option] OPENSSL_NO_BF (skip dir) no-camellia [option] OPENSSL_NO_CAMELLIA (skip dir) no-cast [option] OPENSSL_NO_CAST (skip dir) 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-idea [option] OPENSSL_NO_IDEA (skip dir) no-jpake [experimental] OPENSSL_NO_JPAKE (skip dir) no-krb5 [krb5-flavor not specified] OPENSSL_NO_KRB5 no-md2 [option] OPENSSL_NO_MD2 (skip dir) no-md5 [option] OPENSSL_NO_MD5 (skip dir) no-mdc2 [option] OPENSSL_NO_MDC2 (skip dir) no-rc2 [option] OPENSSL_NO_RC2 (skip dir) no-rc4 [option] OPENSSL_NO_RC4 (skip dir) no-rc5 [option] OPENSSL_NO_RC5 (skip dir) no-rfc3779 [default] OPENSSL_NO_RFC3779 (skip dir) no-ripemd [option] OPENSSL_NO_RIPEMD (skip dir) no-seed [option] OPENSSL_NO_SEED (skip dir) no-srp [forced] OPENSSL_NO_SRP (skip dir) no-ssl2 [forced] OPENSSL_NO_SSL2 (skip dir) no-ssl3 [forced] OPENSSL_NO_SSL3 (skip dir) no-store [experimental] OPENSSL_NO_STORE (skip dir) no-tls1 [forced] OPENSSL_NO_TLS1 (skip dir) no-tlsext [forced] OPENSSL_NO_TLSEXT (skip dir) no-zlib [default] no-zlib-dynamic [default] IsMK1MF=0 CC =gcc CFLAG =-DOPENSSL_FIPSCANISTER -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DTERMIO -O3 -Wall and the corresponding command for *openssl*: *./config fips shared no-asm ${SOME_OTHER_UNIMPORTANT_OPTIONS}* Operating system: *ppc64-whatever-linux2* WARNING! If you wish to build 64-bit library, then you have to invoke './Configure linux-ppc64' *manually*. You have about 5 seconds to press Ctrl-C to abort. Configuring for linux-ppc Configuring for linux-ppc no-asm [option] OPENSSL_NO_ASM 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-idea [option] OPENSSL_NO_IDEA (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-mdc2 [option] OPENSSL_NO_MDC2 (skip dir) no-rc5 [option] OPENSSL_NO_RC5 (skip dir) no-rfc3779 [default] OPENSSL_NO_RFC3779 (skip dir) no-rsax [forced] OPENSSL_NO_RSAX (skip dir) no-sctp [default] OPENSSL_NO_SCTP (skip dir) no-ssl-trace [default] OPENSSL_NO_SSL_TRACE (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 =-fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -fPIC *-m32* -DB_ENDIAN -O3 -Wall -I$(FIPSDIR)/include As you can see, they both identify the machine in the same way, but openssl-fips generates 64bit object files and openssl 32bit, and the linker when trying to build *fips_premain_dso* obviously doesn't like it. Here's the error: *${LINKER_PATH}/ld: powerpc:common64 architecture of input file `${FIPSCANISTER_PATH}/fipscanister.o' is incompatible with powerpc:common output* Last versions that worked for me, were openssl-1.0.1p and openssl-fips-2.0.5, which were both generating 64bit code, and I first encountered this behavior in openssl-1.0.2f (didn't test the versions before). As I see things there are 3 issues: - 2 minor: The warning in both *openssl* and *openssl-fips* is misleading/wrong (shouldn't be there) - 1 major: *openssl* generates 32bit binaries for ppc64. RH5 build machine details: *Linux ${HOST_NAME} 2.6.18-92.el5 #1 SMP Tue Apr 29 13:21:29 EDT 2008 ppc64 ppc64 ppc64 GNU/Linux* The only way to get around this is to instruct openssl to generate 64bit code (*./Configure linux-ppc64*), as I can't modify any *openssl-fips* files and still have a FIPS validated result. Also, as a note: in *openssl-fips* (since version 2.0.6), *Configure* no longer has the exec permissions. Was that the intent? Probably yes, since the only way to configure *openssl-fips* is via *config [no-asm].* Another note: after having everything built I get: *error 7 at 0 depth lookup:certificate signature failure* *550858546160:error:04097077:rsa routines:RSA_private_encrypt:wrong signature length:fips_rsa_sign.c:349:* *550858546160:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib:a_verify.c:218:* when trying to validate a cert against its CA, but only on Linux PPC64 and when FIPS is enabled - validating the same certs on PPC with FIPS off, or on another Linux (x86_64) with FIPS on, works fine - (I'm talking about the same *openssl*, *openssl-fips* versions here), but this is another topic, which I'm going to send a different mail about once I have more details Regards, Cristi Fati. -------------- next part -------------- An HTML attachment was scrubbed... URL: From meissner at suse.de Tue Jun 21 11:37:05 2016 From: meissner at suse.de (Marcus Meissner) Date: Tue, 21 Jun 2016 13:37:05 +0200 Subject: [openssl-dev] BUG - FIPS capable OpenSSL fails to build on Linux PPC64 In-Reply-To: References: Message-ID: <20160621113705.GC5370@suse.de> On Tue, Jun 21, 2016 at 12:39:35PM +0300, Cristi Fati wrote: > Hi all, > > I am trying to build a FIPS (2.0.12) capable OpenSSL (1.0.2h) on PPC64 > Linux (tried RH5 and SLES12), but it fails. FWIW, The openssl packages on SLES 12 have received FIPS certificate for x86_64 While we have not certified them on ppc64le, the same FIPS source code is inside. So the SLES12 ppc64le openssl 1.0.1i is FIPS capable. Ciao, Marcus From rt at openssl.org Tue Jun 21 13:14:12 2016 From: rt at openssl.org (Paul Menzel via RT) Date: Tue, 21 Jun 2016 13:14:12 +0000 Subject: [openssl-dev] [openssl.org #4581] [1.0.2] Running tests in parallel results in failure In-Reply-To: <57692A45.1040005@molgen.mpg.de> References: <57692A45.1040005@molgen.mpg.de> Message-ID: Dear OpenSSL folks, downloading the latest 1.0.1t release [1], building it, and running the tests in parallel I get the failure below. I am able to reproduce this, with the branch.*OpenSSL_1_0_2-stable* [2], but not with the branch *master*. With `-j1` and `-j2` the failure is unreproducible. With `-j3` it sometimes works and sometimes fails. With `-j4` and greater it reliably fails. ``` ...long/negative scalar tests allowing precomputation ... without precomputation ... ok combined multiplication ....p -> p ........d -> d .camellia-128-cbc ......n -> d ..........p -> d .....camellia-128-cbc base64 .d -> n ...n -> n ok ..testing internal curves: ..............camellia-128-ecb ......................p -> n ............d -> p ..............................n -> p .............p -> p ... ok camellia-128-ecb base64 .....rsa .testing rsa conversions p -> d .Parsing test certificates ...camellia-192-cbc p -> p ....OK .camellia-192-cbc base64 d -> d .testing crl conversions p -> d ..p -> d ..p -> p .camellia-192-ecb .d -> p ..p -> p d -> d ...p -> d camellia-192-ecb base64 ..d -> p .../util/shlib_wrap.sh ./rsa_test ..p -> p PKCS #1 v1.5 encryption/decryption ok OAEP encryption/decryption ok ..camellia-256-cbc PKCS #1 v1.5 encryption/decryption ok OAEP encryption/decryption ok .PKCS #1 v1.5 encryption/decryption ok OAEP encryption/decryption ok ...testing session-id conversions p -> d ......p -> p ......d -> d ..camellia-256-cbc base64 .....p -> d .......PKCS #1 v1.5 encryption/decryption ok d -> p OAEP encryption/decryption ok .camellia-256-ecb ...PKCS #1 v1.5 encryption/decryption ok OAEP encryption/decryption ok p -> p ...PKCS #1 v1.5 encryption/decryption ok OAEP encryption/decryption ok .......camellia-256-ecb base64 Generate and verify a certificate request .generating certificate request ...rsa .There should be a 2 sequences of .'s and some +'s. There should not be more that at most 80 per line This could take some time. ....cast ..Generating a 1024 bit RSA private key .....................cast base64 ....................++++++ ......................cast-cbc ..................testing req conversions ..p -> d .......................cast-cbc base64 .Makefile:237: recipe for target 'test_req' failed make[1]: *** [test_req] Error 1 make[1]: *** Waiting for unfinished jobs.... ``` Thanks, Paul PS: I am sorry, if Mozilla Thunderbird wraps the pasted lines. [1] https://www.openssl.org/source/openssl-1.0.1t.tar.gz [2] OpenSSL_1_0_2h-88-g4824496 (Fix missing opening braces) [3] 6feb3c5 Avoid using latest clang since repo not available -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4581 Please log in as guest with password guest if prompted From rsalz at akamai.com Tue Jun 21 13:15:58 2016 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 21 Jun 2016 13:15:58 +0000 Subject: [openssl-dev] [openssl.org #4581] [1.0.2] Running tests in parallel results in failure In-Reply-To: References: <57692A45.1040005@molgen.mpg.de> Message-ID: <11c62b6d905d419894b1dd92b0d8248b@usma1ex-dag1mb1.msg.corp.akamai.com> This is not supported. From rt at openssl.org Tue Jun 21 13:16:02 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Tue, 21 Jun 2016 13:16:02 +0000 Subject: [openssl-dev] [openssl.org #4581] [1.0.2] Running tests in parallel results in failure In-Reply-To: <11c62b6d905d419894b1dd92b0d8248b@usma1ex-dag1mb1.msg.corp.akamai.com> References: <57692A45.1040005@molgen.mpg.de> <11c62b6d905d419894b1dd92b0d8248b@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: This is not supported. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4581 Please log in as guest with password guest if prompted From rt at openssl.org Tue Jun 21 13:24:04 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Tue, 21 Jun 2016 13:24:04 +0000 Subject: [openssl-dev] [openssl.org #4580] "openssl verify -CAfile cacerts.pem cert.pem" fails if cacerts.pem is ordered in certain ways In-Reply-To: References: <7a5d26d9b69743928ebd3fe003cb7f60@XCHMBX1.NavNGo.local> Message-ID: Having a mix of experied and unexpired certificates in the trust store for the same issuer/key seems to be undefined. I am not sure this is a bug. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4580 Please log in as guest with password guest if prompted From rt at openssl.org Tue Jun 21 13:26:29 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Tue, 21 Jun 2016 13:26:29 +0000 Subject: [openssl-dev] [openssl.org #4581] [1.0.2] Running tests in parallel results in failure In-Reply-To: <57692A45.1040005@molgen.mpg.de> References: <57692A45.1040005@molgen.mpg.de> Message-ID: Like Rich says, our build system in 1.0.2 doesn't support parallell building or testing. For upcoming 1.1.0, the build system has been remade from the ground up, with parallell building in mind. Parallell testing hasn't been tested there either, though... it might work, it might not. However, the '-j' option for make till not affect the parallellism of testing in any way. Closing this ticket. Cheers, Richard On Tue Jun 21 13:14:12 2016, pmenzel at molgen.mpg.de wrote: > Dear OpenSSL folks, > > > downloading the latest 1.0.1t release [1], building it, and running the > tests in parallel I get the failure below. > > I am able to reproduce this, with the branch.*OpenSSL_1_0_2-stable* [2], > but not with the branch *master*. > > With `-j1` and `-j2` the failure is unreproducible. With `-j3` it > sometimes works and sometimes fails. With `-j4` and greater it reliably > fails. > > ``` > ...long/negative scalar tests allowing precomputation ... without > precomputation ... ok > combined multiplication ....p -> p > ........d -> d > .camellia-128-cbc > ......n -> d > ..........p -> d > .....camellia-128-cbc base64 > .d -> n > ...n -> n > ok > > ..testing internal curves: ..............camellia-128-ecb > ......................p -> n > ............d -> p > ..............................n -> p > .............p -> p > ... ok > > camellia-128-ecb base64 > .....rsa > .testing rsa conversions > p -> d > .Parsing test certificates > ...camellia-192-cbc > p -> p > ....OK > .camellia-192-cbc base64 > d -> d > .testing crl conversions > p -> d > ..p -> d > ..p -> p > .camellia-192-ecb > .d -> p > ..p -> p > d -> d > ...p -> d > camellia-192-ecb base64 > ..d -> p > .../util/shlib_wrap.sh ./rsa_test > ..p -> p > PKCS #1 v1.5 encryption/decryption ok > OAEP encryption/decryption ok > ..camellia-256-cbc > PKCS #1 v1.5 encryption/decryption ok > OAEP encryption/decryption ok > .PKCS #1 v1.5 encryption/decryption ok > OAEP encryption/decryption ok > ...testing session-id conversions > p -> d > ......p -> p > ......d -> d > ..camellia-256-cbc base64 > .....p -> d > .......PKCS #1 v1.5 encryption/decryption ok > d -> p > OAEP encryption/decryption ok > .camellia-256-ecb > ...PKCS #1 v1.5 encryption/decryption ok > OAEP encryption/decryption ok > p -> p > ...PKCS #1 v1.5 encryption/decryption ok > OAEP encryption/decryption ok > .......camellia-256-ecb base64 > Generate and verify a certificate request > .generating certificate request > ...rsa > .There should be a 2 sequences of .'s and some +'s. > There should not be more that at most 80 per line > This could take some time. > ....cast > ..Generating a 1024 bit RSA private key > .....................cast base64 > ....................++++++ > ......................cast-cbc > ..................testing req conversions > ..p -> d > .......................cast-cbc base64 > .Makefile:237: recipe for target 'test_req' failed > make[1]: *** [test_req] Error 1 > make[1]: *** Waiting for unfinished jobs.... > ``` > > > Thanks, > > Paul > > > PS: I am sorry, if Mozilla Thunderbird wraps the pasted lines. > > > [1] https://www.openssl.org/source/openssl-1.0.1t.tar.gz > [2] OpenSSL_1_0_2h-88-g4824496 (Fix missing opening braces) > [3] 6feb3c5 Avoid using latest clang since repo not available > -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4581 Please log in as guest with password guest if prompted From rt at openssl.org Tue Jun 21 13:37:35 2016 From: rt at openssl.org (=?UTF-8?B?R8OhYm9yIFNURUZBTklL?= via RT) Date: Tue, 21 Jun 2016 13:37:35 +0000 Subject: [openssl-dev] [openssl.org #4580] "openssl verify -CAfile cacerts.pem cert.pem" fails if cacerts.pem is ordered in certain ways In-Reply-To: References: <7a5d26d9b69743928ebd3fe003cb7f60@XCHMBX1.NavNGo.local> Message-ID: Hi, It seems that having the same key isn't actually a prerequisite, I actually have a pair of certificates in hand with the same issuer but different keys that reproduce this order-dependent behavior. (I'm currently in talks with our IT department for clearance to submit these certs as a testcase, since they are currently internal-use only.) Also, we certainly shouldn't _crash_ even with duplicate keys. (Just checked, the nonidentical-key certificate pair above also reproduces the crash on win32.) > -------------------------------------------------------------------------- This message, including its attachments, is confidential. For more information please read NNG's email policy here: http://www.nng.com/emailpolicy/ By responding to this email you accept the email policy. -----Original Message----- > From: Salz, Rich via RT [mailto:rt at openssl.org] > Sent: Tuesday, June 21, 2016 3:24 PM > To: G?bor STEFANIK > Cc: openssl-dev at openssl.org > Subject: RE: [openssl-dev] [openssl.org #4580] "openssl verify -CAfile > cacerts.pem cert.pem" fails if cacerts.pem is ordered in certain ways > > Having a mix of experied and unexpired certificates in the trust store for the > same issuer/key seems to be undefined. I am not sure this is a bug. > > -- > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4580 > Please log in as guest with password guest if prompted -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4580 Please log in as guest with password guest if prompted From rt at openssl.org Tue Jun 21 13:38:40 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Tue, 21 Jun 2016 13:38:40 +0000 Subject: [openssl-dev] [openssl.org #4580] "openssl verify -CAfile cacerts.pem cert.pem" fails if cacerts.pem is ordered in certain ways In-Reply-To: <45fd44eae6dc4552bc66c7db0c6d204a@usma1ex-dag1mb1.msg.corp.akamai.com> References: <7a5d26d9b69743928ebd3fe003cb7f60@XCHMBX1.NavNGo.local> <45fd44eae6dc4552bc66c7db0c6d204a@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: Yes, it should not crash. But without more information it is hard/impossible to debug. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4580 Please log in as guest with password guest if prompted From rt at openssl.org Tue Jun 21 14:11:26 2016 From: rt at openssl.org (=?UTF-8?B?R8OhYm9yIFNURUZBTklL?= via RT) Date: Tue, 21 Jun 2016 14:11:26 +0000 Subject: [openssl-dev] [openssl.org #4580] "openssl verify -CAfile cacerts.pem cert.pem" fails if cacerts.pem is ordered in certain ways In-Reply-To: References: <7a5d26d9b69743928ebd3fe003cb7f60@XCHMBX1.NavNGo.local> <45fd44eae6dc4552bc66c7db0c6d204a@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: Looks like I was wrong, the 2 internal certificates that reproduce the issue do in fact share the key (only a 3rd, even newer certificate has a different key). So, key reuse is an essential part of this problem - however, I can now reproduce it with a trust store containing no expired certificates. Testcase coming soon, I got the OK from our IT department. > -------------------------------------------------------------------------- This message, including its attachments, is confidential. For more information please read NNG's email policy here: http://www.nng.com/emailpolicy/ By responding to this email you accept the email policy. -----Original Message----- > From: Salz, Rich via RT [mailto:rt at openssl.org] > Sent: Tuesday, June 21, 2016 3:39 PM > To: G?bor STEFANIK > Cc: openssl-dev at openssl.org > Subject: RE: [openssl-dev] [openssl.org #4580] "openssl verify -CAfile > cacerts.pem cert.pem" fails if cacerts.pem is ordered in certain ways > > Yes, it should not crash. But without more information it is hard/impossible > to debug. > > > -- > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4580 > Please log in as guest with password guest if prompted -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4580 Please log in as guest with password guest if prompted From rt at openssl.org Tue Jun 21 20:50:39 2016 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 21 Jun 2016 20:50:39 +0000 Subject: [openssl-dev] [openssl.org #3752] Patch to fix thread ID support from FIPS module In-Reply-To: <5506F522.4010007@cisco.com> References: <5506F522.4010007@cisco.com> Message-ID: commit a43cfd7 pushed to 1.0.2 stable, will show up in next release. thanks. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3752 Please log in as guest with password guest if prompted From appro at openssl.org Wed Jun 22 11:16:01 2016 From: appro at openssl.org (Andy Polyakov) Date: Wed, 22 Jun 2016 13:16:01 +0200 Subject: [openssl-dev] Assembler warns about constants in poly1306-x86_64.pl In-Reply-To: References: Message-ID: <576A7371.4000904@openssl.org> > Yasm 1.3.0 (Like nasm, but it embeds debug symbols into the asm code > on Windows) reports: > > poly1305-x86_64.asm(456): warning : value does not fit in 32 bit field > poly1305-x86_64.asm(459): warning : value does not fit in 32 bit field > poly1305-x86_64.asm(1346): warning : value does not fit in 32 bit field > poly1305-x86_64.asm(1349): warning : value does not fit in 32 bit field > > > For these lines: > and \$`-1<<31`,$d1 > and \$`-1<<31`,$d2 > and \$`-1<<31`,$d1 > and \$`-1<<31`,$d2 > > I'm not sure what approach is preferable to silence these warnings though. I can't reproduce this. I generated file with 'perl crypto/poly1305/asm/poly1305-x86_64.pl nasm a.asm', and then compiled it with 'yasm -f win64 a.asm', no warnings observed. 'yasm --version' does print 1.3.0. How do corresponding lines read in *your* *generated* file. Mine are 'and r[89],-2147483648' From rt at openssl.org Wed Jun 22 14:03:24 2016 From: rt at openssl.org (NarayanaGowda, Shivasharan via RT) Date: Wed, 22 Jun 2016 14:03:24 +0000 Subject: [openssl-dev] [openssl.org #4582] BUG - Application crashing in OpenSSL code while creating x509 certificate object In-Reply-To: References: Message-ID: Hi OpenSSL, We have an issue where in our application crashes on windows system in OpenSSL code. Windows version: Microsoft Windows Server 2008 R2 Standard OpenSSL version: OpenSSL 9.8zf Note: We have not modified any code in 9.8zf version. Our application bundles OpenSSL binaries as DLLs and uses them to perform TLS and SSL operations. We are seeing issue while creating x509 certificate object from a public key string. Here is piece of code that can assist you: ****************************** X509 *pubKey = NULL; if (publicKey.empty()) return pubKey; BIO *bp = BIO_new(BIO_s_mem()); BIO_write(bp, publicKey.data(), (int)publicKey.size()); pubKey = X509_new(); if(NULL != pubKey) { char * buf = new char[256]; // Convert the PEM data into a certificate object if(!PEM_read_bio_X509(bp, &pubKey, 0, NULL)) { .... ****************************** The function PEM_read_bio_X509() is what is reported in the crash dump as the entry point to OpenSSL from our application. Crash dump is as below: NULL_CLASS_PTR_READ --------------------------------------------- STACK_TEXT: WARNING: Stack unwind information not available. Following frames may be wrong. 0441f934 72e7c9ea 72e9f232 00000006 02bc5d58 libeay32!OBJ_obj2nid+0x1c 0441f938 72e9f232 00000006 02bc5d58 00000001 libeay32!OBJ_obj2nid+0xa 0441f9bc 72e92ada 72e91bb7 02bfbe78 0441fa1c libeay32!X509_NAME_oneline+0x112 0441f9c0 72e91bb7 02bfbe78 0441fa1c 00000084 libeay32!ASN1_item_ex_d2i+0x7ba 0441f9dc 72e8c090 02b53a68 00000000 00000000 libeay32!asn1_ex_c2i+0x627 0441f9f4 72e92a2a 00000005 0441fb20 72eecd10 libeay32!X509_CINF_free+0x60 0441fa34 72e92e2b 00000100 0441fab0 00000000 libeay32!ASN1_item_ex_d2i+0x70a 0441fa80 72e8c149 0441fb20 0441fab0 000001c6 libeay32!ASN1_item_d2i+0x4b 0441fa94 72e9da35 0441fb20 0441fab0 000001c6 libeay32!d2i_X509+0x19 0441fab4 72e9d7b3 72e8c130 72eeff08 02c8e980 libeay32!PEM_ASN1_read_bio+0x65 0441fad0 73ec5cd0 02c8e980 0441fb20 00000000 libeay32!PEM_read_bio_X509+0x23 00000000 00000000 00000000 00000000 00000000 sockets!XXXXXXX::stringToPublic+0xe0 ----------------------------------------------- Our Inferences: Our code works in most deployments and this crash is reported only by one user. We analyzed and observed that the user setup had more socket reads and writes during which crash occurring (Using resource monitoring tool). As it occurs seldom and intermittently, we wanted to know the cause and would request help from you. Our hunch is it could be similar to below fix mentioned in 9.8zh change log: Changes between 0.9.8zf and 0.9.8zg [11 Jun 2015] ......... *) PKCS7 crash with missing EnvelopedContent The PKCS#7 parsing code does not handle missing inner EncryptedContent correctly. An attacker can craft malformed ASN.1-encoded PKCS#7 blobs with missing content and trigger a NULL pointer dereference on parsing. Applications that decrypt PKCS#7 data or otherwise parse PKCS#7 structures from untrusted sources are affected. OpenSSL clients and servers are not affected. ........ Any help from you is well appreciated. Let me know if you need more details like core dump, etc. Thanks in advance. Regards, Sharan -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4582 Please log in as guest with password guest if prompted From rt at openssl.org Wed Jun 22 14:09:59 2016 From: rt at openssl.org (Rich Salz via RT) Date: Wed, 22 Jun 2016 14:09:59 +0000 Subject: [openssl-dev] [openssl.org #4582] BUG - Application crashing in OpenSSL code while creating x509 certificate object In-Reply-To: References: Message-ID: 0.9.8 is no longer supported. Perhaps some others on openssl-users mailing list can help you. Closing this ticket. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4582 Please log in as guest with password guest if prompted From rt at openssl.org Wed Jun 22 15:11:09 2016 From: rt at openssl.org (=?UTF-8?B?R8OhYm9yIFNURUZBTklL?= via RT) Date: Wed, 22 Jun 2016 15:11:09 +0000 Subject: [openssl-dev] [openssl.org #4580] "openssl verify -CAfile cacerts.pem cert.pem" fails if cacerts.pem is ordered in certain ways In-Reply-To: <20e2c8978c6c485bab6f1fa91d2d83ef@XCHMBX1.NavNGo.local> References: <7a5d26d9b69743928ebd3fe003cb7f60@XCHMBX1.NavNGo.local> <45fd44eae6dc4552bc66c7db0c6d204a@usma1ex-dag1mb1.msg.corp.akamai.com> <20e2c8978c6c485bab6f1fa91d2d83ef@XCHMBX1.NavNGo.local> Message-ID: I've attached the certificates that we originally encountered the bug with. "old.pem" is our old root CA certificate that expired in 2012. "curr.pem" is our current root CA, with the same public key as "old.pem". It is valid till 2017. "new.pem" is the new root CA recently released by our IT department. It has a new public key. "hgcentral1.pem" is the site certificate signed directly using "curr.pem". Verifying hgcentral.pem using curr.pem works, all others fail as expected. However, when I concatenate old.pem, new.pem and curr.pem in various orders, I get inconsistent behavior: old+curr PASS curr+old FAIL curr+new PASS new+curr PASS old+curr+new FAIL old+new+curr FAIL curr+old+new PASS curr+new+old PASS new+old+curr PASS new+curr+old FAIL There doesn't seem to be much of a pattern: curr+old fails, but curr+old+new works, even though new has a different public key and thus has no role in the verification. Also, old+curr+new and old+new+curr fail, despite "curr" following "old", which works when "new" isn't included. I also have a variant where a trust store of 20 certificates, none of them expired, but some with identical keys, containing the correct CA, is rejected when loaded through Python in DER format using the "cadata" parameter, but not when loaded in PEM format using "cafile". I'm still trying to reproduce this using standalone openssl, without python. > -------------------------------------------------------------------------- This message, including its attachments, is confidential. For more information please read NNG's email policy here: http://www.nng.com/emailpolicy/ By responding to this email you accept the email policy. -----Original Message----- > From: G?bor STEFANIK > Sent: Tuesday, June 21, 2016 4:11 PM > To: 'rt at openssl.org' > Subject: RE: [openssl-dev] [openssl.org #4580] "openssl verify -CAfile > cacerts.pem cert.pem" fails if cacerts.pem is ordered in certain ways > > Looks like I was wrong, the 2 internal certificates that reproduce the issue do > in fact share the key (only a 3rd, even newer certificate has a different key). > So, key reuse is an essential part of this problem - however, I can now > reproduce it with a trust store containing no expired certificates. > > Testcase coming soon, I got the OK from our IT department. > > > -----Original Message----- > > From: Salz, Rich via RT [mailto:rt at openssl.org] > > Sent: Tuesday, June 21, 2016 3:39 PM > > To: G?bor STEFANIK > > Cc: openssl-dev at openssl.org > > Subject: RE: [openssl-dev] [openssl.org #4580] "openssl verify -CAfile > > cacerts.pem cert.pem" fails if cacerts.pem is ordered in certain ways > > > > Yes, it should not crash. But without more information it is > > hard/impossible to debug. > > > > > > -- > > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4580 > > Please log in as guest with password guest if prompted -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4580 Please log in as guest with password guest if prompted -------------- next part -------------- A non-text attachment was scrubbed... Name: new.pem Type: application/octet-stream Size: 1646 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: old.pem Type: application/octet-stream Size: 1604 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: curr.pem Type: application/octet-stream Size: 1640 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: hgcentral1.pem Type: application/octet-stream Size: 2024 bytes Desc: not available URL: From brian at briansmith.org Wed Jun 22 18:48:04 2016 From: brian at briansmith.org (Brian Smith) Date: Wed, 22 Jun 2016 08:48:04 -1000 Subject: [openssl-dev] Assembler warns about constants in poly1306-x86_64.pl In-Reply-To: <576A7371.4000904@openssl.org> References: <576A7371.4000904@openssl.org> Message-ID: Andy Polyakov wrote: > I can't reproduce this. Sorry! You already fixed it here: https://github.com/openssl/openssl/commit/284116575d375729e672256cb2b754e8362c5bce on May 4. Cheers, Brian -- https://briansmith.org/ From rt at openssl.org Thu Jun 23 09:55:36 2016 From: rt at openssl.org (noloader@gmail.com via RT) Date: Thu, 23 Jun 2016 09:55:36 +0000 Subject: [openssl-dev] [openssl.org #4583] Debian X32 and "fatal error: sys/cdefs.h: No such file or directory" In-Reply-To: References: Message-ID: I'm working on a Debian X32 system (http://wiki.debian.org/X32Port), and working from HEAD: # git rev-parse HEAD b58614d7f5f98571b2c0bb2fb3df48f4b48a7e92 It appears Configure is mis-detecting the platform, and it results in a compile failure: make ... gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -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/engines\"" -Wall -O3 -pthread -m64 -DL_ENDIAN -Wa,--noexecstack -fPIC -Iinclude -I. -Icrypto/include -MMD -MF crypto/aes/aes_ecb.d.tmp -MT crypto/aes/aes_ecb.o -c -o crypto/aes/aes_ecb.o crypto/aes/aes_ecb.c In file included from /usr/include/assert.h:35:0, from crypto/aes/aes_ecb.c:10: /usr/include/features.h:361:25: fatal error: sys/cdefs.h: No such file or directory compilation terminated. Makefile:728: recipe for target 'crypto/aes/aes_ecb.o' failed make: *** [crypto/aes/aes_ecb.o] Error 1 ********** # ./config Operating system: x86_64-whatever-linux2 Configuring for linux-x86_64 Configuring OpenSSL version 1.1.0-pre6-dev (0x0x10100006L) no-asan [default] OPENSSL_NO_ASAN (skip dir) no-crypto-mdebug [default] OPENSSL_NO_CRYPTO_MDEBUG (skip dir) no-crypto-mdebug-backtrace [default] 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-fuzz-afl [default] OPENSSL_NO_FUZZ_AFL (skip dir) no-fuzz-libfuzzer [default] OPENSSL_NO_FUZZ_LIBFUZZER (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-ssl-trace [default] OPENSSL_NO_SSL_TRACE (skip dir) no-ssl3 [default] OPENSSL_NO_SSL3 (skip dir) no-ssl3-method [default] OPENSSL_NO_SSL3_METHOD (skip dir) no-ubsan [default] OPENSSL_NO_UBSAN (skip dir) no-unit-test [default] OPENSSL_NO_UNIT_TEST (skip dir) no-weak-ssl-ciphers [default] OPENSSL_NO_WEAK_SSL_CIPHERS (skip dir) no-zlib [default] no-zlib-dynamic [default] Configuring for linux-x86_64 CC =gcc CFLAG =-Wall -O3 -pthread -m64 -DL_ENDIAN -Wa,--noexecstack SHARED_CFLAG =-fPIC DEFINES =DSO_DLFCN HAVE_DLFCN_H NDEBUG OPENSSL_THREADS OPENSSL_NO_STATIC_ENGINE OPENSSL_PIC 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 =-ldl APPS_OBJ = CPUID_OBJ =x86_64cpuid.o UPLINK_OBJ = 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 BLAKE2_OBJ = PROCESSOR = RANLIB =ranlib ARFLAGS = PERL =/usr/bin/perl SIXTY_FOUR_BIT_LONG mode Configured for linux-x86_64. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4583 Please log in as guest with password guest if prompted From rt at openssl.org Thu Jun 23 10:02:37 2016 From: rt at openssl.org (noloader@gmail.com via RT) Date: Thu, 23 Jun 2016 10:02:37 +0000 Subject: [openssl-dev] [openssl.org #4583] AutoReply: Debian X32 and "fatal error: sys/cdefs.h: No such file or directory" In-Reply-To: References: Message-ID: As far as I know, these are the two ways to detect the platform because `uname` only provides x86_64/amd64 on some platforms: # gcc -dM -E - ------------------------------------------------------------------------- > I'm working on a Debian X32 system (http://wiki.debian.org/X32Port), > and working from HEAD: > > # git rev-parse HEAD > b58614d7f5f98571b2c0bb2fb3df48f4b48a7e92 > > It appears Configure is mis-detecting the platform, and it results in > a compile failure: > > make > ... > gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS > -DOPENSSL_NO_STATIC_ENGINE -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/engines\"" -Wall -O3 -pthread -m64 > -DL_ENDIAN -Wa,--noexecstack -fPIC -Iinclude -I. -Icrypto/include > -MMD -MF crypto/aes/aes_ecb.d.tmp -MT crypto/aes/aes_ecb.o -c -o > crypto/aes/aes_ecb.o crypto/aes/aes_ecb.c > In file included from /usr/include/assert.h:35:0, > from crypto/aes/aes_ecb.c:10: > /usr/include/features.h:361:25: fatal error: sys/cdefs.h: No such file > or directory > compilation terminated. > Makefile:728: recipe for target 'crypto/aes/aes_ecb.o' failed > make: *** [crypto/aes/aes_ecb.o] Error 1 > > ********** > > # ./config > Operating system: x86_64-whatever-linux2 > Configuring for linux-x86_64 > Configuring OpenSSL version 1.1.0-pre6-dev (0x0x10100006L) > no-asan [default] OPENSSL_NO_ASAN (skip dir) > no-crypto-mdebug [default] OPENSSL_NO_CRYPTO_MDEBUG (skip dir) > no-crypto-mdebug-backtrace [default] > 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-fuzz-afl [default] OPENSSL_NO_FUZZ_AFL (skip dir) > no-fuzz-libfuzzer [default] OPENSSL_NO_FUZZ_LIBFUZZER (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-ssl-trace [default] OPENSSL_NO_SSL_TRACE (skip dir) > no-ssl3 [default] OPENSSL_NO_SSL3 (skip dir) > no-ssl3-method [default] OPENSSL_NO_SSL3_METHOD (skip dir) > no-ubsan [default] OPENSSL_NO_UBSAN (skip dir) > no-unit-test [default] OPENSSL_NO_UNIT_TEST (skip dir) > no-weak-ssl-ciphers [default] OPENSSL_NO_WEAK_SSL_CIPHERS (skip dir) > no-zlib [default] > no-zlib-dynamic [default] > Configuring for linux-x86_64 > CC =gcc > CFLAG =-Wall -O3 -pthread -m64 -DL_ENDIAN -Wa,--noexecstack > SHARED_CFLAG =-fPIC > DEFINES =DSO_DLFCN HAVE_DLFCN_H NDEBUG OPENSSL_THREADS > OPENSSL_NO_STATIC_ENGINE OPENSSL_PIC 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 =-ldl > APPS_OBJ = > CPUID_OBJ =x86_64cpuid.o > UPLINK_OBJ = > 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 > BLAKE2_OBJ = > PROCESSOR = > RANLIB =ranlib > ARFLAGS = > PERL =/usr/bin/perl > SIXTY_FOUR_BIT_LONG mode > Configured for linux-x86_64. > > > > ------------------------------------------------------------------------- > http://rt.openssl.org/Ticket/Display.html?id=4583&user=guest&pass=guest -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4583 Please log in as guest with password guest if prompted From rt at openssl.org Thu Jun 23 10:18:47 2016 From: rt at openssl.org (noloader@gmail.com via RT) Date: Thu, 23 Jun 2016 10:18:47 +0000 Subject: [openssl-dev] [openssl.org #4583] AutoReply: Debian X32 and "fatal error: sys/cdefs.h: No such file or directory" In-Reply-To: References: Message-ID: Here's a couple more ways things don't work as expected: # ./config CFLAGS="-mx32" Operating system: x86_64-whatever-linux2 Configuring for linux-x86_64 Configuring OpenSSL version 1.1.0-pre6-dev (0x0x10100006L) target already defined - linux-x86_64 (offending arg: CFLAGS=-mx32) # ./config -mx32 Operating system: x86_64-whatever-linux2 Configuring for linux-x86_64 ... > ------------------------------------------------------------------------- > I'm working on a Debian X32 system (http://wiki.debian.org/X32Port), > and working from HEAD: > > # git rev-parse HEAD > b58614d7f5f98571b2c0bb2fb3df48f4b48a7e92 > > It appears Configure is mis-detecting the platform, and it results in > a compile failure: > > make > ... > gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS > -DOPENSSL_NO_STATIC_ENGINE -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/engines\"" -Wall -O3 -pthread -m64 > -DL_ENDIAN -Wa,--noexecstack -fPIC -Iinclude -I. -Icrypto/include > -MMD -MF crypto/aes/aes_ecb.d.tmp -MT crypto/aes/aes_ecb.o -c -o > crypto/aes/aes_ecb.o crypto/aes/aes_ecb.c > In file included from /usr/include/assert.h:35:0, > from crypto/aes/aes_ecb.c:10: > /usr/include/features.h:361:25: fatal error: sys/cdefs.h: No such file > or directory > compilation terminated. > Makefile:728: recipe for target 'crypto/aes/aes_ecb.o' failed > make: *** [crypto/aes/aes_ecb.o] Error 1 > > ********** > > # ./config > Operating system: x86_64-whatever-linux2 > Configuring for linux-x86_64 > Configuring OpenSSL version 1.1.0-pre6-dev (0x0x10100006L) > no-asan [default] OPENSSL_NO_ASAN (skip dir) > no-crypto-mdebug [default] OPENSSL_NO_CRYPTO_MDEBUG (skip dir) > no-crypto-mdebug-backtrace [default] > 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-fuzz-afl [default] OPENSSL_NO_FUZZ_AFL (skip dir) > no-fuzz-libfuzzer [default] OPENSSL_NO_FUZZ_LIBFUZZER (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-ssl-trace [default] OPENSSL_NO_SSL_TRACE (skip dir) > no-ssl3 [default] OPENSSL_NO_SSL3 (skip dir) > no-ssl3-method [default] OPENSSL_NO_SSL3_METHOD (skip dir) > no-ubsan [default] OPENSSL_NO_UBSAN (skip dir) > no-unit-test [default] OPENSSL_NO_UNIT_TEST (skip dir) > no-weak-ssl-ciphers [default] OPENSSL_NO_WEAK_SSL_CIPHERS (skip dir) > no-zlib [default] > no-zlib-dynamic [default] > Configuring for linux-x86_64 > CC =gcc > CFLAG =-Wall -O3 -pthread -m64 -DL_ENDIAN -Wa,--noexecstack > SHARED_CFLAG =-fPIC > DEFINES =DSO_DLFCN HAVE_DLFCN_H NDEBUG OPENSSL_THREADS > OPENSSL_NO_STATIC_ENGINE OPENSSL_PIC 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 =-ldl > APPS_OBJ = > CPUID_OBJ =x86_64cpuid.o > UPLINK_OBJ = > 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 > BLAKE2_OBJ = > PROCESSOR = > RANLIB =ranlib > ARFLAGS = > PERL =/usr/bin/perl > SIXTY_FOUR_BIT_LONG mode > Configured for linux-x86_64. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4583 Please log in as guest with password guest if prompted From rt at openssl.org Thu Jun 23 10:25:52 2016 From: rt at openssl.org (Andy Polyakov via RT) Date: Thu, 23 Jun 2016 10:25:52 +0000 Subject: [openssl-dev] [openssl.org #4583] AutoReply: Debian X32 and "fatal error: sys/cdefs.h: No such file or directory" In-Reply-To: <576BB980.3060702@openssl.org> References: <576BB980.3060702@openssl.org> Message-ID: > Here's a couple more ways things don't work as expected: > > # ./config CFLAGS="-mx32" > Operating system: x86_64-whatever-linux2 > Configuring for linux-x86_64 > Configuring OpenSSL version 1.1.0-pre6-dev (0x0x10100006L) > target already defined - linux-x86_64 (offending arg: CFLAGS=-mx32) > > # ./config -mx32 > Operating system: x86_64-whatever-linux2 > Configuring for linux-x86_64 > ... There is linux-x32 config line, use that instead. The only question is *if* x32 should be auto-detected and in such case how. You mentioned that uname returns x86_64. Of course it does, there is no x32 kernel, x32 is pure user-land thing. Well, "pure" is overstatement because it does require certain kernel support, but it's an add-on support for plain 64-bit kernel. Most 64-bit Linux installations can execute x32 binaries (statically linked if there are no corresponding dynamic libraries) and x32 installations can execute 64-bit binaries (statically linked if there are no corresponding dynamic libraries). -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4583 Please log in as guest with password guest if prompted From rt at openssl.org Thu Jun 23 10:31:23 2016 From: rt at openssl.org (Andy Polyakov via RT) Date: Thu, 23 Jun 2016 10:31:23 +0000 Subject: [openssl-dev] [openssl.org #4583] AutoReply: Debian X32 and "fatal error: sys/cdefs.h: No such file or directory" In-Reply-To: <576BBACA.7070302@openssl.org> References: <576BB980.3060702@openssl.org> <576BBACA.7070302@openssl.org> Message-ID: >> Here's a couple more ways things don't work as expected: >> >> # ./config CFLAGS="-mx32" >> Operating system: x86_64-whatever-linux2 >> Configuring for linux-x86_64 >> Configuring OpenSSL version 1.1.0-pre6-dev (0x0x10100006L) >> target already defined - linux-x86_64 (offending arg: CFLAGS=-mx32) >> >> # ./config -mx32 >> Operating system: x86_64-whatever-linux2 >> Configuring for linux-x86_64 >> ... > > There is linux-x32 config line, use that instead. It naturally means that using linux-x86_64 config with -mx32 option is not supported. Or in other words if there are problems with that, questions won't be answered. I.e. *do* use linux-x32 for x32 build. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4583 Please log in as guest with password guest if prompted From rt at openssl.org Thu Jun 23 10:32:43 2016 From: rt at openssl.org (noloader@gmail.com via RT) Date: Thu, 23 Jun 2016 10:32:43 +0000 Subject: [openssl-dev] [openssl.org #4583] AutoReply: Debian X32 and "fatal error: sys/cdefs.h: No such file or directory" In-Reply-To: References: <576BB980.3060702@openssl.org> Message-ID: On Thu, Jun 23, 2016 at 6:25 AM, Andy Polyakov via RT wrote: >> Here's a couple more ways things don't work as expected: >> >> # ./config CFLAGS="-mx32" >> Operating system: x86_64-whatever-linux2 >> Configuring for linux-x86_64 >> Configuring OpenSSL version 1.1.0-pre6-dev (0x0x10100006L) >> target already defined - linux-x86_64 (offending arg: CFLAGS=-mx32) >> >> # ./config -mx32 >> Operating system: x86_64-whatever-linux2 >> Configuring for linux-x86_64 >> ... > > There is linux-x32 config line, use that instead. The only question is > *if* x32 should be auto-detected and in such case how. You mentioned > that uname returns x86_64. Of course it does, there is no x32 kernel, > x32 is pure user-land thing. Well, "pure" is overstatement because it > does require certain kernel support, but it's an add-on support for > plain 64-bit kernel. Most 64-bit Linux installations can execute x32 > binaries (statically linked if there are no corresponding dynamic > libraries) and x32 installations can execute 64-bit binaries (statically > linked if there are no corresponding dynamic libraries). Yeah, I'm less concerned about the mis-detection. As strange as it sounds, you are free to mis-detect as much as you'd like. BUT... you're not allowed to break the compile, regardless of whether there's a proper "X32" kernel. In my mind's eye, things either "just work" or they have issues. This is falling on the "has issues" side of the line. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4583 Please log in as guest with password guest if prompted From rt at openssl.org Thu Jun 23 10:44:47 2016 From: rt at openssl.org (Andy Polyakov via RT) Date: Thu, 23 Jun 2016 10:44:47 +0000 Subject: [openssl-dev] [openssl.org #4583] AutoReply: Debian X32 and "fatal error: sys/cdefs.h: No such file or directory" In-Reply-To: <576BBDEE.6010902@openssl.org> References: <576BB980.3060702@openssl.org> <576BBDEE.6010902@openssl.org> Message-ID: > you're not allowed to break the compile, regardless of whether there's > a proper "X32" kernel. I don't understand what do you mean by "break the compile". I'd say it's the kind of thing that lies on both parties. We are responsible for providing code and config lines, but you have responsibilities too, you are responsible for providing sane compiler environment. For example if there is a system header file missing on target system [or another standard header file attempts to include non-existing system header file], there is nothing we can do. There either is a package missing, not installed, or vendor screwed up packaging... As suggested, start by ./Configure linux-x32... -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4583 Please log in as guest with password guest if prompted From rt at openssl.org Thu Jun 23 10:45:57 2016 From: rt at openssl.org (noloader@gmail.com via RT) Date: Thu, 23 Jun 2016 10:45:57 +0000 Subject: [openssl-dev] [openssl.org #4583] AutoReply: Debian X32 and "fatal error: sys/cdefs.h: No such file or directory" In-Reply-To: References: <576BB980.3060702@openssl.org> <576BBACA.7070302@openssl.org> Message-ID: On Thu, Jun 23, 2016 at 6:31 AM, Andy Polyakov via RT wrote: >>> Here's a couple more ways things don't work as expected: >>> >>> # ./config CFLAGS="-mx32" >>> Operating system: x86_64-whatever-linux2 >>> Configuring for linux-x86_64 >>> Configuring OpenSSL version 1.1.0-pre6-dev (0x0x10100006L) >>> target already defined - linux-x86_64 (offending arg: CFLAGS=-mx32) >>> >>> # ./config -mx32 >>> Operating system: x86_64-whatever-linux2 >>> Configuring for linux-x86_64 >>> ... >> >> There is linux-x32 config line, use that instead. > > It naturally means that using linux-x86_64 config with -mx32 option is > not supported. Or in other words if there are problems with that, > questions won't be answered. I.e. *do* use linux-x32 for x32 build. A quick question about this configuration... Should Linux-x32 enable ec_nistp_64_gcc_128 by default? Does anything prohibit ec_nistp_64_gcc_128 in this configuration? # ./Configure linux-x32 Configuring OpenSSL version 1.1.0-pre6-dev (0x0x10100006L) no-asan [default] OPENSSL_NO_ASAN (skip dir) ... no-ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128 (skip dir) ... I believe it meets the three criteria for ec_nistp_64_gcc_128. Jeff -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4583 Please log in as guest with password guest if prompted From rt at openssl.org Thu Jun 23 10:48:35 2016 From: rt at openssl.org (noloader@gmail.com via RT) Date: Thu, 23 Jun 2016 10:48:35 +0000 Subject: [openssl-dev] [openssl.org #4583] AutoReply: Debian X32 and "fatal error: sys/cdefs.h: No such file or directory" In-Reply-To: References: <576BBDEE.6010902@openssl.org> Message-ID: On Thu, Jun 23, 2016 at 6:44 AM, Andy Polyakov via RT wrote: >> you're not allowed to break the compile, regardless of whether there's >> a proper "X32" kernel. > > I don't understand what do you mean by "break the compile". I'd say it's > the kind of thing that lies on both parties. We are responsible for > providing code and config lines, but you have responsibilities too, you > are responsible for providing sane compiler environment. For example if > there is a system header file missing on target system [or another > standard header file attempts to include non-existing system header > file], there is nothing we can do. There either is a package missing, > not installed, or vendor screwed up packaging... Fair enough, agreed. But Configure ignored my instructions: # ./config CFLAGS="-mx32" Operating system: x86_64-whatever-linux2 Configuring for linux-x86_64 Configuring OpenSSL version 1.1.0-pre6-dev (0x0x10100006L) target already defined - linux-x86_64 (offending arg: CFLAGS=-mx32) And: # ./config -mx32 Operating system: x86_64-whatever-linux2 Configuring for linux-x86_64 Perhaps the second case should fail at configure just like the first case. Upon failure, it would be nice to tell the user what to do: "Please configure with ./Configure linux-x32" Jeff -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4583 Please log in as guest with password guest if prompted From rt at openssl.org Thu Jun 23 10:52:49 2016 From: rt at openssl.org (Andy Polyakov via RT) Date: Thu, 23 Jun 2016 10:52:49 +0000 Subject: [openssl-dev] [openssl.org #4583] AutoReply: Debian X32 and "fatal error: sys/cdefs.h: No such file or directory" In-Reply-To: <576BBFD1.8040708@openssl.org> References: <576BBACA.7070302@openssl.org> <576BBFD1.8040708@openssl.org> Message-ID: > A quick question about this configuration... Should Linux-x32 enable > ec_nistp_64_gcc_128 by default? Does anything prohibit > ec_nistp_64_gcc_128 in this configuration? > > # ./Configure linux-x32 > Configuring OpenSSL version 1.1.0-pre6-dev (0x0x10100006L) > no-asan [default] OPENSSL_NO_ASAN (skip dir) > ... > no-ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128 (skip dir) > ... > > I believe it meets the three criteria for ec_nistp_64_gcc_128. What are "the three criteria"? I mean I'm not really sure. Nor am I sure that they are perfect. I mean maybe they need some adjustment in x32 context. To either allow or prevent erroneous compilation. Bottom line is that I don't actually know at this point... -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4583 Please log in as guest with password guest if prompted From rt at openssl.org Thu Jun 23 10:55:15 2016 From: rt at openssl.org (noloader@gmail.com via RT) Date: Thu, 23 Jun 2016 10:55:15 +0000 Subject: [openssl-dev] [openssl.org #4583] AutoReply: Debian X32 and "fatal error: sys/cdefs.h: No such file or directory" In-Reply-To: References: <576BBFD1.8040708@openssl.org> Message-ID: On Thu, Jun 23, 2016 at 6:52 AM, Andy Polyakov via RT wrote: >> A quick question about this configuration... Should Linux-x32 enable >> ec_nistp_64_gcc_128 by default? Does anything prohibit >> ec_nistp_64_gcc_128 in this configuration? >> >> # ./Configure linux-x32 >> Configuring OpenSSL version 1.1.0-pre6-dev (0x0x10100006L) >> no-asan [default] OPENSSL_NO_ASAN (skip dir) >> ... >> no-ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128 (skip dir) >> ... >> >> I believe it meets the three criteria for ec_nistp_64_gcc_128. > > What are "the three criteria"? I mean I'm not really sure. Nor am I sure > that they are perfect. I mean maybe they need some adjustment in x32 > context. To either allow or prevent erroneous compilation. Bottom line > is that I don't actually know at this point... My bad... According to my notes, one can use ec_nistp_64_gcc_128 when these three conditions are met: * Little endian CPU * CPU allows unaligned data access * Compiler supports __uint128_t Jeff -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4583 Please log in as guest with password guest if prompted From rt at openssl.org Thu Jun 23 11:10:04 2016 From: rt at openssl.org (noloader@gmail.com via RT) Date: Thu, 23 Jun 2016 11:10:04 +0000 Subject: [openssl-dev] [openssl.org #4584] Self test failures under X32 In-Reply-To: References: Message-ID: I'm working on a Debian X32 system (http://wiki.debian.org/X32Port), and working from HEAD: # git rev-parse HEAD b58614d7f5f98571b2c0bb2fb3df48f4b48a7e92 Running 'make test' under a machine configured with './Configure linux-x32 enable-ec_nistp_64_gcc_128' results in two failed self tests: make[1]: Leaving directory '/openssl' ( cd test; \ SRCTOP=../. \ BLDTOP=../. \ PERL="perl" \ EXE_EXT= \ OPENSSL_ENGINES=.././engines \ perl .././test/run_tests.pl ) ../test/recipes/01-test_abort.t ............ ok ../test/recipes/01-test_ordinals.t ......... ok ../test/recipes/01-test_symbol_presence.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_d2i.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_afalg.t ............ 1/1 # Failed test 'running afalgtest' # at ../test/recipes/30-test_afalg.t line 23. # Looks like you failed 1 test of 1. ../test/recipes/30-test_afalg.t ............ Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ../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 ........... 1/5 # Failed test 'Testing that we aren't running as a privileged user, such as root' # at ../test/recipes/40-test_rehash.t line 49. # 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_asyncio.t .......... ok ../test/recipes/70-test_clienthello.t ...... ok ../test/recipes/70-test_packet.t ........... ok ../test/recipes/70-test_sslcertstatus.t .... ok ../test/recipes/70-test_sslextension.t ..... ok ../test/recipes/70-test_sslrecords.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_cipherlist.t ....... ok ../test/recipes/80-test_cms.t .............. ok ../test/recipes/80-test_ct.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_new.t .......... ok ../test/recipes/80-test_ssl_old.t .......... ok ../test/recipes/80-test_ssl_test_ctx.t ..... ok ../test/recipes/80-test_tsa.t .............. ok ../test/recipes/80-test_x509aux.t .......... ok ../test/recipes/90-test_async.t ............ ok ../test/recipes/90-test_bioprint.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_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_sslapi.t ........... ok ../test/recipes/90-test_threads.t .......... ok ../test/recipes/90-test_v3name.t ........... ok Test Summary Report ------------------- ../test/recipes/30-test_afalg.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 Files=80, Tests=422, 44 wallclock secs ( 0.34 usr 0.11 sys + 25.08 cusr 2.64 csys = 28.17 CPU) Result: FAIL Failed 2/80 test programs. 2/422 subtests failed. Makefile:130: recipe for target 'tests' failed make: *** [tests] Error 255 -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4584 Please log in as guest with password guest if prompted From rt at openssl.org Thu Jun 23 11:10:14 2016 From: rt at openssl.org (Andy Polyakov via RT) Date: Thu, 23 Jun 2016 11:10:14 +0000 Subject: [openssl-dev] [openssl.org #4583] AutoReply: Debian X32 and "fatal error: sys/cdefs.h: No such file or directory" In-Reply-To: <576BC3E6.5060301@openssl.org> References: <576BBFD1.8040708@openssl.org> <576BC3E6.5060301@openssl.org> Message-ID: >>> A quick question about this configuration... Should Linux-x32 enable >>> ec_nistp_64_gcc_128 by default? Does anything prohibit >>> ec_nistp_64_gcc_128 in this configuration? >>> >>> # ./Configure linux-x32 >>> Configuring OpenSSL version 1.1.0-pre6-dev (0x0x10100006L) >>> no-asan [default] OPENSSL_NO_ASAN (skip dir) >>> ... >>> no-ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128 (skip dir) >>> ... >>> >>> I believe it meets the three criteria for ec_nistp_64_gcc_128. >> >> What are "the three criteria"? I mean I'm not really sure. Nor am I sure >> that they are perfect. I mean maybe they need some adjustment in x32 >> context. To either allow or prevent erroneous compilation. Bottom line >> is that I don't actually know at this point... > > My bad... According to my notes, one can use ec_nistp_64_gcc_128 when > these three conditions are met: > > * Little endian CPU > * CPU allows unaligned data access > * Compiler supports __uint128_t Correct. But there still might be nuances. For example first two criteria were not actually formulated originally. Upon code submission only __uint128_t requirement was explicitly formulated along with statement that code was developed on x86_64 and therefore tested only on x86_64. The first two criteria were kind of epiphany as result of looking at a compiler warning and realizing that the piece of code in question can possibly work only on little-endian system that tolerates unaligned access. I.e. code was written under this assumption, but it was not explicitly verbalized or maybe even recognized, presumably because it appeared too obvious to original developer. Same in this case, i.e. there *might* as well be some so-far-unverbalized assumption, for example sizeof(long) being 8. Note "might", as I'm not actually saying that there is. All I'm saying is that I don't know [at this point]. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4583 Please log in as guest with password guest if prompted From rt at openssl.org Thu Jun 23 11:12:06 2016 From: rt at openssl.org (noloader@gmail.com via RT) Date: Thu, 23 Jun 2016 11:12:06 +0000 Subject: [openssl-dev] [openssl.org #4583] AutoReply: Debian X32 and "fatal error: sys/cdefs.h: No such file or directory" In-Reply-To: References: <576BC3E6.5060301@openssl.org> Message-ID: On Thu, Jun 23, 2016 at 7:10 AM, Andy Polyakov via RT wrote: >>>> A quick question about this configuration... Should Linux-x32 enable >>>> ec_nistp_64_gcc_128 by default? Does anything prohibit >>>> ec_nistp_64_gcc_128 in this configuration? >>>> >>>> # ./Configure linux-x32 >>>> Configuring OpenSSL version 1.1.0-pre6-dev (0x0x10100006L) >>>> no-asan [default] OPENSSL_NO_ASAN (skip dir) >>>> ... >>>> no-ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128 (skip dir) >>>> ... >>>> >>>> I believe it meets the three criteria for ec_nistp_64_gcc_128. >>> >>> What are "the three criteria"? I mean I'm not really sure. Nor am I sure >>> that they are perfect. I mean maybe they need some adjustment in x32 >>> context. To either allow or prevent erroneous compilation. Bottom line >>> is that I don't actually know at this point... >> >> My bad... According to my notes, one can use ec_nistp_64_gcc_128 when >> these three conditions are met: >> >> * Little endian CPU >> * CPU allows unaligned data access >> * Compiler supports __uint128_t > > Correct. But there still might be nuances. For example first two > criteria were not actually formulated originally.... Gotcha, thanks. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4583 Please log in as guest with password guest if prompted From rt at openssl.org Thu Jun 23 11:23:09 2016 From: rt at openssl.org (Andy Polyakov via RT) Date: Thu, 23 Jun 2016 11:23:09 +0000 Subject: [openssl-dev] [openssl.org #4583] AutoReply: Debian X32 and "fatal error: sys/cdefs.h: No such file or directory" In-Reply-To: <576BC6ED.2050508@openssl.org> References: <576BBDEE.6010902@openssl.org> <576BC6ED.2050508@openssl.org> Message-ID: > Fair enough, agreed. > > But Configure ignored my instructions: > > # ./config CFLAGS="-mx32" > Operating system: x86_64-whatever-linux2 > Configuring for linux-x86_64 > Configuring OpenSSL version 1.1.0-pre6-dev (0x0x10100006L) > target already defined - linux-x86_64 (offending arg: CFLAGS=-mx32) Well, I don't think that you can complain about this one. Basically you can't assume that ./config will [gracefully] handle whatever you might think of. You probably meant to run 'CFLAGS=-mx32 ./config' and computer didn't get what you wanted. But they never do, don't they? Computers getting what you meant to do that is... > And: > > # ./config -mx32 > Operating system: x86_64-whatever-linux2 > Configuring for linux-x86_64 > > Perhaps the second case should fail at configure just like the first > case. Upon failure, it would be nice to tell the user what to do: > "Please configure with ./Configure linux-x32" Well, there is a trade-off. Special cases are too numerous to cover them all, so question would be if this would be common and grave enough to guard against. For example you can actually run ./Configure tru64-alpha-cc on your Linux computer. Running make would fail miserably, but would it give you right to say "you're not allowed to break the compile"? -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4583 Please log in as guest with password guest if prompted From rt at openssl.org Thu Jun 23 11:59:54 2016 From: rt at openssl.org (=?UTF-8?B?55+z56OK?= via RT) Date: Thu, 23 Jun 2016 11:59:54 +0000 Subject: [openssl-dev] [openssl.org #4585] some bugs in ver.1.0.2d (fix) In-Reply-To: <88E4FB7D4EC3E04EAA5DAFEB85C81D42011B604E@EX02.corp.qihoo.net> References: <88E4FB7D4EC3E04EAA5DAFEB85C81D42011B604E@EX02.corp.qihoo.net> Message-ID: Hi, Recently, I found some bugs in ver.1.0.2d. DESCRIPTION _____ 1. Line 122 in a_enum.c: return (0xffffffffL); I think it should be "return -1;". 2. Line 149 in a_enum.c: if (BN_is_negative(bn)) I think it should be "if (BN_is_negative(bn) && !BN_is_zero(bn))". 3. Line 161 and line 164 in f_string.c: sp = (unsigned char *)OPENSSL_malloc((unsigned int)num + i * 2); sp = (unsigned char *)OPENSSL_realloc(s, (unsigned int)num + i * 2); Allocation "num + i" is enough. 4. Function a2i_ASN1_STRING in f_string.c. The processing of the contents containing "\\" is not correct. 5. Function a2i_ASN1_STRING in f_string.c. There is a memory leak when the content like "1234567\\\r\n890". 6. Line 155 and line 158 in f_enum.c: sp = (unsigned char *)OPENSSL_malloc((unsigned int)num + i * 2); sp = (unsigned char *)OPENSSL_realloc(s, (unsigned int)num + i * 2); Allocation "num + i" is enough. 7. Function a2i_ASN1_ENUMERATED in f_enum.c. The processing of the contents containing "\\" is not correct. 8. Function a2i_ASN1_ENUMERATED in f_enum.c. There is a memory leak when the content like "1234567\\\r\n890". 9. Line 169 and line 172 in f_int.c: sp = (unsigned char *)OPENSSL_malloc((unsigned int)num + i * 2); sp = sp = OPENSSL_realloc_clean(s, slen, num + i * 2); Allocation "num + i" is enough. 10. Function a2i_ASN1_INTEGER in f_int.c. The processing of the contents containing "\\" is not correct. 11. Function a2i_ASN1_INTEGER in f_int.c. There is a memory leak when the content like "1234567\\\r\n890". 12. Line 226 in t1_ext.c: exts->meths = OPENSSL_realloc(exts->meths, (exts->meths_count + 1) * sizeof(custom_ext_method)); There's a risk of memory leaks. 13. Line 896 in ssl_rsa.c: ctx->cert->key->serverinfo = OPENSSL_realloc(ctx->cert->key->serverinfo, serverinfo_length); There's a risk of memory leaks. 14. Line 979 in ssl_rsa.c: serverinfo = OPENSSL_realloc(serverinfo, serverinfo_length + extension_length); There's a risk of memory leaks. 15. Line 366 in openbsd_hw.c: md_data->data = OPENSSL_realloc(md_data->data, md_data->len + len); There's a risk of memory leaks. 16. Line 812 in eng_cryptodev.c: state->mac_data = OPENSSL_realloc(state->mac_data, state->mac_len + count); There's a risk of memory leaks. 17. Line 899 in b_sock.c: p = OPENSSL_realloc(p, nl); There's a risk of memory leaks. 18. Line 724 in b_print.c: *buffer = OPENSSL_realloc(*buffer, *maxlen); There's a risk of memory leaks. 19. Line 117 in engine.c: *buf = OPENSSL_realloc(*buf, *size); There's a risk of memory leaks. Thanks, Shi Lei / Qihoo 360 Inc. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4585 Please log in as guest with password guest if prompted From rt at openssl.org Thu Jun 23 12:08:52 2016 From: rt at openssl.org (noloader@gmail.com via RT) Date: Thu, 23 Jun 2016 12:08:52 +0000 Subject: [openssl-dev] [openssl.org #4583] AutoReply: Debian X32 and "fatal error: sys/cdefs.h: No such file or directory" In-Reply-To: References: <576BC6ED.2050508@openssl.org> Message-ID: >> # ./config -mx32 >> Operating system: x86_64-whatever-linux2 >> Configuring for linux-x86_64 >> >> Perhaps the second case should fail at configure just like the first >> case. Upon failure, it would be nice to tell the user what to do: >> "Please configure with ./Configure linux-x32" > > Well, there is a trade-off. Special cases are too numerous to cover them > all, so question would be if this would be common and grave enough to > guard against. For example you can actually run ./Configure > tru64-alpha-cc on your Linux computer. Running make would fail > miserably, but would it give you right to say "you're not allowed to > break the compile"? Kinda agree. I image there could be many cases like you describe. In this case, there's not "too many" or "too numerous". There's only one item of interest: -mx32. When Configure ignores it, it results in a failed compile. Jeff -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4583 Please log in as guest with password guest if prompted From rt at openssl.org Thu Jun 23 12:20:20 2016 From: rt at openssl.org (noloader@gmail.com via RT) Date: Thu, 23 Jun 2016 12:20:20 +0000 Subject: [openssl-dev] [openssl.org #4583] AutoReply: Debian X32 and "fatal error: sys/cdefs.h: No such file or directory" In-Reply-To: References: Message-ID: On Thu, Jun 23, 2016 at 6:18 AM, Jeffrey Walton wrote: > Here's a couple more ways things don't work as expected: > > # ./config CFLAGS="-mx32" > Operating system: x86_64-whatever-linux2 > Configuring for linux-x86_64 > Configuring OpenSSL version 1.1.0-pre6-dev (0x0x10100006L) > target already defined - linux-x86_64 (offending arg: CFLAGS=-mx32) > > # ./config -mx32 > Operating system: x86_64-whatever-linux2 > Configuring for linux-x86_64 > ... Here's another interesting result. This one is significant because its the that's often cited to side step "wrong platform" problems: # CC="gcc -mx32" ./config Operating system: x86_64-whatever-linux2 Configuring for linux-x86_64 Configuring OpenSSL version 1.1.0-pre6-dev (0x0x10100006L) no-asan [default] OPENSSL_NO_ASAN (skip dir) ... no-zlib [default] no-zlib-dynamic [default] Configuring for linux-x86_64 CC =gcc -mx32 CFLAG =-Wall -O3 -pthread -m64 -DL_ENDIAN -Wa,--noexecstack SHARED_CFLAG =-fPIC .... PERL =/usr/bin/perl SIXTY_FOUR_BIT_LONG mode Configured for linux-x86_64. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4583 Please log in as guest with password guest if prompted From rt at openssl.org Thu Jun 23 12:44:15 2016 From: rt at openssl.org (Andy Polyakov via RT) Date: Thu, 23 Jun 2016 12:44:15 +0000 Subject: [openssl-dev] [openssl.org #4583] AutoReply: Debian X32 and "fatal error: sys/cdefs.h: No such file or directory" In-Reply-To: <576BD9EF.6070305@openssl.org> References: <576BC6ED.2050508@openssl.org> <576BD9EF.6070305@openssl.org> Message-ID: >>> # ./config -mx32 >>> Operating system: x86_64-whatever-linux2 >>> Configuring for linux-x86_64 >>> >>> Perhaps the second case should fail at configure just like the first >>> case. Upon failure, it would be nice to tell the user what to do: >>> "Please configure with ./Configure linux-x32" >> >> Well, there is a trade-off. Special cases are too numerous to cover them >> all, so question would be if this would be common and grave enough to >> guard against. For example you can actually run ./Configure >> tru64-alpha-cc on your Linux computer. Running make would fail >> miserably, but would it give you right to say "you're not allowed to >> break the compile"? > > Kinda agree. I image there could be many cases like you describe. One word in the context, cross-compile. > In this case, there's not "too many" or "too numerous". There's only > one item of interest: -mx32. And it might be one too many :-) > When Configure ignores it, But it doesn't, it does pass it down as additional flag to compiler... > it results in a failed compile. Well, Configure is deliberately liberal to allow all kinds of local adaptations. Yes, you can screw things up [easily], but you've got to appreciate the flexibility it provides. Suggestion seems to be to classify flags as generic adaptations and ones that might affect choice of platform. I'd say "no" to that. What one can discuss is to have ./config (not ./Configure) detect x32 environment and pass alternative config line to ./Configure. That's how it worked so far and I see no reason to change it by moving platform detection logic to ./Configure. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4583 Please log in as guest with password guest if prompted From rt at openssl.org Thu Jun 23 13:46:30 2016 From: rt at openssl.org (Andy Polyakov via RT) Date: Thu, 23 Jun 2016 13:46:30 +0000 Subject: [openssl-dev] [openssl.org #4583] AutoReply: Debian X32 and "fatal error: sys/cdefs.h: No such file or directory" In-Reply-To: <576BE884.9080507@openssl.org> References: <576BD9EF.6070305@openssl.org> <576BE884.9080507@openssl.org> Message-ID: > ... What one can discuss is to have > ./config (not ./Configure) detect x32 environment and pass alternative > config line to ./Configure. That's how it worked so far and I see no > reason to change it by moving platform detection logic to ./Configure. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4583 Please log in as guest with password guest if prompted -------------- next part -------------- A non-text attachment was scrubbed... Name: x32.diff Type: text/x-diff Size: 486 bytes Desc: not available URL: From rt at openssl.org Thu Jun 23 14:07:39 2016 From: rt at openssl.org (Andy Polyakov via RT) Date: Thu, 23 Jun 2016 14:07:39 +0000 Subject: [openssl-dev] [openssl.org #4583] AutoReply: Debian X32 and "fatal error: sys/cdefs.h: No such file or directory" In-Reply-To: <576BED7A.7050509@openssl.org> References: <576BC3E6.5060301@openssl.org> <576BED7A.7050509@openssl.org> Message-ID: >>>> A quick question about this configuration... Should Linux-x32 enable >>>> ec_nistp_64_gcc_128 by default? Does anything prohibit >>>> ec_nistp_64_gcc_128 in this configuration? >>>> >>>> # ./Configure linux-x32 >>>> Configuring OpenSSL version 1.1.0-pre6-dev (0x0x10100006L) >>>> no-asan [default] OPENSSL_NO_ASAN (skip dir) >>>> ... >>>> no-ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128 (skip dir) >>>> ... >>>> >>>> I believe it meets the three criteria for ec_nistp_64_gcc_128. >>> >> * Little endian CPU >> * CPU allows unaligned data access >> * Compiler supports __uint128_t > > Correct. But there still might be nuances. ... > ... there *might* as well be some so-far-unverbalized assumption, > for example sizeof(long) being 8. Note "might", as I'm not actually > saying that there is. All I'm saying is that I don't know [at this point]. It should work with linux-x32 and apparently does based on your report in RT#4584. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4583 Please log in as guest with password guest if prompted From rt at openssl.org Thu Jun 23 14:10:21 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 23 Jun 2016 14:10:21 +0000 Subject: [openssl-dev] [openssl.org #2867] des_ede3_cfb1_cipher(): output cropping In-Reply-To: References: Message-ID: fixed with commit fe2d149 in master. Not backported, code has changed. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2867 Please log in as guest with password guest if prompted From rt at openssl.org Thu Jun 23 19:38:50 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 23 Jun 2016 19:38:50 +0000 Subject: [openssl-dev] [openssl.org #2894] [Bug] openssl crl -nameopt has no effect In-Reply-To: <70C50C9A-4D5A-40A7-A3C2-AA45046640A2@epy.co.at> References: <70C50C9A-4D5A-40A7-A3C2-AA45046640A2@epy.co.at> Message-ID: This was implemented some time ago (not sure who). The nmflag variable is used in name_print in apps/crl.c Closing ticket. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2894 Please log in as guest with password guest if prompted From rt at openssl.org Thu Jun 23 19:43:52 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 23 Jun 2016 19:43:52 +0000 Subject: [openssl-dev] [openssl.org #2698] [PATCH] Allow the use of startdate and enddate for ca -gencrl command In-Reply-To: References: Message-ID: This duplicates https://github.com/openssl/openssl/pull/258 so closing the ticket. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2698 Please log in as guest with password guest if prompted From rt at openssl.org Thu Jun 23 19:55:22 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 23 Jun 2016 19:55:22 +0000 Subject: [openssl-dev] [openssl.org #3305] Cppcheck report In-Reply-To: <5349D01A.9080709@yahoo.fr> References: <5349D01A.9080709@yahoo.fr> Message-ID: https://github.com/openssl/openssl/pull/139 Closing ticket. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3305 Please log in as guest with password guest if prompted From rt at openssl.org Thu Jun 23 19:56:02 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 23 Jun 2016 19:56:02 +0000 Subject: [openssl-dev] [openssl.org #3533] [PATCH] Ensures that EVP encryption & decryption operations check the encrypt flag on the context. In-Reply-To: References: Message-ID: https://github.com/openssl/openssl/pull/172 Closing ticket. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3533 Please log in as guest with password guest if prompted From rt at openssl.org Thu Jun 23 19:56:43 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 23 Jun 2016 19:56:43 +0000 Subject: [openssl-dev] [openssl.org #3616] [Patch] Implement option to disable sending TLS extensions In-Reply-To: <1427858765.11155705.1417276883241.JavaMail.zimbra@redhat.com> References: <2094767340.11155582.1417276692063.JavaMail.zimbra@redhat.com> <1427858765.11155705.1417276883241.JavaMail.zimbra@redhat.com> Message-ID: https://github.com/openssl/openssl/pull/215 Closing ticket. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3616 Please log in as guest with password guest if prompted From rt at openssl.org Thu Jun 23 19:58:28 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 23 Jun 2016 19:58:28 +0000 Subject: [openssl-dev] [openssl.org #3709] [PATCH] Constness in SSL_CTX_set_srp_username and SSL_CTX_set_srp_password functions In-Reply-To: <54E22FAD.9010800@leeds.pl> References: <20150216172647.GB12508@roeckx.be> <54E22FAD.9010800@leeds.pl> Message-ID: https://github.com/openssl/openssl/pull/227 Closing ticket. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3709 Please log in as guest with password guest if prompted From rt at openssl.org Thu Jun 23 20:01:07 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 23 Jun 2016 20:01:07 +0000 Subject: [openssl-dev] [openssl.org #3986] [PATCH] Implement HKDF algorithm (RFC 5869) In-Reply-To: <20150805094825.GB31335@kronk.local> References: <20150805094825.GB31335@kronk.local> Message-ID: https://github.com/openssl/openssl/pull/355 Closing ticket. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3986 Please log in as guest with password guest if prompted From rt at openssl.org Thu Jun 23 20:01:44 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 23 Jun 2016 20:01:44 +0000 Subject: [openssl-dev] [openssl.org #4038] SSLv2 session reuse is broken on the 1.0.2 branch In-Reply-To: <55F32FC6.1030705@akamai.com> References: <55F32FC6.1030705@akamai.com> Message-ID: https://github.com/openssl/openssl/pull/395 Closing ticket. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4038 Please log in as guest with password guest if prompted From rt at openssl.org Thu Jun 23 20:02:12 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 23 Jun 2016 20:02:12 +0000 Subject: [openssl-dev] [openssl.org #4108] Set TLS ticket keys API In-Reply-To: References: Message-ID: : https://github.com/openssl/openssl/pull/452 Closing ticket. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4108 Please log in as guest with password guest if prompted From rt at openssl.org Thu Jun 23 20:02:47 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 23 Jun 2016 20:02:47 +0000 Subject: [openssl-dev] [openssl.org #4121] avoid configuring openssl twice In-Reply-To: <20151104140424.GC16133@suse.de> References: <20151104140424.GC16133@suse.de> Message-ID: https://github.com/openssl/openssl/pull/466 Closing ticket. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4121 Please log in as guest with password guest if prompted From rt at openssl.org Thu Jun 23 20:03:32 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 23 Jun 2016 20:03:32 +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: fixed some time ago., -- 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 Thu Jun 23 20:04:36 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 23 Jun 2016 20:04:36 +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: https://github.com/openssl/openssl/pull/683 Closing ticket. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4308 Please log in as guest with password guest if prompted From rt at openssl.org Thu Jun 23 20:05:21 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 23 Jun 2016 20:05:21 +0000 Subject: [openssl-dev] [openssl.org #4432] [BUG] Building with "no-des" fails at crypto/cms/cms_kari.c In-Reply-To: References: Message-ID: https://github.com/openssl/openssl/pull/872 Closing ticket. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4432 Please log in as guest with password guest if prompted From rt at openssl.org Thu Jun 23 20:05:51 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 23 Jun 2016 20:05:51 +0000 Subject: [openssl-dev] =?utf-8?q?=5Bopenssl=2Eorg_=234532=5D_Replacing_the?= =?utf-8?q?_=E2=80=9Cdiv=5Fspoiler=E2=80=9D_hack_in_CBC_code_with_B?= =?utf-8?q?arrett_reduction=2E?= In-Reply-To: References: Message-ID: https://github.com/openssl/openssl/pull/1027 Closing ticket. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4532 Please log in as guest with password guest if prompted From rt at openssl.org Thu Jun 23 20:09:01 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 23 Jun 2016 20:09:01 +0000 Subject: [openssl-dev] [openssl.org #3980] [PATCH] Fix BIO_get_accept_socket so that "port-only" input works on FreeBSD In-Reply-To: References: Message-ID: https://github.com/openssl/openssl/pull/359 Closing ticket. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3980 Please log in as guest with password guest if prompted From rt at openssl.org Thu Jun 23 20:09:38 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 23 Jun 2016 20:09:38 +0000 Subject: [openssl-dev] [openssl.org #4273] explicitText encoding In-Reply-To: <8512c7aa1972d440b94c3f0e74748eae.squirrel@mailhost.ut.ee> References: <8512c7aa1972d440b94c3f0e74748eae.squirrel@mailhost.ut.ee> Message-ID: https://github.com/openssl/openssl/pull/576 Closing ticket. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4273 Please log in as guest with password guest if prompted From rt at openssl.org Thu Jun 23 20:18:18 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 23 Jun 2016 20:18:18 +0000 Subject: [openssl-dev] [openssl.org #3921] [PATCH] Fix const-correctness issues of new ECDSA_METHOD api In-Reply-To: <1434971453-8175-1-git-send-email-Matthias.St.Pierre@ncp-e.com> References: <1434971453-8175-1-git-send-email-Matthias.St.Pierre@ncp-e.com> Message-ID: This API is gone. Closing ticket. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3921 Please log in as guest with password guest if prompted From rt at openssl.org Thu Jun 23 21:58:13 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 23 Jun 2016 21:58:13 +0000 Subject: [openssl-dev] [openssl.org #3499] Bug: Multiple matching certificates in CAfile In-Reply-To: References: Message-ID: Fixed; see RT 3359 per Steve. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3499 Please log in as guest with password guest if prompted From rt at openssl.org Thu Jun 23 22:38:27 2016 From: rt at openssl.org (paul.dale@oracle.com via RT) Date: Thu, 23 Jun 2016 22:38:27 +0000 Subject: [openssl-dev] [openssl.org #4586] RSA_memory_lock ? In-Reply-To: <3cb69a8b-b17c-4d5a-be07-b3af886b38e3@default> References: <3cb69a8b-b17c-4d5a-be07-b3af886b38e3@default> Message-ID: The RSA_memory_lock (crypto/rsa/rsa_lib.c) call isn't mentioned in the documentation. It also isn't called from anywhere inside OpenSSL. The rsa.h header file says: | /* This function needs the memory locking malloc callbacks to be installed */ | int RSA_memory_lock(RSA *r); The problem being that this routine calls OPENSSL_malloc - i.e. no locking. So either the call needs to be updated to call CRYPTO_secure_malloc or it could be a candidate for dead code removal. Pauli -- Oracle Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4586 Please log in as guest with password guest if prompted From brian at briansmith.org Thu Jun 23 23:08:12 2016 From: brian at briansmith.org (Brian Smith) Date: Thu, 23 Jun 2016 13:08:12 -1000 Subject: [openssl-dev] Bugs fixed in one place but not another Message-ID: Hi, Sometimes I report bugs and/or fix bugs which get fixed in [1] and/or [2]. Please make sure you consider the impact of those changes on your own projects. [1] https://boringssl.googlesource.com/boringssl/+log/ [2] https://github.com/briansmith/ring Cheers, Brian -- https://briansmith.org/ From rsalz at akamai.com Thu Jun 23 23:50:03 2016 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 23 Jun 2016 23:50:03 +0000 Subject: [openssl-dev] Bugs fixed in one place but not another In-Reply-To: References: Message-ID: > Sometimes I report bugs and/or fix bugs which get fixed in [1] and/or [2]. > Please make sure you consider the impact of those changes on your own > projects. Not sure what you're asking for. From brian at briansmith.org Fri Jun 24 00:16:10 2016 From: brian at briansmith.org (Brian Smith) Date: Thu, 23 Jun 2016 14:16:10 -1000 Subject: [openssl-dev] Bugs fixed in one place but not another In-Reply-To: References: Message-ID: Salz, Rich wrote: >> Sometimes I report bugs and/or fix bugs which get fixed in [1] and/or [2]. >> Please make sure you consider the impact of those changes on your own >> projects. > > Not sure what you're asking for. In general, I noticed that OpenSSL and LibreSSL don't seem to pay attention to the bugs that are fixed in BoringSSL and *ring*. See, for example: * https://boringssl.googlesource.com/boringssl/+/95b97693403d5c8f09b2870ad9a6d7d198246da4%5E!/ * https://boringssl.googlesource.com/boringssl/+/75b833cc819a9d189adb0fdd56327bee600ff9e9 * https://boringssl.googlesource.com/boringssl/+/44bedc348d9491e63c7ed1438db100a4b8a830be I think it would be a good idea for OpenSSL and LibreSSL to fix the bugs too. Cheers, Brian -- https://briansmith.org/ From rsalz at akamai.com Fri Jun 24 01:11:47 2016 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 24 Jun 2016 01:11:47 +0000 Subject: [openssl-dev] Bugs fixed in one place but not another In-Reply-To: References: Message-ID: <43a12f0b2b154461ba0fb58800ea5909@usma1ex-dag1mb1.msg.corp.akamai.com> > In general, I noticed that OpenSSL and LibreSSL don't seem to pay attention > to the bugs that are fixed in BoringSSL and *ring*. See, for > example: We don't have the time to follow other forks, basically. I don't see that changing. From rt at openssl.org Fri Jun 24 13:01:55 2016 From: rt at openssl.org (123 via RT) Date: Fri, 24 Jun 2016 13:01:55 +0000 Subject: [openssl-dev] [openssl.org #4587] openssl on arm linux run err! In-Reply-To: <647a5741.7dab.155815e8c0d.Coremail.peter_zor@126.com> References: <647a5741.7dab.155815e8c0d.Coremail.peter_zor@126.com> Message-ID: Dear? First of all thank you very much l to contribution.Allow us to use openssl so good tools.I am a beginner, so had a problem, to be consulted.Cross-compilation openssl1.0.1 g, on the arm Linux, running under the/demos/SSL/serv and cli application.The following error: ./serv Connection from 100007f, port f0ae SSL connection using (NONE) Client does not have certificate. 3069232212:error:140940E5:SSL routines:SSL3_READ_BYTES:ssl handshake failure:s3_pkt.c:989: ./cli 3069961300:error:0306E06C:bignum routines:BN_mod_inverse:no inverse:bn_gcd.c:492: 3069961300:error:14098077:SSL routines:SSL3_SEND_CLIENT_KEY_EXCHANGE:bad rsa encrypt:s3_clnt.c:2287: But on x86 Linux, running without problems.I don't know what reason be?Hope to get your help Sincerely yours peter -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4587 Please log in as guest with password guest if prompted From rt at openssl.org Fri Jun 24 13:23:33 2016 From: rt at openssl.org (Rich Salz via RT) Date: Fri, 24 Jun 2016 13:23:33 +0000 Subject: [openssl-dev] [openssl.org #4587] openssl on arm linux run err! In-Reply-To: <647a5741.7dab.155815e8c0d.Coremail.peter_zor@126.com> References: <647a5741.7dab.155815e8c0d.Coremail.peter_zor@126.com> Message-ID: The demo's don't all work, sadly. OpenSSL 1.0.1 is very outdated and only gets security fixes; please try a recent version. closing ticket. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4587 Please log in as guest with password guest if prompted From rt at openssl.org Fri Jun 24 13:52:51 2016 From: rt at openssl.org (Rich Salz via RT) Date: Fri, 24 Jun 2016 13:52:51 +0000 Subject: [openssl-dev] [openssl.org #4586] RSA_memory_lock ? In-Reply-To: <3cb69a8b-b17c-4d5a-be07-b3af886b38e3@default> References: <3cb69a8b-b17c-4d5a-be07-b3af886b38e3@default> Message-ID: I'ts not needed; the secure heap automatically puts all private key material in secure storage, if enabled. https://github.com/openssl/openssl/pull/1250 is an MR to remove it. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4586 Please log in as guest with password guest if prompted From rt at openssl.org Fri Jun 24 15:42:59 2016 From: rt at openssl.org (Hubert Kario via RT) Date: Fri, 24 Jun 2016 15:42:59 +0000 Subject: [openssl-dev] [openssl.org #4588] pkcs12 -info doesn't handle PKCS#12 files with PKCS#5 v2.0 PBE In-Reply-To: <1992022.TCv6Aigntu@pintsize.usersys.redhat.com> References: <1992022.TCv6Aigntu@pintsize.usersys.redhat.com> Message-ID: I can't list PKCS#12 file information when it is encrypted with AES-256-CBC with PKCS#5 v2.0 PBE openssl req -x509 -newkey rsa -keyout localhost.key -out localhost.crt -subj /CN=localhost -nodes -batch openssl pkcs12 -export -out bundle.p12 -in localhost.key -nocerts -passout pass: -name server-key -keypbe AES-256-CBC openssl pkcs12 -info -in bundle.p12 -passin pass: -noout will print: MAC Iteration 2048 PKCS7 Data Shrouded Keybag: instead of: MAC Iteration 2048 PKCS7 Data Shrouded Keybag: PKCS#5 v2 PBE with AES-256-CBC, Iteration 2048 I've tested both 1.0.1 and current master (24bf6f3c7fccd9) -- 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=4588 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 Fri Jun 24 18:07:03 2016 From: rt at openssl.org (Rich Salz via RT) Date: Fri, 24 Jun 2016 18:07:03 +0000 Subject: [openssl-dev] [openssl.org #3792] OpenSSL debug build lacks -Og In-Reply-To: References: Message-ID: As Andy said, this flag is not ubiquitous and the workaround is to specify it config time. Closing ticket. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3792 Please log in as guest with password guest if prompted From rt at openssl.org Fri Jun 24 18:16:15 2016 From: rt at openssl.org (Rich Salz via RT) Date: Fri, 24 Jun 2016 18:16:15 +0000 Subject: [openssl-dev] [openssl.org #4559] bug: CRYPTO_set_mem_functions() Doesn't Work in Version 1.0.1b In-Reply-To: References: Message-ID: I just tried this against 1.0.2 and got a backtrace: #0 0x00007ffff7847c37 in __GI_raise (sig=sig at entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x00007ffff784b028 in __GI_abort () at abort.c:89 #2 0x0000000000401cfe in my_alloc (n=176) at a.c:4 #3 0x000000000044e525 in default_malloc_ex (num=176, file=0x5ca5ce "lhash.c", line=120) at mem.c:79 #4 0x000000000044ebb5 in CRYPTO_malloc (num=176, file=0x5ca5ce "lhash.c", line=120) at mem.c:330 #5 0x0000000000486d58 in lh_new (h=0x4515f7 , c=0x451619 ) at lhash.c:120 #6 0x000000000045167e in OBJ_NAME_init () at o_names.c:61 #7 0x0000000000451a68 in OBJ_NAME_add (name=0x58bccb "DES-CBC", type=2, data=0x5cace0 "\037") at o_names.c:185 #8 0x0000000000490a31 in EVP_add_cipher (c=0x5cace0 ) at names.c:74 #9 0x0000000000421d6e in SSL_library_init () at ssl_algs.c:68 -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4559 Please log in as guest with password guest if prompted From j at w1.fi Fri Jun 24 21:28:57 2016 From: j at w1.fi (Jouni Malinen) Date: Sat, 25 Jun 2016 00:28:57 +0300 Subject: [openssl-dev] 1.1 release being delayed In-Reply-To: References: Message-ID: <20160624212857.GA1420@w1.fi> On Mon, May 23, 2016 at 01:15:45PM +0000, Salz, Rich wrote: > ... in case you haven't noticed :) Our announced release date for 1.1 has come and gone. > > We want to close many more bugs before we release it. In the meantime, please test against master or a daily snapshot or the last beta release. It has now been a month from this announcement and there does not seem to be any updates to the release strategy (*) which is still claiming the "current plan" to be to release 1.1.0 12th May 2016.. While it is obviously fine to push out the release to get more fixes in, it would be nice to get some more details on the updated release plan and especially on whether there is going to be another beta release ("beta 3?") before the public release. I'd like to make sure I run my tests against a snapshot that is close to the release to check for any late regressions. However, I don't want to be doing this on daily basis until some unknown point in time. Would it be possible to either make the beta 3 release before the actual 1.1.0 public release or alternatively, provide some kind of early warning couple of weeks before the public release so that it would be easier to check for last minute regressions? And as far as regressions after beta 2 release are concerned, it looks like there was a change in the API that is not backwards compatible. I was hoping this would not happen after the "Beta 2 - Opaque work complete". Did I misunderstand what that note means? The non-compatible change (this actually broke wpa_supplicant build..) is this one: commit fd809cfdbd6e32b6b67b68c59f6d55fbed7a9327 Constify the parameter getters for RSA, DSA and DH -void DH_get0_key(const DH *dh, BIGNUM **pub_key, BIGNUM **priv_key) +void DH_get0_key(const DH *dh, const BIGNUM **pub_key, const BIGNUM **priv_key) Is there a clear point in time after which the OpenSSL 1.1.0 API is expected to be fully frozen for the release (well, other than the final public release showing up)? (*) https://www.openssl.org/policies/releasestrat.html -- Jouni Malinen PGP id EFC895FA From matt at openssl.org Fri Jun 24 22:27:05 2016 From: matt at openssl.org (Matt Caswell) Date: Fri, 24 Jun 2016 23:27:05 +0100 Subject: [openssl-dev] 1.1 release being delayed In-Reply-To: <20160624212857.GA1420@w1.fi> References: <20160624212857.GA1420@w1.fi> Message-ID: <576DB3B9.1080206@openssl.org> On 24/06/16 22:28, Jouni Malinen wrote: > On Mon, May 23, 2016 at 01:15:45PM +0000, Salz, Rich wrote: >> ... in case you haven't noticed :) Our announced release date for 1.1 has come and gone. >> >> We want to close many more bugs before we release it. In the meantime, please test against master or a daily snapshot or the last beta release. > > It has now been a month from this announcement and there does not seem > to be any updates to the release strategy (*) which is still claiming > the "current plan" to be to release 1.1.0 12th May 2016.. While it is > obviously fine to push out the release to get more fixes in, it would be > nice to get some more details on the updated release plan and especially > on whether there is going to be another beta release ("beta 3?") before > the public release. The current thinking is Thursday 7th July, although that is not set in stone as it depends on what happens between now and then. We don't currently have any plans for a beta 3, although again that could change. > > I'd like to make sure I run my tests against a snapshot that is close to > the release to check for any late regressions. However, I don't want to > be doing this on daily basis until some unknown point in time. Would it > be possible to either make the beta 3 release before the actual 1.1.0 > public release or alternatively, provide some kind of early warning > couple of weeks before the public release so that it would be easier to > check for last minute regressions? > > And as far as regressions after beta 2 release are concerned, it looks > like there was a change in the API that is not backwards compatible. I > was hoping this would not happen after the "Beta 2 - Opaque work > complete". Did I misunderstand what that note means? > > The non-compatible change (this actually broke wpa_supplicant build..) > is this one: > > commit fd809cfdbd6e32b6b67b68c59f6d55fbed7a9327 > Constify the parameter getters for RSA, DSA and DH > > -void DH_get0_key(const DH *dh, BIGNUM **pub_key, BIGNUM **priv_key) > +void DH_get0_key(const DH *dh, const BIGNUM **pub_key, const BIGNUM **priv_key) > > > Is there a clear point in time after which the OpenSSL 1.1.0 API is > expected to be fully frozen for the release (well, other than the final > public release showing up)? > We are not planning any more opaque work before release, and are trying to avoid API breaks at this late stage - but we can't fully rule it out either. Matt > > (*) https://www.openssl.org/policies/releasestrat.html > > From Matthias.St.Pierre at ncp-e.com Sat Jun 25 07:51:20 2016 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Sat, 25 Jun 2016 09:51:20 +0200 Subject: [openssl-dev] 1.1 release being delayed In-Reply-To: <576DB3B9.1080206@openssl.org> References: <20160624212857.GA1420@w1.fi> <576DB3B9.1080206@openssl.org> Message-ID: <1E23EFC52F00C649B69F652AFD284ABD3786A21944@ex07.ncp.local> > > And as far as regressions after beta 2 release are concerned, it looks > > like there was a change in the API that is not backwards compatible. I > > was hoping this would not happen after the "Beta 2 - Opaque work > > complete". Did I misunderstand what that note means? > > > > The non-compatible change (this actually broke wpa_supplicant build..) > > is this one: > > > > commit fd809cfdbd6e32b6b67b68c59f6d55fbed7a9327 > > Constify the parameter getters for RSA, DSA and DH > > > > -void DH_get0_key(const DH *dh, BIGNUM **pub_key, BIGNUM **priv_key) > > +void DH_get0_key(const DH *dh, const BIGNUM **pub_key, const BIGNUM **priv_key) > > > > > > Is there a clear point in time after which the OpenSSL 1.1.0 API is > > expected to be fully frozen for the release (well, other than the final > > public release showing up)? > > > > We are not planning any more opaque work before release, and are trying > to avoid API breaks at this late stage - but we can't fully rule it out > either. > > Matt +1 for the change. IMHO, the constification is a bug fix of the api, not a deliberate change. Having a const-incorrect api is always a nuisance and it is better to have it fixed now than after the final elease. Matthias -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4328 bytes Desc: not available URL: From rt at openssl.org Sat Jun 25 15:46:34 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sat, 25 Jun 2016 15:46:34 +0000 Subject: [openssl-dev] [openssl.org #2911] enhancement request: Windows RT support In-Reply-To: <201211081835.qA8IZMi8068514@givry.fdupont.fr> References: <201211081835.qA8IZMi8068514@givry.fdupont.fr> Message-ID: Nobody got around to looking at this, sorry. I could not decode the patch although 103K is big. Windows RT is no longer supported. Closing ticket. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2911 Please log in as guest with password guest if prompted From rt at openssl.org Sat Jun 25 18:20:23 2016 From: rt at openssl.org (Thomas Waldmann via RT) Date: Sat, 25 Jun 2016 18:20:23 +0000 Subject: [openssl-dev] [openssl.org #4589] simplifying writing code that is 1.0.x and 1.1.x compatible In-Reply-To: <576EC91D.8080301@waldmann-edv.de> References: <576EC91D.8080301@waldmann-edv.de> Message-ID: Hi, at borgbackup project, we are currently trying to make it compatible with OpenSSL 1.0.x and 1.1.x. For the opaque cipher ctx this worked quite easily like this: https://github.com/borgbackup/borg/pull/1193/files#diff-85ee6ebe1cdcfd4a4699c3913d519b27R23 I could not have a cipher ctx structure as a instance variable, but a pointer to one worked. I am just computing the current IV myself, so I do not need to reach into the ctx (I need to do that anyway to support gcm mode). I used EVP_CIPHER_CTX_new/free() - although not in the man page, they are there since 0.98 (and the wiki examples use them, too). Solved. In borgbackup 1.2, we will also need the flexible (not single-call) interface to HMAC and I could get it working using the same method as above (using a pointer and the new/free functions - we do not access into hmac ctx here, so it is even simpler). But: HMAC_CTX_{new/free} are not available on 1.0.x. :-( So my question / request: could these functions be added to a future update, like 1.0.2i, to simplify migration / portability of code? I suspect that these 2 functions are very simple to backport from 1.1 to 1.0.x. Cheers, Thomas -- GPG ID: FAF7B393 GPG FP: 6D5B EF9A DD20 7580 5747 B70F 9F88 FB52 FAF7 B393 -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4589 Please log in as guest with password guest if prompted From rt at openssl.org Sat Jun 25 20:41:51 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sat, 25 Jun 2016 20:41:51 +0000 Subject: [openssl-dev] [openssl.org #2964] OBJ_nid2obj() result value should be const In-Reply-To: References: Message-ID: Updated the docs in master and 1.0.2 to explain that these really are const-like objects. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2964 Please log in as guest with password guest if prompted From rt at openssl.org Sat Jun 25 20:46:25 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sat, 25 Jun 2016 20:46:25 +0000 Subject: [openssl-dev] [openssl.org #3016] openssl ts fix In-Reply-To: <514086CA.8050105@edelweb.fr> References: <514086CA.8050105@edelweb.fr> Message-ID: No plans to do this. Please re-open the ticket if it's *really* needed for interop. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3016 Please log in as guest with password guest if prompted From rt at openssl.org Sat Jun 25 20:51:10 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sat, 25 Jun 2016 20:51:10 +0000 Subject: [openssl-dev] [openssl.org #4169] openssl-1.0.2e build still recommends deprecated (unnecessary?) `make depend`, returns numerous warnings abt not finding stddef.h In-Reply-To: <566478DD.4030105@gmail.com> References: <566478DD.4030105@gmail.com> Message-ID: The warnings are annoying but harmless. running 'make depend' is required. Closing ticket. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4169 Please log in as guest with password guest if prompted From rt at openssl.org Sat Jun 25 20:59:53 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sat, 25 Jun 2016 20:59:53 +0000 Subject: [openssl-dev] [openssl.org #3811] [BUG REPORT] - Missing register name in aes-x86_64.s In-Reply-To: <2416E52E-9F03-488A-AC99-5B56B7BE03E0@macports.org> References: <2416E52E-9F03-488A-AC99-5B56B7BE03E0@macports.org> Message-ID: Cannot reproduce. Attempt to provide a work-around/fix hasn't had any response. Closing ticket. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3811 Please log in as guest with password guest if prompted From rt at openssl.org Sat Jun 25 21:05:15 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sat, 25 Jun 2016 21:05:15 +0000 Subject: [openssl-dev] [openssl.org #3886] [BUG] [PATCH] verify fails for 3-level cert chain when using X509v3 Authority Key Identifier In-Reply-To: References: Message-ID: It's not clear there is a bug (in fact, the bug commentary says that). If so, please open a new ticket with a PEM file of all the certs in the chain. Or perhaps post to openssl-users mailing list. Closing ticket. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3886 Please log in as guest with password guest if prompted From rt at openssl.org Sat Jun 25 21:10:53 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sat, 25 Jun 2016 21:10:53 +0000 Subject: [openssl-dev] [openssl.org #4298] [Bug] Random number generation failing with FIPS and Android < 5.0 In-Reply-To: References: Message-ID: There is not enough information to repeat. Please open a new ticket, post a backtrace, or whatever. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4298 Please log in as guest with password guest if prompted From rt at openssl.org Sat Jun 25 21:23:19 2016 From: rt at openssl.org (Francis Dupont via RT) Date: Sat, 25 Jun 2016 21:23:19 +0000 Subject: [openssl-dev] [openssl.org #2911] enhancement request: Windows RT support In-Reply-To: <201606252104.u5PL4r6d040719@givry.fdupont.fr> References: Your message of Jun 2016 15:46:34 -0000. <201606252104.u5PL4r6d040719@givry.fdupont.fr> Message-ID: In your previous mail you wrote: > Nobody got around to looking at this, sorry. I could not decode the patch > although 103K is big. Windows RT is no longer supported. Closing ticket. => no problem... Thanks Francis.Dupont at fdupont.fr -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2911 Please log in as guest with password guest if prompted From appro at openssl.org Sat Jun 25 21:55:41 2016 From: appro at openssl.org (Andy Polyakov) Date: Sat, 25 Jun 2016 23:55:41 +0200 Subject: [openssl-dev] Making assembly language optimizations working onCortex-M3 In-Reply-To: References: <55C4DC74.6060900@openssl.org> <55C873B8.9060602@openssl.org> <56056D20.9020806@openssl.org> <56b00a41-ed5f-4998-b0fb-55a6a39e4544@openssl.org> <738e4039-092b-9a64-01b6-c60aab0a5769@openssl.org> Message-ID: <5557aa5c-358b-5217-8d5d-4f19ca84c5e5@openssl.org> > The BoringSSL works as follows: > > 1. The person building the code passes -DOPENSSL_STATIC_ARMCAP and some > other flags like -DOPENSSL_STATIC_ARMCAP_NEON, to indicate which > features are available on the target. > > 2. When OPENSSL_STATIC_ARMCAP is defined, the runtime detection of > features is disabled. > > 3. When OPENSSL_STATIC_ARMCAP is defined, OPENSSL_armcap_P is fixed to a > value based on which of DOPENSSL_STATIC_ARMCAP_NEON, etc. are defined. > > 4. When OPENSSL_STATIC_ARMCAP isn't defined, then everything works like > it currently does; i.e. features are detected at runtime. > > The idea is that, instead having to go in and manually edit the code for > each different target system, one can just define these flags and the > code will auto-configure itself at build-time. I again seem to be failing to grasp the point. For far I was under impression that goal [denoted by subject] is to minimize resource consumption including code size. OPENSSL_STATIC_ARMCAP doesn't reduce code size, it simply sets OPENSSL_armcap_P to predefined value. And as we already established that we are talking about some overly specific usage case effectively outside OpenSSL, then why don't you simply replace armcap.c with one-liner that assigns OPENSSL_armcap_P to 0 or 1? > The problem here is you can't have both and having the capability > switch at runtime depending on hardware quirks is the better option > for the majority of users. > > That's usually true, but the topic of this thread is about how to get > OpenSSL working well on Cortex-M microcontrollers. In those situations, > we cannot really afford the dynamic detection or the many different > implementations of the same algorithm to exist in the final image. I doubt that current OPENSSL_STATIC_ARMCAP implementation result in any code savings. In order for compiler to omit code OPENSSL_armcap_P has to be at least declared constant (and it's not) and code omission can be performed only during link-time optimizations. Latter should not be recommended in security programming context and we don't... From rt at openssl.org Sat Jun 25 22:09:59 2016 From: rt at openssl.org (Roumen Petrov via RT) Date: Sat, 25 Jun 2016 22:09:59 +0000 Subject: [openssl-dev] [openssl.org #4590] accessors without const return arguments In-Reply-To: <576EF43A.7010104@roumenpetrov.info> References: <576EF43A.7010104@roumenpetrov.info> Message-ID: Hello, Recently declaration of a number of get0 methods was changed to return constant values (BIGNUM). Lets me quote description of an allocator "/ECDSA_SIG_new()/ allocates a new *ECDSA_SIG* structure (note: this function also allocates the BIGNUMs) and initialize it." Now lets try to write deserialization of a ECDSA signature. With set method allocated and never user ECDSA members r and s has to be freed and replaced by new one. As result extra allocation of big numbers impact performance and increase memory usage. Above is reason the request to remove const from return argument of get0 methods. The issue is not only for ECDSA but also for DSA_SIG and RSA, DSA, DH keys where situation is similar. Regards, Roumen Petrov -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4590 Please log in as guest with password guest if prompted From openssl at roumenpetrov.info Sat Jun 25 21:50:35 2016 From: openssl at roumenpetrov.info (Roumen Petrov) Date: Sun, 26 Jun 2016 00:50:35 +0300 Subject: [openssl-dev] prefer headers from source tree Message-ID: <576EFCAB.5010502@roumenpetrov.info> Hello, Build of master branch fail of on command line is specified include path (-I ...) with headers from another openssl version. Please see attached "0002-make-templates-prepend-path-to-source-headers.patch" file with proposed modification of make template. Tested wilt unix build. Windows modification is similar. Roumen -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-make-templates-prepend-path-to-source-headers.patch Type: text/x-diff Size: 3641 bytes Desc: not available URL: From rt at openssl.org Sun Jun 26 14:44:06 2016 From: rt at openssl.org (Kurt Roeckx via RT) Date: Sun, 26 Jun 2016 14:44:06 +0000 Subject: [openssl-dev] [openssl.org #4591] asynctest: double free or corruption on hppa In-Reply-To: <20160626144349.GA7315@roeckx.be> References: <20160626144349.GA7315@roeckx.be> Message-ID: Hi, My last upload of openssl to experimental show this on hppa: *** Error in `./asynctest': double free or corruption (out): 0x007307d8 *** ../util/shlib_wrap.sh ./asynctest => 134 # Failed test 'running asynctest' # at ../test/testlib/OpenSSL/Test/Simple.pm line 77. # Looks like you failed 1 test of 1. A full log can be seen at: https://buildd.debian.org/status/fetch.php?pkg=openssl&arch=hppa&ver=1.1.0~pre5-4&stamp=1466951184 This is with commit c32bdbf171ce6650ef045ec47b5abe0de7c264db The previous upload was succesful, the log of that is: https://buildd.debian.org/status/fetch.php?pkg=openssl&arch=hppa&ver=1.1.0~pre5-3&stamp=1465602753 That was with commit 5000a6d1215ea7d6ed6179d0bcd44263f6e3c26b I'm not sure if this is reproducible or not, I can try a new build if needed. Kurt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4591 Please log in as guest with password guest if prompted From rt at openssl.org Sun Jun 26 17:36:20 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 26 Jun 2016 17:36:20 +0000 Subject: [openssl-dev] [openssl.org #4235] Crash on ssleay_rand_bytes - global variable is not protected In-Reply-To: References: Message-ID: When it crashes, is k negative? I believe we already fixed this in master. with commit 0f91e1dff4ab2e7c25bbae5a48dfabbd1a4eae3c (RT 2630). -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4235 Please log in as guest with password guest if prompted From rt at openssl.org Sun Jun 26 17:40:25 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 26 Jun 2016 17:40:25 +0000 Subject: [openssl-dev] [openssl.org #3143] ENGINE_load_rdrand sane failure code In-Reply-To: References: Message-ID: Seems to be a duplicate of RT 3421; closing. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3143 Please log in as guest with password guest if prompted From rt at openssl.org Sun Jun 26 17:44:46 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 26 Jun 2016 17:44:46 +0000 Subject: [openssl-dev] [openssl.org #3902] #3423: Undefined behavior in crypto/cast/c_enc.c In-Reply-To: <6.2.5.6.2.20150611163323.083682a8@binnacle.cx> References: <6.2.5.6.2.20150611163323.083682a8@binnacle.cx> Message-ID: See RT 3423 and the links for why this is being rejected. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3902 Please log in as guest with password guest if prompted From rt at openssl.org Sun Jun 26 17:49:15 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 26 Jun 2016 17:49:15 +0000 Subject: [openssl-dev] [openssl.org #3880] [PATCH] Windows: Add definitions for AI_ constants In-Reply-To: References: Message-ID: AI_NUMERICSERV isn't used any more. Is this patch for AI_ADDRCONFIG still needed? The code in b_addr has it ifdef'd. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3880 Please log in as guest with password guest if prompted From rt at openssl.org Sun Jun 26 17:54:16 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 26 Jun 2016 17:54:16 +0000 Subject: [openssl-dev] [openssl.org #2271] [PATCH] building without some ciphers In-Reply-To: <52F25D87971B8E4DA9B4D597233AA0C607110624@EXVSB1.HMSHOST.INT> References: <52F25D87971B8E4DA9B4D597233AA0C607110624@EXVSB1.HMSHOST.INT> Message-ID: The amount of source code/build dependency changes to make more of the no-CIPHER configuration options work is more than we will do for 1.0.2. It is fixed in 1.1. Closing ticket. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2271 Please log in as guest with password guest if prompted From rt at openssl.org Sun Jun 26 18:22:43 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 26 Jun 2016 18:22:43 +0000 Subject: [openssl-dev] [openssl.org #2941] Memory leaks in ca.c In-Reply-To: References: Message-ID: fixed in 1.1; apps/ca.c jumps to common code to free all memory. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2941 Please log in as guest with password guest if prompted From rt at openssl.org Sun Jun 26 18:25:35 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 26 Jun 2016 18:25:35 +0000 Subject: [openssl-dev] [openssl.org #3810] [PATCH] Improved P256 ECC performance by means of a dedicated function for modular inversion modulo the P256 group order In-Reply-To: <3DE91BD01FD68540858FC917201D9B9939BD3C4B@hasmsx107.ger.corp.intel.com> References: <3DE91BD01FD68540858FC917201D9B9939BD3C4B@hasmsx107.ger.corp.intel.com> Message-ID: See https://github.com/openssl/openssl/pull/263 and discussion thread. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3810 Please log in as guest with password guest if prompted From rt at openssl.org Sun Jun 26 21:30:53 2016 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 26 Jun 2016 21:30:53 +0000 Subject: [openssl-dev] [openssl.org #2680] 1.0.1-beta1 issue: Public EC key is shown as private with -text option In-Reply-To: <4982.84.190.59.221.1325958373.squirrel@www2.informatik.hu-berlin.de> References: <4982.84.190.59.221.1325958373.squirrel@www2.informatik.hu-berlin.de> Message-ID: fixed, but slightly differently. thanks! -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2680 Please log in as guest with password guest if prompted From rt at openssl.org Mon Jun 27 02:05:23 2016 From: rt at openssl.org (123 via RT) Date: Mon, 27 Jun 2016 02:05:23 +0000 Subject: [openssl-dev] [openssl.org #4587] openssl on arm linux run err! In-Reply-To: <187eb3e5.278f.1558f998460.Coremail.peter_zor@126.com> References: <647a5741.7dab.155815e8c0d.Coremail.peter_zor@126.com> <187eb3e5.278f.1558f998460.Coremail.peter_zor@126.com> Message-ID: Hi? Thank you very much for your reply.According to your advice, I use a new openssl-1.0.2h tried.The result is the same as before. Really don't understand.In addition, the demo will need a few small changes can be compiled through. Guess problem is caused by the CPU architecture.The same example, arm and x86 result is different.hope to receive your reply very much! thank you At 2016-06-24 21:23:33, "Rich Salz via RT" wrote: >The demo's don't all work, sadly. >OpenSSL 1.0.1 is very outdated and only gets security fixes; please try a >recent version. >closing ticket. > >-- >Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4587 >Please log in as guest with password guest if prompted > -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4587 Please log in as guest with password guest if prompted From rt at openssl.org Mon Jun 27 03:03:22 2016 From: rt at openssl.org (123 via RT) Date: Mon, 27 Jun 2016 03:03:22 +0000 Subject: [openssl-dev] [openssl.org #4587] openssl on arm linux run err! In-Reply-To: <563aad56.3e44.1558fcf96c6.Coremail.peter_zor@126.com> References: <647a5741.7dab.155815e8c0d.Coremail.peter_zor@126.com> <563aad56.3e44.1558fcf96c6.Coremail.peter_zor@126.com> Message-ID: Hi? The following is the new print(using openssl-1.0.2h): # ./serv Connection from 100007f, port 8fec SSL connection using (NONE) Client does not have certificate. 3069940820:error:140940E5:SSL routines:ssl3_read_bytes:ssl handshake failure:s3_pkt.c:1210: # ./cli 3070080084:error:0306E06C:bignum routines:BN_mod_inverse:no inverse:bn_gcd.c:525: 3070080084:error:14098077:SSL routines:ssl3_send_client_key_exchange:bad rsa encrypt:s3_clnt.c:2540: The attachment is the cross compile a Makefile.the problem may be related to this (modified compiler in Makefile) At 2016-06-24 21:23:33, "Rich Salz via RT" wrote: >The demo's don't all work, sadly. >OpenSSL 1.0.1 is very outdated and only gets security fixes; please try a >recent version. >closing ticket. > >-- >Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4587 >Please log in as guest with password guest if prompted > -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4587 Please log in as guest with password guest if prompted -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile Type: application/octet-stream Size: 28352 bytes Desc: not available URL: From rt at openssl.org Mon Jun 27 07:40:35 2016 From: rt at openssl.org (Alexandre PAQUE via RT) Date: Mon, 27 Jun 2016 07:40:35 +0000 Subject: [openssl-dev] [openssl.org #4235] Crash on ssleay_rand_bytes - global variable is not protected In-Reply-To: References: Message-ID: OK thanks for your support. On 26 June 2016 at 19:36, Rich Salz via RT wrote: > When it crashes, is k negative? I believe we already fixed this in master. > with > commit 0f91e1dff4ab2e7c25bbae5a48dfabbd1a4eae3c (RT 2630). > > -- > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4235 > Please log in as guest with password guest if prompted > > -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4235 Please log in as guest with password guest if prompted From rt at openssl.org Mon Jun 27 08:44:06 2016 From: rt at openssl.org (Daniel Stenberg via RT) Date: Mon, 27 Jun 2016 08:44:06 +0000 Subject: [openssl-dev] [openssl.org #4592] [docs] SSL_set_app_data() returns 'int', not 'void' In-Reply-To: References: Message-ID: Hey! SSL_set_app_data() is a macro that actually uses the SSL_set_ex_data() function. SSL_set_ex_data() returns an int. Yet, the docs say SSL_set_app_data() returns void. I'd suggest a fix for this like the following. diff --git a/doc/ssl/ssl.pod b/doc/ssl/ssl.pod index 589fc2d..ac2664d 100644 --- a/doc/ssl/ssl.pod +++ b/doc/ssl/ssl.pod @@ -620,11 +620,11 @@ fresh handle for each connection. =item long B(SSL *ssl); =item void B(SSL *ssl); -=item void B(SSL *ssl, char *arg); +=item int B(SSL *ssl, char *arg); =item void B(SSL *ssl, BIO *rbio, BIO *wbio); =item int B(SSL *ssl, char *str); -- / daniel.haxx.se -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4592 Please log in as guest with password guest if prompted From rt at openssl.org Mon Jun 27 09:51:21 2016 From: rt at openssl.org (Matt Caswell via RT) Date: Mon, 27 Jun 2016 09:51:21 +0000 Subject: [openssl-dev] [openssl.org #4591] asynctest: double free or corruption on hppa In-Reply-To: <5770F716.9000109@openssl.org> References: <20160626144349.GA7315@roeckx.be> <5770F716.9000109@openssl.org> Message-ID: On 26/06/16 15:44, Kurt Roeckx via RT wrote: > Hi, > > My last upload of openssl to experimental show this on hppa: > *** Error in `./asynctest': double free or corruption (out): 0x007307d8 *** > ../util/shlib_wrap.sh ./asynctest => 134 > > # Failed test 'running asynctest' > # at ../test/testlib/OpenSSL/Test/Simple.pm line 77. > # Looks like you failed 1 test of 1. > > A full log can be seen at: > https://buildd.debian.org/status/fetch.php?pkg=openssl&arch=hppa&ver=1.1.0~pre5-4&stamp=1466951184 > > This is with commit c32bdbf171ce6650ef045ec47b5abe0de7c264db > > The previous upload was succesful, the log of that is: > https://buildd.debian.org/status/fetch.php?pkg=openssl&arch=hppa&ver=1.1.0~pre5-3&stamp=1465602753 > > That was with commit 5000a6d1215ea7d6ed6179d0bcd44263f6e3c26b There do not appear to be any changes at all in either the asynctest or the async code between those two commits. > > > I'm not sure if this is reproducible or not, I can try a new build > if needed. That would be good to know, although to take this any further I think we're going to need more information, e.g. a backtrace. Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4591 Please log in as guest with password guest if prompted From rt at openssl.org Mon Jun 27 11:41:05 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 27 Jun 2016 11:41:05 +0000 Subject: [openssl-dev] [openssl.org #4586] RSA_memory_lock ? In-Reply-To: <3cb69a8b-b17c-4d5a-be07-b3af886b38e3@default> References: <3cb69a8b-b17c-4d5a-be07-b3af886b38e3@default> Message-ID: removed the function. the secure-heap does most of this, anyway now. :) -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4586 Please log in as guest with password guest if prompted From cata.vasile at nxp.com Mon Jun 27 12:37:39 2016 From: cata.vasile at nxp.com (Catalin Vasile) Date: Mon, 27 Jun 2016 12:37:39 +0000 Subject: [openssl-dev] arch (ARM) capabilities Message-ID: Hi, Is there an option when making an app that uses OpenSSL to verify that is uses Crypto Extensions (like checking a flag or something like that) ? Cata From rt at openssl.org Mon Jun 27 13:49:17 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Mon, 27 Jun 2016 13:49:17 +0000 Subject: [openssl-dev] [openssl.org #4587] openssl on arm linux run err! In-Reply-To: References: <647a5741.7dab.155815e8c0d.Coremail.peter_zor@126.com> <563aad56.3e44.1558fcf96c6.Coremail.peter_zor@126.com> Message-ID: Is this using 1.0.1? Please try to do it with 1.0.2 or master. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4587 Please log in as guest with password guest if prompted From rt at openssl.org Mon Jun 27 13:58:05 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Mon, 27 Jun 2016 13:58:05 +0000 Subject: [openssl-dev] [openssl.org #4592] [docs] SSL_set_app_data() returns 'int', not 'void' In-Reply-To: References: Message-ID: You missed SSL_CTX_set_app_data :) I'll fix this as part of another doc fix which is being reviewed now. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4592 Please log in as guest with password guest if prompted From hkario at redhat.com Mon Jun 27 14:11:57 2016 From: hkario at redhat.com (Hubert Kario) Date: Mon, 27 Jun 2016 16:11:57 +0200 Subject: [openssl-dev] arch (ARM) capabilities In-Reply-To: References: Message-ID: <1651225.FMzIPc1M60@pintsize.usersys.redhat.com> On Monday 27 June 2016 12:37:39 Catalin Vasile wrote: > Hi, > > Is there an option when making an app that uses OpenSSL > to verify that is uses Crypto Extensions (like checking > a flag or something like that) ? With x86_64, ciphers like aes-128-cbc are much faster with AES-NI, so a simple benchmark: openssl speed aes-128-cbc openssl speed -evp aes-128-cbc will tell you if the code uses hardware acceleration, as it's only the EVP that is accelerated. But when I've tested it on AArch64 with openssl-1.1.0-pre5 and current master (./configure no-shared no-engine) I'm getting 100524.03k vs 52172.12k/s in favour of the non-EVP version. Is that really expected? With 1.0.1 and 1.0.2 I'm getting around 100000k/s with and without EVP, so that looks like a regression to me. -- 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 cata.vasile at nxp.com Mon Jun 27 14:46:02 2016 From: cata.vasile at nxp.com (Catalin Vasile) Date: Mon, 27 Jun 2016 14:46:02 +0000 Subject: [openssl-dev] arch (ARM) capabilities In-Reply-To: <1651225.FMzIPc1M60@pintsize.usersys.redhat.com> References: , <1651225.FMzIPc1M60@pintsize.usersys.redhat.com> Message-ID: I want something more programmatic, more general. I want to deliver a piece of software that will run on ARM architectures and will issue a warning or something like that if the user does not have an OpenSSL library set to work with ARM Crypto Extension. From: Hubert Kario Sent: Monday, June 27, 2016 5:11 PM To: openssl-dev at openssl.org Cc: Catalin Vasile Subject: Re: [openssl-dev] arch (ARM) capabilities ? On Monday 27 June 2016 12:37:39 Catalin Vasile wrote: > Hi, > > Is there an option when making an app that uses OpenSSL > to verify that is uses Crypto Extensions (like checking > a flag or something like that) ? With x86_64, ciphers like aes-128-cbc are much faster with AES-NI, so a simple benchmark: openssl speed aes-128-cbc openssl speed -evp aes-128-cbc will tell you if the code uses hardware acceleration, as it's only the EVP that is accelerated. But when I've tested it on AArch64 with openssl-1.1.0-pre5 and current master (./configure no-shared no-engine) I'm getting 100524.03k vs 52172.12k/s in favour of the non-EVP version. Is that really expected? With 1.0.1 and 1.0.2 I'm getting around 100000k/s with and without EVP, so that looks like a regression to me. -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com The world's open source leader www.cz.redhat.com Red Hat is the world?s leading provider of open source solutions, using a community-powered approach to provide reliable and high-performing cloud, virtualization, storage, Linux, and middleware technologies. Red Hat also offers award-winning support, training, and consulting services. Red Hat is an S&P 500 company with more than 80 offices spanning the globe, empowering its customers? businesses. Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic From cata.vasile at nxp.com Mon Jun 27 14:38:05 2016 From: cata.vasile at nxp.com (Catalin Vasile) Date: Mon, 27 Jun 2016 14:38:05 +0000 Subject: [openssl-dev] arch (ARM) capabilities In-Reply-To: <1651225.FMzIPc1M60@pintsize.usersys.redhat.com> References: , <1651225.FMzIPc1M60@pintsize.usersys.redhat.com> Message-ID: I want something more programmatic, more general. I want to deliver a piece of software that will run on ARM architectures and will issue a warning or something like that if the user does not have an OpenSSL library set to work with ARM Crypto Extension. ________________________________ From: Hubert Kario Sent: Monday, June 27, 2016 5:11:57 PM To: openssl-dev at openssl.org Cc: Catalin Vasile Subject: Re: [openssl-dev] arch (ARM) capabilities On Monday 27 June 2016 12:37:39 Catalin Vasile wrote: > Hi, > > Is there an option when making an app that uses OpenSSL > to verify that is uses Crypto Extensions (like checking > a flag or something like that) ? With x86_64, ciphers like aes-128-cbc are much faster with AES-NI, so a simple benchmark: openssl speed aes-128-cbc openssl speed -evp aes-128-cbc will tell you if the code uses hardware acceleration, as it's only the EVP that is accelerated. But when I've tested it on AArch64 with openssl-1.1.0-pre5 and current master (./configure no-shared no-engine) I'm getting 100524.03k vs 52172.12k/s in favour of the non-EVP version. Is that really expected? With 1.0.1 and 1.0.2 I'm getting around 100000k/s with and without EVP, so that looks like a regression to me. -- 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 -------------- An HTML attachment was scrubbed... URL: From appro at openssl.org Mon Jun 27 15:20:39 2016 From: appro at openssl.org (Andy Polyakov) Date: Mon, 27 Jun 2016 17:20:39 +0200 Subject: [openssl-dev] arch (ARM) capabilities In-Reply-To: <1651225.FMzIPc1M60@pintsize.usersys.redhat.com> References: <1651225.FMzIPc1M60@pintsize.usersys.redhat.com> Message-ID: <57714447.9000202@openssl.org> >> Is there an option when making an app that uses OpenSSL to verify >> that is uses Crypto Extensions (like checking a flag or something >> like that) ? > > With x86_64, ciphers like aes-128-cbc are much faster with AES-NI, > so a simple benchmark: > > openssl speed aes-128-cbc openssl speed -evp aes-128-cbc > > will tell you if the code uses hardware acceleration, as it's only > the EVP that is accelerated. > > But when I've tested it on AArch64 with openssl-1.1.0-pre5 and > current master (./configure no-shared no-engine) I'm getting > 100524.03k vs 52172.12k/s in favour of the non-EVP version. > > Is that really expected? Depends on your system. Not all AArch64 processors were born equal, some have crypto extensions, some don't, some have mighty pipelines, some don't. The presented numbers suggest that you ended up on APM X-Gene processor which doesn't. Is it a regression? In EVP mode it uses NEON code path which is resistant to side-channel attacks, so that you loose performance, but do gain security. In other words it is expected. See even crypto/aes/asm/vpaes-armv8.pl for processor comparison, compare even to crypto/aes/asm/aesv8-armx.pl. > With 1.0.1 and 1.0.2 I'm getting around 100000k/s with and without > EVP, so that looks like a regression to me. That's because there is no NEON AES code path in 1.0.2. From appro at openssl.org Mon Jun 27 15:28:40 2016 From: appro at openssl.org (Andy Polyakov) Date: Mon, 27 Jun 2016 17:28:40 +0200 Subject: [openssl-dev] arch (ARM) capabilities In-Reply-To: References: <1651225.FMzIPc1M60@pintsize.usersys.redhat.com> Message-ID: <57714628.4060601@openssl.org> > I want something more programmatic, more general. > I want to deliver a piece of software that will run on ARM architectures and will issue a warning or something like that if the user does not have an OpenSSL library set to work with ARM Crypto Extension. What does "set to work" mean? Compiled with support for ARMv8 extensions or actually uses them? While there is no direct means to tell either, there are indirect methods that you might find usable. To see if it's compiled with support for ARMv8 you might be able to use dlsym to lookup either of symbols specific to ARMv8 code. As for those subroutines actually being used, if you trust OpenSSL capability detection, you can simply look at /proc/cpuinfo, or replicate OpenSSL's detection. From tterribe at xiph.org Mon Jun 27 16:21:20 2016 From: tterribe at xiph.org (Timothy B. Terriberry) Date: Mon, 27 Jun 2016 09:21:20 -0700 Subject: [openssl-dev] Feedback on BIO API changes in 1.1 Message-ID: <57715280.1090904@xiph.org> I recently attempted to convert libopusfile to the new 1.1 API changes (in response to this Debian bug report: , if you want to see what broke). I realize that this late in the release cycle, people are unlikely to want to make additional backwards-incompatible changes, but you may find some of this useful, nonetheless. Feel free to disregard it, also, as it is just one developer's opinion. 1) There is no accessor for the "num" field in the BIO struct. This is typically used to store a file descriptor or similar value. As can be seen by its explicit access in BIO_dup_chain(), there may be legitimate reasons to get at its value, even if you are not writing your own new BIO implementation. 2) The API documentation for BIO_meth_new() says that "type" should be a unique integer, but provides no way to ensure this is true. Particularly, when using this from a library, I have no way to ensure that some number I choose here does not conflict with that chosen by some other library in the same application, or with the application itself. Furthermore, the values used by OpenSSL for its own internal BIO implementations appear to have some structure which the code relies on, but which is not documented. Not really having any way to do what the documentation asks for, I've simply chosen to pass in BIO_TYPE_NULL, and live with the fact that anything that relies on this being unique (not much, that I can tell) will not work correctly. 3) I'm not sure the conversion of BIO_METHOD to an opaque struct is really a good idea. In prior versions of the library, anyone wanting to make their own BIO implementation would typically have a static table (which could not be const because the API did not take const pointers). OpenSSL itself does this for all of its BIO implementations (which are now fortunately const), and any difficulties you might see there in converting to use the new API apply equally well to external implementations. If extensibility is really needed here, I think a better approach than arbitrarily changing the contents of this structure would be to simply define a new structure, BIO_METHOD2, or similar, and have new APIs to construct BIOs with these methods (or, for APIs which must handle any version, to have a "version" parameter to tell you which variety you have). This approach seems to make it much simpler to reason about what must be supported to ensure both backwards and forwards compatibility. From rt at openssl.org Mon Jun 27 18:42:35 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Mon, 27 Jun 2016 18:42:35 +0000 Subject: [openssl-dev] [openssl.org #4587] openssl on arm linux run err! In-Reply-To: References: <647a5741.7dab.155815e8c0d.Coremail.peter_zor@126.com> <187eb3e5.278f.1558f998460.Coremail.peter_zor@126.com> Message-ID: > Guess problem is caused by the CPU architecture.The same example, arm > and x86 result is different.hope to receive your reply very much! Yes it probably is. What did you change to make it compile? The demo's are mostly old and broken, and in the next release most of them are gone. Looks in apps/s_client.c, for example. This is currently not likely to get fixed without a lot of detail. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4587 Please log in as guest with password guest if prompted From rsalz at akamai.com Mon Jun 27 18:59:05 2016 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 27 Jun 2016 18:59:05 +0000 Subject: [openssl-dev] Feedback on BIO API changes in 1.1 In-Reply-To: <57715280.1090904@xiph.org> References: <57715280.1090904@xiph.org> Message-ID: <9fa8d87eb0684598b44831102d6274f0@usma1ex-dag1mb1.msg.corp.akamai.com> This feedback is very useful. > 1) There is no accessor for the "num" field in the BIO struct. > This is typically used to store a file descriptor or similar value. As can be seen > by its explicit access in BIO_dup_chain(), there may be legitimate reasons to > get at its value, even if you are not writing your own new BIO > implementation. Can you explain when/how/why you need it? > 2) The API documentation for BIO_meth_new() says that "type" should be a > unique integer, but provides no way to ensure this is true. That sounds like a bug we need to fix. Perhaps something like int BIO_meth_new_index([int flags?]) ? > 3) I'm not sure the conversion of BIO_METHOD to an opaque struct is really a > good idea. Did you see BIO_meth_set_write etc ? From rt at openssl.org Mon Jun 27 20:25:06 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 27 Jun 2016 20:25:06 +0000 Subject: [openssl-dev] [openssl.org #4589] simplifying writing code that is 1.0.x and 1.1.x compatible In-Reply-To: <576EC91D.8080301@waldmann-edv.de> References: <576EC91D.8080301@waldmann-edv.de> Message-ID: Look at the wiki, in particular https://wiki.openssl.org/index.php/1.1_API_Changes#Adding_forward-compatible_code_to_older_versions closing ticket. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4589 Please log in as guest with password guest if prompted From rt at openssl.org Mon Jun 27 20:43:07 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 27 Jun 2016 20:43:07 +0000 Subject: [openssl-dev] [openssl.org #2777] OpenSSL 1.0.1 TLS Version Handling Errors In-Reply-To: References: Message-ID: please open a new ticket if this is still an issue with current (at least 1.0.2, ideally master) sources. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2777 Please log in as guest with password guest if prompted From rt at openssl.org Mon Jun 27 20:50:43 2016 From: rt at openssl.org (Thomas Waldmann via RT) Date: Mon, 27 Jun 2016 20:50:43 +0000 Subject: [openssl-dev] [openssl.org #4589] Resolved: simplifying writing code that is 1.0.x and 1.1.x compatible In-Reply-To: <57719187.9020802@waldmann-edv.de> References: <57719187.9020802@waldmann-edv.de> Message-ID: On 06/27/2016 10:25 PM, Rich Salz via RT wrote: > According to our records, your request has been resolved. If you have any > further questions or concerns, please respond to this message. No, it wasn't resolved. You completely missed / ignored the point, which you can read again in the subject line of this mail. I didn't ask where to get the missing code from, I asked whether you maybe want to make life simpler for people by adding this to 1.0.x rather than having a thousand software developers copy and pasting it into their projects. But obviously I was expecting too much... Cython (in our case) has no #if, so we will need a separate C module just for what was forgotten in 1.0.x (or 0.9.8) back then. -- GPG ID: FAF7B393 GPG FP: 6D5B EF9A DD20 7580 5747 B70F 9F88 FB52 FAF7 B393 -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4589 Please log in as guest with password guest if prompted From rt at openssl.org Mon Jun 27 20:52:27 2016 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 27 Jun 2016 20:52:27 +0000 Subject: [openssl-dev] [openssl.org #2919] Incorrect return code and printing of modulus in dsa module In-Reply-To: <1353513142.13242.44.camel@arnem.softservecom.com> References: <1353513142.13242.44.camel@arnem.softservecom.com> Message-ID: The exit value was fixed some time ago (not sure). The -modulus flag is documented as printing out the public key :) -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2919 Please log in as guest with password guest if prompted From tterribe at xiph.org Mon Jun 27 20:56:50 2016 From: tterribe at xiph.org (Timothy B. Terriberry) Date: Mon, 27 Jun 2016 13:56:50 -0700 Subject: [openssl-dev] Feedback on BIO API changes in 1.1 In-Reply-To: <9fa8d87eb0684598b44831102d6274f0@usma1ex-dag1mb1.msg.corp.akamai.com> References: <57715280.1090904@xiph.org> <9fa8d87eb0684598b44831102d6274f0@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <57719312.2080504@xiph.org> Salz, Rich wrote: > This feedback is very useful. > >> 1) There is no accessor for the "num" field in the BIO struct. >> This is typically used to store a file descriptor or similar value. As can be seen >> by its explicit access in BIO_dup_chain(), there may be legitimate reasons to >> get at its value, even if you are not writing your own new BIO >> implementation. > > Can you explain when/how/why you need it? My old code was initializing this field to zero in the BIO's "create" method. I honestly don't remember why, or even if this is necessary, I just noticed the gap in the API when looking for a replacement. >> 2) The API documentation for BIO_meth_new() says that "type" should be a >> unique integer, but provides no way to ensure this is true. > > That sounds like a bug we need to fix. Perhaps something like > int BIO_meth_new_index([int flags?]) > ? Something like that would probably work. However, with the new opaque struct approach, I now create a new BIO_METHOD from scratch for every connection attempt, and don't really have a convenient place to store this value, so this will get called rather a lot unless I restructure my code to cache a value somewhere. Because I am writing a library, which I intend to be re-entrant, but which does not have any explicit threading support (or dependencies), I don't have any convenient global place to cache it. I haven't needed one for anything else. See point #3. If there was also some way to give these back when no longer needed, then at least I could ensure my code wouldn't use up the whole namespace and start failing after a few million connections. But I think even just some advice on _how_ to pick a value here would be sufficient. As long as the space is sufficiently sparse, picking a static value with reasonably low probability of colliding with anything else would be good enough for me. >> 3) I'm not sure the conversion of BIO_METHOD to an opaque struct is really a >> good idea. > > Did you see BIO_meth_set_write etc ? I did. I also saw that exactly no code in OpenSSL itself uses this API. From rsalz at akamai.com Mon Jun 27 20:57:47 2016 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 27 Jun 2016 20:57:47 +0000 Subject: [openssl-dev] [openssl.org #4589] Resolved: simplifying writing code that is 1.0.x and 1.1.x compatible In-Reply-To: References: <57719187.9020802@waldmann-edv.de> Message-ID: <0189c67d54214f39adb5006c3563dadf@usma1ex-dag1mb1.msg.corp.akamai.com> > But obviously I was expecting too much... Sorry you're not pleased. Not sure what to say -- you get what you pay for? Maybe someone will come up with a "openssl-102-compat" package? From rt at openssl.org Mon Jun 27 20:57:50 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Mon, 27 Jun 2016 20:57:50 +0000 Subject: [openssl-dev] [openssl.org #4589] Resolved: simplifying writing code that is 1.0.x and 1.1.x compatible In-Reply-To: <0189c67d54214f39adb5006c3563dadf@usma1ex-dag1mb1.msg.corp.akamai.com> References: <57719187.9020802@waldmann-edv.de> <0189c67d54214f39adb5006c3563dadf@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: > But obviously I was expecting too much... Sorry you're not pleased. Not sure what to say -- you get what you pay for? Maybe someone will come up with a "openssl-102-compat" package? -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4589 Please log in as guest with password guest if prompted From rsalz at akamai.com Mon Jun 27 20:59:28 2016 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 27 Jun 2016 20:59:28 +0000 Subject: [openssl-dev] Feedback on BIO API changes in 1.1 In-Reply-To: <57719312.2080504@xiph.org> References: <57715280.1090904@xiph.org> <9fa8d87eb0684598b44831102d6274f0@usma1ex-dag1mb1.msg.corp.akamai.com> <57719312.2080504@xiph.org> Message-ID: > > That sounds like a bug we need to fix. Perhaps something like > > int BIO_meth_new_index([int flags?]) > But I think even just some advice on _how_ to pick a value here would be > sufficient. As long as the space is sufficiently sparse, picking a static value > with reasonably low probability of colliding with anything else would be good > enough for me. Hm, perhaps like the ENGINE commands we add a few values for BIO_APP_TYPE1, etc? > I did. I also saw that exactly no code in OpenSSL itself uses this API. Yeah, RHIP :) From levitte at openssl.org Mon Jun 27 21:53:32 2016 From: levitte at openssl.org (Richard Levitte) Date: Mon, 27 Jun 2016 23:53:32 +0200 (CEST) Subject: [openssl-dev] prefer headers from source tree In-Reply-To: <576EFCAB.5010502@roumenpetrov.info> References: <576EFCAB.5010502@roumenpetrov.info> Message-ID: <20160627.235332.997959383131951805.levitte@openssl.org> Hey, good point, and good simple patch. Applied and committed to master. Cheers Richard In message <576EFCAB.5010502 at roumenpetrov.info> on Sun, 26 Jun 2016 00:50:35 +0300, Roumen Petrov said: openssl> Hello, openssl> openssl> Build of master branch fail of on command line is specified include openssl> path (-I ...) with headers from another openssl version. openssl> Please see attached openssl> "0002-make-templates-prepend-path-to-source-headers.patch" file with openssl> proposed modification of make template. openssl> Tested wilt unix build. Windows modification is similar. From matt at openssl.org Mon Jun 27 22:01:49 2016 From: matt at openssl.org (Matt Caswell) Date: Mon, 27 Jun 2016 23:01:49 +0100 Subject: [openssl-dev] Feedback on BIO API changes in 1.1 In-Reply-To: <57719312.2080504@xiph.org> References: <57715280.1090904@xiph.org> <9fa8d87eb0684598b44831102d6274f0@usma1ex-dag1mb1.msg.corp.akamai.com> <57719312.2080504@xiph.org> Message-ID: <5771A24D.5000305@openssl.org> On 27/06/16 21:56, Timothy B. Terriberry wrote: >> Did you see BIO_meth_set_write etc ? > > I did. I also saw that exactly no code in OpenSSL itself uses this API. Not strictly true. s_server uses it as does asynciotest. We also use the similar RSA_METHOD functions and DSA_METHOD functions in the engine code. Matt From rt at openssl.org Mon Jun 27 22:46:29 2016 From: rt at openssl.org (Mike Frysinger via RT) Date: Mon, 27 Jun 2016 22:46:29 +0000 Subject: [openssl-dev] [openssl.org #4593] [PATCH] pod: fix nits related to spacing around commas and assignments In-Reply-To: <1467067084-24065-1-git-send-email-vapier@gentoo.org> References: <1467067084-24065-1-git-send-email-vapier@gentoo.org> Message-ID: Also update the nit checker to catch missing spaces in prototypes as that is where the majority of errors were located. --- crypto/bn/README.pod | 10 +++++----- doc/apps/ec.pod | 2 +- doc/apps/ecparam.pod | 2 +- doc/crypto/BF_encrypt.pod | 4 ++-- doc/crypto/BIO_ctrl.pod | 12 ++++++------ doc/crypto/BIO_f_buffer.pod | 8 ++++---- doc/crypto/BIO_f_ssl.pod | 24 ++++++++++++------------ doc/crypto/BIO_find_type.pod | 2 +- doc/crypto/BIO_new.pod | 2 +- doc/crypto/BIO_push.pod | 2 +- doc/crypto/BIO_s_bio.pod | 12 ++++++------ doc/crypto/BIO_s_fd.pod | 4 ++-- doc/crypto/BIO_s_file.pod | 4 ++-- doc/crypto/BIO_s_mem.pod | 6 +++--- doc/crypto/BIO_set_callback.pod | 16 ++++++++-------- doc/crypto/BN_BLINDING_new.pod | 2 +- doc/crypto/BN_generate_prime.pod | 6 +++--- doc/crypto/DH_generate_parameters.pod | 2 +- doc/crypto/DSA_generate_parameters.pod | 2 +- doc/crypto/EVP_BytesToKey.pod | 4 ++-- doc/crypto/EVP_DigestInit.pod | 4 ++-- doc/crypto/EVP_OpenInit.pod | 4 ++-- doc/crypto/EVP_PKEY_encrypt.pod | 2 +- doc/crypto/EVP_PKEY_keygen.pod | 12 ++++++------ doc/crypto/EVP_PKEY_set1_RSA.pod | 16 ++++++++-------- doc/crypto/EVP_SignInit.pod | 2 +- doc/crypto/EVP_VerifyInit.pod | 2 +- doc/crypto/OPENSSL_LH_COMPFUNC.pod | 2 +- doc/crypto/RSA_generate_key.pod | 2 +- doc/crypto/RSA_get0_key.pod | 2 +- doc/crypto/X509_NAME_ENTRY_get_object.pod | 2 +- doc/crypto/X509_NAME_add_entry_by_txt.pod | 2 +- doc/crypto/X509_NAME_get_index_by_NID.pod | 8 ++++---- doc/crypto/X509_NAME_print_ex.pod | 2 +- doc/crypto/X509_STORE_CTX_new.pod | 2 +- doc/crypto/X509_STORE_CTX_set_verify_cb.pod | 22 +++++++++++----------- doc/ssl/SSL_CTX_set_cert_verify_callback.pod | 2 +- doc/ssl/SSL_CTX_set_client_CA_list.pod | 2 +- doc/ssl/SSL_CTX_set_info_callback.pod | 22 +++++++++++----------- doc/ssl/SSL_CTX_set_read_ahead.pod | 4 ++-- doc/ssl/SSL_CTX_set_split_send_fragment.pod | 24 ++++++++++++------------ doc/ssl/SSL_CTX_set_tlsext_ticket_key_cb.pod | 2 +- doc/ssl/SSL_CTX_set_verify.pod | 2 +- doc/ssl/SSL_CTX_use_certificate.pod | 2 +- doc/ssl/SSL_get_current_cipher.pod | 4 ++-- doc/ssl/ssl.pod | 4 ++-- util/find-doc-nits.pl | 4 ++++ 47 files changed, 144 insertions(+), 140 deletions(-) diff --git a/crypto/bn/README.pod b/crypto/bn/README.pod index 07e72aa2c5d9..109ab0d91428 100644 --- a/crypto/bn/README.pod +++ b/crypto/bn/README.pod @@ -36,9 +36,9 @@ library internal functions int nb); void bn_mul_low_normal(BN_ULONG *r, BN_ULONG *a, BN_ULONG *b, int n); void bn_mul_recursive(BN_ULONG *r, BN_ULONG *a, BN_ULONG *b, int n2, - int dna,int dnb,BN_ULONG *tmp); + int dna, int dnb, BN_ULONG *tmp); void bn_mul_part_recursive(BN_ULONG *r, BN_ULONG *a, BN_ULONG *b, - int n, int tna,int tnb, BN_ULONG *tmp); + int n, int tna, int tnb, BN_ULONG *tmp); void bn_mul_low_recursive(BN_ULONG *r, BN_ULONG *a, BN_ULONG *b, int n2, BN_ULONG *tmp); void bn_mul_high(BN_ULONG *r, BN_ULONG *a, BN_ULONG *b, BN_ULONG *l, @@ -96,8 +96,8 @@ bn.top=1. B is 1 if the number is negative. When a B is B<0>, the B field can be B and B == B<0>. B is a bit field of flags which are defined in C. The -flags begin with B. The macros BN_set_flags(b,n) and -BN_get_flags(b,n) exist to enable or fetch flag(s) B from B +flags begin with B. The macros BN_set_flags(b, n) and +BN_get_flags(b, n) exist to enable or fetch flag(s) B from B structure B. Various routines in this library require the use of temporary @@ -124,7 +124,7 @@ bn_sqr_words(B, B, B) operates on the B word array B and the 2*B word array B. It computes B * B word-wise, and places the low and high bytes of the result in B. -bn_div_words(B, B, B) divides the two word number (B,B) +bn_div_words(B, B, B) divides the two word number (B, B) by B and returns the result. bn_add_words(B, B, B, B) operates on the B word diff --git a/doc/apps/ec.pod b/doc/apps/ec.pod index 10c5e859aac9..758709f081dd 100644 --- a/doc/apps/ec.pod +++ b/doc/apps/ec.pod @@ -132,7 +132,7 @@ Possible value are: B, i.e. the ec parameters are specified by an OID, or B where the ec parameters are explicitly given (see RFC 3279 for the definition of the EC parameters structures). The default value is B. -B the B alternative ,as specified in RFC 3279, +B the B alternative, as specified in RFC 3279, is currently not implemented in OpenSSL. =item B<-no_public> diff --git a/doc/apps/ecparam.pod b/doc/apps/ecparam.pod index e55322c9b5e7..51678964031d 100644 --- a/doc/apps/ecparam.pod +++ b/doc/apps/ecparam.pod @@ -104,7 +104,7 @@ Possible value are: B, i.e. the ec parameters are specified by an OID, or B where the ec parameters are explicitly given (see RFC 3279 for the definition of the EC parameters structures). The default value is B. -B the B alternative ,as specified in RFC 3279, +B the B alternative, as specified in RFC 3279, is currently not implemented in OpenSSL. =item B<-no_seed> diff --git a/doc/crypto/BF_encrypt.pod b/doc/crypto/BF_encrypt.pod index 6d8cf1fdb438..0401e90a20e7 100644 --- a/doc/crypto/BF_encrypt.pod +++ b/doc/crypto/BF_encrypt.pod @@ -22,8 +22,8 @@ BF_cfb64_encrypt, BF_ofb64_encrypt, BF_options - Blowfish encryption long length, BF_KEY *schedule, unsigned char *ivec, int *num); const char *BF_options(void); - void BF_encrypt(BF_LONG *data,const BF_KEY *key); - void BF_decrypt(BF_LONG *data,const BF_KEY *key); + void BF_encrypt(BF_LONG *data, const BF_KEY *key); + void BF_decrypt(BF_LONG *data, const BF_KEY *key); =head1 DESCRIPTION diff --git a/doc/crypto/BIO_ctrl.pod b/doc/crypto/BIO_ctrl.pod index d6d0df1c5a1c..00c47a34eb7c 100644 --- a/doc/crypto/BIO_ctrl.pod +++ b/doc/crypto/BIO_ctrl.pod @@ -11,25 +11,25 @@ BIO_get_info_callback, BIO_set_info_callback - BIO control operations #include - long BIO_ctrl(BIO *bp,int cmd,long larg,void *parg); + long BIO_ctrl(BIO *bp, int cmd, long larg, void *parg); long BIO_callback_ctrl(BIO *b, int cmd, void (*fp)(struct bio_st *, int, const char *, int, long, long)); - char * BIO_ptr_ctrl(BIO *bp,int cmd,long larg); - long BIO_int_ctrl(BIO *bp,int cmd,long larg,int iarg); + char * BIO_ptr_ctrl(BIO *bp, int cmd, long larg); + long BIO_int_ctrl(BIO *bp, int cmd, long larg, int iarg); int BIO_reset(BIO *b); int BIO_seek(BIO *b, int ofs); int BIO_tell(BIO *b); int BIO_flush(BIO *b); int BIO_eof(BIO *b); - int BIO_set_close(BIO *b,long flag); + int BIO_set_close(BIO *b, long flag); int BIO_get_close(BIO *b); int BIO_pending(BIO *b); int BIO_wpending(BIO *b); size_t BIO_ctrl_pending(BIO *b); size_t BIO_ctrl_wpending(BIO *b); - int BIO_get_info_callback(BIO *b,bio_info_cb **cbp); - int BIO_set_info_callback(BIO *b,bio_info_cb *cb); + int BIO_get_info_callback(BIO *b, bio_info_cb **cbp); + int BIO_set_info_callback(BIO *b, bio_info_cb *cb); typedef void bio_info_cb(BIO *b, int oper, const char *ptr, int arg1, long arg2, long arg3); diff --git a/doc/crypto/BIO_f_buffer.pod b/doc/crypto/BIO_f_buffer.pod index 286a39c9ed43..486d1e6b425f 100644 --- a/doc/crypto/BIO_f_buffer.pod +++ b/doc/crypto/BIO_f_buffer.pod @@ -16,10 +16,10 @@ BIO_f_buffer - buffering BIO const BIO_METHOD * BIO_f_buffer(void); #define BIO_get_buffer_num_lines(b) - #define BIO_set_read_buffer_size(b,size) - #define BIO_set_write_buffer_size(b,size) - #define BIO_set_buffer_size(b,size) - #define BIO_set_buffer_read_data(b,buf,num) + #define BIO_set_read_buffer_size(b, size) + #define BIO_set_write_buffer_size(b, size) + #define BIO_set_buffer_size(b, size) + #define BIO_set_buffer_read_data(b, buf, num) =head1 DESCRIPTION diff --git a/doc/crypto/BIO_f_ssl.pod b/doc/crypto/BIO_f_ssl.pod index 40071301501a..45f9e0017bf7 100644 --- a/doc/crypto/BIO_f_ssl.pod +++ b/doc/crypto/BIO_f_ssl.pod @@ -18,23 +18,23 @@ BIO_ssl_shutdown - SSL BIO const BIO_METHOD *BIO_f_ssl(void); - #define BIO_set_ssl(b,ssl,c) BIO_ctrl(b,BIO_C_SET_SSL,c,(char *)ssl) - #define BIO_get_ssl(b,sslp) BIO_ctrl(b,BIO_C_GET_SSL,0,(char *)sslp) - #define BIO_set_ssl_mode(b,client) BIO_ctrl(b,BIO_C_SSL_MODE,client,NULL) - #define BIO_set_ssl_renegotiate_bytes(b,num) \ - BIO_ctrl(b,BIO_C_SET_SSL_RENEGOTIATE_BYTES,num,NULL); - #define BIO_set_ssl_renegotiate_timeout(b,seconds) \ - BIO_ctrl(b,BIO_C_SET_SSL_RENEGOTIATE_TIMEOUT,seconds,NULL); + #define BIO_set_ssl(b, ssl, c) BIO_ctrl(b, BIO_C_SET_SSL, c, (char *)ssl) + #define BIO_get_ssl(b, sslp) BIO_ctrl(b, BIO_C_GET_SSL, 0, (char *)sslp) + #define BIO_set_ssl_mode(b, client) BIO_ctrl(b, BIO_C_SSL_MODE, client, NULL) + #define BIO_set_ssl_renegotiate_bytes(b, num) \ + BIO_ctrl(b, BIO_C_SET_SSL_RENEGOTIATE_BYTES, num, NULL) + #define BIO_set_ssl_renegotiate_timeout(b, seconds) \ + BIO_ctrl(b, BIO_C_SET_SSL_RENEGOTIATE_TIMEOUT, seconds, NULL) #define BIO_get_num_renegotiates(b) \ - BIO_ctrl(b,BIO_C_SET_SSL_NUM_RENEGOTIATES,0,NULL); + BIO_ctrl(b, BIO_C_SET_SSL_NUM_RENEGOTIATES, 0, NULL) - BIO *BIO_new_ssl(SSL_CTX *ctx,int client); + BIO *BIO_new_ssl(SSL_CTX *ctx, int client); BIO *BIO_new_ssl_connect(SSL_CTX *ctx); BIO *BIO_new_buffer_ssl_connect(SSL_CTX *ctx); - int BIO_ssl_copy_session_id(BIO *to,BIO *from); + int BIO_ssl_copy_session_id(BIO *to, BIO *from); void BIO_ssl_shutdown(BIO *bio); - #define BIO_do_handshake(b) BIO_ctrl(b,BIO_C_DO_STATE_MACHINE,0,NULL) + #define BIO_do_handshake(b) BIO_ctrl(b, BIO_C_DO_STATE_MACHINE, 0, NULL) =head1 DESCRIPTION @@ -211,7 +211,7 @@ a client and also echoes the request to standard output. /* XXX Other things like set verify locations, EDH temp callbacks. */ /* New SSL BIO setup as server */ - sbio = BIO_new_ssl(ctx,0); + sbio = BIO_new_ssl(ctx, 0); BIO_get_ssl(sbio, &ssl); if (ssl == NULL) { fprintf(stderr, "Can't locate SSL pointer\n"); diff --git a/doc/crypto/BIO_find_type.pod b/doc/crypto/BIO_find_type.pod index f03071ad9b25..fa7f2830a48e 100644 --- a/doc/crypto/BIO_find_type.pod +++ b/doc/crypto/BIO_find_type.pod @@ -14,7 +14,7 @@ BIO_find_type, BIO_next, BIO_method_type - BIO chain traversal #include - BIO * BIO_find_type(BIO *b,int bio_type); + BIO * BIO_find_type(BIO *b, int bio_type); BIO * BIO_next(BIO *b); #define BIO_method_type(b) ((b)->method->type) diff --git a/doc/crypto/BIO_new.pod b/doc/crypto/BIO_new.pod index 8e42e650a21e..226f13feef96 100644 --- a/doc/crypto/BIO_new.pod +++ b/doc/crypto/BIO_new.pod @@ -9,7 +9,7 @@ BIO_new, BIO_set, BIO_up_ref, BIO_free, BIO_vfree, BIO_free_all - BIO allocation #include BIO * BIO_new(const BIO_METHOD *type); - int BIO_set(BIO *a,const BIO_METHOD *type); + int BIO_set(BIO *a, const BIO_METHOD *type); int BIO_up_ref(BIO *a); int BIO_free(BIO *a); void BIO_vfree(BIO *a); diff --git a/doc/crypto/BIO_push.pod b/doc/crypto/BIO_push.pod index cb19c0b3bab3..762027ff6a98 100644 --- a/doc/crypto/BIO_push.pod +++ b/doc/crypto/BIO_push.pod @@ -8,7 +8,7 @@ BIO_push, BIO_pop, BIO_set_next - add and remove BIOs from a chain #include - BIO *BIO_push(BIO *b,BIO *append); + BIO *BIO_push(BIO *b, BIO *append); BIO *BIO_pop(BIO *b); void BIO_set_next(BIO *b, BIO *next); diff --git a/doc/crypto/BIO_s_bio.pod b/doc/crypto/BIO_s_bio.pod index fb661979d8eb..c29f5c2a6851 100644 --- a/doc/crypto/BIO_s_bio.pod +++ b/doc/crypto/BIO_s_bio.pod @@ -13,20 +13,20 @@ BIO_ctrl_get_read_request, BIO_ctrl_reset_read_request - BIO pair BIO const BIO_METHOD *BIO_s_bio(void); - #define BIO_make_bio_pair(b1,b2) (int)BIO_ctrl(b1,BIO_C_MAKE_BIO_PAIR,0,b2) - #define BIO_destroy_bio_pair(b) (int)BIO_ctrl(b,BIO_C_DESTROY_BIO_PAIR,0,NULL) + #define BIO_make_bio_pair(b1, b2) (int)BIO_ctrl(b1, BIO_C_MAKE_BIO_PAIR, 0, b2) + #define BIO_destroy_bio_pair(b) (int)BIO_ctrl(b, BIO_C_DESTROY_BIO_PAIR, 0, NULL) #define BIO_shutdown_wr(b) (int)BIO_ctrl(b, BIO_C_SHUTDOWN_WR, 0, NULL) - #define BIO_set_write_buf_size(b,size) (int)BIO_ctrl(b,BIO_C_SET_WRITE_BUF_SIZE,size,NULL) - #define BIO_get_write_buf_size(b,size) (size_t)BIO_ctrl(b,BIO_C_GET_WRITE_BUF_SIZE,size,NULL) + #define BIO_set_write_buf_size(b, size) (int)BIO_ctrl(b, BIO_C_SET_WRITE_BUF_SIZE, size, NULL) + #define BIO_get_write_buf_size(b, size) (size_t)BIO_ctrl(b, BIO_C_GET_WRITE_BUF_SIZE, size, NULL) int BIO_new_bio_pair(BIO **bio1, size_t writebuf1, BIO **bio2, size_t writebuf2); - #define BIO_get_write_guarantee(b) (int)BIO_ctrl(b,BIO_C_GET_WRITE_GUARANTEE,0,NULL) + #define BIO_get_write_guarantee(b) (int)BIO_ctrl(b, BIO_C_GET_WRITE_GUARANTEE, 0, NULL) size_t BIO_ctrl_get_write_guarantee(BIO *b); - #define BIO_get_read_request(b) (int)BIO_ctrl(b,BIO_C_GET_READ_REQUEST,0,NULL) + #define BIO_get_read_request(b) (int)BIO_ctrl(b, BIO_C_GET_READ_REQUEST, 0, NULL) size_t BIO_ctrl_get_read_request(BIO *b); int BIO_ctrl_reset_read_request(BIO *b); diff --git a/doc/crypto/BIO_s_fd.pod b/doc/crypto/BIO_s_fd.pod index 8002ad7754f3..5f5ce6c2db9f 100644 --- a/doc/crypto/BIO_s_fd.pod +++ b/doc/crypto/BIO_s_fd.pod @@ -10,8 +10,8 @@ BIO_s_fd, BIO_set_fd, BIO_get_fd, BIO_new_fd - file descriptor BIO const BIO_METHOD * BIO_s_fd(void); - #define BIO_set_fd(b,fd,c) BIO_int_ctrl(b,BIO_C_SET_FD,c,fd) - #define BIO_get_fd(b,c) BIO_ctrl(b,BIO_C_GET_FD,0,(char *)c) + #define BIO_set_fd(b, fd, c) BIO_int_ctrl(b, BIO_C_SET_FD, c, fd) + #define BIO_get_fd(b, c) BIO_ctrl(b, BIO_C_GET_FD, 0, (char *)c) BIO *BIO_new_fd(int fd, int close_flag); diff --git a/doc/crypto/BIO_s_file.pod b/doc/crypto/BIO_s_file.pod index 5eb564d8eb50..848586754c0b 100644 --- a/doc/crypto/BIO_s_file.pod +++ b/doc/crypto/BIO_s_file.pod @@ -14,8 +14,8 @@ BIO_rw_filename - FILE bio BIO *BIO_new_file(const char *filename, const char *mode); BIO *BIO_new_fp(FILE *stream, int flags); - BIO_set_fp(BIO *b,FILE *fp, int flags); - BIO_get_fp(BIO *b,FILE **fpp); + BIO_set_fp(BIO *b, FILE *fp, int flags); + BIO_get_fp(BIO *b, FILE **fpp); int BIO_read_filename(BIO *b, char *name) int BIO_write_filename(BIO *b, char *name) diff --git a/doc/crypto/BIO_s_mem.pod b/doc/crypto/BIO_s_mem.pod index afde930906e7..b272c410a089 100644 --- a/doc/crypto/BIO_s_mem.pod +++ b/doc/crypto/BIO_s_mem.pod @@ -13,10 +13,10 @@ BIO_get_mem_ptr, BIO_new_mem_buf - memory BIO const BIO_METHOD * BIO_s_mem(void); const BIO_METHOD * BIO_s_secmem(void); - BIO_set_mem_eof_return(BIO *b,int v) + BIO_set_mem_eof_return(BIO *b, int v) long BIO_get_mem_data(BIO *b, char **pp) - BIO_set_mem_buf(BIO *b,BUF_MEM *bm,int c) - BIO_get_mem_ptr(BIO *b,BUF_MEM **pp) + BIO_set_mem_buf(BIO *b, BUF_MEM *bm, int c) + BIO_get_mem_ptr(BIO *b, BUF_MEM **pp) BIO *BIO_new_mem_buf(const void *buf, int len); diff --git a/doc/crypto/BIO_set_callback.pod b/doc/crypto/BIO_set_callback.pod index 219a6dd3ebda..26a99e844ec3 100644 --- a/doc/crypto/BIO_set_callback.pod +++ b/doc/crypto/BIO_set_callback.pod @@ -9,16 +9,16 @@ BIO_debug_callback - BIO callback functions #include - #define BIO_set_callback(b,cb) ((b)->callback=(cb)) + #define BIO_set_callback(b, cb) ((b)->callback = (cb)) #define BIO_get_callback(b) ((b)->callback) - #define BIO_set_callback_arg(b,arg) ((b)->cb_arg=(char *)(arg)) - #define BIO_get_callback_arg(b) ((b)->cb_arg) + #define BIO_set_callback_arg(b, arg) ((b)->cb_arg = (char *)(arg)) + #define BIO_get_callback_arg(b) ((b)->cb_arg) - long BIO_debug_callback(BIO *bio,int cmd,const char *argp,int argi, - long argl,long ret); + long BIO_debug_callback(BIO *bio, int cmd, const char *argp, int argi, + long argl, long ret); typedef long (*callback)(BIO *b, int oper, const char *argp, - int argi, long argl, long retvalue); + int argi, long argl, long retvalue); =head1 DESCRIPTION @@ -93,8 +93,8 @@ after. =item B -callback(b,BIO_CB_CTRL,parg,cmd,larg,1L) is called before the call and -callback(b,BIO_CB_CTRL|BIO_CB_RETURN,parg,cmd, larg,ret) after. +callback(b, BIO_CB_CTRL, parg, cmd, larg, 1L) is called before the call and +callback(b, BIO_CB_CTRL|BIO_CB_RETURN, parg, cmd, larg, ret) after. =back diff --git a/doc/crypto/BN_BLINDING_new.pod b/doc/crypto/BN_BLINDING_new.pod index 754bcf3c3abe..5f56aa3fc93b 100644 --- a/doc/crypto/BN_BLINDING_new.pod +++ b/doc/crypto/BN_BLINDING_new.pod @@ -15,7 +15,7 @@ BN_BLINDING_set_flags, BN_BLINDING_create_param - blinding related BIGNUM functi BN_BLINDING *BN_BLINDING_new(const BIGNUM *A, const BIGNUM *Ai, BIGNUM *mod); void BN_BLINDING_free(BN_BLINDING *b); - int BN_BLINDING_update(BN_BLINDING *b,BN_CTX *ctx); + int BN_BLINDING_update(BN_BLINDING *b, BN_CTX *ctx); int BN_BLINDING_convert(BIGNUM *n, BN_BLINDING *b, BN_CTX *ctx); int BN_BLINDING_invert(BIGNUM *n, BN_BLINDING *b, BN_CTX *ctx); int BN_BLINDING_convert_ex(BIGNUM *n, BIGNUM *r, BN_BLINDING *b, diff --git a/doc/crypto/BN_generate_prime.pod b/doc/crypto/BN_generate_prime.pod index 2757448c6a70..0472b9b829ae 100644 --- a/doc/crypto/BN_generate_prime.pod +++ b/doc/crypto/BN_generate_prime.pod @@ -11,12 +11,12 @@ for primality #include - int BN_generate_prime_ex(BIGNUM *ret,int bits,int safe, const BIGNUM *add, + int BN_generate_prime_ex(BIGNUM *ret, int bits, int safe, const BIGNUM *add, const BIGNUM *rem, BN_GENCB *cb); - int BN_is_prime_ex(const BIGNUM *p,int nchecks, BN_CTX *ctx, BN_GENCB *cb); + int BN_is_prime_ex(const BIGNUM *p, int nchecks, BN_CTX *ctx, BN_GENCB *cb); - int BN_is_prime_fasttest_ex(const BIGNUM *p,int nchecks, BN_CTX *ctx, + int BN_is_prime_fasttest_ex(const BIGNUM *p, int nchecks, BN_CTX *ctx, int do_trial_division, BN_GENCB *cb); int BN_GENCB_call(BN_GENCB *cb, int a, int b); diff --git a/doc/crypto/DH_generate_parameters.pod b/doc/crypto/DH_generate_parameters.pod index 8970aae444f3..b71497baaf12 100644 --- a/doc/crypto/DH_generate_parameters.pod +++ b/doc/crypto/DH_generate_parameters.pod @@ -9,7 +9,7 @@ DH_check - generate and check Diffie-Hellman parameters #include - int DH_generate_parameters_ex(DH *dh, int prime_len,int generator, BN_GENCB *cb); + int DH_generate_parameters_ex(DH *dh, int prime_len, int generator, BN_GENCB *cb); int DH_check(DH *dh, int *codes); diff --git a/doc/crypto/DSA_generate_parameters.pod b/doc/crypto/DSA_generate_parameters.pod index 87e4eff055dc..ca2c2ce7bb41 100644 --- a/doc/crypto/DSA_generate_parameters.pod +++ b/doc/crypto/DSA_generate_parameters.pod @@ -9,7 +9,7 @@ DSA_generate_parameters_ex, DSA_generate_parameters - generate DSA parameters #include int DSA_generate_parameters_ex(DSA *dsa, int bits, - const unsigned char *seed,int seed_len, + const unsigned char *seed, int seed_len, int *counter_ret, unsigned long *h_ret, BN_GENCB *cb); Deprecated: diff --git a/doc/crypto/EVP_BytesToKey.pod b/doc/crypto/EVP_BytesToKey.pod index 003afb27e8e7..18fc9ca909ec 100644 --- a/doc/crypto/EVP_BytesToKey.pod +++ b/doc/crypto/EVP_BytesToKey.pod @@ -8,10 +8,10 @@ EVP_BytesToKey - password based encryption routine #include - int EVP_BytesToKey(const EVP_CIPHER *type,const EVP_MD *md, + int EVP_BytesToKey(const EVP_CIPHER *type, const EVP_MD *md, const unsigned char *salt, const unsigned char *data, int datal, int count, - unsigned char *key,unsigned char *iv); + unsigned char *key, unsigned char *iv); =head1 DESCRIPTION diff --git a/doc/crypto/EVP_DigestInit.pod b/doc/crypto/EVP_DigestInit.pod index 405810ee242e..39b893e4ee77 100644 --- a/doc/crypto/EVP_DigestInit.pod +++ b/doc/crypto/EVP_DigestInit.pod @@ -24,13 +24,13 @@ EVP_get_digestbynid, EVP_get_digestbyobj - EVP digest routines int EVP_DigestFinal_ex(EVP_MD_CTX *ctx, unsigned char *md, unsigned int *s); - int EVP_MD_CTX_copy_ex(EVP_MD_CTX *out,const EVP_MD_CTX *in); + int EVP_MD_CTX_copy_ex(EVP_MD_CTX *out, const EVP_MD_CTX *in); int EVP_DigestInit(EVP_MD_CTX *ctx, const EVP_MD *type); int EVP_DigestFinal(EVP_MD_CTX *ctx, unsigned char *md, unsigned int *s); - int EVP_MD_CTX_copy(EVP_MD_CTX *out,EVP_MD_CTX *in); + int EVP_MD_CTX_copy(EVP_MD_CTX *out, EVP_MD_CTX *in); #define EVP_MAX_MD_SIZE 64 /* SHA512 */ diff --git a/doc/crypto/EVP_OpenInit.pod b/doc/crypto/EVP_OpenInit.pod index 293b4eb398c4..ff84490a424e 100644 --- a/doc/crypto/EVP_OpenInit.pod +++ b/doc/crypto/EVP_OpenInit.pod @@ -8,8 +8,8 @@ EVP_OpenInit, EVP_OpenUpdate, EVP_OpenFinal - EVP envelope decryption #include - int EVP_OpenInit(EVP_CIPHER_CTX *ctx,EVP_CIPHER *type,unsigned char *ek, - int ekl,unsigned char *iv,EVP_PKEY *priv); + int EVP_OpenInit(EVP_CIPHER_CTX *ctx, EVP_CIPHER *type, unsigned char *ek, + int ekl, unsigned char *iv, EVP_PKEY *priv); int EVP_OpenUpdate(EVP_CIPHER_CTX *ctx, unsigned char *out, int *outl, unsigned char *in, int inl); int EVP_OpenFinal(EVP_CIPHER_CTX *ctx, unsigned char *out, diff --git a/doc/crypto/EVP_PKEY_encrypt.pod b/doc/crypto/EVP_PKEY_encrypt.pod index d75f3f22cd93..01336e128b02 100644 --- a/doc/crypto/EVP_PKEY_encrypt.pod +++ b/doc/crypto/EVP_PKEY_encrypt.pod @@ -59,7 +59,7 @@ set 'eng = NULL;' to start with the default OpenSSL RSA implementation: /* NB: assumes eng, key, in, inlen are already set up, * and that key is an RSA public key */ - ctx = EVP_PKEY_CTX_new(key,eng); + ctx = EVP_PKEY_CTX_new(key, eng); if (!ctx) /* Error occurred */ if (EVP_PKEY_encrypt_init(ctx) <= 0) diff --git a/doc/crypto/EVP_PKEY_keygen.pod b/doc/crypto/EVP_PKEY_keygen.pod index cebd95b5a11c..f203e9ebe606 100644 --- a/doc/crypto/EVP_PKEY_keygen.pod +++ b/doc/crypto/EVP_PKEY_keygen.pod @@ -134,15 +134,15 @@ Example of generation callback for OpenSSL public key implementations: static int genpkey_cb(EVP_PKEY_CTX *ctx) { - char c='*'; + char c ='*'; BIO *b = EVP_PKEY_CTX_get_app_data(ctx); int p; p = EVP_PKEY_CTX_get_keygen_info(ctx, 0); - if (p == 0) c='.'; - if (p == 1) c='+'; - if (p == 2) c='*'; - if (p == 3) c='\n'; - BIO_write(b,&c,1); + if (p == 0) c = '.'; + if (p == 1) c = '+'; + if (p == 2) c = '*'; + if (p == 3) c = '\n'; + BIO_write(b, &c, 1); (void)BIO_flush(b); return 1; } diff --git a/doc/crypto/EVP_PKEY_set1_RSA.pod b/doc/crypto/EVP_PKEY_set1_RSA.pod index 1498df7413b8..e1b7110fe516 100644 --- a/doc/crypto/EVP_PKEY_set1_RSA.pod +++ b/doc/crypto/EVP_PKEY_set1_RSA.pod @@ -14,10 +14,10 @@ EVP_PKEY_type, EVP_PKEY_id, EVP_PKEY_base_id #include - int EVP_PKEY_set1_RSA(EVP_PKEY *pkey,RSA *key); - int EVP_PKEY_set1_DSA(EVP_PKEY *pkey,DSA *key); - int EVP_PKEY_set1_DH(EVP_PKEY *pkey,DH *key); - int EVP_PKEY_set1_EC_KEY(EVP_PKEY *pkey,EC_KEY *key); + int EVP_PKEY_set1_RSA(EVP_PKEY *pkey, RSA *key); + int EVP_PKEY_set1_DSA(EVP_PKEY *pkey, DSA *key); + int EVP_PKEY_set1_DH(EVP_PKEY *pkey, DH *key); + int EVP_PKEY_set1_EC_KEY(EVP_PKEY *pkey, EC_KEY *key); RSA *EVP_PKEY_get1_RSA(EVP_PKEY *pkey); DSA *EVP_PKEY_get1_DSA(EVP_PKEY *pkey); @@ -30,10 +30,10 @@ EVP_PKEY_type, EVP_PKEY_id, EVP_PKEY_base_id DH *EVP_PKEY_get0_DH(EVP_PKEY *pkey); EC_KEY *EVP_PKEY_get0_EC_KEY(EVP_PKEY *pkey); - int EVP_PKEY_assign_RSA(EVP_PKEY *pkey,RSA *key); - int EVP_PKEY_assign_DSA(EVP_PKEY *pkey,DSA *key); - int EVP_PKEY_assign_DH(EVP_PKEY *pkey,DH *key); - int EVP_PKEY_assign_EC_KEY(EVP_PKEY *pkey,EC_KEY *key); + int EVP_PKEY_assign_RSA(EVP_PKEY *pkey, RSA *key); + int EVP_PKEY_assign_DSA(EVP_PKEY *pkey, DSA *key); + int EVP_PKEY_assign_DH(EVP_PKEY *pkey, DH *key); + int EVP_PKEY_assign_EC_KEY(EVP_PKEY *pkey, EC_KEY *key); int EVP_PKEY_id(const EVP_PKEY *pkey); int EVP_PKEY_base_id(const EVP_PKEY *pkey); diff --git a/doc/crypto/EVP_SignInit.pod b/doc/crypto/EVP_SignInit.pod index ea4e71eb55c1..cfbfd5efd4ca 100644 --- a/doc/crypto/EVP_SignInit.pod +++ b/doc/crypto/EVP_SignInit.pod @@ -12,7 +12,7 @@ functions int EVP_SignInit_ex(EVP_MD_CTX *ctx, const EVP_MD *type, ENGINE *impl); int EVP_SignUpdate(EVP_MD_CTX *ctx, const void *d, unsigned int cnt); - int EVP_SignFinal(EVP_MD_CTX *ctx,unsigned char *sig,unsigned int *s, EVP_PKEY *pkey); + int EVP_SignFinal(EVP_MD_CTX *ctx, unsigned char *sig, unsigned int *s, EVP_PKEY *pkey); void EVP_SignInit(EVP_MD_CTX *ctx, const EVP_MD *type); diff --git a/doc/crypto/EVP_VerifyInit.pod b/doc/crypto/EVP_VerifyInit.pod index 355dc9f4099f..518c05ea0a33 100644 --- a/doc/crypto/EVP_VerifyInit.pod +++ b/doc/crypto/EVP_VerifyInit.pod @@ -12,7 +12,7 @@ EVP_VerifyInit, EVP_VerifyUpdate, EVP_VerifyFinal int EVP_VerifyInit_ex(EVP_MD_CTX *ctx, const EVP_MD *type, ENGINE *impl); int EVP_VerifyUpdate(EVP_MD_CTX *ctx, const void *d, unsigned int cnt); - int EVP_VerifyFinal(EVP_MD_CTX *ctx,unsigned char *sigbuf, unsigned int siglen,EVP_PKEY *pkey); + int EVP_VerifyFinal(EVP_MD_CTX *ctx, unsigned char *sigbuf, unsigned int siglen, EVP_PKEY *pkey); int EVP_VerifyInit(EVP_MD_CTX *ctx, const EVP_MD *type); diff --git a/doc/crypto/OPENSSL_LH_COMPFUNC.pod b/doc/crypto/OPENSSL_LH_COMPFUNC.pod index 372f0d952c16..4748346e4faa 100644 --- a/doc/crypto/OPENSSL_LH_COMPFUNC.pod +++ b/doc/crypto/OPENSSL_LH_COMPFUNC.pod @@ -74,7 +74,7 @@ as; int name##_LHASH_COMP(const void *arg1, const void *arg2) { \ const o_type *a = arg1; \ const o_type *b = arg2; \ - return name##_cmp(a,b); } + return name##_cmp(a, b); } #define LHASH_COMP_FN(name) name##_LHASH_COMP #define DECLARE_LHASH_DOALL_FN(name, o_type) \ diff --git a/doc/crypto/RSA_generate_key.pod b/doc/crypto/RSA_generate_key.pod index a8fab52cb95c..3bafc6fe27db 100644 --- a/doc/crypto/RSA_generate_key.pod +++ b/doc/crypto/RSA_generate_key.pod @@ -14,7 +14,7 @@ Deprecated: #if OPENSSL_API_COMPAT < 0x00908000L RSA *RSA_generate_key(int num, unsigned long e, - void (*callback)(int,int,void *), void *cb_arg); + void (*callback)(int, int, void *), void *cb_arg); #endif =head1 DESCRIPTION diff --git a/doc/crypto/RSA_get0_key.pod b/doc/crypto/RSA_get0_key.pod index 77e0d3b42cf2..52f83e1b907b 100644 --- a/doc/crypto/RSA_get0_key.pod +++ b/doc/crypto/RSA_get0_key.pod @@ -13,7 +13,7 @@ and setting data in an RSA object int RSA_set0_key(RSA *r, BIGNUM *n, BIGNUM *e, BIGNUM *d); int RSA_set0_factors(RSA *r, BIGNUM *p, BIGNUM *q); - int RSA_set0_crt_params(RSA *r,BIGNUM *dmp1, BIGNUM *dmq1, BIGNUM *iqmp); + int RSA_set0_crt_params(RSA *r, BIGNUM *dmp1, BIGNUM *dmq1, BIGNUM *iqmp); void RSA_get0_key(const RSA *r, const BIGNUM **n, const BIGNUM **e, const BIGNUM **d); void RSA_get0_factors(const RSA *r, const BIGNUM **p, const BIGNUM **q); diff --git a/doc/crypto/X509_NAME_ENTRY_get_object.pod b/doc/crypto/X509_NAME_ENTRY_get_object.pod index 363a89b56c5e..e47cc9487850 100644 --- a/doc/crypto/X509_NAME_ENTRY_get_object.pod +++ b/doc/crypto/X509_NAME_ENTRY_get_object.pod @@ -18,7 +18,7 @@ X509_NAME_ENTRY_create_by_OBJ - X509_NAME_ENTRY utility functions int X509_NAME_ENTRY_set_data(X509_NAME_ENTRY *ne, int type, const unsigned char *bytes, int len); X509_NAME_ENTRY *X509_NAME_ENTRY_create_by_txt(X509_NAME_ENTRY **ne, const char *field, int type, const unsigned char *bytes, int len); - X509_NAME_ENTRY *X509_NAME_ENTRY_create_by_NID(X509_NAME_ENTRY **ne, int nid, int type,unsigned char *bytes, int len); + X509_NAME_ENTRY *X509_NAME_ENTRY_create_by_NID(X509_NAME_ENTRY **ne, int nid, int type, unsigned char *bytes, int len); X509_NAME_ENTRY *X509_NAME_ENTRY_create_by_OBJ(X509_NAME_ENTRY **ne, ASN1_OBJECT *obj, int type, const unsigned char *bytes, int len); =head1 DESCRIPTION diff --git a/doc/crypto/X509_NAME_add_entry_by_txt.pod b/doc/crypto/X509_NAME_add_entry_by_txt.pod index 0b002781aab4..c89b8d52292d 100644 --- a/doc/crypto/X509_NAME_add_entry_by_txt.pod +++ b/doc/crypto/X509_NAME_add_entry_by_txt.pod @@ -15,7 +15,7 @@ X509_NAME_add_entry, X509_NAME_delete_entry - X509_NAME modification functions int X509_NAME_add_entry_by_NID(X509_NAME *name, int nid, int type, unsigned char *bytes, int len, int loc, int set); - int X509_NAME_add_entry(X509_NAME *name,X509_NAME_ENTRY *ne, int loc, int set); + int X509_NAME_add_entry(X509_NAME *name, X509_NAME_ENTRY *ne, int loc, int set); X509_NAME_ENTRY *X509_NAME_delete_entry(X509_NAME *name, int loc); diff --git a/doc/crypto/X509_NAME_get_index_by_NID.pod b/doc/crypto/X509_NAME_get_index_by_NID.pod index e84642ae11e9..1a36a99a188e 100644 --- a/doc/crypto/X509_NAME_get_index_by_NID.pod +++ b/doc/crypto/X509_NAME_get_index_by_NID.pod @@ -10,14 +10,14 @@ X509_NAME lookup and enumeration functions #include - int X509_NAME_get_index_by_NID(X509_NAME *name,int nid,int lastpos); - int X509_NAME_get_index_by_OBJ(X509_NAME *name,ASN1_OBJECT *obj, int lastpos); + int X509_NAME_get_index_by_NID(X509_NAME *name, int nid, int lastpos); + int X509_NAME_get_index_by_OBJ(X509_NAME *name, ASN1_OBJECT *obj, int lastpos); int X509_NAME_entry_count(X509_NAME *name); X509_NAME_ENTRY *X509_NAME_get_entry(X509_NAME *name, int loc); - int X509_NAME_get_text_by_NID(X509_NAME *name, int nid, char *buf,int len); - int X509_NAME_get_text_by_OBJ(X509_NAME *name, ASN1_OBJECT *obj, char *buf,int len); + int X509_NAME_get_text_by_NID(X509_NAME *name, int nid, char *buf, int len); + int X509_NAME_get_text_by_OBJ(X509_NAME *name, ASN1_OBJECT *obj, char *buf, int len); =head1 DESCRIPTION diff --git a/doc/crypto/X509_NAME_print_ex.pod b/doc/crypto/X509_NAME_print_ex.pod index 9d928245bb81..e0c21a481c22 100644 --- a/doc/crypto/X509_NAME_print_ex.pod +++ b/doc/crypto/X509_NAME_print_ex.pod @@ -11,7 +11,7 @@ X509_NAME_oneline - X509_NAME printing routines int X509_NAME_print_ex(BIO *out, X509_NAME *nm, int indent, unsigned long flags); int X509_NAME_print_ex_fp(FILE *fp, X509_NAME *nm, int indent, unsigned long flags); - char * X509_NAME_oneline(X509_NAME *a,char *buf,int size); + char * X509_NAME_oneline(X509_NAME *a, char *buf, int size); int X509_NAME_print(BIO *bp, X509_NAME *name, int obase); =head1 DESCRIPTION diff --git a/doc/crypto/X509_STORE_CTX_new.pod b/doc/crypto/X509_STORE_CTX_new.pod index 480b492eb7a3..040fa59efeab 100644 --- a/doc/crypto/X509_STORE_CTX_new.pod +++ b/doc/crypto/X509_STORE_CTX_new.pod @@ -27,7 +27,7 @@ X509_STORE_CTX_get_verify - X509_STORE_CTX initialisation void X509_STORE_CTX_set0_trusted_stack(X509_STORE_CTX *ctx, STACK_OF(X509) *sk); - void X509_STORE_CTX_set_cert(X509_STORE_CTX *ctx,X509 *x); + void X509_STORE_CTX_set_cert(X509_STORE_CTX *ctx, X509 *x); STACK_OF(X509) *X509_STORE_CTX_get0_chain(X609_STORE_CTX *ctx); void X509_STORE_CTX_set0_verified_chain(X509_STORE_CTX *ctx, STACK_OF(X509) *chain); void X509_STORE_CTX_set0_crls(X509_STORE_CTX *ctx, STACK_OF(X509_CRL) *sk); diff --git a/doc/crypto/X509_STORE_CTX_set_verify_cb.pod b/doc/crypto/X509_STORE_CTX_set_verify_cb.pod index 1305f32c59e8..57371bf286b5 100644 --- a/doc/crypto/X509_STORE_CTX_set_verify_cb.pod +++ b/doc/crypto/X509_STORE_CTX_set_verify_cb.pod @@ -106,13 +106,13 @@ B. int verify_callback(int ok, X509_STORE_CTX *ctx) { X509 *err_cert; - int err,depth; + int err, depth; err_cert = X509_STORE_CTX_get_current_cert(ctx); err = X509_STORE_CTX_get_error(ctx); depth = X509_STORE_CTX_get_error_depth(ctx); - BIO_printf(bio_err,"depth=%d ",depth); + BIO_printf(bio_err, "depth=%d ", depth); if (err_cert) { X509_NAME_print_ex(bio_err, X509_get_subject_name(err_cert), @@ -122,27 +122,27 @@ B. else BIO_puts(bio_err, "\n"); if (!ok) - BIO_printf(bio_err,"verify error:num=%d:%s\n",err, + BIO_printf(bio_err, "verify error:num=%d:%s\n", err, X509_verify_cert_error_string(err)); switch (err) { case X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT: - BIO_puts(bio_err,"issuer= "); + BIO_puts(bio_err, "issuer= "); X509_NAME_print_ex(bio_err, X509_get_issuer_name(err_cert), 0, XN_FLAG_ONELINE); BIO_puts(bio_err, "\n"); break; case X509_V_ERR_CERT_NOT_YET_VALID: case X509_V_ERR_ERROR_IN_CERT_NOT_BEFORE_FIELD: - BIO_printf(bio_err,"notBefore="); - ASN1_TIME_print(bio_err,X509_get_notBefore(err_cert)); - BIO_printf(bio_err,"\n"); + BIO_printf(bio_err, "notBefore="); + ASN1_TIME_print(bio_err, X509_get_notBefore(err_cert)); + BIO_printf(bio_err, "\n"); break; case X509_V_ERR_CERT_HAS_EXPIRED: case X509_V_ERR_ERROR_IN_CERT_NOT_AFTER_FIELD: - BIO_printf(bio_err,"notAfter="); - ASN1_TIME_print(bio_err,X509_get_notAfter(err_cert)); - BIO_printf(bio_err,"\n"); + BIO_printf(bio_err, "notAfter="); + ASN1_TIME_print(bio_err, X509_get_notAfter(err_cert)); + BIO_printf(bio_err, "\n"); break; case X509_V_ERR_NO_EXPLICIT_POLICY: policies_print(bio_err, ctx); @@ -151,7 +151,7 @@ B. if (err == X509_V_OK && ok == 2) /* print out policies */ - BIO_printf(bio_err,"verify return:%d\n",ok); + BIO_printf(bio_err, "verify return:%d\n", ok); return(ok); } diff --git a/doc/ssl/SSL_CTX_set_cert_verify_callback.pod b/doc/ssl/SSL_CTX_set_cert_verify_callback.pod index ca614d1a22b4..af303f25fa30 100644 --- a/doc/ssl/SSL_CTX_set_cert_verify_callback.pod +++ b/doc/ssl/SSL_CTX_set_cert_verify_callback.pod @@ -8,7 +8,7 @@ SSL_CTX_set_cert_verify_callback - set peer certificate verification procedure #include - void SSL_CTX_set_cert_verify_callback(SSL_CTX *ctx, int (*callback)(X509_STORE_CTX *,void *), void *arg); + void SSL_CTX_set_cert_verify_callback(SSL_CTX *ctx, int (*callback)(X509_STORE_CTX *, void *), void *arg); =head1 DESCRIPTION diff --git a/doc/ssl/SSL_CTX_set_client_CA_list.pod b/doc/ssl/SSL_CTX_set_client_CA_list.pod index 668fbbb906e8..0252e7b5216b 100644 --- a/doc/ssl/SSL_CTX_set_client_CA_list.pod +++ b/doc/ssl/SSL_CTX_set_client_CA_list.pod @@ -82,7 +82,7 @@ The operation succeeded. Scan all certificates in B and list them as acceptable CAs: - SSL_CTX_set_client_CA_list(ctx,SSL_load_client_CA_file(CAfile)); + SSL_CTX_set_client_CA_list(ctx, SSL_load_client_CA_file(CAfile)); =head1 SEE ALSO diff --git a/doc/ssl/SSL_CTX_set_info_callback.pod b/doc/ssl/SSL_CTX_set_info_callback.pod index b0e845daa235..f36f217e3bde 100644 --- a/doc/ssl/SSL_CTX_set_info_callback.pod +++ b/doc/ssl/SSL_CTX_set_info_callback.pod @@ -114,20 +114,20 @@ about alerts being handled and error messages to the B BIO. const char *str; int w; - w=where& ~SSL_ST_MASK; + w = where & ~SSL_ST_MASK; - if (w & SSL_ST_CONNECT) str="SSL_connect"; - else if (w & SSL_ST_ACCEPT) str="SSL_accept"; - else str="undefined"; + if (w & SSL_ST_CONNECT) str = "SSL_connect"; + else if (w & SSL_ST_ACCEPT) str = "SSL_accept"; + else str = "undefined"; if (where & SSL_CB_LOOP) { - BIO_printf(bio_err,"%s:%s\n",str,SSL_state_string_long(s)); + BIO_printf(bio_err, "%s:%s\n", str, SSL_state_string_long(s)); } else if (where & SSL_CB_ALERT) { - str=(where & SSL_CB_READ)?"read":"write"; - BIO_printf(bio_err,"SSL3 alert %s:%s:%s\n", + str = (where & SSL_CB_READ) ? "read" : "write"; + BIO_printf(bio_err, "SSL3 alert %s:%s:%s\n", str, SSL_alert_type_string_long(ret), SSL_alert_desc_string_long(ret)); @@ -135,12 +135,12 @@ about alerts being handled and error messages to the B BIO. else if (where & SSL_CB_EXIT) { if (ret == 0) - BIO_printf(bio_err,"%s:failed in %s\n", - str,SSL_state_string_long(s)); + BIO_printf(bio_err, "%s:failed in %s\n", + str, SSL_state_string_long(s)); else if (ret < 0) { - BIO_printf(bio_err,"%s:error in %s\n", - str,SSL_state_string_long(s)); + BIO_printf(bio_err, "%s:error in %s\n", + str, SSL_state_string_long(s)); } } } diff --git a/doc/ssl/SSL_CTX_set_read_ahead.pod b/doc/ssl/SSL_CTX_set_read_ahead.pod index d2b584d35cf8..d3082c4b999e 100644 --- a/doc/ssl/SSL_CTX_set_read_ahead.pod +++ b/doc/ssl/SSL_CTX_set_read_ahead.pod @@ -14,9 +14,9 @@ SSL_CTX_get_default_read_ahead, SSL_set_read_ahead, SSL_get_read_ahead void SSL_set_read_ahead(SSL *s, int yes); #define SSL_CTX_get_default_read_ahead(ctx) - #define SSL_CTX_set_default_read_ahead(ctx,m) + #define SSL_CTX_set_default_read_ahead(ctx, m) #define SSL_CTX_get_read_ahead(ctx) - #define SSL_CTX_set_read_ahead(ctx,m) + #define SSL_CTX_set_read_ahead(ctx, m) =head1 DESCRIPTION diff --git a/doc/ssl/SSL_CTX_set_split_send_fragment.pod b/doc/ssl/SSL_CTX_set_split_send_fragment.pod index a1f42e2eaf96..b1363e99572b 100644 --- a/doc/ssl/SSL_CTX_set_split_send_fragment.pod +++ b/doc/ssl/SSL_CTX_set_split_send_fragment.pod @@ -12,18 +12,18 @@ fragment sizes and pipelining operations #include - # define SSL_CTX_set_max_send_fragment(ctx,m) \ - SSL_CTX_ctrl(ctx,SSL_CTRL_SET_MAX_SEND_FRAGMENT,m,NULL) - # define SSL_set_max_send_fragment(ssl,m) \ - SSL_ctrl(ssl,SSL_CTRL_SET_MAX_SEND_FRAGMENT,m,NULL) - # define SSL_CTX_set_max_pipelines(ctx,m) \ - SSL_CTX_ctrl(ctx,SSL_CTRL_SET_MAX_PIPELINES,m,NULL) - # define SSL_set_max_pipelines(ssl,m) \ - SSL_ctrl(ssl,SSL_CTRL_SET_MAX_PIPELINES,m,NULL) - # define SSL_CTX_set_split_send_fragment(ctx,m) \ - SSL_CTX_ctrl(ctx,SSL_CTRL_SET_SPLIT_SEND_FRAGMENT,m,NULL) - # define SSL_set_split_send_fragment(ssl,m) \ - SSL_ctrl(ssl,SSL_CTRL_SET_SPLIT_SEND_FRAGMENT,m,NULL) + # define SSL_CTX_set_max_send_fragment(ctx, m) \ + SSL_CTX_ctrl(ctx, SSL_CTRL_SET_MAX_SEND_FRAGMENT, m, NULL) + # define SSL_set_max_send_fragment(ssl, m) \ + SSL_ctrl(ssl, SSL_CTRL_SET_MAX_SEND_FRAGMENT, m, NULL) + # define SSL_CTX_set_max_pipelines(ctx, m) \ + SSL_CTX_ctrl(ctx, SSL_CTRL_SET_MAX_PIPELINES, m, NULL) + # define SSL_set_max_pipelines(ssl, m) \ + SSL_ctrl(ssl, SSL_CTRL_SET_MAX_PIPELINES, m, NULL) + # define SSL_CTX_set_split_send_fragment(ctx, m) \ + SSL_CTX_ctrl(ctx, SSL_CTRL_SET_SPLIT_SEND_FRAGMENT, m, NULL) + # define SSL_set_split_send_fragment(ssl, m) \ + SSL_ctrl(ssl, SSL_CTRL_SET_SPLIT_SEND_FRAGMENT, m, NULL) void SSL_CTX_set_default_read_buffer_len(SSL_CTX *ctx, size_t len); void SSL_set_default_read_buffer_len(SSL *s, size_t len); diff --git a/doc/ssl/SSL_CTX_set_tlsext_ticket_key_cb.pod b/doc/ssl/SSL_CTX_set_tlsext_ticket_key_cb.pod index 5308cccdd8a8..34d8ce9ae085 100644 --- a/doc/ssl/SSL_CTX_set_tlsext_ticket_key_cb.pod +++ b/doc/ssl/SSL_CTX_set_tlsext_ticket_key_cb.pod @@ -124,7 +124,7 @@ enable an attacker to obtain the session keys. =head1 EXAMPLES Reference Implementation: - SSL_CTX_set_tlsext_ticket_key_cb(SSL,ssl_tlsext_ticket_key_cb); + SSL_CTX_set_tlsext_ticket_key_cb(SSL, ssl_tlsext_ticket_key_cb); .... static int ssl_tlsext_ticket_key_cb(SSL *s, unsigned char key_name[16], unsigned char *iv, EVP_CIPHER_CTX *ctx, HMAC_CTX *hctx, int enc) diff --git a/doc/ssl/SSL_CTX_set_verify.pod b/doc/ssl/SSL_CTX_set_verify.pod index 1afd548f48be..7d7195d9cb98 100644 --- a/doc/ssl/SSL_CTX_set_verify.pod +++ b/doc/ssl/SSL_CTX_set_verify.pod @@ -12,7 +12,7 @@ SSL_CTX_set_verify, SSL_set_verify, SSL_CTX_set_verify_depth, SSL_set_verify_dep int (*verify_callback)(int, X509_STORE_CTX *)); void SSL_set_verify(SSL *s, int mode, int (*verify_callback)(int, X509_STORE_CTX *)); - void SSL_CTX_set_verify_depth(SSL_CTX *ctx,int depth); + void SSL_CTX_set_verify_depth(SSL_CTX *ctx, int depth); void SSL_set_verify_depth(SSL *s, int depth); int verify_callback(int preverify_ok, X509_STORE_CTX *x509_ctx); diff --git a/doc/ssl/SSL_CTX_use_certificate.pod b/doc/ssl/SSL_CTX_use_certificate.pod index 748175b9959d..c645f58078e8 100644 --- a/doc/ssl/SSL_CTX_use_certificate.pod +++ b/doc/ssl/SSL_CTX_use_certificate.pod @@ -36,7 +36,7 @@ SSL_use_RSAPrivateKey_file, SSL_CTX_check_private_key, SSL_check_private_key int SSL_CTX_use_RSAPrivateKey_ASN1(SSL_CTX *ctx, unsigned char *d, long len); int SSL_CTX_use_RSAPrivateKey_file(SSL_CTX *ctx, const char *file, int type); int SSL_use_PrivateKey(SSL *ssl, EVP_PKEY *pkey); - int SSL_use_PrivateKey_ASN1(int pk,SSL *ssl, unsigned char *d, long len); + int SSL_use_PrivateKey_ASN1(int pk, SSL *ssl, unsigned char *d, long len); int SSL_use_PrivateKey_file(SSL *ssl, const char *file, int type); int SSL_use_RSAPrivateKey(SSL *ssl, RSA *rsa); int SSL_use_RSAPrivateKey_ASN1(SSL *ssl, unsigned char *d, long len); diff --git a/doc/ssl/SSL_get_current_cipher.pod b/doc/ssl/SSL_get_current_cipher.pod index 0fdf60f6c186..a5a269cc950b 100644 --- a/doc/ssl/SSL_get_current_cipher.pod +++ b/doc/ssl/SSL_get_current_cipher.pod @@ -14,8 +14,8 @@ SSL_get_cipher_bits, SSL_get_cipher_version - get SSL_CIPHER of a connection SSL_CIPHER_get_name(SSL_get_current_cipher(s)) #define SSL_get_cipher_name(s) \ SSL_CIPHER_get_name(SSL_get_current_cipher(s)) - #define SSL_get_cipher_bits(s,np) \ - SSL_CIPHER_get_bits(SSL_get_current_cipher(s),np) + #define SSL_get_cipher_bits(s, np) \ + SSL_CIPHER_get_bits(SSL_get_current_cipher(s), np) #define SSL_get_cipher_version(s) \ SSL_CIPHER_get_version(SSL_get_current_cipher(s)) diff --git a/doc/ssl/ssl.pod b/doc/ssl/ssl.pod index 589fc2dbd949..36301772e8e5 100644 --- a/doc/ssl/ssl.pod +++ b/doc/ssl/ssl.pod @@ -308,7 +308,7 @@ protocol context defined in the B structure. =item int B(SSL_CTX *ctx); -=item void B(SSL_CTX *ctx,t); +=item void B(SSL_CTX *ctx, t); =item void B(SSL_CTX *ctx, SSL_SESSION *(*cb)(SSL *ssl, unsigned char *data, int len, int *copy)); @@ -578,7 +578,7 @@ fresh handle for each connection. =item long B(const SSL *ssl); -=item int (*B(const SSL *ssl))(int,X509_STORE_CTX *) +=item int (*B(const SSL *ssl))(int, X509_STORE_CTX *) =item int B(const SSL *ssl); diff --git a/util/find-doc-nits.pl b/util/find-doc-nits.pl index ba600367f6ab..d9d16d698e60 100755 --- a/util/find-doc-nits.pl +++ b/util/find-doc-nits.pl @@ -83,6 +83,10 @@ sub name_synopsis() print "$id $sym missing from NAME section\n" unless defined $names{$sym}; $names{$sym} = 2; + + # Do some sanity checks on the prototype. + print "$id prototype missing spaces around commas: $line\n" + if ( $line =~ /[a-z0-9],[^ ]/ ); } foreach my $n ( keys %names ) { -- 2.8.2 -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4593 Please log in as guest with password guest if prompted From rt at openssl.org Tue Jun 28 01:49:21 2016 From: rt at openssl.org (123 via RT) Date: Tue, 28 Jun 2016 01:49:21 +0000 Subject: [openssl-dev] [openssl.org #4587] openssl on arm linux run err! In-Reply-To: <6dcf1d17.238d.15594b1f8eb.Coremail.peter_zor@126.com> References: <647a5741.7dab.155815e8c0d.Coremail.peter_zor@126.com> <187eb3e5.278f.1558f998460.Coremail.peter_zor@126.com> <6dcf1d17.238d.15594b1f8eb.Coremail.peter_zor@126.com> Message-ID: Hi: Makefile part I have modified the compiler to remove "- m64" option.Compile completed smoothly.According to what you say, I use the apps/in the program.Also appear a mistake, print is as follows: /mnt/flash/nfs/apps # ./openssl s_server & /mnt/flash/nfs/apps # Error setting EC curve 3069895744:error:0306E06C:bignum routines:BN_mod_inverse:no inverse:bn_gcd.c:525: 3069895744:error:0307706E:bignum routines:BN_mod_lshift_quick:input not reduced:bn_mod.c:289: 3069895744:error:1408502B:SSL routines:ssl3_ctx_ctrl:reason(43):s3_lib.c:3795: [1]+ Done(1) ./openssl s_server Also, under the x86 no problem.Now how to solve this problem? At 2016-06-28 02:42:35, "Salz, Rich via RT" wrote: >> Guess problem is caused by the CPU architecture.The same example, arm >> and x86 result is different.hope to receive your reply very much! > >Yes it probably is. > >What did you change to make it compile? > >The demo's are mostly old and broken, and in the next release most of them are gone. Looks in apps/s_client.c, for example. This is currently not likely to get fixed without a lot of detail. > >-- >Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4587 >Please log in as guest with password guest if prompted > -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4587 Please log in as guest with password guest if prompted From appro at openssl.org Tue Jun 28 11:29:57 2016 From: appro at openssl.org (Andy Polyakov) Date: Tue, 28 Jun 2016 13:29:57 +0200 Subject: [openssl-dev] arch (ARM) capabilities In-Reply-To: <57714628.4060601@openssl.org> References: <1651225.FMzIPc1M60@pintsize.usersys.redhat.com> <57714628.4060601@openssl.org> Message-ID: <57725FB5.7090405@openssl.org> >> I want something more programmatic, more general. I want to deliver >> a piece of software that will run on ARM architectures and will >> issue a warning or something like that if the user does not have an >> OpenSSL library set to work with ARM Crypto Extension. > > What does "set to work" mean? Compiled with support for ARMv8 extensions > or actually uses them? While there is no direct means to tell either, > there are indirect methods that you might find usable. To see if it's > compiled with support for ARMv8 you might be able to use dlsym to lookup > either of symbols specific to ARMv8 code. As for those subroutines > actually being used, if you trust OpenSSL capability detection, you can > simply look at /proc/cpuinfo, or replicate OpenSSL's detection. I'd say that if it is that important, then it would be more appropriate to bundle OpenSSL copy with your application. I mean if faith in system-provided code is that low, then you'd have to answer questions if you can trust that target code is actually called despite its presence and should-be-called detection. And then the only way to be sure that it works as advertised is to bundle own copy and debug it to verify that everything is in shape. From hkario at redhat.com Tue Jun 28 11:43:15 2016 From: hkario at redhat.com (Hubert Kario) Date: Tue, 28 Jun 2016 13:43:15 +0200 Subject: [openssl-dev] arch (ARM) capabilities In-Reply-To: <57714447.9000202@openssl.org> References: <1651225.FMzIPc1M60@pintsize.usersys.redhat.com> <57714447.9000202@openssl.org> Message-ID: <1740739.NPozv26IhF@pintsize.usersys.redhat.com> On Monday 27 June 2016 17:20:39 Andy Polyakov wrote: > >> Is there an option when making an app that uses OpenSSL to verify > >> that is uses Crypto Extensions (like checking a flag or something > >> like that) ? > > > > With x86_64, ciphers like aes-128-cbc are much faster with AES-NI, > > so a simple benchmark: > > > > openssl speed aes-128-cbc openssl speed -evp aes-128-cbc > > > > will tell you if the code uses hardware acceleration, as it's only > > the EVP that is accelerated. > > > > But when I've tested it on AArch64 with openssl-1.1.0-pre5 and > > current master (./configure no-shared no-engine) I'm getting > > 100524.03k vs 52172.12k/s in favour of the non-EVP version. > > > > Is that really expected? > > Depends on your system. Not all AArch64 processors were born equal, > some have crypto extensions, some don't, some have mighty pipelines, > some don't. The presented numbers suggest that you ended up on APM > X-Gene processor which doesn't. yes, it is an X-Gene, though I don't know which exact one The product briefs I could find, say that X-Genes do support cryptograpic extensions: https://myapm.apm.com/technical_documents/download/apm883208-product-brief1 -- 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 appro at openssl.org Tue Jun 28 12:35:52 2016 From: appro at openssl.org (Andy Polyakov) Date: Tue, 28 Jun 2016 14:35:52 +0200 Subject: [openssl-dev] arch (ARM) capabilities In-Reply-To: <1740739.NPozv26IhF@pintsize.usersys.redhat.com> References: <1651225.FMzIPc1M60@pintsize.usersys.redhat.com> <57714447.9000202@openssl.org> <1740739.NPozv26IhF@pintsize.usersys.redhat.com> Message-ID: <57726F28.2090703@openssl.org> >>> But when I've tested it on AArch64 with openssl-1.1.0-pre5 and >>> current master (./configure no-shared no-engine) I'm getting >>> 100524.03k vs 52172.12k/s in favour of the non-EVP version. >>> >>> Is that really expected? >> >> Depends on your system. Not all AArch64 processors were born equal, >> some have crypto extensions, some don't, some have mighty pipelines, >> some don't. The presented numbers suggest that you ended up on APM >> X-Gene processor which doesn't. > > yes, it is an X-Gene, though I don't know which exact one > > The product briefs I could find, say that X-Genes do support cryptograpic > extensions: > https://myapm.apm.com/technical_documents/download/apm883208-product-brief1 I says "APM883208-X1 *can* deliver advanced security capabilities with the *optional* security engine." Mention of "engine" and then algorithm list suggests that it's kind of embedded peripheral, which would appear to user-land as device. While what we are talking about here is AES-NI equivalent for ARMv8, i.e. ARM *instruction* set extension directly accessible to user-land. Availability of this extension is normally reflected in Features: in /proc/cpuinfo. From cata.vasile at nxp.com Tue Jun 28 12:38:20 2016 From: cata.vasile at nxp.com (Catalin Vasile) Date: Tue, 28 Jun 2016 12:38:20 +0000 Subject: [openssl-dev] global OpenSSL symbols in user apps Message-ID: Hi, Is there a way to use global non-API functions or variables in user apps? For example: Is there a way to use OpenSSL_armcap_P in your user apps? I tried declaring it as "extern" variable, but at linking the linker says it cannot find the symbol. Cata From levitte at openssl.org Tue Jun 28 13:41:01 2016 From: levitte at openssl.org (Richard Levitte) Date: Tue, 28 Jun 2016 15:41:01 +0200 (CEST) Subject: [openssl-dev] global OpenSSL symbols in user apps In-Reply-To: References: Message-ID: <20160628.154101.27249018672015008.levitte@openssl.org> In message on Tue, 28 Jun 2016 12:38:20 +0000, Catalin Vasile said: cata.vasile> Hi, cata.vasile> cata.vasile> Is there a way to use global non-API functions or variables in user apps? cata.vasile> For example: Is there a way to use OpenSSL_armcap_P in your user apps? I tried declaring it as "extern" variable, but at linking the linker says it cannot find the symbol. Generally speaking: no. Practically speaking, it depends. Provided we're talking about shared libraries, it's a definite "no" on Windows, VMS, Linux and Solaris (the list of Unix platforms are likely to expand) because the non-public symbols aren't made available. If we're talking about static libraries, no symbols are hidden. I would *not* recommend fiddling with the non-public symbols. You may be safe in one OpenSSL version, but you cannot know what's happening with them in the next. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From hkario at redhat.com Tue Jun 28 13:45:58 2016 From: hkario at redhat.com (Hubert Kario) Date: Tue, 28 Jun 2016 15:45:58 +0200 Subject: [openssl-dev] arch (ARM) capabilities In-Reply-To: <57726F28.2090703@openssl.org> References: <1740739.NPozv26IhF@pintsize.usersys.redhat.com> <57726F28.2090703@openssl.org> Message-ID: <1979101.rdzpD9Q2nr@pintsize.usersys.redhat.com> On Tuesday 28 June 2016 14:35:52 Andy Polyakov wrote: > >>> But when I've tested it on AArch64 with openssl-1.1.0-pre5 and > >>> current master (./configure no-shared no-engine) I'm getting > >>> 100524.03k vs 52172.12k/s in favour of the non-EVP version. > >>> > >>> Is that really expected? > >> > >> Depends on your system. Not all AArch64 processors were born equal, > >> some have crypto extensions, some don't, some have mighty pipelines, > >> some don't. The presented numbers suggest that you ended up on APM > >> X-Gene processor which doesn't. > > > > yes, it is an X-Gene, though I don't know which exact one > > > > The product briefs I could find, say that X-Genes do support cryptograpic > > extensions: > > https://myapm.apm.com/technical_documents/download/apm883208-product-brief1 > > I says "APM883208-X1 *can* deliver advanced security capabilities with > the *optional* security engine." Mention of "engine" and then algorithm > list suggests that it's kind of embedded peripheral, which would appear > to user-land as device. While what we are talking about here is AES-NI > equivalent for ARMv8, i.e. ARM *instruction* set extension directly > accessible to user-land. Availability of this extension is normally > reflected in Features: in /proc/cpuinfo. ah, yes, the X-Gene 1 product brief says that the SHA-512 *can* be accelerated which is not part of the ARM cryptographic extensions it's the X-Gene 2 that says that the optional ARM v8 cryptographic instructions are supported: https://myapm.apm.com/technical_documents/download/apm883408-x2-product-brief my mistake since I don't see any "aes" or "sha" in /proc/cpuinfo, it means that I'm probably running the first not the second generation X-Gene thanks for clarification! -- 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 matt at openssl.org Tue Jun 28 13:48:47 2016 From: matt at openssl.org (Matt Caswell) Date: Tue, 28 Jun 2016 14:48:47 +0100 Subject: [openssl-dev] global OpenSSL symbols in user apps In-Reply-To: <20160628.154101.27249018672015008.levitte@openssl.org> References: <20160628.154101.27249018672015008.levitte@openssl.org> Message-ID: <5772803F.3060403@openssl.org> On 28/06/16 14:41, Richard Levitte wrote: > In message on Tue, 28 Jun 2016 12:38:20 +0000, Catalin Vasile said: > > cata.vasile> Hi, > cata.vasile> > cata.vasile> Is there a way to use global non-API functions or variables in user apps? > cata.vasile> For example: Is there a way to use OpenSSL_armcap_P in your user apps? I tried declaring it as "extern" variable, but at linking the linker says it cannot find the symbol. > > Generally speaking: no. > > Practically speaking, it depends. Provided we're talking about shared > libraries, it's a definite "no" on Windows, VMS, Linux and Solaris > (the list of Unix platforms are likely to expand) because the > non-public symbols aren't made available. That's true in 1.1.0. I think they are available in 1.0.2/1.0.1 on Linux and Solaris. Matt > > If we're talking about static libraries, no symbols are hidden. > > I would *not* recommend fiddling with the non-public symbols. You may > be safe in one OpenSSL version, but you cannot know what's happening > with them in the next. > > Cheers, > Richard > From levitte at openssl.org Tue Jun 28 13:56:25 2016 From: levitte at openssl.org (Richard Levitte) Date: Tue, 28 Jun 2016 15:56:25 +0200 (CEST) Subject: [openssl-dev] global OpenSSL symbols in user apps In-Reply-To: <5772803F.3060403@openssl.org> References: <20160628.154101.27249018672015008.levitte@openssl.org> <5772803F.3060403@openssl.org> Message-ID: <20160628.155625.2227586368751448324.levitte@openssl.org> In message <5772803F.3060403 at openssl.org> on Tue, 28 Jun 2016 14:48:47 +0100, Matt Caswell said: matt> matt> matt> On 28/06/16 14:41, Richard Levitte wrote: matt> > Practically speaking, it depends. Provided we're talking about shared matt> > libraries, it's a definite "no" on Windows, VMS, Linux and Solaris matt> > (the list of Unix platforms are likely to expand) because the matt> > non-public symbols aren't made available. matt> matt> That's true in 1.1.0. I think they are available in 1.0.2/1.0.1 on Linux matt> and Solaris. Good point, thanks for the correction. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From pbellino at mrv.com Tue Jun 28 12:02:19 2016 From: pbellino at mrv.com (Philip Bellino) Date: Tue, 28 Jun 2016 12:02:19 +0000 Subject: [openssl-dev] CVE-2016-2177 Message-ID: Hello, Will you be releasing 1.0.2i soon to address this issue? https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-2177 openssl -- openssl OpenSSL through 1.0.2h incorrectly uses pointer arithmetic for heap-buffer boundary checks, which might allow remote attackers to cause a denial of service (integer overflow and application crash) or possibly have unspecified other impact by leveraging unexpected malloc behavior, related to s3_srvr.c, ssl_sess.c, and t1_lib.c. Thanks, Phil [E-Banner] MRV Communications is a global supplier of packet and optical solutions that power the world's largest networks. Our products combine innovative hardware with intelligent software to make networks smarter, faster and more efficient. The contents of this message, together with any attachments, are intended only for the use of the person(s) to whom they are addressed and may contain confidential and/or privileged information. If you are not the intended recipient, immediately advise the sender, delete this message and any attachments and note that any distribution, or copying of this message, or any attachment, is prohibited. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Tue Jun 28 15:18:27 2016 From: rt at openssl.org (Oleg Kukartsev via RT) Date: Tue, 28 Jun 2016 15:18:27 +0000 Subject: [openssl-dev] [openssl.org #4594] openssl s_client issue on windows platform In-Reply-To: <3ac4ed516b2e97d84920e45e0c34a66e@mail.gmail.com> References: <3ac4ed516b2e97d84920e45e0c34a66e@mail.gmail.com> Message-ID: Guys, There is an issue with openssl s_client described here: http://stackoverflow.com/questions/25760596/how-to-terminate-openssl-s-client-after-connection Basically, it prevents openssl s_client automation on windows platform. And a similar question here: http://stackoverflow.com/questions/19147280/how-do-you-pipe-echo-into-openssl It works on Linux just fine, but not on windows. I?ve tested it on windows server 2012 R2 SP1 with following openssl versions: OpenSSL 1.0.2f 28 Jan 2016 OpenSSL 1.0.2h 3 May 2016 Downloaded from here: https://slproweb.com/products/Win32OpenSSL.html To clarify: A single command like this openssl s_client -brief -servername some.dns.name -connect 192.168.68.160:443 Jul 05, 2013; 9:19pm wrote why it might be happening: I'll guess this is because WaitForSingleObject doesn't treat a diskfile or full pipe as 'notified' (unlike a console), whereas Unix select() does treat them as 'ready' (like a tty). Let me know, if I need to clarify any further. Thank you! Oleg Kukartsev -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4594 Please log in as guest with password guest if prompted From rt at openssl.org Tue Jun 28 15:21:29 2016 From: rt at openssl.org (Matt Caswell via RT) Date: Tue, 28 Jun 2016 15:21:29 +0000 Subject: [openssl-dev] [openssl.org #4594] openssl s_client issue on windows platform In-Reply-To: <577295F3.7070008@openssl.org> References: <3ac4ed516b2e97d84920e45e0c34a66e@mail.gmail.com> <577295F3.7070008@openssl.org> Message-ID: On 28/06/16 16:18, Oleg Kukartsev via RT wrote: > Guys, > There is an issue with openssl s_client described here: > http://stackoverflow.com/questions/25760596/how-to-terminate-openssl-s-client-after-connection > Basically, it prevents openssl s_client automation on windows platform. > > And a similar question here: > http://stackoverflow.com/questions/19147280/how-do-you-pipe-echo-into-openssl > > It works on Linux just fine, but not on windows. > I?ve tested it on windows server 2012 R2 SP1 with following openssl > versions: > OpenSSL 1.0.2f 28 Jan 2016 > OpenSSL 1.0.2h 3 May 2016 It would be interesting to try this on OpenSSL 1.1.0. I have a suspicion this issue is fixed there. Matt > > Downloaded from here: > https://slproweb.com/products/Win32OpenSSL.html > > To clarify: > A single command like this > openssl s_client -brief -servername some.dns.name -connect > 192.168.68.160:443 waits for ?any key? click (enter, esc, etc.) > If I run a batch with 10 commands like above, only 1 one will wait for key > click, all others will run right away, because a ?key? is in the buffer > still, and openssl reads from pipe in fact (i.e. > And after running batch, ?any key? I clicked will be interpreted by shell, > since openssl has never read it. > > Here is speculation, why it might behave like this: > http://openssl.6102.n7.nabble.com/openssl-s-client-takes-over-30-seconds-to-complete-on-Windows-td45781.html > Dave Thompson-5 > > Jul > 05, 2013; 9:19pm wrote why it might be happening: > I'll guess this is because WaitForSingleObject doesn't treat a diskfile or > full pipe as 'notified' (unlike a console), whereas Unix select() does > treat them as 'ready' (like a tty). > > Let me know, if I need to clarify any further. > Thank you! > Oleg Kukartsev > -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4594 Please log in as guest with password guest if prompted From rsalz at akamai.com Tue Jun 28 15:22:52 2016 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 28 Jun 2016 15:22:52 +0000 Subject: [openssl-dev] CVE-2016-2177 In-Reply-To: References: Message-ID: >Will you be releasing 1.0.2i soon to address this issue? > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-2177 Please see https://www.openssl.org/blog/blog/2016/06/27/undefined-pointer-arithmetic/ Short answer: this is a LOW issue, and does not justify a release by itself. -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz From rt at openssl.org Tue Jun 28 16:04:49 2016 From: rt at openssl.org (Robert Wagner via RT) Date: Tue, 28 Jun 2016 16:04:49 +0000 Subject: [openssl-dev] [openssl.org #4595] Enhancement Request - FPE (FF1 and FF3) In-Reply-To: References: Message-ID: Dear OpenSSL, As you may be aware, NIST recently approved two Format Preserving Encryption (FPE) methods - FF1 and FF3. See: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-38G.pdf The field of tokenization and fixed format encryption (FFX) has taken off due to PCI compliance. These protocols allow one to replace a sensitive field with similarly formatted ciphertext. This is useful when field type and size is fixed (like SSN, Credit Card Number). I would like to request that OpenSSL implement these ciphers as fpe-ff1 and fpe-ff3. Sincerely, Robert Wagner -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4595 Please log in as guest with password guest if prompted From rt at openssl.org Tue Jun 28 16:12:18 2016 From: rt at openssl.org (Oleg Kukartsev via RT) Date: Tue, 28 Jun 2016 16:12:18 +0000 Subject: [openssl-dev] [openssl.org #4594] openssl s_client issue on windows platform In-Reply-To: <5046644af6e01976d51718f40b885e5d@mail.gmail.com> References: <3ac4ed516b2e97d84920e45e0c34a66e@mail.gmail.com> <577295F3.7070008@openssl.org> <5046644af6e01976d51718f40b885e5d@mail.gmail.com> Message-ID: Matt, >It would be interesting to try this on OpenSSL 1.1.0. >I have a suspicion this issue is fixed there. I hope so. I cannot find a OpenSSL 1.1.0 compiled version anywhere to try. I'm not that good to compile it myself. I'll try to contact slproweb.com guys, hopefully they can help. Thanks Oleg -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4594 Please log in as guest with password guest if prompted From rsalz at akamai.com Tue Jun 28 16:33:33 2016 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 28 Jun 2016 16:33:33 +0000 Subject: [openssl-dev] [openssl.org #4587] openssl on arm linux run err! In-Reply-To: References: <647a5741.7dab.155815e8c0d.Coremail.peter_zor@126.com> <187eb3e5.278f.1558f998460.Coremail.peter_zor@126.com> <6dcf1d17.238d.15594b1f8eb.Coremail.peter_zor@126.com> Message-ID: <9c5acbcfac0c45de8d5f92ddc7c8230f@usma1ex-dag1mb1.msg.corp.akamai.com> > Also, under the x86 no problem.Now how to solve this problem? The same way you debug any C problem. Start by running it under the debugger? From rt at openssl.org Tue Jun 28 16:33:37 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Tue, 28 Jun 2016 16:33:37 +0000 Subject: [openssl-dev] [openssl.org #4587] openssl on arm linux run err! In-Reply-To: <9c5acbcfac0c45de8d5f92ddc7c8230f@usma1ex-dag1mb1.msg.corp.akamai.com> References: <647a5741.7dab.155815e8c0d.Coremail.peter_zor@126.com> <187eb3e5.278f.1558f998460.Coremail.peter_zor@126.com> <6dcf1d17.238d.15594b1f8eb.Coremail.peter_zor@126.com> <9c5acbcfac0c45de8d5f92ddc7c8230f@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: > Also, under the x86 no problem.Now how to solve this problem? The same way you debug any C problem. Start by running it under the debugger? -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4587 Please log in as guest with password guest if prompted From rt at openssl.org Tue Jun 28 17:25:57 2016 From: rt at openssl.org (Hubert Kario via RT) Date: Tue, 28 Jun 2016 17:25:57 +0000 Subject: [openssl-dev] [openssl.org #4596] OpenSSL TLS Version Handling Errors In-Reply-To: <36682878.kUsO3VN8sE@pintsize.usersys.redhat.com> References: <36682878.kUsO3VN8sE@pintsize.usersys.redhat.com> Message-ID: from RT#2777 On Monday 27 June 2016 20:43:07 Rich Salz via RT wrote: > please open a new ticket if this is still an issue with current (at least > 1.0.2, ideally master) sources. Current 1.0.2 still doesn't handle ClientHello.client_version set to 0x00,0x00 correctly in a 0x03, 0x00 record layer, the connection is just closed without sending an Alert message. current master handles all correctly all test performed: 3, 3 version in 3, 0 record - passed 3, 3 version in 3, 254 record - passed 254, 254 version in 3, 254 record - passed 254, 254 version in 3, 0 record - passed 0, 0 version in 3, 0 record - fail (if you think any other values should be checked, feel free to contact me) reproducer script: https://github.com/tomato42/tlsfuzzer/blob/master/scripts/test-version-numbers.py to reproduce: openssl req -x509 -newkey rsa -keyout localhost.key -out localhost.crt -subj /CN=localhost -nodes -batch openssl s_server -key localhost.key -cert localhost.crt -www 2>server.err >server.out & openssl_pid=$! git clone https://github.com/tomato42/tlsfuzzer pushd tlsfuzzer git clone https://github.com/tomato42/tlslite-ng .tlslite-ng ln -s .tlslite-ng/tlslite tlslite git clone https://github.com/warner/python-ecdsa .python-ecdsa ln -s .python-ecdsa/ecdsa ecdsa PYTHONPATH=. python scripts/test-version-numbers.py popd kill $openssl_pid -- 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=4596 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 Jun 28 17:52:24 2016 From: rt at openssl.org (Hubert Kario via RT) Date: Tue, 28 Jun 2016 17:52:24 +0000 Subject: [openssl-dev] [openssl.org #4589] Resolved: simplifying writing code that is 1.0.x and 1.1.x compatible In-Reply-To: <4878717.biaQBHTPEX@pintsize.usersys.redhat.com> References: <0189c67d54214f39adb5006c3563dadf@usma1ex-dag1mb1.msg.corp.akamai.com> <4878717.biaQBHTPEX@pintsize.usersys.redhat.com> Message-ID: On Monday 27 June 2016 20:57:50 Salz, Rich via RT wrote: > > But obviously I was expecting too much... > > Sorry you're not pleased. Not sure what to say -- you get what you pay for? and you will not accept pull requests that do that? > Maybe someone will come up with a "openssl-102-compat" package? what about Debian CVE-2008-0166 like scenario? -- 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=4589 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 Jun 28 18:03:39 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Tue, 28 Jun 2016 18:03:39 +0000 Subject: [openssl-dev] [openssl.org #4589] Resolved: simplifying writing code that is 1.0.x and 1.1.x compatible In-Reply-To: <8921874b39544ae98ab59330861ff8b7@usma1ex-dag1mb1.msg.corp.akamai.com> References: <0189c67d54214f39adb5006c3563dadf@usma1ex-dag1mb1.msg.corp.akamai.com> <4878717.biaQBHTPEX@pintsize.usersys.redhat.com> <8921874b39544ae98ab59330861ff8b7@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: > and you will not accept pull requests that do that? So far, the team is not interested in doing that. Features are not added to stable branches. But, for myself, I would like to see something like a GitHub repo that built on top of 1.0.2 and made the 1.1 API's available. I think that for most of them it should not be too hard. > what about Debian CVE-2008-0166 like scenario? So far that kind of thing seems unlikely, but maybe I'm missing the point your trying to make? -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4589 Please log in as guest with password guest if prompted From brian at briansmith.org Tue Jun 28 20:43:09 2016 From: brian at briansmith.org (Brian Smith) Date: Tue, 28 Jun 2016 10:43:09 -1000 Subject: [openssl-dev] Are the point-at-infinity checks in ecp_nistz256 correct? Message-ID: When doing math on short Weierstrass curves like P-256, we have to special case points at infinity. In Jacobian coordinates (X, Y, Z), points at infinity have Z == 0. However, instead of checking for Z == 0, p256-x86-64 instead checks for (X, Y) == (0, 0). In other words, it does, in some sense, the opposite of what I expect it to do. I have built a testing framework for exploring things like this in *ring*. I will attach the input file for my tests which show that ecp_nistz256_point_add seems to fail to recognize the point at infinity correctly. However, it is also possible that I just don't understand how ecp_nistz256 intends to work. My questions are: 1. With respect to additions of the form (a + infinity == a) and (infinity + b == b), is the code in ecp_nistz256_point_add and ecp_nistz256_point_add_affine correct? 2. if it is correct, could we add more explanation as to why it is correct? 3. Given the specifics of the implementation of the ecp_nistz256 implementation, is it even possible for us to encounter the point at infinity as one of the parameters to ecp_nistz256_point_add, other than in the very final addition that adds g_scalar*G + p_scalar*P? See Section 4.1 of [1]. Background: For based point (G) multiplication, the code has a large table of multiples of G, in affine (not Jacobian) coordinates. The point at infinity cannot be encoded in affine coordinates. The authors instead decided to encode the point at infinity as (0, 0), since the affine point (0, 0) isn't on the P-256 curve. It isn't clear why the authors chose to do that though, since the point at infinity doesn't (can't, logically) appear in the table of precomputed multiples of G anyway. Regardless, if you represent the point at infinity as (0, 0) then it makes sense to check (x, y) == (0, 0). But, it seems like the functions that do the computations, like ecp_nistz256_point_add and ecp_nistz256_point_add_affine, output the point at infinity as (_, _, 0), not necessarily (0, 0, _). Also, ecp_nistz256's EC_METHOD uses ec_GFp_simple_is_at_infinity and ec_GFp_simple_point_set_to_infinity, which represent the point at infinity with z == 0, not (x, y) == 0. Further ecp_nistz256_get_affine uses EC_POINT_is_at_infinity, which checks z == 0, not (x, y) == 0. This inconsistency is confusing, if not wrong. Given this, it seems like the point-at-infinity checks in the ecp_nistz256_point_add and ecp_nistz256_point_add_affine code should also be checking that z == 0 instead of (x, y) == (0, 0). Note that this is confusing because `EC_POINT_new` followed by `EC_POINT_to_infinity` initializes (X, Y, Z) = (0, 0, 0). Thus, the check of (x, y) == (0, 0) "works" as well as the check z == 0. But, it doesn't work in real-life cases where the point is infinity is encountered during calculations, because we'll have (X, Y) != (0, 0) but Z == 0. The assembly language code that does this check is hard to understand unless one is familiar with SIMD. However, the C reference implementation that the assembly language code used as a model is easy to understand. This code can be found in the ecp_nistz256.c file. Note the parameters of ecp_nistz256_point_add are P256_POINT, not P256_POINT_AFFINE, so "representation of the point at infinity as (0, 0)" doesn't make sense to me. But, that's exactly what it checks. In ecp_nistz256_point_add_affine, it makes more sense to me, because parameter |b| is in fact a |P256_POINT_AFFINE|. However, |a| is not a |P256_POINT_AFFINE|, so the (x, y) == (0, 0) check doesn't make sense to me. The x86-64 and x86 assembly language code seems to emulate this exactly. I didn't test the ARM code, but I'd guess it is similar. [1] https://eprint.iacr.org/2014/130.pdf (Section 4.1) Here's the specific logic I'm talking about (which is also present in the asm code): ``` static void ecp_nistz256_point_add(P256_POINT *r, const P256_POINT *a, const P256_POINT *b) { [...] const BN_ULONG *in1_x = a->X; const BN_ULONG *in1_y = a->Y; const BN_ULONG *in1_z = a->Z; const BN_ULONG *in2_x = b->X; const BN_ULONG *in2_y = b->Y; const BN_ULONG *in2_z = b->Z; /* We encode infinity as (0,0), which is not on the curve, * so it is OK. */ in1infty = (in1_x[0] | in1_x[1] | in1_x[2] | in1_x[3] | in1_y[0] | in1_y[1] | in1_y[2] | in1_y[3]); if (P256_LIMBS == 8) in1infty |= (in1_x[4] | in1_x[5] | in1_x[6] | in1_x[7] | in1_y[4] | in1_y[5] | in1_y[6] | in1_y[7]); in2infty = (in2_x[0] | in2_x[1] | in2_x[2] | in2_x[3] | in2_y[0] | in2_y[1] | in2_y[2] | in2_y[3]); if (P256_LIMBS == 8) in2infty |= (in2_x[4] | in2_x[5] | in2_x[6] | in2_x[7] | in2_y[4] | in2_y[5] | in2_y[6] | in2_y[7]); [...] } static void ecp_nistz256_point_add_affine(P256_POINT *r, const P256_POINT *a, const P256_POINT_AFFINE *b) { [...] const BN_ULONG *in1_x = a->X; const BN_ULONG *in1_y = a->Y; const BN_ULONG *in1_z = a->Z; const BN_ULONG *in2_x = b->X; const BN_ULONG *in2_y = b->Y; /* * In affine representation we encode infty as (0,0), which is not on the * curve, so it is OK */ in1infty = (in1_x[0] | in1_x[1] | in1_x[2] | in1_x[3] | in1_y[0] | in1_y[1] | in1_y[2] | in1_y[3]); if (P256_LIMBS == 8) in1infty |= (in1_x[4] | in1_x[5] | in1_x[6] | in1_x[7] | in1_y[4] | in1_y[5] | in1_y[6] | in1_y[7]); in2infty = (in2_x[0] | in2_x[1] | in2_x[2] | in2_x[3] | in2_y[0] | in2_y[1] | in2_y[2] | in2_y[3]); if (P256_LIMBS == 8) in2infty |= (in2_x[4] | in2_x[5] | in2_x[6] | in2_x[7] | in2_y[4] | in2_y[5] | in2_y[6] | in2_y[7]); in1infty = is_zero(in1infty); in2infty = is_zero(in2infty); [...] } ``` Cheers, Brian -- https://briansmith.org/ From brian at briansmith.org Tue Jun 28 20:44:20 2016 From: brian at briansmith.org (Brian Smith) Date: Tue, 28 Jun 2016 10:44:20 -1000 Subject: [openssl-dev] Are the point-at-infinity checks in ecp_nistz256 correct? In-Reply-To: References: Message-ID: :sigh: I forgot the attachment with my test vectors. Here it is. On Tue, Jun 28, 2016 at 10:43 AM, Brian Smith wrote: > When doing math on short Weierstrass curves like P-256, we have to > special case points at infinity. In Jacobian coordinates (X, Y, Z), > points at infinity have Z == 0. However, instead of checking for Z == > 0, p256-x86-64 instead checks for (X, Y) == (0, 0). In other words, it > does, in some sense, the opposite of what I expect it to do. > > I have built a testing framework for exploring things like this in > *ring*. I will attach the input file for my tests which show that > ecp_nistz256_point_add seems to fail to recognize the point at > infinity correctly. However, it is also possible that I just don't > understand how ecp_nistz256 intends to work. My questions are: > > 1. With respect to additions of the form (a + infinity == a) and > (infinity + b == b), is the code in ecp_nistz256_point_add and > ecp_nistz256_point_add_affine correct? > > 2. if it is correct, could we add more explanation as to why it is correct? > > 3. Given the specifics of the implementation of the ecp_nistz256 > implementation, is it even possible for us to encounter the point at > infinity as one of the parameters to ecp_nistz256_point_add, other > than in the very final addition that adds g_scalar*G + p_scalar*P? See > Section 4.1 of [1]. > > Background: For based point (G) multiplication, the code has a large > table of multiples of G, in affine (not Jacobian) coordinates. The > point at infinity cannot be encoded in affine coordinates. The authors > instead decided to encode the point at infinity as (0, 0), since the > affine point (0, 0) isn't on the P-256 curve. It isn't clear why the > authors chose to do that though, since the point at infinity doesn't > (can't, logically) appear in the table of precomputed multiples of G > anyway. Regardless, if you represent the point at infinity as (0, 0) > then it makes sense to check (x, y) == (0, 0). > > But, it seems like the functions that do the computations, like > ecp_nistz256_point_add and ecp_nistz256_point_add_affine, output the > point at infinity as (_, _, 0), not necessarily (0, 0, _). Also, > ecp_nistz256's EC_METHOD uses ec_GFp_simple_is_at_infinity and > ec_GFp_simple_point_set_to_infinity, which represent the point at > infinity with z == 0, not (x, y) == 0. Further ecp_nistz256_get_affine > uses EC_POINT_is_at_infinity, which checks z == 0, not (x, y) == 0. > This inconsistency is confusing, if not wrong. Given this, it seems > like the point-at-infinity checks in the ecp_nistz256_point_add and > ecp_nistz256_point_add_affine code should also be checking that z == 0 > instead of (x, y) == (0, 0). > > Note that this is confusing because `EC_POINT_new` followed by > `EC_POINT_to_infinity` initializes (X, Y, Z) = (0, 0, 0). Thus, the > check of (x, y) == (0, 0) "works" as well as the check z == 0. But, it > doesn't work in real-life cases where the point is infinity is > encountered during calculations, because we'll have (X, Y) != (0, 0) > but Z == 0. > > The assembly language code that does this check is hard to understand > unless one is familiar with SIMD. However, the C reference > implementation that the assembly language code used as a model is easy > to understand. This code can be found in the ecp_nistz256.c file. > > Note the parameters of ecp_nistz256_point_add are P256_POINT, not > P256_POINT_AFFINE, so "representation of the point at infinity as (0, > 0)" doesn't make sense to me. But, that's exactly what it checks. > > In ecp_nistz256_point_add_affine, it makes more sense to me, because > parameter |b| is in fact a |P256_POINT_AFFINE|. However, |a| is not a > |P256_POINT_AFFINE|, so the (x, y) == (0, 0) check doesn't make sense > to me. The x86-64 and x86 assembly language code seems to emulate this > exactly. I didn't test the ARM code, but I'd guess it is similar. > > [1] https://eprint.iacr.org/2014/130.pdf (Section 4.1) > > Here's the specific logic I'm talking about (which is also present in > the asm code): > > ``` > static void ecp_nistz256_point_add(P256_POINT *r, > const P256_POINT *a, const P256_POINT *b) { > [...] > > const BN_ULONG *in1_x = a->X; > const BN_ULONG *in1_y = a->Y; > const BN_ULONG *in1_z = a->Z; > > const BN_ULONG *in2_x = b->X; > const BN_ULONG *in2_y = b->Y; > const BN_ULONG *in2_z = b->Z; > > /* We encode infinity as (0,0), which is not on the curve, > * so it is OK. */ > in1infty = (in1_x[0] | in1_x[1] | in1_x[2] | in1_x[3] | > in1_y[0] | in1_y[1] | in1_y[2] | in1_y[3]); > if (P256_LIMBS == 8) > in1infty |= (in1_x[4] | in1_x[5] | in1_x[6] | in1_x[7] | > in1_y[4] | in1_y[5] | in1_y[6] | in1_y[7]); > > in2infty = (in2_x[0] | in2_x[1] | in2_x[2] | in2_x[3] | > in2_y[0] | in2_y[1] | in2_y[2] | in2_y[3]); > if (P256_LIMBS == 8) > in2infty |= (in2_x[4] | in2_x[5] | in2_x[6] | in2_x[7] | > in2_y[4] | in2_y[5] | in2_y[6] | in2_y[7]); > > [...] > } > > static void ecp_nistz256_point_add_affine(P256_POINT *r, > const P256_POINT *a, > const P256_POINT_AFFINE *b) { > [...] > > const BN_ULONG *in1_x = a->X; > const BN_ULONG *in1_y = a->Y; > const BN_ULONG *in1_z = a->Z; > > const BN_ULONG *in2_x = b->X; > const BN_ULONG *in2_y = b->Y; > > /* > * In affine representation we encode infty as (0,0), which is not on the > * curve, so it is OK > */ > in1infty = (in1_x[0] | in1_x[1] | in1_x[2] | in1_x[3] | > in1_y[0] | in1_y[1] | in1_y[2] | in1_y[3]); > if (P256_LIMBS == 8) > in1infty |= (in1_x[4] | in1_x[5] | in1_x[6] | in1_x[7] | > in1_y[4] | in1_y[5] | in1_y[6] | in1_y[7]); > > in2infty = (in2_x[0] | in2_x[1] | in2_x[2] | in2_x[3] | > in2_y[0] | in2_y[1] | in2_y[2] | in2_y[3]); > if (P256_LIMBS == 8) > in2infty |= (in2_x[4] | in2_x[5] | in2_x[6] | in2_x[7] | > in2_y[4] | in2_y[5] | in2_y[6] | in2_y[7]); > > in1infty = is_zero(in1infty); > in2infty = is_zero(in2infty); > > [...] > } > ``` > > Cheers, > Brian > -- > https://briansmith.org/ -- https://briansmith.org/ -------------- next part -------------- # Some test vectors for a + b == r for the P-256 curve that demonstrate the # incorrect point-on-the-curve check. # # All test vectors' elements are in the Montgomery domain. Also, the result |r| # is normalized to Z == to_mont(1). # G + inf == G. The code handles this correctly, but only accidentally because # all three of (X, Y, Z) are zero. Curve = P-256 a = 18905f76a53755c679fb732b7762251075ba95fc5fedb60179e730d418a9143c, 8571ff1825885d85d2e88688dd21f3258b4ab8e4ba19e45cddf25357ce95560a, 00000000fffffffeffffffffffffffffffffffff000000000000000000000001 b = 0000000000000000000000000000000000000000000000000000000000000000, 0000000000000000000000000000000000000000000000000000000000000000, 0000000000000000000000000000000000000000000000000000000000000000 r = 18905f76a53755c679fb732b7762251075ba95fc5fedb60179e730d418a9143c, 8571ff1825885d85d2e88688dd21f3258b4ab8e4ba19e45cddf25357ce95560a, 00000000fffffffeffffffffffffffffffffffff000000000000000000000001 # G + the point (0, 0, Junk), which is not on the curve as affine point (0, 0) # is not on the curve. The code thinks this is at infinity because # (X, Y) == (0, 0), but it's not at infinity, because Z != 0. The value of |r| # here is what the code actually calculates (the value of G). There is no right # answer for this input because b isn't even on the curve. Curve = P-256 a = 18905f76a53755c679fb732b7762251075ba95fc5fedb60179e730d418a9143c, 8571ff1825885d85d2e88688dd21f3258b4ab8e4ba19e45cddf25357ce95560a, 00000000fffffffeffffffffffffffffffffffff000000000000000000000001 b = 0000000000000000000000000000000000000000000000000000000000000000, 0000000000000000000000000000000000000000000000000000000000000000, 6d333da42e30f7011245b6281015ded14e0f100968e758a1b6c3c083afc14ea0 r = 18905f76a53755c679fb732b7762251075ba95fc5fedb60179e730d418a9143c, 8571ff1825885d85d2e88688dd21f3258b4ab8e4ba19e45cddf25357ce95560a, 00000000fffffffeffffffffffffffffffffffff000000000000000000000001 # G + (n*G) == G. Note that n*G results in the point at infinity (Z == 0), but # with (X, Y) != (0, 0). The code calculates the wrong result. Here |r| is what # the code should calculate (the value of G). Curve = P-256 a = 18905f76a53755c679fb732b7762251075ba95fc5fedb60179e730d418a9143c, 8571ff1825885d85d2e88688dd21f3258b4ab8e4ba19e45cddf25357ce95560a, 00000000fffffffeffffffffffffffffffffffff000000000000000000000001 b = 2b11cb945c8cf152ffa4c9c2b1c965b019b35d0b7626919ef0ae6cb9d232f8af, 6d333da42e30f7011245b6281015ded14e0f100968e758a1b6c3c083afc14ea0, 0000000000000000000000000000000000000000000000000000000000000000 r = 18905f76a53755c679fb732b7762251075ba95fc5fedb60179e730d418a9143c, 8571ff1825885d85d2e88688dd21f3258b4ab8e4ba19e45cddf25357ce95560a, 00000000fffffffeffffffffffffffffffffffff000000000000000000000001 From rt at openssl.org Tue Jun 28 21:18:12 2016 From: rt at openssl.org (Kurt Roeckx via RT) Date: Tue, 28 Jun 2016 21:18:12 +0000 Subject: [openssl-dev] [openssl.org #4589] Resolved: simplifying writing code that is 1.0.x and 1.1.x compatible In-Reply-To: <20160628211756.GA21531@roeckx.be> References: <57719187.9020802@waldmann-edv.de> <20160628211756.GA21531@roeckx.be> Message-ID: On Mon, Jun 27, 2016 at 08:50:43PM +0000, Thomas Waldmann via RT wrote: > I didn't ask where to get the missing code from, I asked whether you > maybe want to make life simpler for people by adding this to 1.0.x > rather than having a thousand software developers copy and pasting it > into their projects. I think this will not actually make life easier. People using a 1.0.x version are not always using the latest 1.0.x version. Or are you happy to say that they either need a certain version of the 1.0.x branch or the 1.1 branch? Then why not just say they need the 1.1 branch? I know it's annoying, but I don't see this solving anything, nor do I see a good way to avoid it. But adding things to master to make it easier to upgrade are clearly things we do want to do. Kurt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4589 Please log in as guest with password guest if prompted From rt at openssl.org Tue Jun 28 22:10:02 2016 From: rt at openssl.org (Thomas Waldmann via RT) Date: Tue, 28 Jun 2016 22:10:02 +0000 Subject: [openssl-dev] [openssl.org #4589] Resolved: simplifying writing code that is 1.0.x and 1.1.x compatible In-Reply-To: <5772F5B1.2060603@waldmann-edv.de> References: <57719187.9020802@waldmann-edv.de> <20160628211756.GA21531@roeckx.be> <5772F5B1.2060603@waldmann-edv.de> Message-ID: On 06/28/2016 11:18 PM, Kurt Roeckx via RT wrote: > On Mon, Jun 27, 2016 at 08:50:43PM +0000, Thomas Waldmann via RT wrote: >> I didn't ask where to get the missing code from, I asked whether you >> maybe want to make life simpler for people by adding this to 1.0.x >> rather than having a thousand software developers copy and pasting it >> into their projects. > > I think this will not actually make life easier. People using a > 1.0.x version are not always using the latest 1.0.x version. Aren't they? Don't they use 1.0.xLATEST rather soon, due to security fixes? And in case some dist maintainer chooses to rather backport, couldn't they also backport the added function if it is documented as "openssl 1.1.x migration support" or so? We aren't talking about incompatible changes, just adding 2 trivial functions that were not there yet (but should have been there, when looking at the rest of the API). > Or are you happy to say that they either need a certain version of > the 1.0.x branch Well, of course openssl project would only care about latest update of each series 1.0.1x, 1.0.2x, 1.1.0x. > or the 1.1 branch? Then why not just say they need the 1.1 branch? Because software needs to be able to run on both versions, likely for years. For borgbackup, we want to support running on centos6, debian wheezy, ... debian experimental. In a year, openssl 1.0.x and 1.1.x will be in stable and supported distributions that openssl-using software needs to support. -- GPG ID: FAF7B393 GPG FP: 6D5B EF9A DD20 7580 5747 B70F 9F88 FB52 FAF7 B393 -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4589 Please log in as guest with password guest if prompted From rt at openssl.org Wed Jun 29 03:21:08 2016 From: rt at openssl.org (noloader@gmail.com via RT) Date: Wed, 29 Jun 2016 03:21:08 +0000 Subject: [openssl-dev] [openssl.org #4597] Print Git repo information during configure In-Reply-To: References: Message-ID: The attached adds Git repo information if its available. In the "things work as expected" case, the repo information is available. It will be submitted with bug reports when configuration information is provided. In the "its not a repo" case, then the call to system fails and nothing is printed. This is no worse than you have now. $ cat Configure.diff diff --git a/Configure b/Configure index ee0b4a7..2059fe1 100755 --- a/Configure +++ b/Configure @@ -232,6 +232,13 @@ if (defined $ENV{$local_config_envname}) { print "Configuring OpenSSL version $config{version} (0x$config{version_num})\n"; +my $git_repo = system("git rev-parse HEAD >/dev/null 2>&1"); +if ($git_repo == 0) { + chomp(my $branch =`git rev-parse --abbrev-ref HEAD`); + chomp(my $revision = `git rev-parse HEAD`); + print "Git branch $branch, commit $revision\n"; +} + $config{prefix}=""; $config{openssldir}=""; $config{processor}=""; -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4597 Please log in as guest with password guest if prompted From support at go-forward.net Wed Jun 29 03:52:45 2016 From: support at go-forward.net (Support) Date: Wed, 29 Jun 2016 13:52:45 +1000 Subject: [openssl-dev] [openssl.org #4594] openssl s_client issue on windows platform In-Reply-To: References: <3ac4ed516b2e97d84920e45e0c34a66e@mail.gmail.com> <577295F3.7070008@openssl.org> Message-ID: <0540b0d0-d0fd-9e68-842c-f0d27e339112@go-forward.net> Hi, This can be fixed using the patch attached in https://rt.openssl.org/Ticket/Display.html?id=3464 See also https://github.com/PeterMosmans/openssl/commit/68ab9b308e173072e5015063be7e194bec1f311f Cheers, Peter Mosmans On 29-06-2016 01:21, Matt Caswell via RT wrote: > > On 28/06/16 16:18, Oleg Kukartsev via RT wrote: >> Guys, >> There is an issue with openssl s_client described here: >> http://stackoverflow.com/questions/25760596/how-to-terminate-openssl-s-client-after-connection >> Basically, it prevents openssl s_client automation on windows platform. >> >> And a similar question here: >> http://stackoverflow.com/questions/19147280/how-do-you-pipe-echo-into-openssl >> >> It works on Linux just fine, but not on windows. >> I?ve tested it on windows server 2012 R2 SP1 with following openssl >> versions: >> OpenSSL 1.0.2f 28 Jan 2016 >> OpenSSL 1.0.2h 3 May 2016 > It would be interesting to try this on OpenSSL 1.1.0. I have a suspicion > this issue is fixed there. > > Matt > > >> Downloaded from here: >> https://slproweb.com/products/Win32OpenSSL.html >> >> To clarify: >> A single command like this >> openssl s_client -brief -servername some.dns.name -connect >> 192.168.68.160:443 > waits for ?any key? click (enter, esc, etc.) >> If I run a batch with 10 commands like above, only 1 one will wait for key >> click, all others will run right away, because a ?key? is in the buffer >> still, and openssl reads from pipe in fact (i.e. > >> And after running batch, ?any key? I clicked will be interpreted by shell, >> since openssl has never read it. >> >> Here is speculation, why it might behave like this: >> http://openssl.6102.n7.nabble.com/openssl-s-client-takes-over-30-seconds-to-complete-on-Windows-td45781.html >> Dave Thompson-5 >> >> Jul >> 05, 2013; 9:19pm wrote why it might be happening: >> I'll guess this is because WaitForSingleObject doesn't treat a diskfile or >> full pipe as 'notified' (unlike a console), whereas Unix select() does >> treat them as 'ready' (like a tty). >> >> Let me know, if I need to clarify any further. >> Thank you! >> Oleg Kukartsev >> > From rt at openssl.org Wed Jun 29 03:52:06 2016 From: rt at openssl.org (Support via RT) Date: Wed, 29 Jun 2016 03:52:06 +0000 Subject: [openssl-dev] [openssl.org #4594] openssl s_client issue on windows platform In-Reply-To: <0540b0d0-d0fd-9e68-842c-f0d27e339112@go-forward.net> References: <3ac4ed516b2e97d84920e45e0c34a66e@mail.gmail.com> <577295F3.7070008@openssl.org> <0540b0d0-d0fd-9e68-842c-f0d27e339112@go-forward.net> Message-ID: Hi, This can be fixed using the patch attached in https://rt.openssl.org/Ticket/Display.html?id=3464 See also https://github.com/PeterMosmans/openssl/commit/68ab9b308e173072e5015063be7e194bec1f311f Cheers, Peter Mosmans On 29-06-2016 01:21, Matt Caswell via RT wrote: > > On 28/06/16 16:18, Oleg Kukartsev via RT wrote: >> Guys, >> There is an issue with openssl s_client described here: >> http://stackoverflow.com/questions/25760596/how-to-terminate-openssl-s-client-after-connection >> Basically, it prevents openssl s_client automation on windows platform. >> >> And a similar question here: >> http://stackoverflow.com/questions/19147280/how-do-you-pipe-echo-into-openssl >> >> It works on Linux just fine, but not on windows. >> I?ve tested it on windows server 2012 R2 SP1 with following openssl >> versions: >> OpenSSL 1.0.2f 28 Jan 2016 >> OpenSSL 1.0.2h 3 May 2016 > It would be interesting to try this on OpenSSL 1.1.0. I have a suspicion > this issue is fixed there. > > Matt > > >> Downloaded from here: >> https://slproweb.com/products/Win32OpenSSL.html >> >> To clarify: >> A single command like this >> openssl s_client -brief -servername some.dns.name -connect >> 192.168.68.160:443 > waits for ?any key? click (enter, esc, etc.) >> If I run a batch with 10 commands like above, only 1 one will wait for key >> click, all others will run right away, because a ?key? is in the buffer >> still, and openssl reads from pipe in fact (i.e. > >> And after running batch, ?any key? I clicked will be interpreted by shell, >> since openssl has never read it. >> >> Here is speculation, why it might behave like this: >> http://openssl.6102.n7.nabble.com/openssl-s-client-takes-over-30-seconds-to-complete-on-Windows-td45781.html >> Dave Thompson-5 >> >> Jul >> 05, 2013; 9:19pm wrote why it might be happening: >> I'll guess this is because WaitForSingleObject doesn't treat a diskfile or >> full pipe as 'notified' (unlike a console), whereas Unix select() does >> treat them as 'ready' (like a tty). >> >> Let me know, if I need to clarify any further. >> Thank you! >> Oleg Kukartsev >> > -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4594 Please log in as guest with password guest if prompted From matt at openssl.org Wed Jun 29 07:33:22 2016 From: matt at openssl.org (Matt Caswell) Date: Wed, 29 Jun 2016 08:33:22 +0100 Subject: [openssl-dev] Feedback on BIO API changes in 1.1 In-Reply-To: <57719312.2080504@xiph.org> References: <57715280.1090904@xiph.org> <9fa8d87eb0684598b44831102d6274f0@usma1ex-dag1mb1.msg.corp.akamai.com> <57719312.2080504@xiph.org> Message-ID: <577379C2.7040706@openssl.org> On 27/06/16 21:56, Timothy B. Terriberry wrote: > Because I am writing a library, which I > intend to be re-entrant, but which does not have any explicit threading > support (or dependencies), I don't have any convenient global place to > cache it. I haven't needed one for anything else. You could initialise a global variable which holds your BIO_METHOD using CRYPTO_THREAD_run_once() and free it up when OpenSSL exits using OPENSSL_atexit(). Matt From tmraz at redhat.com Wed Jun 29 07:33:41 2016 From: tmraz at redhat.com (Tomas Mraz) Date: Wed, 29 Jun 2016 09:33:41 +0200 Subject: [openssl-dev] [openssl.org #4589] Resolved: simplifying writing code that is 1.0.x and 1.1.x compatible In-Reply-To: References: <57719187.9020802@waldmann-edv.de> <20160628211756.GA21531@roeckx.be> <5772F5B1.2060603@waldmann-edv.de> Message-ID: <1467185621.7792.17.camel@redhat.com> On ?t, 2016-06-28 at 22:10 +0000, Thomas Waldmann via RT wrote: > On 06/28/2016 11:18 PM, Kurt Roeckx via RT wrote: > > > > On Mon, Jun 27, 2016 at 08:50:43PM +0000, Thomas Waldmann via RT > > wrote: > > > > > > I didn't ask where to get the missing code from, I asked whether > > > you > > > maybe want to make life simpler for people by adding this to > > > 1.0.x > > > rather than having a thousand software developers copy and > > > pasting it > > > into their projects. > > I think this will not actually make life easier.??People using a > > 1.0.x version are not always using the latest 1.0.x version. > Aren't they? > > Don't they use 1.0.xLATEST rather soon, due to security fixes? > > And in case some dist maintainer chooses to rather backport, couldn't > they also backport the added function if it is documented as "openssl > 1.1.x migration support" or so? > > We aren't talking about incompatible changes, just adding 2 trivial > functions that were not there yet (but should have been there, when > looking at the rest of the API). You might get such kind of backport to something that still evolves such as (RHEL/CentOS 7) however you would not get it in older releases (RHEL/CentOS 5 and most probably RHEL/CentOS 6 either). So you will still be facing the issue that there are environments where someone wants to build your code and these functions are not present. --? 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 Wed Jun 29 07:33:55 2016 From: rt at openssl.org (Tomas Mraz via RT) Date: Wed, 29 Jun 2016 07:33:55 +0000 Subject: [openssl-dev] [openssl.org #4589] Resolved: simplifying writing code that is 1.0.x and 1.1.x compatible In-Reply-To: <1467185621.7792.17.camel@redhat.com> References: <57719187.9020802@waldmann-edv.de> <20160628211756.GA21531@roeckx.be> <5772F5B1.2060603@waldmann-edv.de> <1467185621.7792.17.camel@redhat.com> Message-ID: On ?t, 2016-06-28 at 22:10 +0000, Thomas Waldmann via RT wrote: > On 06/28/2016 11:18 PM, Kurt Roeckx via RT wrote: > > > > On Mon, Jun 27, 2016 at 08:50:43PM +0000, Thomas Waldmann via RT > > wrote: > > > > > > I didn't ask where to get the missing code from, I asked whether > > > you > > > maybe want to make life simpler for people by adding this to > > > 1.0.x > > > rather than having a thousand software developers copy and > > > pasting it > > > into their projects. > > I think this will not actually make life easier.??People using a > > 1.0.x version are not always using the latest 1.0.x version. > Aren't they? > > Don't they use 1.0.xLATEST rather soon, due to security fixes? > > And in case some dist maintainer chooses to rather backport, couldn't > they also backport the added function if it is documented as "openssl > 1.1.x migration support" or so? > > We aren't talking about incompatible changes, just adding 2 trivial > functions that were not there yet (but should have been there, when > looking at the rest of the API). You might get such kind of backport to something that still evolves such as (RHEL/CentOS 7) however you would not get it in older releases (RHEL/CentOS 5 and most probably RHEL/CentOS 6 either). So you will still be facing the issue that there are environments where someone wants to build your code and these functions are not present. --? 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.) -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4589 Please log in as guest with password guest if prompted From rt at openssl.org Wed Jun 29 08:12:00 2016 From: rt at openssl.org (Matt Caswell via RT) Date: Wed, 29 Jun 2016 08:12:00 +0000 Subject: [openssl-dev] [openssl.org #4589] Resolved: simplifying writing code that is 1.0.x and 1.1.x compatible In-Reply-To: <577382CE.8080907@openssl.org> References: <57719187.9020802@waldmann-edv.de> <5772F5B1.2060603@waldmann-edv.de> <1467185621.7792.17.camel@redhat.com> <577382CE.8080907@openssl.org> Message-ID: On 29/06/16 08:33, Tomas Mraz via RT wrote: > On ?t, 2016-06-28 at 22:10 +0000, Thomas Waldmann via RT wrote: >> On 06/28/2016 11:18 PM, Kurt Roeckx via RT wrote: >>> >>> On Mon, Jun 27, 2016 at 08:50:43PM +0000, Thomas Waldmann via RT >>> wrote: >>>> >>>> I didn't ask where to get the missing code from, I asked whether >>>> you >>>> maybe want to make life simpler for people by adding this to >>>> 1.0.x >>>> rather than having a thousand software developers copy and >>>> pasting it >>>> into their projects. >>> I think this will not actually make life easier. People using a >>> 1.0.x version are not always using the latest 1.0.x version. >> Aren't they? >> >> Don't they use 1.0.xLATEST rather soon, due to security fixes? No, many do not. Most distros just cherry-pick the actual security fixes. >> >> And in case some dist maintainer chooses to rather backport, couldn't >> they also backport the added function if it is documented as "openssl >> 1.1.x migration support" or so? >> >> We aren't talking about incompatible changes, just adding 2 trivial >> functions that were not there yet (but should have been there, when >> looking at the rest of the API). Well its 2 functions that you are interested in. There are actually quite a lot of these types of things. > You might get such kind of backport to something that still evolves > such as (RHEL/CentOS 7) however you would not get it in older releases > (RHEL/CentOS 5 and most probably RHEL/CentOS 6 either). > > So you will still be facing the issue that there are environments where > someone wants to build your code and these functions are not present. Exactly! I do think it would be a good idea to create a separate stand alone "openssl-compat" repo on github somewhere, i.e. to just provide the missing functions and translate them into the 1.0.2 way of doing things. I'd create such a thing myself, but I'm fully focussed on just getting 1.1.0 out the door! Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4589 Please log in as guest with password guest if prompted From rt at openssl.org Wed Jun 29 09:04:12 2016 From: rt at openssl.org (noloader@gmail.com via RT) Date: Wed, 29 Jun 2016 09:04:12 +0000 Subject: [openssl-dev] [openssl.org #4598] OpenSSL fails to Configure on Windows 10 In-Reply-To: References: Message-ID: Working on a Windows 10, 32-bit netbook. HEAD, 03cb37acec0c23a01bee4357cd59ec9f97e528ba. It looks like configure dies if it can't find NASM. Perhpas it would be better to automatically add no-asm. Once NASM is added, Configure dies because it tries to write outside %HOME%. Windows 8 used to tolerate it and create the directories, but Windows 10 returns the access denied. A small nit: "Configure LIST" does not list VC-WIN32, VC-WIN64A or VC-WIN64I. VC-WIN32 is present in WIN.NOTES, but the other selections are also missing. Also, the configuration target VC-WIN32 is listed twice in WIN.NOTES, which appears to be a copy/paste error. If I am parsing things correctly, one of them should be VC-WIN32 and the other should be VC-WIN64A or VC-WIN64I. ********** C:\Users\Jeffrey Walton\openssl>perl .\Configure VC-WIN32 Configuring OpenSSL version 1.1.0-pre6-dev (0x0x10100006L) no-asan [default] OPENSSL_NO_ASAN (skip dir) no-crypto-mdebug [default] OPENSSL_NO_CRYPTO_MDEBUG (skip dir) no-crypto-mdebug-backtrace [default] 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-fuzz-afl [default] OPENSSL_NO_FUZZ_AFL (skip dir) no-fuzz-libfuzzer [default] OPENSSL_NO_FUZZ_LIBFUZZER (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-ssl-trace [default] OPENSSL_NO_SSL_TRACE (skip dir) no-ssl3 [default] OPENSSL_NO_SSL3 (skip dir) no-ssl3-method [default] OPENSSL_NO_SSL3_METHOD (skip dir) no-ubsan [default] OPENSSL_NO_UBSAN (skip dir) no-unit-test [default] OPENSSL_NO_UNIT_TEST (skip dir) no-weak-ssl-ciphers [default] OPENSSL_NO_WEAK_SSL_CIPHERS (skip dir) no-zlib [default] no-zlib-dynamic [default] Configuring for VC-WIN32 NASM not found - please read INSTALL and NOTES.WIN for further details C:\Users\Jeffrey Walton\openssl>perl .\Configure VC-WIN32 no-asm Configuring OpenSSL version 1.1.0-pre6-dev (0x0x10100006L) no-asan [default] OPENSSL_NO_ASAN (skip dir) no-asm [option] OPENSSL_NO_ASM no-crypto-mdebug [default] OPENSSL_NO_CRYPTO_MDEBUG (skip dir) no-crypto-mdebug-backtrace [default] 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-fuzz-afl [default] OPENSSL_NO_FUZZ_AFL (skip dir) no-fuzz-libfuzzer [default] OPENSSL_NO_FUZZ_LIBFUZZER (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-ssl-trace [default] OPENSSL_NO_SSL_TRACE (skip dir) no-ssl3 [default] OPENSSL_NO_SSL3 (skip dir) no-ssl3-method [default] OPENSSL_NO_SSL3_METHOD (skip dir) no-ubsan [default] OPENSSL_NO_UBSAN (skip dir) no-unit-test [default] OPENSSL_NO_UNIT_TEST (skip dir) no-weak-ssl-ciphers [default] OPENSSL_NO_WEAK_SSL_CIPHERS (skip dir) no-zlib [default] no-zlib-dynamic [default] Configuring for VC-WIN32 mkdir C:\Users\Jeffrey: Permission denied; Access is denied at .\Configure line 1314. C:\Users\Jeffrey Walton\openssl> -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4598 Please log in as guest with password guest if prompted From rt at openssl.org Wed Jun 29 10:49:03 2016 From: rt at openssl.org (Hubert Kario via RT) Date: Wed, 29 Jun 2016 10:49:03 +0000 Subject: [openssl-dev] [openssl.org #4589] Resolved: simplifying writing code that is 1.0.x and 1.1.x compatible In-Reply-To: <5225932.LPjtsRFWka@pintsize.usersys.redhat.com> References: <8921874b39544ae98ab59330861ff8b7@usma1ex-dag1mb1.msg.corp.akamai.com> <5225932.LPjtsRFWka@pintsize.usersys.redhat.com> Message-ID: On Tuesday 28 June 2016 18:03:39 Salz, Rich via RT wrote: > > what about Debian CVE-2008-0166 like scenario? > > So far that kind of thing seems unlikely, but maybe I'm > missing the point your trying to make? even if unlikely, it would make me sleep better at night knowing that at least one of the core developers did take a look at it I mean, sure, the same code will need to be written by application developers wanting compatibility and it will not be reviewed by OpenSSL developers, but there's a difference between few applications using bad code and all applications that want backwards API compatibility using bad code -- 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=4589 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 Wed Jun 29 13:48:11 2016 From: rt at openssl.org (Rich Salz via RT) Date: Wed, 29 Jun 2016 13:48:11 +0000 Subject: [openssl-dev] [openssl.org #4594] openssl s_client issue on windows platform In-Reply-To: <3ac4ed516b2e97d84920e45e0c34a66e@mail.gmail.com> References: <3ac4ed516b2e97d84920e45e0c34a66e@mail.gmail.com> Message-ID: Duplicate of RT 3464 -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4594 Please log in as guest with password guest if prompted From deengert at gmail.com Wed Jun 29 14:05:48 2016 From: deengert at gmail.com (Douglas E Engert) Date: Wed, 29 Jun 2016 09:05:48 -0500 Subject: [openssl-dev] [openssl.org #4589] Resolved: simplifying writing code that is 1.0.x and 1.1.x compatible In-Reply-To: References: <57719187.9020802@waldmann-edv.de> <0189c67d54214f39adb5006c3563dadf@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <401e6185-93b8-6625-7570-f052d56858be@gmail.com> On 6/27/2016 3:57 PM, Salz, Rich via RT wrote: >> But obviously I was expecting too much... > Sorry you're not pleased. Not sure what to say -- you get what you pay for? Maybe someone will come up with a "openssl-102-compat" package? OpenSC has been looking at the approach - program to 1.1.0 and add a sc_ossl_compat.h that uses inline routines for older version of openssl going back to 0.9.7 (not my choice, but someone asked for 0.9.7) Only changes needed by OpenSC are defined, but it is a start. Some #ifdefs are still needed, but only a handful, and could be isolated to the sc_ossl_compat.h. See https://github.com/dengert/OpenSC/commit/8e00355cbcb42deefc2c44e910f23aa3d137f298 > > -- Douglas E. Engert From janjust at nikhef.nl Wed Jun 29 14:35:30 2016 From: janjust at nikhef.nl (Jan Just Keijser) Date: Wed, 29 Jun 2016 16:35:30 +0200 Subject: [openssl-dev] build issue with openssl 1.1.0-pre5 Message-ID: <5773DCB2.8040003@nikhef.nl> hi all, I'm the maintainer of grid-proxy-verify, a grid-tool that uses "plain" openssl to verify a grid proxy (either RFC3820 or legacy Globus proxy). This tool http://www.nikhef.nl/~janjust/proxy-verify/ and http://www.nikhef.nl/~janjust/proxy-verify/grid-proxy-verify.c builds without any warnings with openssl 0.9.8 and 1.0.x, e.g. using gcc -Wall -pedantic -c -o grid-proxy-verify.o grid-proxy-verify.c but with 1.1.0 I run into all sorts of issues (see the bottom of this email). Most of these have to do with members of structs becoming opaque but especially the disappearance of the check_issued callback is worrisome, as that callback is crucial for verifying proxy certificates. How should I modify my code so that it builds and links with openssl 1.1.0? thx for any pointers, JJK / Jan Just Keijser $ gcc -I openssl-1.1.0-pre5/include -o grid-proxy-verify.o grid-proxy-verify.c grid-proxy-verify.c: In function ?grid_X509_check_issued_wrapper?: grid-proxy-verify.c:337:14: error: dereferencing pointer to incomplete type if (!(ctx->param->flags & X509_V_FLAG_CB_ISSUER_CHECK)) return 0; ^ grid-proxy-verify.c:341:8: error: dereferencing pointer to incomplete type ctx->error = ret; ^ grid-proxy-verify.c:342:8: error: dereferencing pointer to incomplete type ctx->current_cert = x; ^ grid-proxy-verify.c:343:8: error: dereferencing pointer to incomplete type ctx->current_issuer = issuer; ^ grid-proxy-verify.c:344:15: error: dereferencing pointer to incomplete type return ctx->verify_cb(0, ctx); ^ grid-proxy-verify.c: In function ?grid_verifyProxy?: grid-proxy-verify.c:529:25: error: dereferencing pointer to incomplete type if (pkey->type == EVP_PKEY_RSA) ^ grid-proxy-verify.c:531:56: error: dereferencing pointer to incomplete type int key_strength = BN_num_bits(pkey->pkey.rsa->n); ^ grid-proxy-verify.c: In function ?grid_X509_verify_callback?: grid-proxy-verify.c:593:16: error: dereferencing pointer to incomplete type ctx->error = errnum; ^ grid-proxy-verify.c:620:21: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] certstack = (STACK_OF(X509) *) X509_STORE_CTX_get_chain( ctx ); ^ grid-proxy-verify.c:627:12: error: dereferencing pointer to incomplete type ctx->error = errnum; ^ In file included from openssl-1.1.0-pre5/include/openssl/x509.h:363:0, from grid-proxy-verify.c:38: grid-proxy-verify.c: In function ?grid_verifyCert?: openssl-1.1.0-pre5/include/openssl/x509_vfy.h:107:56: error: dereferencing pointer to incomplete type # define X509_STORE_set_verify_cb_func(ctx,func) ((ctx)->verify_cb=(func)) ^ grid-proxy-verify.c:686:5: note: in expansion of macro ?X509_STORE_set_verify_cb_func? X509_STORE_set_verify_cb_func (store, grid_X509_verify_callback); ^ grid-proxy-verify.c:720:10: error: dereferencing pointer to incomplete type store->check_issued = grid_X509_check_issued_wrapper; ^ grid-proxy-verify.c:783:9: error: dereferencing pointer to incomplete type cert->ex_flags |= EXFLAG_PROXY; ^ grid-proxy-verify.c:785:16: error: dereferencing pointer to incomplete type verify_ctx -> param -> depth = depth + 5; ^ grid-proxy-verify.c:794:25: error: dereferencing pointer to incomplete type ret = verify_ctx->error; ^ grid-proxy-verify.c: In function ?main?: grid-proxy-verify.c:965:5: warning: ?ERR_remove_state? is deprecated (declared at openssl-1.1.0-pre5/include/openssl/err.h:363) [-Wdeprecated-declarations] ERR_remove_state(0); ^ From rt at openssl.org Wed Jun 29 15:24:18 2016 From: rt at openssl.org (Hubert Kario via RT) Date: Wed, 29 Jun 2016 15:24:18 +0000 Subject: [openssl-dev] [openssl.org #4600] Core dump when using -keymatexport and receiving a handshake alert In-Reply-To: <5339913.Psn8H2xh9u@pintsize.usersys.redhat.com> References: <5339913.Psn8H2xh9u@pintsize.usersys.redhat.com> Message-ID: when s_client receives alert during handshake and is configured to export keying material, it will crash with a segmentation fault current 1.0.2 and master are affected reproducer: openssl s_client -keymatexport EXPORT-label -connect google.com:443 -cipher IDEA Result: CONNECTED(00000003) 140315545597592:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:769: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 7 bytes and written 99 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : 0000 Session-ID: Session-ID-ctx: Master-Key: Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1467213777 Timeout : 300 (sec) Verify return code: 0 (ok) Keying material exporter: Label: 'EXPORT-label' Length: 20 bytes Segmentation fault (core dumped) -- 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=4600 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 deengert at gmail.com Wed Jun 29 15:47:26 2016 From: deengert at gmail.com (Douglas E Engert) Date: Wed, 29 Jun 2016 10:47:26 -0500 Subject: [openssl-dev] build issue with openssl 1.1.0-pre5 In-Reply-To: <5773DCB2.8040003@nikhef.nl> References: <5773DCB2.8040003@nikhef.nl> Message-ID: <72e0848b-aca0-8f76-1d86-1e3efcb11dbf@gmail.com> Good to hear that grid proxy and RFC3820 are still being used. I worked on both before I retired a few years ago from Argonne Nat Lab. I see you have commented on the OpenSC mailinig list too. In a note earlier today I said: OpenSC has been looking at the approach - program to 1.1.0 and add a sc_ossl_compat.h that uses inline routines for older version of openssl going back to 0.9.7 (not my choice, but someone asked for 0.9.7) Only changes needed by OpenSC are defined, but it is a start. Some #ifdefs are still needed, but only a handful, and could be isolated to the sc_ossl_compat.h. See https://github.com/dengert/OpenSC/commit/8e00355cbcb42deefc2c44e910f23aa3d137f298 This does not address all your issues because OpenSC is not using X509_STORE_CTX but have a look at the BN_ and pkey->type == EVP_PKEY_RSA type issues. On 6/29/2016 9:35 AM, Jan Just Keijser wrote: > hi all, > > I'm the maintainer of grid-proxy-verify, a grid-tool that uses "plain" openssl to verify a grid proxy (either RFC3820 or legacy Globus proxy). This tool > http://www.nikhef.nl/~janjust/proxy-verify/ > and > http://www.nikhef.nl/~janjust/proxy-verify/grid-proxy-verify.c > builds without any warnings with openssl 0.9.8 and 1.0.x, e.g. using > gcc -Wall -pedantic -c -o grid-proxy-verify.o grid-proxy-verify.c > but with 1.1.0 I run into all sorts of issues (see the bottom of this email). Most of these have to do with members of structs becoming opaque but especially the disappearance of the check_issued > callback is worrisome, as that callback is crucial for verifying proxy certificates. How should I modify my code so that it builds and links with openssl 1.1.0? > > > thx for any pointers, > > JJK / Jan Just Keijser > > $ gcc -I openssl-1.1.0-pre5/include -o grid-proxy-verify.o grid-proxy-verify.c > grid-proxy-verify.c: In function ?grid_X509_check_issued_wrapper?: > grid-proxy-verify.c:337:14: error: dereferencing pointer to incomplete type > if (!(ctx->param->flags & X509_V_FLAG_CB_ISSUER_CHECK)) return 0; > ^ > grid-proxy-verify.c:341:8: error: dereferencing pointer to incomplete type > ctx->error = ret; > ^ > grid-proxy-verify.c:342:8: error: dereferencing pointer to incomplete type > ctx->current_cert = x; > ^ > grid-proxy-verify.c:343:8: error: dereferencing pointer to incomplete type > ctx->current_issuer = issuer; > ^ > grid-proxy-verify.c:344:15: error: dereferencing pointer to incomplete type > return ctx->verify_cb(0, ctx); > ^ > grid-proxy-verify.c: In function ?grid_verifyProxy?: > grid-proxy-verify.c:529:25: error: dereferencing pointer to incomplete type > if (pkey->type == EVP_PKEY_RSA) > ^ > grid-proxy-verify.c:531:56: error: dereferencing pointer to incomplete type > int key_strength = BN_num_bits(pkey->pkey.rsa->n); > ^ > grid-proxy-verify.c: In function ?grid_X509_verify_callback?: > grid-proxy-verify.c:593:16: error: dereferencing pointer to incomplete type > ctx->error = errnum; > ^ > grid-proxy-verify.c:620:21: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] > certstack = (STACK_OF(X509) *) X509_STORE_CTX_get_chain( ctx ); > ^ > grid-proxy-verify.c:627:12: error: dereferencing pointer to incomplete type > ctx->error = errnum; > ^ > In file included from openssl-1.1.0-pre5/include/openssl/x509.h:363:0, > from grid-proxy-verify.c:38: > grid-proxy-verify.c: In function ?grid_verifyCert?: > openssl-1.1.0-pre5/include/openssl/x509_vfy.h:107:56: error: dereferencing pointer to incomplete type > # define X509_STORE_set_verify_cb_func(ctx,func) ((ctx)->verify_cb=(func)) > ^ > grid-proxy-verify.c:686:5: note: in expansion of macro ?X509_STORE_set_verify_cb_func? > X509_STORE_set_verify_cb_func (store, grid_X509_verify_callback); > ^ > grid-proxy-verify.c:720:10: error: dereferencing pointer to incomplete type > store->check_issued = grid_X509_check_issued_wrapper; > ^ > grid-proxy-verify.c:783:9: error: dereferencing pointer to incomplete type > cert->ex_flags |= EXFLAG_PROXY; > ^ > grid-proxy-verify.c:785:16: error: dereferencing pointer to incomplete type > verify_ctx -> param -> depth = depth + 5; > ^ > grid-proxy-verify.c:794:25: error: dereferencing pointer to incomplete type > ret = verify_ctx->error; > ^ > grid-proxy-verify.c: In function ?main?: > grid-proxy-verify.c:965:5: warning: ?ERR_remove_state? is deprecated (declared at openssl-1.1.0-pre5/include/openssl/err.h:363) [-Wdeprecated-declarations] > ERR_remove_state(0); > ^ > -- Douglas E. Engert From matt at openssl.org Wed Jun 29 15:59:47 2016 From: matt at openssl.org (Matt Caswell) Date: Wed, 29 Jun 2016 16:59:47 +0100 Subject: [openssl-dev] build issue with openssl 1.1.0-pre5 In-Reply-To: <5773DCB2.8040003@nikhef.nl> References: <5773DCB2.8040003@nikhef.nl> Message-ID: <5773F073.3010704@openssl.org> On 29/06/16 15:35, Jan Just Keijser wrote: > hi all, > > I'm the maintainer of grid-proxy-verify, a grid-tool that uses "plain" > openssl to verify a grid proxy (either RFC3820 or legacy Globus proxy). > This tool > http://www.nikhef.nl/~janjust/proxy-verify/ > and > http://www.nikhef.nl/~janjust/proxy-verify/grid-proxy-verify.c > builds without any warnings with openssl 0.9.8 and 1.0.x, e.g. using > gcc -Wall -pedantic -c -o grid-proxy-verify.o grid-proxy-verify.c > but with 1.1.0 I run into all sorts of issues (see the bottom of this > email). Most of these have to do with members of structs becoming opaque > but especially the disappearance of the check_issued callback is > worrisome, as that callback is crucial for verifying proxy certificates. > How should I modify my code so that it builds and links with openssl 1.1.0? There have been lots of structures made opaque. Where as before you might have done this: FOO x; FOO_init(x); x->bar = 1; ... FOO_cleanup(x); Now you might have to do: FOO *x; x = FOO_new(); if (x == NULL) goto err; FOO_set_bar(x, 1); ... FOO_free(x); Making these changes will fix most of the "incomplete type" issues you are seeing. This issue: > grid-proxy-verify.c: In function ?grid_verifyCert?: > openssl-1.1.0-pre5/include/openssl/x509_vfy.h:107:56: error: > dereferencing pointer to incomplete type > # define X509_STORE_set_verify_cb_func(ctx,func) ((ctx)->verify_cb=(func)) > ^ > grid-proxy-verify.c:686:5: note: in expansion of macro > ?X509_STORE_set_verify_cb_func? > X509_STORE_set_verify_cb_func (store, grid_X509_verify_callback); is actually a bug in pre5. Fixed in the latest master version. > grid-proxy-verify.c:965:5: warning: ?ERR_remove_state? is deprecated > (declared at openssl-1.1.0-pre5/include/openssl/err.h:363) > [-Wdeprecated-declarations] > ERR_remove_state(0); ERR_remove_state() was actually deprecated in OpenSSL 1.0.0. Its successor ERR_remove_thread_state() has also now been deprecated. You should not need to call this at all in OpenSSL 1.1.0 - it can be removed. The library is auto-deinitialised (see https://www.openssl.org/docs/manmaster/crypto/OPENSSL_init_crypto.html) The "check_issued" thing looks like a possible missing accessor function(s) (if so please raise a GitHub Issue). Matt > > > thx for any pointers, > > JJK / Jan Just Keijser > > $ gcc -I openssl-1.1.0-pre5/include -o grid-proxy-verify.o > grid-proxy-verify.c > grid-proxy-verify.c: In function ?grid_X509_check_issued_wrapper?: > grid-proxy-verify.c:337:14: error: dereferencing pointer to incomplete type > if (!(ctx->param->flags & X509_V_FLAG_CB_ISSUER_CHECK)) return 0; > ^ > grid-proxy-verify.c:341:8: error: dereferencing pointer to incomplete type > ctx->error = ret; > ^ > grid-proxy-verify.c:342:8: error: dereferencing pointer to incomplete type > ctx->current_cert = x; > ^ > grid-proxy-verify.c:343:8: error: dereferencing pointer to incomplete type > ctx->current_issuer = issuer; > ^ > grid-proxy-verify.c:344:15: error: dereferencing pointer to incomplete type > return ctx->verify_cb(0, ctx); > ^ > grid-proxy-verify.c: In function ?grid_verifyProxy?: > grid-proxy-verify.c:529:25: error: dereferencing pointer to incomplete type > if (pkey->type == EVP_PKEY_RSA) > ^ > grid-proxy-verify.c:531:56: error: dereferencing pointer to incomplete type > int key_strength = BN_num_bits(pkey->pkey.rsa->n); > ^ > grid-proxy-verify.c: In function ?grid_X509_verify_callback?: > grid-proxy-verify.c:593:16: error: dereferencing pointer to incomplete type > ctx->error = errnum; > ^ > grid-proxy-verify.c:620:21: warning: cast to pointer from integer of > different size [-Wint-to-pointer-cast] > certstack = (STACK_OF(X509) *) X509_STORE_CTX_get_chain( ctx ); > ^ > grid-proxy-verify.c:627:12: error: dereferencing pointer to incomplete type > ctx->error = errnum; > ^ > In file included from openssl-1.1.0-pre5/include/openssl/x509.h:363:0, > from grid-proxy-verify.c:38: > grid-proxy-verify.c: In function ?grid_verifyCert?: > openssl-1.1.0-pre5/include/openssl/x509_vfy.h:107:56: error: > dereferencing pointer to incomplete type > # define X509_STORE_set_verify_cb_func(ctx,func) ((ctx)->verify_cb=(func)) > ^ > grid-proxy-verify.c:686:5: note: in expansion of macro > ?X509_STORE_set_verify_cb_func? > X509_STORE_set_verify_cb_func (store, grid_X509_verify_callback); > ^ > grid-proxy-verify.c:720:10: error: dereferencing pointer to incomplete type > store->check_issued = grid_X509_check_issued_wrapper; > ^ > grid-proxy-verify.c:783:9: error: dereferencing pointer to incomplete type > cert->ex_flags |= EXFLAG_PROXY; > ^ > grid-proxy-verify.c:785:16: error: dereferencing pointer to incomplete type > verify_ctx -> param -> depth = depth + 5; > ^ > grid-proxy-verify.c:794:25: error: dereferencing pointer to incomplete type > ret = verify_ctx->error; > ^ > grid-proxy-verify.c: In function ?main?: > grid-proxy-verify.c:965:5: warning: ?ERR_remove_state? is deprecated > (declared at openssl-1.1.0-pre5/include/openssl/err.h:363) > [-Wdeprecated-declarations] > ERR_remove_state(0); > ^ > From pbellino at mrv.com Wed Jun 29 19:00:02 2016 From: pbellino at mrv.com (Philip Bellino) Date: Wed, 29 Jun 2016 19:00:02 +0000 Subject: [openssl-dev] CVE-2016-2177 In-Reply-To: References: Message-ID: Rich, We have customers who are asking us to address this vulnerability as well as CVE-2016-2178. CVE-2016-2177 (s3_srvr.c, ssl_sess.c, t1_lib.c) CVE-2016-2178 (dsa_ossl.c). Do you see any reason why we should not go ahead and add these changes to our existing 1.0.2h code? Thanks, Phil -----Original Message----- From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Salz, Rich Sent: Tuesday, June 28, 2016 11:23 AM To: openssl-dev at openssl.org Subject: Re: [openssl-dev] CVE-2016-2177 >Will you be releasing 1.0.2i soon to address this issue? > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-2177 Please see https://www.openssl.org/blog/blog/2016/06/27/undefined-pointer-arithmetic/ Short answer: this is a LOW issue, and does not justify a release by itself. -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev [E-Banner] MRV Communications is a global supplier of packet and optical solutions that power the world?s largest networks. Our products combine innovative hardware with intelligent software to make networks smarter, faster and more efficient. The contents of this message, together with any attachments, are intended only for the use of the person(s) to whom they are addressed and may contain confidential and/or privileged information. If you are not the intended recipient, immediately advise the sender, delete this message and any attachments and note that any distribution, or copying of this message, or any attachment, is prohibited. From rsalz at akamai.com Wed Jun 29 19:03:23 2016 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 29 Jun 2016 19:03:23 +0000 Subject: [openssl-dev] CVE-2016-2177 In-Reply-To: References: Message-ID: <169c45fc45264087b4b327c3d9d51762@usma1ex-dag1mb1.msg.corp.akamai.com> No, just do it. -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz > -----Original Message----- > From: Philip Bellino [mailto:pbellino at mrv.com] > Sent: Wednesday, June 29, 2016 3:00 PM > To: openssl-dev at openssl.org > Subject: Re: [openssl-dev] CVE-2016-2177 > > Rich, > We have customers who are asking us to address this vulnerability as well as > CVE-2016-2178. > CVE-2016-2177 (s3_srvr.c, ssl_sess.c, t1_lib.c) > CVE-2016-2178 (dsa_ossl.c). > > Do you see any reason why we should not go ahead and add these changes > to our existing 1.0.2h code? > > Thanks, > Phil > > > > -----Original Message----- > From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of > Salz, Rich > Sent: Tuesday, June 28, 2016 11:23 AM > To: openssl-dev at openssl.org > Subject: Re: [openssl-dev] CVE-2016-2177 > > >Will you be releasing 1.0.2i soon to address this issue? > > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-2177 > > Please see https://www.openssl.org/blog/blog/2016/06/27/undefined- > pointer-arithmetic/ > > Short answer: this is a LOW issue, and does not justify a release by itself. > > -- > Senior Architect, Akamai Technologies > IM: richsalz at jabber.at Twitter: RichSalz > > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > [E-Banner] > > > MRV Communications is a global supplier of packet and optical solutions that > power the world?s largest networks. Our products combine innovative > hardware with intelligent software to make networks smarter, faster and > more efficient. > > > The contents of this message, together with any attachments, are intended > only for the use of the person(s) to whom they are addressed and may > contain confidential and/or privileged information. If you are not the > intended recipient, immediately advise the sender, delete this message and > any attachments and note that any distribution, or copying of this message, > or any attachment, is prohibited. > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From rt at openssl.org Wed Jun 29 21:16:31 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Wed, 29 Jun 2016 21:16:31 +0000 Subject: [openssl-dev] [openssl.org #1852] Invalid Proxy Certificates Pass Validation In-Reply-To: References: <49A81357.30509@switch.ch> <20160202014435.GM4987@mournblade.imrryr.org> Message-ID: On Mon Jun 20 19:37:41 2016, levitte wrote: > On Tue Feb 02 01:44:47 2016, openssl-dev at openssl.org wrote: > > 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. > > This has now been fixed in master, along with a pc pathlength checking > bug fix. > > The backport to 1.0.2 (and possibly 1.0.1) is still pending review. Fix merged into 1.0.2 Cheers, Richard -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=1852 Please log in as guest with password guest if prompted From rt at openssl.org Wed Jun 29 21:19:37 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Wed, 29 Jun 2016 21:19:37 +0000 Subject: [openssl-dev] [openssl.org #4598] OpenSSL fails to Configure on Windows 10 In-Reply-To: References: Message-ID: This has nothing to do with Windows 10 per se, it's the space-in-directory issue that's come back. I'm working on a solution that should avoid that problem more consistently, going forward. Cheers, Richard On Wed Jun 29 09:04:12 2016, noloader at gmail.com wrote: > Working on a Windows 10, 32-bit netbook. HEAD, > 03cb37acec0c23a01bee4357cd59ec9f97e528ba. > > It looks like configure dies if it can't find NASM. Perhpas it would > be better to automatically add no-asm. > > Once NASM is added, Configure dies because it tries to write outside > %HOME%. Windows 8 used to tolerate it and create the directories, but > Windows 10 returns the access denied. > > A small nit: "Configure LIST" does not list VC-WIN32, VC-WIN64A or > VC-WIN64I. VC-WIN32 is present in WIN.NOTES, but the other selections > are also missing. > > Also, the configuration target VC-WIN32 is listed twice in WIN.NOTES, > which appears to be a copy/paste error. If I am parsing things > correctly, one of them should be VC-WIN32 and the other should be > VC-WIN64A or VC-WIN64I. > > ********** > > C:\Users\Jeffrey Walton\openssl>perl .\Configure VC-WIN32 > Configuring OpenSSL version 1.1.0-pre6-dev (0x0x10100006L) > no-asan [default] OPENSSL_NO_ASAN (skip dir) > no-crypto-mdebug [default] OPENSSL_NO_CRYPTO_MDEBUG (skip dir) > no-crypto-mdebug-backtrace [default] > 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-fuzz-afl [default] OPENSSL_NO_FUZZ_AFL (skip dir) > no-fuzz-libfuzzer [default] OPENSSL_NO_FUZZ_LIBFUZZER (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-ssl-trace [default] OPENSSL_NO_SSL_TRACE (skip dir) > no-ssl3 [default] OPENSSL_NO_SSL3 (skip dir) > no-ssl3-method [default] OPENSSL_NO_SSL3_METHOD (skip dir) > no-ubsan [default] OPENSSL_NO_UBSAN (skip dir) > no-unit-test [default] OPENSSL_NO_UNIT_TEST (skip dir) > no-weak-ssl-ciphers [default] OPENSSL_NO_WEAK_SSL_CIPHERS (skip > dir) > no-zlib [default] > no-zlib-dynamic [default] > Configuring for VC-WIN32 > NASM not found - please read INSTALL and NOTES.WIN for further details > > C:\Users\Jeffrey Walton\openssl>perl .\Configure VC-WIN32 no-asm > Configuring OpenSSL version 1.1.0-pre6-dev (0x0x10100006L) > no-asan [default] OPENSSL_NO_ASAN (skip dir) > no-asm [option] OPENSSL_NO_ASM > no-crypto-mdebug [default] OPENSSL_NO_CRYPTO_MDEBUG (skip dir) > no-crypto-mdebug-backtrace [default] > 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-fuzz-afl [default] OPENSSL_NO_FUZZ_AFL (skip dir) > no-fuzz-libfuzzer [default] OPENSSL_NO_FUZZ_LIBFUZZER (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-ssl-trace [default] OPENSSL_NO_SSL_TRACE (skip dir) > no-ssl3 [default] OPENSSL_NO_SSL3 (skip dir) > no-ssl3-method [default] OPENSSL_NO_SSL3_METHOD (skip dir) > no-ubsan [default] OPENSSL_NO_UBSAN (skip dir) > no-unit-test [default] OPENSSL_NO_UNIT_TEST (skip dir) > no-weak-ssl-ciphers [default] OPENSSL_NO_WEAK_SSL_CIPHERS (skip > dir) > no-zlib [default] > no-zlib-dynamic [default] > Configuring for VC-WIN32 > mkdir C:\Users\Jeffrey: Permission denied; Access is denied at > .\Configure line 1314. > > C:\Users\Jeffrey Walton\openssl> -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4598 Please log in as guest with password guest if prompted From brian at briansmith.org Wed Jun 29 21:49:01 2016 From: brian at briansmith.org (Brian Smith) Date: Wed, 29 Jun 2016 11:49:01 -1000 Subject: [openssl-dev] A faster addition chain for use in P-256 inversion mod n Message-ID: Hi, I saw Vlad Krasnov's patch to optimize inversion mod n for the P-256 curve. Please see [1], which presents an addition chain that uses 9 fewer multiplications (but two more squarings, IIRC). I spent some non-trivial effort to optimize this chain, but I wouldn't be surprised to see somebody remove 3-4 more multiplications. I don't think you'll want to use the code directly, but I think you can make use of the math. The same code has an analogous addition chain for the P-384 curve, but it isn't optimized to the same extent. [1] https://github.com/briansmith/ring/commit/ad6528f98bd228208f93c179cbbae87604c282fe#diff-b0cdc11124e9960a1faeb7baa390b50fR76 Cheers, Brian -- https://briansmith.org/ From rt at openssl.org Wed Jun 29 23:10:19 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Wed, 29 Jun 2016 23:10:19 +0000 Subject: [openssl-dev] [openssl.org #1852] Invalid Proxy Certificates Pass Validation In-Reply-To: References: <49A81357.30509@switch.ch> <20160202014435.GM4987@mournblade.imrryr.org> Message-ID: On Wed Jun 29 21:16:31 2016, levitte wrote: > On Mon Jun 20 19:37:41 2016, levitte wrote: > > On Tue Feb 02 01:44:47 2016, openssl-dev at openssl.org wrote: > > > 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. > > > > This has now been fixed in master, along with a pc pathlength checking > > bug fix. > > > > The backport to 1.0.2 (and possibly 1.0.1) is still pending review. > > Fix merged into 1.0.2 ... and finally, fix merged into the 1.0.1 branch as well That closes this ticket. Cheers, Richard -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=1852 Please log in as guest with password guest if prompted From cata.vasile at nxp.com Thu Jun 30 09:15:48 2016 From: cata.vasile at nxp.com (Catalin Vasile) Date: Thu, 30 Jun 2016 09:15:48 +0000 Subject: [openssl-dev] aarch64 64bit build with linaro tools Message-ID: Hi, I'm trying to build a 64bit aarch64 OpenSSL library with linaro tools[1]. Whatever I try, the library compiles to the 32bit version. How do I get a 64bit library version? This is my config command: perl ./Configure -no-ssl3 --prefix=... --openssldir=/usr/lib/ssl --libdir=lib shared linux-aarch64 Here is its output: Configuring for linux-aarch64 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 [default] 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-weak-ssl-ciphers [default] OPENSSL_NO_WEAK_SSL_CIPHERS (skip dir) no-zlib [default] no-zlib-dynamic [default] IsMK1MF=0 CC =aarch64-linux-gnu-gcc --sysroot=.../openssl-upstream/gcc-linaro-4.9-2014.11-x86_64_aarch64-linux-gnu/libc -I.../openssl-upstream/gcc-linaro-4.9-2014.11-x86_64_aarch64-linux-gnu/lib/gcc/aarch64-linux-gnu/4.9.3/include -I.../openssl-upstream/gcc-linaro-4.9-2014.11-x86_64_aarch64-linux-gnu/aarch64-linux-gnu/include -I.../openssl-upstream/gcc-linaro-4.9-2014.11-x86_64_aarch64-linux-gnu/include -I.../openssl-upstream/gcc-linaro-4.9-2014.11-x86_64_aarch64-linux-gnu/libc/usr/include CFLAG =-fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -O3 -Wall -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM EX_LIBS =-ldl CPUID_OBJ =armcap.o arm64cpuid.o mem_clr.o BN_ASM =bn_asm.o EC_ASM = DES_ENC =des_enc.o fcrypt_b.o AES_ENC =aes_core.o aes_cbc.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-armv8.o sha256-armv8.o sha512-armv8.o RMD160_OBJ_ASM= CMLL_ENC =camellia.o cmll_misc.o cmll_cbc.o MODES_OBJ =ghashv8-armx.o ENGINES_OBJ = PROCESSOR = RANLIB =.../openssl-upstream/gcc-linaro-4.9-2014.11-x86_64_aarch64-linux-gnu/aarch64-linux-gnu/bin/ranlib ARFLAGS = PERL =/bin/perl SIXTY_FOUR_BIT_LONG mode DES_UNROLL used DES_INT used RC4 uses uchar RC4_CHUNK is unsigned long BF_PTR used Regards, Catalin Vasile [1] http://releases.linaro.org/14.11/components/toolchain/binaries/aarch64-linux-gnu/gcc-linaro-4.9-2014.11-x86_64_aarch64-linux-gnu.tar.xz From appro at openssl.org Thu Jun 30 11:32:14 2016 From: appro at openssl.org (Andy Polyakov) Date: Thu, 30 Jun 2016 13:32:14 +0200 Subject: [openssl-dev] aarch64 64bit build with linaro tools In-Reply-To: References: Message-ID: <5775033E.8030800@openssl.org> > I'm trying to build a 64bit aarch64 OpenSSL library with linaro tools[1]. > Whatever I try, the library compiles to the 32bit version. > How do I get a 64bit library version? I'm using very same toolchain, and I get as 64-bit AArch64 library as it can possibly get. Though truth be told I'm using it with scratchbox, which means that I let "somebody else" pass compiler flags such as -isystem --sysroot, as well as additional -I and -L. However I can confirm that scratchbox doesn't pass any magic flags that tell it to generate 64-bit module. On the contrary, I can confirm that 64-bit code generation is default one, and it is 32-bit code generation that takes additional flag, -mabi=ilp32. (Though I don't have ilp32 libraries to link with, so I never actually build linux-arm64ilp32 for myself.) Bottom line is that there is no evidence that it's not a problem specific to your setup, which in turn means that you would have to be the one to figure it out. Sorry... From cata.vasile at nxp.com Thu Jun 30 12:26:38 2016 From: cata.vasile at nxp.com (Catalin Vasile) Date: Thu, 30 Jun 2016 12:26:38 +0000 Subject: [openssl-dev] aarch64 64bit build with linaro tools In-Reply-To: <5775033E.8030800@openssl.org> References: , <5775033E.8030800@openssl.org> Message-ID: Sorry, it was my bad. I used some old scripts I made, where I only modified some env variables. From what I remembered the scripts also did the "make install", but I was wrong. The library and linaro tools worked perfectly. Catalin Vasile From: openssl-dev on behalf of Andy Polyakov Sent: Thursday, June 30, 2016 2:32 PM To: openssl-dev at openssl.org Subject: Re: [openssl-dev] aarch64 64bit build with linaro tools ? > I'm trying to build a 64bit aarch64 OpenSSL library with linaro tools[1]. > Whatever I try, the library compiles to the 32bit version. > How do I get a 64bit library version? I'm using very same toolchain, and I get as 64-bit AArch64 library as it can possibly get. Though truth be told I'm using it with scratchbox, which means that I let "somebody else" pass compiler flags such as -isystem --sysroot, as well as additional -I and -L. However I can confirm that scratchbox doesn't pass any magic flags that tell it to generate 64-bit module. On the contrary, I can confirm that 64-bit code generation is default one, and it is 32-bit code generation that takes additional flag, -mabi=ilp32. (Though I don't have ilp32 libraries to link with, so I never actually build linux-arm64ilp32 for myself.) Bottom line is that there is no evidence that it's not a problem specific to your setup, which in turn means that you would have to be the one to figure it out. Sorry... -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From rt at openssl.org Thu Jun 30 14:31:33 2016 From: rt at openssl.org (noloader@gmail.com via RT) Date: Thu, 30 Jun 2016 14:31:33 +0000 Subject: [openssl-dev] [openssl.org #4601] install_sw does not honor --openssldir In-Reply-To: References: Message-ID: Working on OS 10.8.5. Working from Master, 8a3c000c8f621cd01929313fcb7d0cc23fb516a6. Using the following configure line: $ KERNEL_BITS=64 ./config no-shared enable-ec_nistp_64_gcc_128 --openssldir=/usr/local/ssl/1.1.0 Later, when I attempt to compile: $ gcc -I/usr/local/ssl/1.1.0/include test.cc -o test.exe /usr/local/ssl/1.1.0/lib/libcrypto.a clang: error: no such file or directory: '/usr/local/ssl/1.1.0/lib/libcrypto.a' And: $ ls /usr/local/ssl/1.1.0/ misc ********** $ sudo make install_sw /opt/local/bin/perl5.22 "-I." -Mconfigdata "util/dofile.pl" \ "-oMakefile" crypto/include/internal/bn_conf.h.in > crypto/include/internal/bn_conf.h /opt/local/bin/perl5.22 "-I." -Mconfigdata "util/dofile.pl" \ "-oMakefile" crypto/include/internal/dso_conf.h.in > crypto/include/internal/dso_conf.h /opt/local/bin/perl5.22 "-I." -Mconfigdata "util/dofile.pl" \ "-oMakefile" include/openssl/opensslconf.h.in > include/openssl/opensslconf.h /opt/local/bin/perl5.22 util/mkbuildinf.pl "cc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_DYNAMIC_ENGINE -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/1.1.0\\\"\" -DENGINESDIR=\"\\\"/usr/local/lib/engines\\\"\" " "darwin64-x86_64-cc" > crypto/buildinf.h cc -Iinclude -I. -Icrypto/include -Icrypto -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_DYNAMIC_ENGINE -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/1.1.0\"" -DENGINESDIR="\"/usr/local/lib/engines\"" -O3 -D_REENTRANT -arch x86_64 -DL_ENDIAN -Wall -fPIC -MMD -MF crypto/cversion.d.tmp -MT crypto/cversion.o -c -o crypto/cversion.o crypto/cversion.c ar r libcrypto.a crypto/cversion.o /usr/bin/ranlib: file: libcrypto.a(async_null.o) has no symbols /usr/bin/ranlib: file: libcrypto.a(async_win.o) has no symbols /usr/bin/ranlib: file: libcrypto.a(cms_cd.o) has no symbols /usr/bin/ranlib: file: libcrypto.a(dso_dl.o) has no symbols /usr/bin/ranlib: file: libcrypto.a(dso_openssl.o) has no symbols /usr/bin/ranlib: file: libcrypto.a(dso_vms.o) has no symbols /usr/bin/ranlib: file: libcrypto.a(dso_win32.o) has no symbols /usr/bin/ranlib: file: libcrypto.a(ebcdic.o) has no symbols /usr/bin/ranlib: file: libcrypto.a(e_rc5.o) has no symbols /usr/bin/ranlib: file: libcrypto.a(m_md2.o) has no symbols /usr/bin/ranlib: file: libcrypto.a(rand_egd.o) has no symbols /usr/bin/ranlib: file: libcrypto.a(rand_vms.o) has no symbols /usr/bin/ranlib: file: libcrypto.a(rand_win.o) has no symbols /usr/bin/ranlib: file: libcrypto.a(threads_none.o) has no symbols /usr/bin/ranlib: file: libcrypto.a(threads_win.o) has no symbols ranlib -c libcrypto.a || echo Never mind. ranlib: file: libcrypto.a(async_null.o) has no symbols ranlib: file: libcrypto.a(async_win.o) has no symbols ranlib: file: libcrypto.a(cms_cd.o) has no symbols ranlib: file: libcrypto.a(dso_dl.o) has no symbols ranlib: file: libcrypto.a(dso_openssl.o) has no symbols ranlib: file: libcrypto.a(dso_vms.o) has no symbols ranlib: file: libcrypto.a(dso_win32.o) has no symbols ranlib: file: libcrypto.a(ebcdic.o) has no symbols ranlib: file: libcrypto.a(e_rc5.o) has no symbols ranlib: file: libcrypto.a(m_md2.o) has no symbols ranlib: file: libcrypto.a(rand_egd.o) has no symbols ranlib: file: libcrypto.a(rand_vms.o) has no symbols ranlib: file: libcrypto.a(rand_win.o) has no symbols ranlib: file: libcrypto.a(threads_none.o) has no symbols ranlib: file: libcrypto.a(threads_win.o) has no symbols rm -f apps/openssl make -f ./Makefile.shared -e \ PERL="/opt/local/bin/perl5.22" SRCDIR=. \ APPNAME=apps/openssl OBJECTS="apps/app_rand.o apps/apps.o apps/asn1pars.o apps/ca.o apps/ciphers.o apps/cms.o apps/crl.o apps/crl2p7.o apps/dgst.o apps/dhparam.o apps/dsa.o apps/dsaparam.o apps/ec.o apps/ecparam.o apps/enc.o apps/engine.o apps/errstr.o apps/gendsa.o apps/genpkey.o apps/genrsa.o apps/nseq.o apps/ocsp.o apps/openssl.o apps/opt.o apps/passwd.o apps/pkcs12.o apps/pkcs7.o apps/pkcs8.o apps/pkey.o apps/pkeyparam.o apps/pkeyutl.o apps/prime.o apps/rand.o apps/rehash.o apps/req.o apps/rsa.o apps/rsautl.o apps/s_cb.o apps/s_client.o apps/s_server.o apps/s_socket.o apps/s_time.o apps/sess_id.o apps/smime.o apps/speed.o apps/spkac.o apps/srp.o apps/ts.o apps/verify.o apps/version.o apps/x509.o" \ LIBDEPS='-Wl,-search_paths_first '" -L. -lssl -L. -lcrypto"' ' \ CC='cc' CFLAGS='-DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_DYNAMIC_ENGINE -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/1.1.0\"" -DENGINESDIR="\"/usr/local/lib/engines\"" -O3 -D_REENTRANT -arch x86_64 -DL_ENDIAN -Wall ' \ LDFLAGS='' LIBRPATH='/usr/local/lib' \ link_app. make[1]: Entering directory '/Users/jwalton/openssl' ( :; LIBDEPS="${LIBDEPS:--Wl,-search_paths_first -L. -lssl -L. -lcrypto }"; LDCMD="${LDCMD:-cc}"; LDFLAGS="${LDFLAGS:--DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_DYNAMIC_ENGINE -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/1.1.0\"" -DENGINESDIR="\"/usr/local/lib/engines\"" -O3 -D_REENTRANT -arch x86_64 -DL_ENDIAN -Wall }"; LIBPATH=`for x in $LIBDEPS; do echo $x; done | sed -e 's/^ *-L//;t' -e d | uniq`; LIBPATH=`echo $LIBPATH | sed -e 's/ /:/g'`; echo LD_LIBRARY_PATH=$LIBPATH:$LD_LIBRARY_PATH ${LDCMD} ${LDFLAGS} -o ${APPNAME:=apps/openssl} apps/app_rand.o apps/apps.o apps/asn1pars.o apps/ca.o apps/ciphers.o apps/cms.o apps/crl.o apps/crl2p7.o apps/dgst.o apps/dhparam.o apps/dsa.o apps/dsaparam.o apps/ec.o apps/ecparam.o apps/enc.o apps/engine.o apps/errstr.o apps/gendsa.o apps/genpkey.o apps/genrsa.o apps/nseq.o apps/ocsp.o apps/openssl.o apps/opt.o apps/passwd.o apps/pkcs12.o apps/pkcs7.o apps/pkcs8.o apps/pkey.o apps/pkeyparam.o apps/pkeyutl.o apps/prime.o apps/rand.o apps/rehash.o apps/req.o apps/rsa.o apps/rsautl.o apps/s_cb.o apps/s_client.o apps/s_server.o apps/s_socket.o apps/s_time.o apps/sess_id.o apps/smime.o apps/speed.o apps/spkac.o apps/srp.o apps/ts.o apps/verify.o apps/version.o apps/x509.o ${LIBDEPS}; LD_LIBRARY_PATH=$LIBPATH:$LD_LIBRARY_PATH ${LDCMD} ${LDFLAGS} -o ${APPNAME:=apps/openssl} apps/app_rand.o apps/apps.o apps/asn1pars.o apps/ca.o apps/ciphers.o apps/cms.o apps/crl.o apps/crl2p7.o apps/dgst.o apps/dhparam.o apps/dsa.o apps/dsaparam.o apps/ec.o apps/ecparam.o apps/enc.o apps/engine.o apps/errstr.o apps/gendsa.o apps/genpkey.o apps/genrsa.o apps/nseq.o apps/ocsp.o apps/openssl.o apps/opt.o apps/passwd.o apps/pkcs12.o apps/pkcs7.o apps/pkcs8.o apps/pkey.o apps/pkeyparam.o apps/pkeyutl.o apps/prime.o apps/rand.o apps/rehash.o apps/req.o apps/rsa.o apps/rsautl.o apps/s_cb.o apps/s_client.o apps/s_server.o apps/s_socket.o apps/s_time.o apps/sess_id.o apps/smime.o apps/speed.o apps/spkac.o apps/srp.o apps/ts.o apps/verify.o apps/version.o apps/x509.o ${LIBDEPS} ) LD_LIBRARY_PATH=.: cc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_DYNAMIC_ENGINE -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/1.1.0" -DENGINESDIR="/usr/local/lib/engines" -O3 -D_REENTRANT -arch x86_64 -DL_ENDIAN -Wall -o apps/openssl apps/app_rand.o apps/apps.o apps/asn1pars.o apps/ca.o apps/ciphers.o apps/cms.o apps/crl.o apps/crl2p7.o apps/dgst.o apps/dhparam.o apps/dsa.o apps/dsaparam.o apps/ec.o apps/ecparam.o apps/enc.o apps/engine.o apps/errstr.o apps/gendsa.o apps/genpkey.o apps/genrsa.o apps/nseq.o apps/ocsp.o apps/openssl.o apps/opt.o apps/passwd.o apps/pkcs12.o apps/pkcs7.o apps/pkcs8.o apps/pkey.o apps/pkeyparam.o apps/pkeyutl.o apps/prime.o apps/rand.o apps/rehash.o apps/req.o apps/rsa.o apps/rsautl.o apps/s_cb.o apps/s_client.o apps/s_server.o apps/s_socket.o apps/s_time.o apps/sess_id.o apps/smime.o apps/speed.o apps/spkac.o apps/srp.o apps/ts.o apps/verify.o apps/version.o apps/x509.o -Wl,-search_paths_first -L. -lssl -L. -lcrypto make[1]: Leaving directory '/Users/jwalton/openssl' *** Installing development files install ./include/openssl/aes.h -> /usr/local/include/openssl/aes.h install ./include/openssl/asn1.h -> /usr/local/include/openssl/asn1.h install ./include/openssl/asn1_mac.h -> /usr/local/include/openssl/asn1_mac.h install ./include/openssl/asn1t.h -> /usr/local/include/openssl/asn1t.h install ./include/openssl/async.h -> /usr/local/include/openssl/async.h install ./include/openssl/bio.h -> /usr/local/include/openssl/bio.h install ./include/openssl/blowfish.h -> /usr/local/include/openssl/blowfish.h install ./include/openssl/bn.h -> /usr/local/include/openssl/bn.h install ./include/openssl/buffer.h -> /usr/local/include/openssl/buffer.h install ./include/openssl/camellia.h -> /usr/local/include/openssl/camellia.h install ./include/openssl/cast.h -> /usr/local/include/openssl/cast.h install ./include/openssl/cmac.h -> /usr/local/include/openssl/cmac.h install ./include/openssl/cms.h -> /usr/local/include/openssl/cms.h install ./include/openssl/comp.h -> /usr/local/include/openssl/comp.h install ./include/openssl/conf.h -> /usr/local/include/openssl/conf.h install ./include/openssl/conf_api.h -> /usr/local/include/openssl/conf_api.h install ./include/openssl/crypto.h -> /usr/local/include/openssl/crypto.h install ./include/openssl/ct.h -> /usr/local/include/openssl/ct.h install ./include/openssl/des.h -> /usr/local/include/openssl/des.h install ./include/openssl/dh.h -> /usr/local/include/openssl/dh.h install ./include/openssl/dsa.h -> /usr/local/include/openssl/dsa.h install ./include/openssl/dtls1.h -> /usr/local/include/openssl/dtls1.h install ./include/openssl/e_os2.h -> /usr/local/include/openssl/e_os2.h install ./include/openssl/ebcdic.h -> /usr/local/include/openssl/ebcdic.h install ./include/openssl/ec.h -> /usr/local/include/openssl/ec.h install ./include/openssl/ecdh.h -> /usr/local/include/openssl/ecdh.h install ./include/openssl/ecdsa.h -> /usr/local/include/openssl/ecdsa.h install ./include/openssl/engine.h -> /usr/local/include/openssl/engine.h install ./include/openssl/err.h -> /usr/local/include/openssl/err.h install ./include/openssl/evp.h -> /usr/local/include/openssl/evp.h install ./include/openssl/hmac.h -> /usr/local/include/openssl/hmac.h install ./include/openssl/idea.h -> /usr/local/include/openssl/idea.h install ./include/openssl/kdf.h -> /usr/local/include/openssl/kdf.h install ./include/openssl/lhash.h -> /usr/local/include/openssl/lhash.h install ./include/openssl/md2.h -> /usr/local/include/openssl/md2.h install ./include/openssl/md4.h -> /usr/local/include/openssl/md4.h install ./include/openssl/md5.h -> /usr/local/include/openssl/md5.h install ./include/openssl/mdc2.h -> /usr/local/include/openssl/mdc2.h install ./include/openssl/modes.h -> /usr/local/include/openssl/modes.h install ./include/openssl/obj_mac.h -> /usr/local/include/openssl/obj_mac.h install ./include/openssl/objects.h -> /usr/local/include/openssl/objects.h install ./include/openssl/ocsp.h -> /usr/local/include/openssl/ocsp.h install ./include/openssl/opensslconf.h -> /usr/local/include/openssl/opensslconf.h install ./include/openssl/opensslv.h -> /usr/local/include/openssl/opensslv.h install ./include/openssl/ossl_typ.h -> /usr/local/include/openssl/ossl_typ.h install ./include/openssl/pem.h -> /usr/local/include/openssl/pem.h install ./include/openssl/pem2.h -> /usr/local/include/openssl/pem2.h install ./include/openssl/pkcs12.h -> /usr/local/include/openssl/pkcs12.h install ./include/openssl/pkcs7.h -> /usr/local/include/openssl/pkcs7.h install ./include/openssl/rand.h -> /usr/local/include/openssl/rand.h install ./include/openssl/rc2.h -> /usr/local/include/openssl/rc2.h install ./include/openssl/rc4.h -> /usr/local/include/openssl/rc4.h install ./include/openssl/rc5.h -> /usr/local/include/openssl/rc5.h install ./include/openssl/ripemd.h -> /usr/local/include/openssl/ripemd.h install ./include/openssl/rsa.h -> /usr/local/include/openssl/rsa.h install ./include/openssl/safestack.h -> /usr/local/include/openssl/safestack.h install ./include/openssl/seed.h -> /usr/local/include/openssl/seed.h install ./include/openssl/sha.h -> /usr/local/include/openssl/sha.h install ./include/openssl/srp.h -> /usr/local/include/openssl/srp.h install ./include/openssl/srtp.h -> /usr/local/include/openssl/srtp.h install ./include/openssl/ssl.h -> /usr/local/include/openssl/ssl.h install ./include/openssl/ssl2.h -> /usr/local/include/openssl/ssl2.h install ./include/openssl/ssl3.h -> /usr/local/include/openssl/ssl3.h install ./include/openssl/stack.h -> /usr/local/include/openssl/stack.h install ./include/openssl/symhacks.h -> /usr/local/include/openssl/symhacks.h install ./include/openssl/tls1.h -> /usr/local/include/openssl/tls1.h install ./include/openssl/ts.h -> /usr/local/include/openssl/ts.h install ./include/openssl/txt_db.h -> /usr/local/include/openssl/txt_db.h install ./include/openssl/ui.h -> /usr/local/include/openssl/ui.h install ./include/openssl/whrlpool.h -> /usr/local/include/openssl/whrlpool.h install ./include/openssl/x509.h -> /usr/local/include/openssl/x509.h install ./include/openssl/x509_vfy.h -> /usr/local/include/openssl/x509_vfy.h install ./include/openssl/x509v3.h -> /usr/local/include/openssl/x509v3.h install ./include/openssl/aes.h -> /usr/local/include/openssl/aes.h install ./include/openssl/asn1.h -> /usr/local/include/openssl/asn1.h install ./include/openssl/asn1_mac.h -> /usr/local/include/openssl/asn1_mac.h install ./include/openssl/asn1t.h -> /usr/local/include/openssl/asn1t.h install ./include/openssl/async.h -> /usr/local/include/openssl/async.h install ./include/openssl/bio.h -> /usr/local/include/openssl/bio.h install ./include/openssl/blowfish.h -> /usr/local/include/openssl/blowfish.h install ./include/openssl/bn.h -> /usr/local/include/openssl/bn.h install ./include/openssl/buffer.h -> /usr/local/include/openssl/buffer.h install ./include/openssl/camellia.h -> /usr/local/include/openssl/camellia.h install ./include/openssl/cast.h -> /usr/local/include/openssl/cast.h install ./include/openssl/cmac.h -> /usr/local/include/openssl/cmac.h install ./include/openssl/cms.h -> /usr/local/include/openssl/cms.h install ./include/openssl/comp.h -> /usr/local/include/openssl/comp.h install ./include/openssl/conf.h -> /usr/local/include/openssl/conf.h install ./include/openssl/conf_api.h -> /usr/local/include/openssl/conf_api.h install ./include/openssl/crypto.h -> /usr/local/include/openssl/crypto.h install ./include/openssl/ct.h -> /usr/local/include/openssl/ct.h install ./include/openssl/des.h -> /usr/local/include/openssl/des.h install ./include/openssl/dh.h -> /usr/local/include/openssl/dh.h install ./include/openssl/dsa.h -> /usr/local/include/openssl/dsa.h install ./include/openssl/dtls1.h -> /usr/local/include/openssl/dtls1.h install ./include/openssl/e_os2.h -> /usr/local/include/openssl/e_os2.h install ./include/openssl/ebcdic.h -> /usr/local/include/openssl/ebcdic.h install ./include/openssl/ec.h -> /usr/local/include/openssl/ec.h install ./include/openssl/ecdh.h -> /usr/local/include/openssl/ecdh.h install ./include/openssl/ecdsa.h -> /usr/local/include/openssl/ecdsa.h install ./include/openssl/engine.h -> /usr/local/include/openssl/engine.h install ./include/openssl/err.h -> /usr/local/include/openssl/err.h install ./include/openssl/evp.h -> /usr/local/include/openssl/evp.h install ./include/openssl/hmac.h -> /usr/local/include/openssl/hmac.h install ./include/openssl/idea.h -> /usr/local/include/openssl/idea.h install ./include/openssl/kdf.h -> /usr/local/include/openssl/kdf.h install ./include/openssl/lhash.h -> /usr/local/include/openssl/lhash.h install ./include/openssl/md2.h -> /usr/local/include/openssl/md2.h install ./include/openssl/md4.h -> /usr/local/include/openssl/md4.h install ./include/openssl/md5.h -> /usr/local/include/openssl/md5.h install ./include/openssl/mdc2.h -> /usr/local/include/openssl/mdc2.h install ./include/openssl/modes.h -> /usr/local/include/openssl/modes.h install ./include/openssl/obj_mac.h -> /usr/local/include/openssl/obj_mac.h install ./include/openssl/objects.h -> /usr/local/include/openssl/objects.h install ./include/openssl/ocsp.h -> /usr/local/include/openssl/ocsp.h install ./include/openssl/opensslconf.h -> /usr/local/include/openssl/opensslconf.h install ./include/openssl/opensslv.h -> /usr/local/include/openssl/opensslv.h install ./include/openssl/ossl_typ.h -> /usr/local/include/openssl/ossl_typ.h install ./include/openssl/pem.h -> /usr/local/include/openssl/pem.h install ./include/openssl/pem2.h -> /usr/local/include/openssl/pem2.h install ./include/openssl/pkcs12.h -> /usr/local/include/openssl/pkcs12.h install ./include/openssl/pkcs7.h -> /usr/local/include/openssl/pkcs7.h install ./include/openssl/rand.h -> /usr/local/include/openssl/rand.h install ./include/openssl/rc2.h -> /usr/local/include/openssl/rc2.h install ./include/openssl/rc4.h -> /usr/local/include/openssl/rc4.h install ./include/openssl/rc5.h -> /usr/local/include/openssl/rc5.h install ./include/openssl/ripemd.h -> /usr/local/include/openssl/ripemd.h install ./include/openssl/rsa.h -> /usr/local/include/openssl/rsa.h install ./include/openssl/safestack.h -> /usr/local/include/openssl/safestack.h install ./include/openssl/seed.h -> /usr/local/include/openssl/seed.h install ./include/openssl/sha.h -> /usr/local/include/openssl/sha.h install ./include/openssl/srp.h -> /usr/local/include/openssl/srp.h install ./include/openssl/srtp.h -> /usr/local/include/openssl/srtp.h install ./include/openssl/ssl.h -> /usr/local/include/openssl/ssl.h install ./include/openssl/ssl2.h -> /usr/local/include/openssl/ssl2.h install ./include/openssl/ssl3.h -> /usr/local/include/openssl/ssl3.h install ./include/openssl/stack.h -> /usr/local/include/openssl/stack.h install ./include/openssl/symhacks.h -> /usr/local/include/openssl/symhacks.h install ./include/openssl/tls1.h -> /usr/local/include/openssl/tls1.h install ./include/openssl/ts.h -> /usr/local/include/openssl/ts.h install ./include/openssl/txt_db.h -> /usr/local/include/openssl/txt_db.h install ./include/openssl/ui.h -> /usr/local/include/openssl/ui.h install ./include/openssl/whrlpool.h -> /usr/local/include/openssl/whrlpool.h install ./include/openssl/x509.h -> /usr/local/include/openssl/x509.h install ./include/openssl/x509_vfy.h -> /usr/local/include/openssl/x509_vfy.h install ./include/openssl/x509v3.h -> /usr/local/include/openssl/x509v3.h install libcrypto.a -> /usr/local/lib/libcrypto.a ranlib: file: /usr/local/lib/libcrypto.a.new(async_null.o) has no symbols ranlib: file: /usr/local/lib/libcrypto.a.new(async_win.o) has no symbols ranlib: file: /usr/local/lib/libcrypto.a.new(cms_cd.o) has no symbols ranlib: file: /usr/local/lib/libcrypto.a.new(dso_dl.o) has no symbols ranlib: file: /usr/local/lib/libcrypto.a.new(dso_openssl.o) has no symbols ranlib: file: /usr/local/lib/libcrypto.a.new(dso_vms.o) has no symbols ranlib: file: /usr/local/lib/libcrypto.a.new(dso_win32.o) has no symbols ranlib: file: /usr/local/lib/libcrypto.a.new(ebcdic.o) has no symbols ranlib: file: /usr/local/lib/libcrypto.a.new(e_rc5.o) has no symbols ranlib: file: /usr/local/lib/libcrypto.a.new(m_md2.o) has no symbols ranlib: file: /usr/local/lib/libcrypto.a.new(rand_egd.o) has no symbols ranlib: file: /usr/local/lib/libcrypto.a.new(rand_vms.o) has no symbols ranlib: file: /usr/local/lib/libcrypto.a.new(rand_win.o) has no symbols ranlib: file: /usr/local/lib/libcrypto.a.new(threads_none.o) has no symbols ranlib: file: /usr/local/lib/libcrypto.a.new(threads_win.o) has no symbols install libssl.a -> /usr/local/lib/libssl.a ranlib: file: /usr/local/lib/libssl.a.new(ssl_utst.o) has no symbols ranlib: file: /usr/local/lib/libssl.a.new(t1_trce.o) has no symbols install libcrypto.pc -> /usr/local/lib/pkgconfig/libcrypto.pc install libssl.pc -> /usr/local/lib/pkgconfig/libssl.pc install openssl.pc -> /usr/local/lib/pkgconfig/openssl.pc *** Installing engines *** Installing runtime files : ; install apps/openssl -> /usr/local/bin/openssl install ./tools/c_rehash -> /usr/local/bin/c_rehash ********** Operating system: x86_64-apple-darwinDarwin Kernel Version 12.6.0: Wed Mar 18 16:23:48 PDT 2015; root:xnu-2050.48.19~1/RELEASE_X86_64 Configuring for darwin64-x86_64-cc Configuring OpenSSL version 1.1.0-pre6-dev (0x0x10100006L) no-asan [default] OPENSSL_NO_ASAN (skip dir) no-crypto-mdebug [default] OPENSSL_NO_CRYPTO_MDEBUG (skip dir) no-crypto-mdebug-backtrace [default] OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE (skip dir) no-dynamic-engine [forced] no-egd [default] OPENSSL_NO_EGD (skip dir) no-fuzz-afl [default] OPENSSL_NO_FUZZ_AFL (skip dir) no-fuzz-libfuzzer [default] OPENSSL_NO_FUZZ_LIBFUZZER (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-ssl3 [default] OPENSSL_NO_SSL3 (skip dir) no-ssl3-method [default] OPENSSL_NO_SSL3_METHOD (skip dir) no-ubsan [default] OPENSSL_NO_UBSAN (skip dir) no-unit-test [default] OPENSSL_NO_UNIT_TEST (skip dir) no-weak-ssl-ciphers [default] OPENSSL_NO_WEAK_SSL_CIPHERS (skip dir) no-zlib [default] no-zlib-dynamic [default] Configuring for darwin64-x86_64-cc CC =cc CFLAG =-O3 -D_REENTRANT -arch x86_64 -DL_ENDIAN -Wall SHARED_CFLAG =-fPIC DEFINES =DSO_DLFCN HAVE_DLFCN_H NDEBUG OPENSSL_THREADS OPENSSL_NO_DYNAMIC_ENGINE OPENSSL_PIC 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 =-Wl,-search_paths_first EX_LIBS = APPS_OBJ = CPUID_OBJ =x86_64cpuid.o UPLINK_OBJ = 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 BLAKE2_OBJ = PROCESSOR = RANLIB =ranlib -c ARFLAGS = PERL =/opt/local/bin/perl5.22 SIXTY_FOUR_BIT_LONG mode Configured for darwin64-x86_64-cc. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4601 Please log in as guest with password guest if prompted From cristifati0 at gmail.com Thu Jun 30 15:10:48 2016 From: cristifati0 at gmail.com (Cristi Fati) Date: Thu, 30 Jun 2016 18:10:48 +0300 Subject: [openssl-dev] BUG - FIPS capable OpenSSL fails to build on Linux PPC64 In-Reply-To: <20160621113705.GC5370@suse.de> References: <20160621113705.GC5370@suse.de> Message-ID: Thank you Marcus for the comments. Couple of notes: - My archs are Big Endian. - I was aiming for openssl1.0.2(h) since this is the LTS version. Short recap: - *On (Linux running on) PPC64*, openssl 1.0.2h + openssl-fips-2.0.12, when both are automatically configured (using *config*) *does not build*: error when linking *libcrypto.so.1.0.0* (error described in my previous mail) - This does *not* reproduce with older versions (tried with openssl 1.0.1p + openssl-fips-2.0.5), where everything works fine. Details: when autoconfiguring both products, *ppc64-whatever-linux2* is identified by *config* and *Configure linux-ppc* is called. But in openssl-1.0.2(h), some extra processing is performed by *config* for *ppc64-*-linux2* resulting (at least for me) in adding *-m32* compiler option. So, openssl generates 32 bit code, but not openssl-fips that doesn't have this processing, and naturally when the linker tries to add the objects together, it fails. *The quick workaround* that did the trick for me was to call *./**Configure linux-ppc* for openssl-1.0.2 and skip the extra processing done by *config*. *However:* Given the fact that *Configure*'s *linux-ppc* target generates 64bit code (*ELF 64-bit MSB*), I assume that *linux-ppc64 *does the same thing, I think that the final solution should: - since *config* is a client for *Configure*, I think the extra processing done actually in (openssl-1.0.2h's) *config* should be ported to *Configure*, so the same binaries are obtained configuring using whether *config*(which calls *Configure linux-ppc*) or *Configure linux-ppc *directly. - port the extra processing to openssl-fips as well, so both products when auto configured, generate the same binaries type (linkable together). Regards, Cristi. On Tue, Jun 21, 2016 at 2:37 PM, Marcus Meissner wrote: > On Tue, Jun 21, 2016 at 12:39:35PM +0300, Cristi Fati wrote: > > Hi all, > > > > I am trying to build a FIPS (2.0.12) capable OpenSSL (1.0.2h) on PPC64 > > Linux (tried RH5 and SLES12), but it fails. > > FWIW, > > The openssl packages on SLES 12 have received FIPS certificate for x86_64 > While we have not certified them on ppc64le, the same FIPS source code is > inside. > > So the SLES12 ppc64le openssl 1.0.1i is FIPS capable. > > Ciao, Marcus > -- > 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 Jun 30 15:12:50 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Thu, 30 Jun 2016 15:12:50 +0000 Subject: [openssl-dev] [openssl.org #4601] install_sw does not honor --openssldir In-Reply-To: References: Message-ID: That's correct for 1.1.0. install_sw honors --prefix. We made that change to get away from all the weird magic around the combinations of --prefix and --openssldir that happened in previous versions. In other words, it's not a bug, it's a feature. Closing this ticket. Cheers, Richard On Thu Jun 30 14:31:33 2016, noloader at gmail.com wrote: > Working on OS 10.8.5. Working from Master, > 8a3c000c8f621cd01929313fcb7d0cc23fb516a6. > > Using the following configure line: > > $ KERNEL_BITS=64 ./config no-shared enable-ec_nistp_64_gcc_128 > --openssldir=/usr/local/ssl/1.1.0 > > Later, when I attempt to compile: > > $ gcc -I/usr/local/ssl/1.1.0/include test.cc -o test.exe > /usr/local/ssl/1.1.0/lib/libcrypto.a > clang: error: no such file or directory: > '/usr/local/ssl/1.1.0/lib/libcrypto.a' > > And: > > $ ls /usr/local/ssl/1.1.0/ > misc > > ********** > > $ sudo make install_sw > /opt/local/bin/perl5.22 "-I." -Mconfigdata "util/dofile.pl" \ > "-oMakefile" crypto/include/internal/bn_conf.h.in > > crypto/include/internal/bn_conf.h > /opt/local/bin/perl5.22 "-I." -Mconfigdata "util/dofile.pl" \ > "-oMakefile" crypto/include/internal/dso_conf.h.in > > crypto/include/internal/dso_conf.h > /opt/local/bin/perl5.22 "-I." -Mconfigdata "util/dofile.pl" \ > "-oMakefile" include/openssl/opensslconf.h.in > > include/openssl/opensslconf.h > /opt/local/bin/perl5.22 util/mkbuildinf.pl "cc -DDSO_DLFCN > -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_DYNAMIC_ENGINE > -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/1.1.0\\\"\" > -DENGINESDIR=\"\\\"/usr/local/lib/engines\\\"\" " "darwin64-x86_64-cc" > > crypto/buildinf.h > cc -Iinclude -I. -Icrypto/include -Icrypto -DDSO_DLFCN -DHAVE_DLFCN_H > -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_DYNAMIC_ENGINE -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/1.1.0\"" > -DENGINESDIR="\"/usr/local/lib/engines\"" -O3 -D_REENTRANT -arch > x86_64 -DL_ENDIAN -Wall -fPIC -MMD -MF crypto/cversion.d.tmp -MT > crypto/cversion.o -c -o crypto/cversion.o crypto/cversion.c > ar r libcrypto.a crypto/cversion.o > /usr/bin/ranlib: file: libcrypto.a(async_null.o) has no symbols > /usr/bin/ranlib: file: libcrypto.a(async_win.o) has no symbols > /usr/bin/ranlib: file: libcrypto.a(cms_cd.o) has no symbols > /usr/bin/ranlib: file: libcrypto.a(dso_dl.o) has no symbols > /usr/bin/ranlib: file: libcrypto.a(dso_openssl.o) has no symbols > /usr/bin/ranlib: file: libcrypto.a(dso_vms.o) has no symbols > /usr/bin/ranlib: file: libcrypto.a(dso_win32.o) has no symbols > /usr/bin/ranlib: file: libcrypto.a(ebcdic.o) has no symbols > /usr/bin/ranlib: file: libcrypto.a(e_rc5.o) has no symbols > /usr/bin/ranlib: file: libcrypto.a(m_md2.o) has no symbols > /usr/bin/ranlib: file: libcrypto.a(rand_egd.o) has no symbols > /usr/bin/ranlib: file: libcrypto.a(rand_vms.o) has no symbols > /usr/bin/ranlib: file: libcrypto.a(rand_win.o) has no symbols > /usr/bin/ranlib: file: libcrypto.a(threads_none.o) has no symbols > /usr/bin/ranlib: file: libcrypto.a(threads_win.o) has no symbols > ranlib -c libcrypto.a || echo Never mind. > ranlib: file: libcrypto.a(async_null.o) has no symbols > ranlib: file: libcrypto.a(async_win.o) has no symbols > ranlib: file: libcrypto.a(cms_cd.o) has no symbols > ranlib: file: libcrypto.a(dso_dl.o) has no symbols > ranlib: file: libcrypto.a(dso_openssl.o) has no symbols > ranlib: file: libcrypto.a(dso_vms.o) has no symbols > ranlib: file: libcrypto.a(dso_win32.o) has no symbols > ranlib: file: libcrypto.a(ebcdic.o) has no symbols > ranlib: file: libcrypto.a(e_rc5.o) has no symbols > ranlib: file: libcrypto.a(m_md2.o) has no symbols > ranlib: file: libcrypto.a(rand_egd.o) has no symbols > ranlib: file: libcrypto.a(rand_vms.o) has no symbols > ranlib: file: libcrypto.a(rand_win.o) has no symbols > ranlib: file: libcrypto.a(threads_none.o) has no symbols > ranlib: file: libcrypto.a(threads_win.o) has no symbols > rm -f apps/openssl > make -f ./Makefile.shared -e \ > PERL="/opt/local/bin/perl5.22" SRCDIR=. \ > APPNAME=apps/openssl OBJECTS="apps/app_rand.o apps/apps.o > apps/asn1pars.o apps/ca.o apps/ciphers.o apps/cms.o apps/crl.o > apps/crl2p7.o apps/dgst.o apps/dhparam.o apps/dsa.o apps/dsaparam.o > apps/ec.o apps/ecparam.o apps/enc.o apps/engine.o apps/errstr.o > apps/gendsa.o apps/genpkey.o apps/genrsa.o apps/nseq.o apps/ocsp.o > apps/openssl.o apps/opt.o apps/passwd.o apps/pkcs12.o apps/pkcs7.o > apps/pkcs8.o apps/pkey.o apps/pkeyparam.o apps/pkeyutl.o apps/prime.o > apps/rand.o apps/rehash.o apps/req.o apps/rsa.o apps/rsautl.o > apps/s_cb.o apps/s_client.o apps/s_server.o apps/s_socket.o > apps/s_time.o apps/sess_id.o apps/smime.o apps/speed.o apps/spkac.o > apps/srp.o apps/ts.o apps/verify.o apps/version.o apps/x509.o" \ > LIBDEPS='-Wl,-search_paths_first '" -L. -lssl -L. -lcrypto"' ' \ > CC='cc' CFLAGS='-DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG > -DOPENSSL_THREADS -DOPENSSL_NO_DYNAMIC_ENGINE -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/1.1.0\"" > -DENGINESDIR="\"/usr/local/lib/engines\"" -O3 -D_REENTRANT -arch > x86_64 -DL_ENDIAN -Wall ' \ > LDFLAGS='' LIBRPATH='/usr/local/lib' \ > link_app. > make[1]: Entering directory '/Users/jwalton/openssl' > ( :; LIBDEPS="${LIBDEPS:--Wl,-search_paths_first -L. -lssl -L. > -lcrypto }"; LDCMD="${LDCMD:-cc}"; LDFLAGS="${LDFLAGS:--DDSO_DLFCN > -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_DYNAMIC_ENGINE > -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/1.1.0\"" > -DENGINESDIR="\"/usr/local/lib/engines\"" -O3 -D_REENTRANT -arch > x86_64 -DL_ENDIAN -Wall }"; LIBPATH=`for x in $LIBDEPS; do echo $x; > done | sed -e 's/^ *-L//;t' -e d | uniq`; LIBPATH=`echo $LIBPATH | sed > -e 's/ /:/g'`; echo LD_LIBRARY_PATH=$LIBPATH:$LD_LIBRARY_PATH ${LDCMD} > ${LDFLAGS} -o ${APPNAME:=apps/openssl} apps/app_rand.o apps/apps.o > apps/asn1pars.o apps/ca.o apps/ciphers.o apps/cms.o apps/crl.o > apps/crl2p7.o apps/dgst.o apps/dhparam.o apps/dsa.o apps/dsaparam.o > apps/ec.o apps/ecparam.o apps/enc.o apps/engine.o apps/errstr.o > apps/gendsa.o apps/genpkey.o apps/genrsa.o apps/nseq.o apps/ocsp.o > apps/openssl.o apps/opt.o apps/passwd.o apps/pkcs12.o apps/pkcs7.o > apps/pkcs8.o apps/pkey.o apps/pkeyparam.o apps/pkeyutl.o apps/prime.o > apps/rand.o apps/rehash.o apps/req.o apps/rsa.o apps/rsautl.o > apps/s_cb.o apps/s_client.o apps/s_server.o apps/s_socket.o > apps/s_time.o apps/sess_id.o apps/smime.o apps/speed.o apps/spkac.o > apps/srp.o apps/ts.o apps/verify.o apps/version.o apps/x509.o > ${LIBDEPS}; LD_LIBRARY_PATH=$LIBPATH:$LD_LIBRARY_PATH ${LDCMD} > ${LDFLAGS} -o ${APPNAME:=apps/openssl} apps/app_rand.o apps/apps.o > apps/asn1pars.o apps/ca.o apps/ciphers.o apps/cms.o apps/crl.o > apps/crl2p7.o apps/dgst.o apps/dhparam.o apps/dsa.o apps/dsaparam.o > apps/ec.o apps/ecparam.o apps/enc.o apps/engine.o apps/errstr.o > apps/gendsa.o apps/genpkey.o apps/genrsa.o apps/nseq.o apps/ocsp.o > apps/openssl.o apps/opt.o apps/passwd.o apps/pkcs12.o apps/pkcs7.o > apps/pkcs8.o apps/pkey.o apps/pkeyparam.o apps/pkeyutl.o apps/prime.o > apps/rand.o apps/rehash.o apps/req.o apps/rsa.o apps/rsautl.o > apps/s_cb.o apps/s_client.o apps/s_server.o apps/s_socket.o > apps/s_time.o apps/sess_id.o apps/smime.o apps/speed.o apps/spkac.o > apps/srp.o apps/ts.o apps/verify.o apps/version.o apps/x509.o > ${LIBDEPS} ) > LD_LIBRARY_PATH=.: cc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG > -DOPENSSL_THREADS -DOPENSSL_NO_DYNAMIC_ENGINE -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/1.1.0" > -DENGINESDIR="/usr/local/lib/engines" -O3 -D_REENTRANT -arch x86_64 > -DL_ENDIAN -Wall -o apps/openssl apps/app_rand.o apps/apps.o > apps/asn1pars.o apps/ca.o apps/ciphers.o apps/cms.o apps/crl.o > apps/crl2p7.o apps/dgst.o apps/dhparam.o apps/dsa.o apps/dsaparam.o > apps/ec.o apps/ecparam.o apps/enc.o apps/engine.o apps/errstr.o > apps/gendsa.o apps/genpkey.o apps/genrsa.o apps/nseq.o apps/ocsp.o > apps/openssl.o apps/opt.o apps/passwd.o apps/pkcs12.o apps/pkcs7.o > apps/pkcs8.o apps/pkey.o apps/pkeyparam.o apps/pkeyutl.o apps/prime.o > apps/rand.o apps/rehash.o apps/req.o apps/rsa.o apps/rsautl.o > apps/s_cb.o apps/s_client.o apps/s_server.o apps/s_socket.o > apps/s_time.o apps/sess_id.o apps/smime.o apps/speed.o apps/spkac.o > apps/srp.o apps/ts.o apps/verify.o apps/version.o apps/x509.o > -Wl,-search_paths_first -L. -lssl -L. -lcrypto > make[1]: Leaving directory '/Users/jwalton/openssl' > *** Installing development files > install ./include/openssl/aes.h -> /usr/local/include/openssl/aes.h > install ./include/openssl/asn1.h -> /usr/local/include/openssl/asn1.h > install ./include/openssl/asn1_mac.h -> > /usr/local/include/openssl/asn1_mac.h > install ./include/openssl/asn1t.h -> > /usr/local/include/openssl/asn1t.h > install ./include/openssl/async.h -> > /usr/local/include/openssl/async.h > install ./include/openssl/bio.h -> /usr/local/include/openssl/bio.h > install ./include/openssl/blowfish.h -> > /usr/local/include/openssl/blowfish.h > install ./include/openssl/bn.h -> /usr/local/include/openssl/bn.h > install ./include/openssl/buffer.h -> > /usr/local/include/openssl/buffer.h > install ./include/openssl/camellia.h -> > /usr/local/include/openssl/camellia.h > install ./include/openssl/cast.h -> /usr/local/include/openssl/cast.h > install ./include/openssl/cmac.h -> /usr/local/include/openssl/cmac.h > install ./include/openssl/cms.h -> /usr/local/include/openssl/cms.h > install ./include/openssl/comp.h -> /usr/local/include/openssl/comp.h > install ./include/openssl/conf.h -> /usr/local/include/openssl/conf.h > install ./include/openssl/conf_api.h -> > /usr/local/include/openssl/conf_api.h > install ./include/openssl/crypto.h -> > /usr/local/include/openssl/crypto.h > install ./include/openssl/ct.h -> /usr/local/include/openssl/ct.h > install ./include/openssl/des.h -> /usr/local/include/openssl/des.h > install ./include/openssl/dh.h -> /usr/local/include/openssl/dh.h > install ./include/openssl/dsa.h -> /usr/local/include/openssl/dsa.h > install ./include/openssl/dtls1.h -> > /usr/local/include/openssl/dtls1.h > install ./include/openssl/e_os2.h -> > /usr/local/include/openssl/e_os2.h > install ./include/openssl/ebcdic.h -> > /usr/local/include/openssl/ebcdic.h > install ./include/openssl/ec.h -> /usr/local/include/openssl/ec.h > install ./include/openssl/ecdh.h -> /usr/local/include/openssl/ecdh.h > install ./include/openssl/ecdsa.h -> > /usr/local/include/openssl/ecdsa.h > install ./include/openssl/engine.h -> > /usr/local/include/openssl/engine.h > install ./include/openssl/err.h -> /usr/local/include/openssl/err.h > install ./include/openssl/evp.h -> /usr/local/include/openssl/evp.h > install ./include/openssl/hmac.h -> /usr/local/include/openssl/hmac.h > install ./include/openssl/idea.h -> /usr/local/include/openssl/idea.h > install ./include/openssl/kdf.h -> /usr/local/include/openssl/kdf.h > install ./include/openssl/lhash.h -> > /usr/local/include/openssl/lhash.h > install ./include/openssl/md2.h -> /usr/local/include/openssl/md2.h > install ./include/openssl/md4.h -> /usr/local/include/openssl/md4.h > install ./include/openssl/md5.h -> /usr/local/include/openssl/md5.h > install ./include/openssl/mdc2.h -> /usr/local/include/openssl/mdc2.h > install ./include/openssl/modes.h -> > /usr/local/include/openssl/modes.h > install ./include/openssl/obj_mac.h -> > /usr/local/include/openssl/obj_mac.h > install ./include/openssl/objects.h -> > /usr/local/include/openssl/objects.h > install ./include/openssl/ocsp.h -> /usr/local/include/openssl/ocsp.h > install ./include/openssl/opensslconf.h -> > /usr/local/include/openssl/opensslconf.h > install ./include/openssl/opensslv.h -> > /usr/local/include/openssl/opensslv.h > install ./include/openssl/ossl_typ.h -> > /usr/local/include/openssl/ossl_typ.h > install ./include/openssl/pem.h -> /usr/local/include/openssl/pem.h > install ./include/openssl/pem2.h -> /usr/local/include/openssl/pem2.h > install ./include/openssl/pkcs12.h -> > /usr/local/include/openssl/pkcs12.h > install ./include/openssl/pkcs7.h -> > /usr/local/include/openssl/pkcs7.h > install ./include/openssl/rand.h -> /usr/local/include/openssl/rand.h > install ./include/openssl/rc2.h -> /usr/local/include/openssl/rc2.h > install ./include/openssl/rc4.h -> /usr/local/include/openssl/rc4.h > install ./include/openssl/rc5.h -> /usr/local/include/openssl/rc5.h > install ./include/openssl/ripemd.h -> > /usr/local/include/openssl/ripemd.h > install ./include/openssl/rsa.h -> /usr/local/include/openssl/rsa.h > install ./include/openssl/safestack.h -> > /usr/local/include/openssl/safestack.h > install ./include/openssl/seed.h -> /usr/local/include/openssl/seed.h > install ./include/openssl/sha.h -> /usr/local/include/openssl/sha.h > install ./include/openssl/srp.h -> /usr/local/include/openssl/srp.h > install ./include/openssl/srtp.h -> /usr/local/include/openssl/srtp.h > install ./include/openssl/ssl.h -> /usr/local/include/openssl/ssl.h > install ./include/openssl/ssl2.h -> /usr/local/include/openssl/ssl2.h > install ./include/openssl/ssl3.h -> /usr/local/include/openssl/ssl3.h > install ./include/openssl/stack.h -> > /usr/local/include/openssl/stack.h > install ./include/openssl/symhacks.h -> > /usr/local/include/openssl/symhacks.h > install ./include/openssl/tls1.h -> /usr/local/include/openssl/tls1.h > install ./include/openssl/ts.h -> /usr/local/include/openssl/ts.h > install ./include/openssl/txt_db.h -> > /usr/local/include/openssl/txt_db.h > install ./include/openssl/ui.h -> /usr/local/include/openssl/ui.h > install ./include/openssl/whrlpool.h -> > /usr/local/include/openssl/whrlpool.h > install ./include/openssl/x509.h -> /usr/local/include/openssl/x509.h > install ./include/openssl/x509_vfy.h -> > /usr/local/include/openssl/x509_vfy.h > install ./include/openssl/x509v3.h -> > /usr/local/include/openssl/x509v3.h > install ./include/openssl/aes.h -> /usr/local/include/openssl/aes.h > install ./include/openssl/asn1.h -> /usr/local/include/openssl/asn1.h > install ./include/openssl/asn1_mac.h -> > /usr/local/include/openssl/asn1_mac.h > install ./include/openssl/asn1t.h -> > /usr/local/include/openssl/asn1t.h > install ./include/openssl/async.h -> > /usr/local/include/openssl/async.h > install ./include/openssl/bio.h -> /usr/local/include/openssl/bio.h > install ./include/openssl/blowfish.h -> > /usr/local/include/openssl/blowfish.h > install ./include/openssl/bn.h -> /usr/local/include/openssl/bn.h > install ./include/openssl/buffer.h -> > /usr/local/include/openssl/buffer.h > install ./include/openssl/camellia.h -> > /usr/local/include/openssl/camellia.h > install ./include/openssl/cast.h -> /usr/local/include/openssl/cast.h > install ./include/openssl/cmac.h -> /usr/local/include/openssl/cmac.h > install ./include/openssl/cms.h -> /usr/local/include/openssl/cms.h > install ./include/openssl/comp.h -> /usr/local/include/openssl/comp.h > install ./include/openssl/conf.h -> /usr/local/include/openssl/conf.h > install ./include/openssl/conf_api.h -> > /usr/local/include/openssl/conf_api.h > install ./include/openssl/crypto.h -> > /usr/local/include/openssl/crypto.h > install ./include/openssl/ct.h -> /usr/local/include/openssl/ct.h > install ./include/openssl/des.h -> /usr/local/include/openssl/des.h > install ./include/openssl/dh.h -> /usr/local/include/openssl/dh.h > install ./include/openssl/dsa.h -> /usr/local/include/openssl/dsa.h > install ./include/openssl/dtls1.h -> > /usr/local/include/openssl/dtls1.h > install ./include/openssl/e_os2.h -> > /usr/local/include/openssl/e_os2.h > install ./include/openssl/ebcdic.h -> > /usr/local/include/openssl/ebcdic.h > install ./include/openssl/ec.h -> /usr/local/include/openssl/ec.h > install ./include/openssl/ecdh.h -> /usr/local/include/openssl/ecdh.h > install ./include/openssl/ecdsa.h -> > /usr/local/include/openssl/ecdsa.h > install ./include/openssl/engine.h -> > /usr/local/include/openssl/engine.h > install ./include/openssl/err.h -> /usr/local/include/openssl/err.h > install ./include/openssl/evp.h -> /usr/local/include/openssl/evp.h > install ./include/openssl/hmac.h -> /usr/local/include/openssl/hmac.h > install ./include/openssl/idea.h -> /usr/local/include/openssl/idea.h > install ./include/openssl/kdf.h -> /usr/local/include/openssl/kdf.h > install ./include/openssl/lhash.h -> > /usr/local/include/openssl/lhash.h > install ./include/openssl/md2.h -> /usr/local/include/openssl/md2.h > install ./include/openssl/md4.h -> /usr/local/include/openssl/md4.h > install ./include/openssl/md5.h -> /usr/local/include/openssl/md5.h > install ./include/openssl/mdc2.h -> /usr/local/include/openssl/mdc2.h > install ./include/openssl/modes.h -> > /usr/local/include/openssl/modes.h > install ./include/openssl/obj_mac.h -> > /usr/local/include/openssl/obj_mac.h > install ./include/openssl/objects.h -> > /usr/local/include/openssl/objects.h > install ./include/openssl/ocsp.h -> /usr/local/include/openssl/ocsp.h > install ./include/openssl/opensslconf.h -> > /usr/local/include/openssl/opensslconf.h > install ./include/openssl/opensslv.h -> > /usr/local/include/openssl/opensslv.h > install ./include/openssl/ossl_typ.h -> > /usr/local/include/openssl/ossl_typ.h > install ./include/openssl/pem.h -> /usr/local/include/openssl/pem.h > install ./include/openssl/pem2.h -> /usr/local/include/openssl/pem2.h > install ./include/openssl/pkcs12.h -> > /usr/local/include/openssl/pkcs12.h > install ./include/openssl/pkcs7.h -> > /usr/local/include/openssl/pkcs7.h > install ./include/openssl/rand.h -> /usr/local/include/openssl/rand.h > install ./include/openssl/rc2.h -> /usr/local/include/openssl/rc2.h > install ./include/openssl/rc4.h -> /usr/local/include/openssl/rc4.h > install ./include/openssl/rc5.h -> /usr/local/include/openssl/rc5.h > install ./include/openssl/ripemd.h -> > /usr/local/include/openssl/ripemd.h > install ./include/openssl/rsa.h -> /usr/local/include/openssl/rsa.h > install ./include/openssl/safestack.h -> > /usr/local/include/openssl/safestack.h > install ./include/openssl/seed.h -> /usr/local/include/openssl/seed.h > install ./include/openssl/sha.h -> /usr/local/include/openssl/sha.h > install ./include/openssl/srp.h -> /usr/local/include/openssl/srp.h > install ./include/openssl/srtp.h -> /usr/local/include/openssl/srtp.h > install ./include/openssl/ssl.h -> /usr/local/include/openssl/ssl.h > install ./include/openssl/ssl2.h -> /usr/local/include/openssl/ssl2.h > install ./include/openssl/ssl3.h -> /usr/local/include/openssl/ssl3.h > install ./include/openssl/stack.h -> > /usr/local/include/openssl/stack.h > install ./include/openssl/symhacks.h -> > /usr/local/include/openssl/symhacks.h > install ./include/openssl/tls1.h -> /usr/local/include/openssl/tls1.h > install ./include/openssl/ts.h -> /usr/local/include/openssl/ts.h > install ./include/openssl/txt_db.h -> > /usr/local/include/openssl/txt_db.h > install ./include/openssl/ui.h -> /usr/local/include/openssl/ui.h > install ./include/openssl/whrlpool.h -> > /usr/local/include/openssl/whrlpool.h > install ./include/openssl/x509.h -> /usr/local/include/openssl/x509.h > install ./include/openssl/x509_vfy.h -> > /usr/local/include/openssl/x509_vfy.h > install ./include/openssl/x509v3.h -> > /usr/local/include/openssl/x509v3.h > install libcrypto.a -> /usr/local/lib/libcrypto.a > ranlib: file: /usr/local/lib/libcrypto.a.new(async_null.o) has no > symbols > ranlib: file: /usr/local/lib/libcrypto.a.new(async_win.o) has no > symbols > ranlib: file: /usr/local/lib/libcrypto.a.new(cms_cd.o) has no symbols > ranlib: file: /usr/local/lib/libcrypto.a.new(dso_dl.o) has no symbols > ranlib: file: /usr/local/lib/libcrypto.a.new(dso_openssl.o) has no > symbols > ranlib: file: /usr/local/lib/libcrypto.a.new(dso_vms.o) has no symbols > ranlib: file: /usr/local/lib/libcrypto.a.new(dso_win32.o) has no > symbols > ranlib: file: /usr/local/lib/libcrypto.a.new(ebcdic.o) has no symbols > ranlib: file: /usr/local/lib/libcrypto.a.new(e_rc5.o) has no symbols > ranlib: file: /usr/local/lib/libcrypto.a.new(m_md2.o) has no symbols > ranlib: file: /usr/local/lib/libcrypto.a.new(rand_egd.o) has no > symbols > ranlib: file: /usr/local/lib/libcrypto.a.new(rand_vms.o) has no > symbols > ranlib: file: /usr/local/lib/libcrypto.a.new(rand_win.o) has no > symbols > ranlib: file: /usr/local/lib/libcrypto.a.new(threads_none.o) has no > symbols > ranlib: file: /usr/local/lib/libcrypto.a.new(threads_win.o) has no > symbols > install libssl.a -> /usr/local/lib/libssl.a > ranlib: file: /usr/local/lib/libssl.a.new(ssl_utst.o) has no symbols > ranlib: file: /usr/local/lib/libssl.a.new(t1_trce.o) has no symbols > install libcrypto.pc -> /usr/local/lib/pkgconfig/libcrypto.pc > install libssl.pc -> /usr/local/lib/pkgconfig/libssl.pc > install openssl.pc -> /usr/local/lib/pkgconfig/openssl.pc > *** Installing engines > *** Installing runtime files > : ; > install apps/openssl -> /usr/local/bin/openssl > install ./tools/c_rehash -> /usr/local/bin/c_rehash > > > ********** > > Operating system: x86_64-apple-darwinDarwin Kernel Version 12.6.0: Wed > Mar 18 16:23:48 PDT 2015; root:xnu-2050.48.19~1/RELEASE_X86_64 > Configuring for darwin64-x86_64-cc > Configuring OpenSSL version 1.1.0-pre6-dev (0x0x10100006L) > no-asan [default] OPENSSL_NO_ASAN (skip dir) > no-crypto-mdebug [default] OPENSSL_NO_CRYPTO_MDEBUG (skip dir) > no-crypto-mdebug-backtrace [default] > OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE (skip dir) > no-dynamic-engine [forced] > no-egd [default] OPENSSL_NO_EGD (skip dir) > no-fuzz-afl [default] OPENSSL_NO_FUZZ_AFL (skip dir) > no-fuzz-libfuzzer [default] OPENSSL_NO_FUZZ_LIBFUZZER (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-ssl3 [default] OPENSSL_NO_SSL3 (skip dir) > no-ssl3-method [default] OPENSSL_NO_SSL3_METHOD (skip dir) > no-ubsan [default] OPENSSL_NO_UBSAN (skip dir) > no-unit-test [default] OPENSSL_NO_UNIT_TEST (skip dir) > no-weak-ssl-ciphers [default] OPENSSL_NO_WEAK_SSL_CIPHERS (skip > dir) > no-zlib [default] > no-zlib-dynamic [default] > Configuring for darwin64-x86_64-cc > CC =cc > CFLAG =-O3 -D_REENTRANT -arch x86_64 -DL_ENDIAN -Wall > SHARED_CFLAG =-fPIC > DEFINES =DSO_DLFCN HAVE_DLFCN_H NDEBUG OPENSSL_THREADS > OPENSSL_NO_DYNAMIC_ENGINE OPENSSL_PIC 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 =-Wl,-search_paths_first > EX_LIBS = > APPS_OBJ = > CPUID_OBJ =x86_64cpuid.o > UPLINK_OBJ = > 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 > BLAKE2_OBJ = > PROCESSOR = > RANLIB =ranlib -c > ARFLAGS = > PERL =/opt/local/bin/perl5.22 > > SIXTY_FOUR_BIT_LONG mode > > Configured for darwin64-x86_64-cc. -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4601 Please log in as guest with password guest if prompted From waywardgeek at gmail.com Thu Jun 30 15:25:43 2016 From: waywardgeek at gmail.com (Bill Cox) Date: Thu, 30 Jun 2016 08:25:43 -0700 Subject: [openssl-dev] Low priority feature request: EVP_SIG object Message-ID: This is low priority, IMO, but it would help with my current task. I happen to be updating my token binding library at work to use the new more compact HTTP headers. We write the X, Y, R, and S values, length-prefixed, for ECDSA-P256, and the modulus and exponent for RSA. My previous code uses the EVP API, but I see no simple way to convert an EVP signature, which is a byte array, to the values I need. If there were an EVP_SIG object that could let me access the lower-level SIG objects, then I could get these values with less difficulty. As it is, unless I've missed some existing API (likely - I'll blame my poor header scanning skills on low vision), it looks like my choices are: A) Don't use the EVP API, and drop to the older lower-level algorithm specific APIs. B) Decode the DER-encoded byte arrays returned by the EVP interface. I'm leaning towards B, but it feels like a hack. With this approach I can more easily switch to a new EVP_SIG API if it becomes available down the road. Thanks, Bill -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Thu Jun 30 15:29:54 2016 From: rt at openssl.org (noloader@gmail.com via RT) Date: Thu, 30 Jun 2016 15:29:54 +0000 Subject: [openssl-dev] [openssl.org #4601] install_sw does not honor --openssldir In-Reply-To: References: Message-ID: On Thu, Jun 30, 2016 at 11:12 AM, Richard Levitte via RT wrote: > That's correct for 1.1.0. install_sw honors --prefix. We made that change to > get away from all the weird magic around the combinations of --prefix and > --openssldir that happened in previous versions. > > In other words, it's not a bug, it's a feature. Closing this ticket. Gotta love unexpected changes :) They don't seem related given the documented behaviors: * 'make install' installs the library and man pages * 'make install_sw' install the library only Then we have: * if neither --prefix nor --openssldir, then use /usr/local/ssl * If --openssldir and not --prefix, then use --openssldir I don't know what to expect if both --prefix and --openssldir because I don't use it. is --prefix actiling like $DESTDIR for make recipes? Maybe I need to ask, how do we install only the library into the directory of our choosing? Jeff -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4601 Please log in as guest with password guest if prompted From levitte at openssl.org Thu Jun 30 15:42:08 2016 From: levitte at openssl.org (Richard Levitte) Date: Thu, 30 Jun 2016 17:42:08 +0200 (CEST) Subject: [openssl-dev] [openssl.org #4601] install_sw does not honor --openssldir In-Reply-To: References: Message-ID: <20160630.174208.211794795749745098.levitte@openssl.org> [taking this out of RT] In message on Thu, 30 Jun 2016 15:29:54 +0000, "noloader at gmail.com via RT" said: noloader> On Thu, Jun 30, 2016 at 11:12 AM, Richard Levitte via RT wrote: noloader> > That's correct for 1.1.0. install_sw honors --prefix. We made that change to noloader> > get away from all the weird magic around the combinations of --prefix and noloader> > --openssldir that happened in previous versions. noloader> > noloader> > In other words, it's not a bug, it's a feature. Closing this ticket. noloader> noloader> Gotta love unexpected changes :) Maybe you should read NEWS a CHANGES ;-) NEWS: o Change of Configure to use --prefix as the main installation directory location rather than --openssldir. The latter becomes the directory for certs, private key and openssl.cnf exclusively. CHANGES: *) To clarify their intended purposes, the Configure options --prefix and --openssldir change their semantics, and become more straightforward and less interdependent. --prefix shall be used exclusively to give the location INSTALLTOP where programs, scripts, libraries, include files and manuals are going to be installed. The default is now /usr/local. --openssldir shall be used exclusively to give the default location OPENSSLDIR where certificates, private keys, CRLs are managed. This is also where the default openssl.cnf gets installed. If the directory given with this option is a relative path, the values of both the --prefix value and the --openssldir value will be combined to become OPENSSLDIR. The default for --openssldir is INSTALLTOP/ssl. Anyone who uses --openssldir to specify where OpenSSL is to be installed MUST change to use --prefix instead. [Richard Levitte] noloader> I don't know what to expect if both --prefix and --openssldir because noloader> I don't use it. is --prefix actiling like $DESTDIR for make recipes? DESTDIR is to be used if you want things to get installed in a staging directory rather than the final installation directory. That's useful for package builders. noloader> Maybe I need to ask, how do we install only the library into the noloader> directory of our choosing? ./config --prefix=/TOP/INSTALL/DIRECTORY make install_sw Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From rt at openssl.org Thu Jun 30 16:49:11 2016 From: rt at openssl.org (noloader@gmail.com via RT) Date: Thu, 30 Jun 2016 16:49:11 +0000 Subject: [openssl-dev] [openssl.org #4601] install_sw does not honor --openssldir In-Reply-To: References: Message-ID: On Thu, Jun 30, 2016 at 11:29 AM, Jeffrey Walton wrote: > On Thu, Jun 30, 2016 at 11:12 AM, Richard Levitte via RT wrote: >> That's correct for 1.1.0. install_sw honors --prefix. We made that change to >> get away from all the weird magic around the combinations of --prefix and >> --openssldir that happened in previous versions. >> >> In other words, it's not a bug, it's a feature. Closing this ticket. > > Gotta love unexpected changes :) They don't seem related given the > documented behaviors: > > * 'make install' installs the library and man pages > * 'make install_sw' install the library only > > Then we have: > > * if neither --prefix nor --openssldir, then use /usr/local/ssl > * If --openssldir and not --prefix, then use --openssldir > > I don't know what to expect if both --prefix and --openssldir because > I don't use it. is --prefix actiling like $DESTDIR for make recipes? By the way, here's there reference for DESTDIR and staged installs: http://www.gnu.org/software/make/manual/make.html#DESTDIR . I don't want either of them. I only want to install the library in the directory of my choosing :) Jeff -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4601 Please log in as guest with password guest if prompted From rt at openssl.org Thu Jun 30 16:52:15 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Thu, 30 Jun 2016 16:52:15 +0000 Subject: [openssl-dev] [openssl.org #4601] install_sw does not honor --openssldir In-Reply-To: <33b294f48483427896d028fcc853ec84@usma1ex-dag1mb1.msg.corp.akamai.com> References: <33b294f48483427896d028fcc853ec84@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: > I don't want either of them. I only want to install the library in the directory of > my choosing :) #! /bin/sh make $* && cp *.a $MYDIR Less flippantly, not everything is supported :) -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4601 Please log in as guest with password guest if prompted From levitte at openssl.org Thu Jun 30 16:55:45 2016 From: levitte at openssl.org (Richard Levitte) Date: Thu, 30 Jun 2016 18:55:45 +0200 (CEST) Subject: [openssl-dev] [openssl.org #4601] install_sw does not honor --openssldir In-Reply-To: References: Message-ID: <20160630.185545.1260887344549422320.levitte@openssl.org> In message on Thu, 30 Jun 2016 16:49:11 +0000, "noloader at gmail.com via RT" said: noloader> I don't want either of them. I only want to install the library in the noloader> directory of my choosing :) Then configure with --prefix -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From rt at openssl.org Thu Jun 30 16:59:31 2016 From: rt at openssl.org (noloader@gmail.com via RT) Date: Thu, 30 Jun 2016 16:59:31 +0000 Subject: [openssl-dev] [openssl.org #4601] install_sw does not honor --openssldir In-Reply-To: References: <33b294f48483427896d028fcc853ec84@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: On Thu, Jun 30, 2016 at 12:52 PM, Salz, Rich via RT wrote: >> I don't want either of them. I only want to install the library in the directory of >> my choosing :) > > #! /bin/sh > make $* && cp *.a $MYDIR > > Less flippantly, not everything is supported :) Thanks Rich. So what are the new rules we should use? Do we specify both --prefix and --openssldir? --prefix only? Something else? Jeff -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4601 Please log in as guest with password guest if prompted From matt at openssl.org Thu Jun 30 19:19:43 2016 From: matt at openssl.org (Matt Caswell) Date: Thu, 30 Jun 2016 20:19:43 +0100 Subject: [openssl-dev] [openssl.org #4601] install_sw does not honor --openssldir In-Reply-To: References: <33b294f48483427896d028fcc853ec84@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <577570CF.3020903@openssl.org> On 30/06/16 17:59, noloader at gmail.com via RT wrote: > On Thu, Jun 30, 2016 at 12:52 PM, Salz, Rich via RT wrote: >>> I don't want either of them. I only want to install the library in the directory of >>> my choosing :) >> >> #! /bin/sh >> make $* && cp *.a $MYDIR >> >> Less flippantly, not everything is supported :) > > Thanks Rich. > > So what are the new rules we should use? Do we specify both --prefix > and --openssldir? --prefix only? Something else? Specify neither if you want most stuff to be installed in /usr/local and config files/default cert/keystore in /usr/local/ssl Specify just --openssldir if you want just config files/default cert/keystore to go into and everything else in /usr/local Specify just --prefix if you want most stuff in and config files/default cert/keystore in /ssl. Specify both if you want config file/default cert/keystore in and everything else in . Matt From rsalz at akamai.com Thu Jun 30 19:23:44 2016 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 30 Jun 2016 19:23:44 +0000 Subject: [openssl-dev] [openssl.org #4601] install_sw does not honor --openssldir In-Reply-To: <577570CF.3020903@openssl.org> References: <33b294f48483427896d028fcc853ec84@usma1ex-dag1mb1.msg.corp.akamai.com> <577570CF.3020903@openssl.org> Message-ID: <461b717bcf1340cb9db7adee9852f282@usma1ex-dag1mb1.msg.corp.akamai.com> > Specify neither if you want most stuff to be installed in /usr/local and config > files/default cert/keystore in /usr/local/ssl > > Specify just --openssldir if you want just config files/default cert/keystore to > go into and everything else in /usr/local > > Specify just --prefix if you want most stuff in and config > files/default cert/keystore in /ssl. > > Specify both if you want config file/default cert/keystore in and > everything else in . +1 to someone's MR that puts that in a README or as a comment to config :) From matt at openssl.org Thu Jun 30 19:27:11 2016 From: matt at openssl.org (Matt Caswell) Date: Thu, 30 Jun 2016 20:27:11 +0100 Subject: [openssl-dev] [openssl.org #4601] install_sw does not honor --openssldir In-Reply-To: <461b717bcf1340cb9db7adee9852f282@usma1ex-dag1mb1.msg.corp.akamai.com> References: <33b294f48483427896d028fcc853ec84@usma1ex-dag1mb1.msg.corp.akamai.com> <577570CF.3020903@openssl.org> <461b717bcf1340cb9db7adee9852f282@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <5775728F.1060003@openssl.org> On 30/06/16 20:23, Salz, Rich wrote: > >> Specify neither if you want most stuff to be installed in /usr/local and config >> files/default cert/keystore in /usr/local/ssl >> >> Specify just --openssldir if you want just config files/default cert/keystore to >> go into and everything else in /usr/local >> >> Specify just --prefix if you want most stuff in and config >> files/default cert/keystore in /ssl. >> >> Specify both if you want config file/default cert/keystore in and >> everything else in . > > +1 to someone's MR that puts that in a README or as a comment to config :) > It's already documented in INSTALL. Perhaps it could be clarified even further. Matt From rt at openssl.org Wed Jun 29 12:05:24 2016 From: rt at openssl.org (David Tillemans via RT) Date: Wed, 29 Jun 2016 12:05:24 -0000 Subject: [openssl-dev] [openssl.org #4599] big CRLs problem with openssl 1.0.2h In-Reply-To: <87A602C2B312594B9BDAAC3A69D6F465077FEE25@mailbox02.isabelteam.be> References: <87A602C2B312594B9BDAAC3A69D6F465077FEE25@mailbox02.isabelteam.be> Message-ID: Hi There is a ASN decoding problem when decoding a big crl (example can be found at (http://crl.luxtrust.lu/LTGQCA2.crl). I tested it with openssl 1.0.2g, which is able to process the CRL without problems Failure test: [cid:image001.png at 01D1D1F5.3595D6A0] Could you please look at it what is the problem? Friendly greetings, David Tillemans David Tillemans Security Developer DTillemans at external.isabel.eu t. +32 2 5451 711 m. Isabel NV/SA Keizerinlaan 13-15 Bld de l'Imp?ratrice 1000 Brussels Belgium t. +32 2 5451 711 f. +32 2 5451 719 www.isabel.eu [Isabel Group - Transactions you can bank on.] Disclaimer: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the named addressee, you should not further read, disclose, distribute, copy or use this e-mail or its contents, immediately notify the sender by reply to this e-mail and delete this message as well as any attachments without retaining a copy. The entire email disclaimer of Isabel NV/SA [Isabel Group - Transactions you can bank on.] -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4599 Please log in as guest with password guest if prompted -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 50676 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: imageb1524c.JPG Type: image/jpeg Size: 23353 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image7e1ffa.JPG Type: image/jpeg Size: 4344 bytes Desc: not available URL: