[openssl-dev] [openssl.org #4658] bug: Abort() in 1.0.2h parsing server cert in ASN.1 routine

2016-08-24 Thread Quanah Gibson-Mount via RT 
A customer of ours has a server cert where the CSR was generated with 
1.0.2h but was signed with 1.0.0j.

When a process (nginx in this case) has this as the server cert, it core 
dumps with an abort() when clients request the cert:

[root@zre-ldap005 q]# gdb /opt/zimbra/common/sbin/nginx 
core-nginx-sig6-user1004-group1004-pid8084-time1471924181
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-80.el7
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /opt/zimbra/common/sbin/nginx...Reading symbols from 
/usr/lib/debug/opt/zimbra/common/sbin/nginx.debug...done.
done.
[New LWP 8084]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `nginx: worker process 
'.
Program terminated with signal 6, Aborted.
#0  0x7f22ba1245f7 in __GI_raise (sig=sig@entry=6) at 
../nptl/sysdeps/unix/sysv/linux/raise.c:56
56return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
Missing separate debuginfos, use: debuginfo-install 
pcre-8.32-15.el7_2.1.x86_64 
zimbra-cyrus-sasl-libs-2.1.26-1zimbra8.7b1.el7.x86_64 
zlib-1.2.7-15.el7.x86_64
(gdb) bt
#0  0x7f22ba1245f7 in __GI_raise (sig=sig@entry=6) at 
../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x7f22ba125ce8 in __GI_abort () at abort.c:90
#2  0x7f22ba164327 in __libc_message (do_abort=do_abort@entry=2, 
fmt=fmt@entry=0x7f22ba26e488 "*** Error in `%s': %s: 0x%s ***\n") at 
../sysdeps/unix/sysv/linux/libc_fatal.c:196
#3  0x7f22ba16ada5 in malloc_printerr (ar_ptr=0x7f22ba4aa760 
, ptr=, str=0x7f22ba26bb57 "corrupted 
double-linked list", action=3) at malloc.c:5022
#4  malloc_consolidate (av=av@entry=0x7f22ba4aa760 ) at 
malloc.c:4169
#5  0x7f22ba16ced5 in _int_malloc (av=av@entry=0x7f22ba4aa760 
, bytes=bytes@entry=1366) at malloc.c:3443
#6  0x7f22ba16f26c in __GI___libc_malloc (bytes=1366) at malloc.c:2895
#7  0x7f22bab51048 in CRYPTO_malloc (num=num@entry=1366, 
file=file@entry=0x7f22bace2220 "tasn_utl.c", line=line@entry=174) at 
mem.c:342
#8  0x7f22bac4be94 in asn1_enc_save (pval=pval@entry=0x21302b0, 
in=0x214c6ce 
"0\202\005R\240\003\002\001\002\002\002\022x0\r\006\t*\206H\206\367\r\001\001\v\005",
 
inlen=1366,
it=it@entry=0x7f22baf35f60 ) at tasn_utl.c:174
#9  0x7f22bac4b14e in ASN1_item_ex_d2i (pval=, 
in=0x7ffc53c497e0, len=0, it=0x7f22baf35f60 , tag=, tag@entry=-1, aclass=,
opt=0 '\000', ctx=0x7ffc53c49a10) at tasn_dec.c:492
#10 0x7f22bac4b4f2 in asn1_template_noexp_d2i (val=0x21302b0, 
in=0x7ffc53c499a0, len=1513, tt=0x7f22baf3cd20 , 
opt=, ctx=0x7ffc53c49a10) at tasn_dec.c:694
#11 0x7f22bac4b735 in asn1_template_ex_d2i (val=0x21302b0, 
in=0x7ffc53c499a0, inlen=1513, tt=0x7f22baf3cd20 , 
opt=, ctx=) at tasn_dec.c:582
#12 0x7f22bac4ae9b in ASN1_item_ex_d2i (pval=pval@entry=0x7ffc53c49a00, 
in=in@entry=0x7ffc53c49a60, len=1513, len@entry=1517, 
it=it@entry=0x7f22baf35ee0 ,
tag=, tag@entry=-1, aclass=, 
aclass@entry=0, opt=opt@entry=0 '\000', ctx=ctx@entry=0x7ffc53c49a10) at 
tasn_dec.c:445
#13 0x7f22bac4b294 in ASN1_item_d2i (pval=0x7ffc53c49a00, 
pval@entry=0x0, in=in@entry=0x7ffc53c49a60, len=len@entry=1517, 
it=it@entry=0x7f22baf35ee0 ) at tasn_dec.c:146
#14 0x7f22bac435ec in d2i_X509 (a=a@entry=0x0, 
in=in@entry=0x7ffc53c49a60, len=len@entry=1517) at x_x509.c:143
#15 0x7f22baf71da2 in ssl3_get_server_certificate (s=s@entry=0x2167a50) 
at s3_clnt.c:1228
#16 0x7f22baf76cee in ssl3_connect (s=0x2167a50) at s3_clnt.c:345
#17 0x7f22baf8166e in ssl23_get_server_hello (s=0x2167a50) at 
s23_clnt.c:799
#18 ssl23_connect (s=0x2167a50) at s23_clnt.c:228
#19 0x0044a755 in ngx_ssl_handshake (c=0x7f22b8ca0f60) at 
src/event/ngx_event_openssl.c:791
#20 0x0044adbf in ngx_ssl_handshake_handler (ev=0x7f22b8b99640) at 
src/event/ngx_event_openssl.c:939
#21 0x0043a8da in ngx_event_process_posted (cycle=0x1e86db0, 
posted=0x73d4e8 ) at src/event/ngx_event_posted.c:40
#22 0x0043843a in ngx_process_events_and_timers (cycle=0x1e86db0) 
at src/event/ngx_event.c:275
#23 0x00445dad in ngx_worker_process_cycle (cycle=0x1e86db0, 
data=0x1) at src/os/unix/ngx_process_cycle.c:879
#24 0x004423cb in ngx_spawn_process (cycle=0x1e86db0, proc=0x445bca 
, data=0x1, name=0x4ff02f "worker process", 
respawn=1)
at src/os/unix/ngx_process.c:198
#25 0x0044579d in ngx_reap_children (cycle=0x1e86db0) at 
src/os/unix/ngx_process_cycle.c:688
#26 0x0043 in ngx_master_process_cycle (cycle=0x1e86db0) at 
src/os/unix/ngx_process_cycle.c:241
#27 0x004075fb in main (argc=3

[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

2016-06-13 Thread Quanah Gibson-Mount via RT 
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  0x7f3c70fe8171 in ldap_pvt_thread_cond_wait (cond=0x1fa0038,
mutex=0x1fa0010) at thr_posix.c:277
No locals.
#2  0x7f3c70fe63c2 in ldap_pvt_thread_pool_destroy (tpool=0x7618c0
, run_pending=1) at tpool.c:817
pool = 0x1f763c0
pptr = 0x1f763c0
pq = 0x1fa
task = 0x7f3c716a61c8
i = 0
#3  0x00438967 in slapd_daemon_task (ptr=0x1d7bce8) at daemon.c:2829
l = 3
last_idle_check = 1464372736
ebadf = 0
tid = 0
#4  0x7f3c70552184 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  0x7f3c7027f37d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:111
No locals.

Thread 3 (Thread 0x7f1468498700 (LWP 16810)):
#0  0x7f3c705593ad in read () at ../sysdeps/unix/syscall-template.S:81
No locals.
#1  0x7f3c70dd2435 in sb_stream_read (sbiod=0x5d36630, buf=0x5a3c057,
len=433) at sockbuf.c:490D0D
__PRETTY_FUNCTION__ = "sb_stream_read"
#2  0x7f3c70dd2e56 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  0x7f3c7101ebd1 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#00#003#00\004."..., len=433) at tls_o.c:721
p = 0x5a6caa0
ret = 79
#4  0x7f3c6f19988b in BIO_read () from
/opt/zimbra/common/lib/libcrypto.so.1.0.0
No symbol table info available.
#5  0x7f3c6f501ffc in ssl3_read_n () from
/opt/zimbra/common/lib/libssl.so.1.0.0
No symbol table info available.
#6  0x7f3c6f503ebf in ssl3_read_bytes () from
/opt/zimbra/common/lib/libssl.so.1.0.0
No symbol table info available.
#7  0x7f3c6f50033b in ssl3_read () from
/opt/zimbra/common/lib/libssl.so.1.0.0
No symbol table info available.
#8  0x7f3c7101f093 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  0x7f3c70dd2e56 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

[openssl-dev] [openssl.org #4165] 1.0.1q release busted, does not compile

2015-12-03 Thread Quanah Gibson-Mount via RT 
make[5]: Leaving directory 
`/home/build/p4/zimbra/main/ThirdParty/openssl/tmp/UBUNTU14_64/zimbra-openssl/crypto/err'
making all in crypto/evp...
make[5]: Entering directory 
`/home/build/p4/zimbra/main/ThirdParty/openssl/tmp/UBUNTU14_64/zimbra-openssl/crypto/evp'
gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include  -fPIC 
-DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -g 
-O2 -DOPENSSL_NO_HEARTBEATS -m64 -DL_ENDIAN -O3 -Wall -DOPENSSL_IA32_SSE2 
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m 
-DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM 
-DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -D_FORTIFY_SOURCE=2  -c -o encode.o 
encode.c
gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include  -fPIC 
-DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -g 
-O2 -DOPENSSL_NO_HEARTBEATS -m64 -DL_ENDIAN -O3 -Wall -DOPENSSL_IA32_SSE2 
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m 
-DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM 
-DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -D_FORTIFY_SOURCE=2  -c -o digest.o 
digest.c
gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include  -fPIC 
-DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -g 
-O2 -DOPENSSL_NO_HEARTBEATS -m64 -DL_ENDIAN -O3 -Wall -DOPENSSL_IA32_SSE2 
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m 
-DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM 
-DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -D_FORTIFY_SOURCE=2  -c -o 
evp_enc.o evp_enc.c
gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include  -fPIC 
-DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -g 
-O2 -DOPENSSL_NO_HEARTBEATS -m64 -DL_ENDIAN -O3 -Wall -DOPENSSL_IA32_SSE2 
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m 
-DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM 
-DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -D_FORTIFY_SOURCE=2  -c -o 
evp_key.o evp_key.c
gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include  -fPIC 
-DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -g 
-O2 -DOPENSSL_NO_HEARTBEATS -m64 -DL_ENDIAN -O3 -Wall -DOPENSSL_IA32_SSE2 
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m 
-DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM 
-DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -D_FORTIFY_SOURCE=2  -c -o 
evp_acnf.o evp_acnf.c
gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include  -fPIC 
-DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -g 
-O2 -DOPENSSL_NO_HEARTBEATS -m64 -DL_ENDIAN -O3 -Wall -DOPENSSL_IA32_SSE2 
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m 
-DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM 
-DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -D_FORTIFY_SOURCE=2  -c -o 
evp_cnf.o evp_cnf.c
gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include  -fPIC 
-DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -g 
-O2 -DOPENSSL_NO_HEARTBEATS -m64 -DL_ENDIAN -O3 -Wall -DOPENSSL_IA32_SSE2 
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m 
-DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM 
-DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -D_FORTIFY_SOURCE=2  -c -o e_des.o 
e_des.c
gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include  -fPIC 
-DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -g 
-O2 -DOPENSSL_NO_HEARTBEATS -m64 -DL_ENDIAN -O3 -Wall -DOPENSSL_IA32_SSE2 
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m 
-DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM 
-DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -D_FORTIFY_SOURCE=2  -c -o e_bf.o 
e_bf.c
make[5]: *** No rule to make target `../../include/openssl/idea.h', needed 
by `e_idea.o'.  Stop.


--

Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.

Zimbra ::  the leader in open source messaging and collaboration

___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4153] [PATCH] Fix grammar errors in s_client.c

2015-11-22 Thread Quanah Gibson-Mount via RT 
This patch fixes small grammar errors in s_client.c.




--Quanah

--

Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.

Zimbra ::  the leader in open source messaging and collaboration

___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #3857] hash files for validating source are incorrectly formed

2015-05-22 Thread Quanah Gibson-Mount via RT 
The hash files (md5, sha1) for validating downloaded source are not 
correclty formed, breaking the check (-c) function:

wget https://www.openssl.org/source/openssl-1.0.1m.tar.gz
wget https://www.openssl.org/source/openssl-1.0.1m.tar.gz.sha1
build@c7test:~/p4/zimbra/main/ThirdParty/openssl/src$ sha1sum -c 
openssl-1.0.1m.tar.gz.sha1
sha1sum: openssl-1.0.1m.tar.gz.sha1: no properly formatted SHA1 checksum 
lines found
build@c7test:~/p4/zimbra/main/ThirdParty/openssl/src$ cat 
openssl-1.0.1m.tar.gz.sha1
4ccaf6e505529652f9fdafa01d1d8300bd9f3179

Now, to have it correctly formatted:

build@c7test:~/p4/zimbra/main/ThirdParty/openssl/src$ sha1sum 
openssl-1.0.1m.tar.gz > openssl-1.0.1m.tar.gz.sha1
build@c7test:~/p4/zimbra/main/ThirdParty/openssl/src$ cat 
openssl-1.0.1m.tar.gz.sha1
4ccaf6e505529652f9fdafa01d1d8300bd9f3179  openssl-1.0.1m.tar.gz
build@c7test:~/p4/zimbra/main/ThirdParty/openssl/src$ sha1sum -c 
openssl-1.0.1m.tar.gz.sha1
openssl-1.0.1m.tar.gz: OK

--Quanah

--

Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.

Zimbra ::  the leader in open source messaging and collaboration


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3717] Patch for IPv6 support in s_client/s_server

2015-03-25 Thread Quanah Gibson-Mount via RT 
--On Wednesday, March 25, 2015 12:01 AM +0100 Kurt Roeckx via RT 
 wrote:

> On Tue, Mar 24, 2015 at 10:09:18PM +0100, Salz, Rich via RT wrote:
>> The short answer is that nobody has come up with comprehensive
>> cross-platform IPv6 support.  Fixing the apps isn't enough; how does a
>> server listen on IPv4, v6, both -- and make it work on our supported
>> platforms? What should the various BIO API's do?
>
> Please note that I actually have a patch that does all that.  I
> also said not to actually submit this patch.

Where can one obtain your patch from?  When will it be integrated into 
OpenSSL?  Do you have a version of your patch that works with the 1.0.1 
series?

--Quanah


--

Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.

Zimbra ::  the leader in open source messaging and collaboration


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3717] Patch for IPv6 support in s_client/s_server

2015-03-24 Thread Quanah Gibson-Mount via RT 
--On Tuesday, March 24, 2015 9:29 PM + "Short, Todd" 
 wrote:

> I was unaware of 2501. But that's fine by me… however, why hasn't
> 2051 been applied to the code?

People have been asking this question for years.

https://lwn.net/Articles/486369/



Here's an even *older* RT from 2006: 


There's never been any sort of real substantive answer as to why getting 
IPv6 support in has taken almost a decade, when people have constantly 
supplied patches for it.  Supposedly it was going to go into 1.0.2.


--Quanah

--

Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.

Zimbra ::  the leader in open source messaging and collaboration


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3717] Patch for IPv6 support in s_client/s_server

2015-03-24 Thread Quanah Gibson-Mount via RT 
--On Tuesday, March 03, 2015 3:15 PM -0600 "Short, Todd" 
 wrote:

> The previous patch file had two bugs due to a swapped argument and the
> formatting changes (missing braces).
>
>
> The attached is an updated patch.

Why did you open a new RT when 
 already exists and has 
for ages?  I would suggest RT3717 be marked as a duplicate of 2051.

--Quanah

--

Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.

Zimbra ::  the leader in open source messaging and collaboration


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl.org #2665] s_client support for starttls ldap

2014-11-13 Thread Quanah Gibson-Mount via RT 
Like it or not, s_client is generally the de facto tool for testing 
starttls via the openssl command line.

In addition, the work to add support for startTLS and ldap is rather 
trivial, and has already been done:



It would be invaluable to have this support in OpenSSL to admins around the 
world.  This subject comes up repeatedly because people expect it to work.

--Quanah

-- 
Quanah Gibson-Mount
Platform Architect
Zimbra, Inc

Zimbra ::  the leader in open source messaging and collaboration


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #3381] Typo in macro name for ASN (1.0.1h)

2014-06-09 Thread Quanah Gibson-Mount via RT 
--On Sunday, June 08, 2014 11:57 PM +0200 Matt Caswell via RT 
 wrote:

> Hi Quanah
>
> Thanks for the submission. The problem with correcting this is that
> technically it forms part of the public API (since the macro is defined
> in asn1.h). I guess there's probably not a huge risk in changing it, as I
> can't imagine there's too many people relying on that define being there,
> but then on the other hand as this is just a minor cosmetic change its
> probably not worth it.
>
> I note that this has been spotted before and that the decision then was
> to just correct the error string itself (and not the macro name) - see
> commit 2b4ffc6. I think that's a reasonable compromise, so I'll stick
> with that decision and not make any further corrections.

It could be fixed for 1.0.2 however, right?  It's reasonable to expect the 
API to change across major releases.

--Quanah



--

Quanah Gibson-Mount
Server Architect
Zimbra, Inc.

Zimbra ::  the leader in open source messaging and collaboration


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #3381] Typo in macro name for ASN (1.0.1h)

2014-06-06 Thread Quanah Gibson-Mount via RT 
ASN1_R_UNKOWN_FORMAT should be ASN1_R_UNKNOWN_FORMAT:

./crypto/asn1/asn1_err.c:{ERR_REASON(ASN1_R_UNKOWN_FORMAT),"unknown 
format"},
./crypto/asn1/asn1_gen.c:   ASN1err(ASN1_F_ASN1_CB, 
ASN1_R_UNKOWN_FORMAT);
./crypto/asn1/asn1.h:#define ASN1_R_UNKOWN_FORMAT 
195

--Quanah

--

Quanah Gibson-Mount
Server Architect
Zimbra, Inc.

Zimbra ::  the leader in open source messaging and collaboration

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #2866] Openssl can deadlock OpenSSL version 1.0.1c

2012-09-04 Thread Quanah Gibson-Mount via RT 
--On Tuesday, September 04, 2012 10:26 PM +0200 Stephen Henson via RT 
 wrote:

>> [qua...@zimbra.com - Tue Aug 28 22:43:34 2012]:
>>
>> --On Tuesday, August 28, 2012 4:36 PM +0200 The default queue via RT
>>  wrote:
>>
>> Mutex information from gdb:
>>
>> (gdb) print mutex
>> $5 = (ldap_pvt_thread_mutex_t *) 0x7f8387626f30
>> (gdb) print *mutex
>> $6 = {__data = {__lock = 2, __count = 0, __owner = 23352, __nusers = 1,
>> __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}},
>>   __size = "\002\000\000\000\000\000\000\000\070[\000\000\001", '\000'
>> , __align = 2}
>>
>>
>
> Can you provide a stack trace when you get the deadlock?

Hi Stephen,

The first comment is a full stack trace.  Did you download it from RT?



--Quanah

--

Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.

Zimbra ::  the leader in open source messaging and collaboration


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #2866] AutoReply: Openssl can deadlock OpenSSL version 1.0.1c

2012-08-28 Thread Quanah Gibson-Mount via RT 
--On Tuesday, August 28, 2012 4:36 PM +0200 The default queue via RT 
 wrote:

Mutex information from gdb:

(gdb) print mutex
$5 = (ldap_pvt_thread_mutex_t *) 0x7f8387626f30
(gdb) print *mutex
$6 = {__data = {__lock = 2, __count = 0, __owner = 23352, __nusers = 1, 
__kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}},
  __size = "\002\000\000\000\000\000\000\000\070[\000\000\001", '\000' 
, __align = 2}


--Quanah



--

Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.

Zimbra ::  the leader in open source messaging and collaboration


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #2866] Openssl can deadlock OpenSSL version 1.0.1c

2012-08-28 Thread Quanah Gibson-Mount via RT 
In using OpenLDAP 2.4.32 linked to OpenSSL 1.0.1c, OpenSSL can deadlock by 
having a thread try to acquire a lock on a mutex that it already owns.

#0  0x7f838666eb53 in epoll_wait () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x004373db in slapd_daemon_task (ptr=0x16cfe48) at daemon.c:2540
#2  0x7f8386940e9a in start_thread () from
/lib/x86_64-linux-gnu/libpthread.so.0
#3  0x7f838666e4bd in clone () from /lib/x86_64-linux-gnu/libc.so.6
#4  0x in ?? ()

Thread 9 (Thread 0x7f6f80b46700 (LWP 23349)):
#0  0x7f838694789c in __lll_lock_wait () from
/lib/x86_64-linux-gnu/libpthread.so.0
#1  0x7f8386943065 in _L_lock_858 () from
/lib/x86_64-linux-gnu/libpthread.so.0
#2  0x7f8386942eba in pthread_mutex_lock () from
/lib/x86_64-linux-gnu/libpthread.so.0
#3  0x7f83873d9d90 in ldap_pvt_thread_mutex_lock (mutex=0x7f8387626f30) 
at
thr_posix.c:296
#4  0x7f838740da54 in tlso_locking_cb (mode=9, type=10, 
file=0x7f8385683d3b
"pmeth_lib.c", line=185) at tls_o.c:84
#5  0x7f83855748a7 in CRYPTO_add_lock (pointer=0x3564048, amount=1, 
type=10,
file=0x7f8385683d3b "pmeth_lib.c", line=) at
cryptlib.c:632
#6  0x7f838560aaed in int_ctx_new (pkey=0x3564040, e=,
id=) at pmeth_lib.c:185
#7  0x7f838560c094 in do_sigver_init (ctx=0x7f6f80b455c0, pctx=0x0,
type=0x7f83858d1860, e=0x0, pkey=, ver=) at
m_sigver.c:71
#8  0x7f8385612c90 in ASN1_item_verify (it=0x7f83858cbe40, a=, signature=0x3534e00, asn=0x1f1efc0, pkey=0x3564040) at a_verify.c:185
#9  0x7f8385632327 in internal_verify (ctx=0x7f6f80b45720) at
x509_vfy.c:1627
#10 0x7f8385632e13 in X509_verify_cert (ctx=0x7f6f80b45720) at
x509_vfy.c:367
#11 0x7f838591474b in ssl3_output_cert_chain (s=0x1dc9180, x=) at s3_both.c:377
#12 0x7f8385907965 in ssl3_send_server_certificate (s=0x1dc9180) at
s3_srvr.c:3336
#13 0x7f83859090c4 in ssl3_accept (s=0x1dc9180) at s3_srvr.c:415
#14 0x7f8385915a63 in ssl23_accept (s=0x1dc9180) at s23_srvr.c:210
#15 0x7f838740e328 in tlso_session_accept (sess=0x1dc9180) at 
tls_o.c:372
#16 0x7f838740bb3a in ldap_pvt_tls_accept (sb=0x3530d20, 
ctx_arg=0x16fa600)
at tls2.c:421
#17 0x0043bfb5 in connection_read (s=10, cri=0x7f6f80b45b10) at
connection.c:1367
#18 0x0043bb56 in connection_read_thread (ctx=0x7f6f80b45b60, 
argv=0xa)
at connection.c:1279
#19 0x7f83873d877a in ldap_int_thread_pool_wrapper (xpool=0x1714000) at
tpool.c:688
#20 0x7f8386940e9a in start_thread () from
/lib/x86_64-linux-gnu/libpthread.so.0
#21 0x7f838666e4bd in clone () from /lib/x86_64-linux-gnu/libc.so.6
#22 0x in ?? ()

Thread 8 (Thread 0x7f6f80345700 (LWP 23352)):
#0  0x7f838694789c in __lll_lock_wait () from
/lib/x86_64-linux-gnu/libpthread.so.0
#1  0x7f8386943065 in _L_lock_858 () from
/lib/x86_64-linux-gnu/libpthread.so.0
#2  0x7f8386942eba in pthread_mutex_lock () from
/lib/x86_64-linux-gnu/libpthread.so.0
#3  0x7f83873d9d90 in ldap_pvt_thread_mutex_lock (mutex=0x7f8387626f30) 
at
thr_posix.c:296
#4  0x7f838740da54 in tlso_locking_cb (mode=9, type=10, 
file=0x7f838568a7ef
"p_lib.c", line=393) at tls_o.c:84
#5  0x7f83855748a7 in CRYPTO_add_lock (pointer=0x17bbec8, amount=-1,
type=10, file=0x7f838568a7ef "p_lib.c", line=) at
cryptlib.c:632
#6  0x7f8385605459 in EVP_PKEY_free (x=0x17bbec0) at p_lib.c:393
#7  0x7f8385614bfa in X509_PUBKEY_get (key=0x3535b00) at x_pubkey.c:178
#8  0x7f8385632310 in internal_verify (ctx=0x7f6f80344720) at
x509_vfy.c:1620
#9  0x7f8385632e13 in X509_verify_cert (ctx=0x7f6f80344720) at
x509_vfy.c:367
#10 0x7f838591474b in ssl3_output_cert_chain (s=0x1dc8700, x=) at s3_both.c:377
#11 0x7f8385907965 in ssl3_send_server_certificate (s=0x1dc8700) at
s3_srvr.c:3336
#12 0x7f83859090c4 in ssl3_accept (s=0x1dc8700) at s3_srvr.c:415
#13 0x7f8385915a63 in ssl23_accept (s=0x1dc8700) at s23_srvr.c:210
#14 0x7f838740e328 in tlso_session_accept (sess=0x1dc8700) at 
tls_o.c:372
#15 0x7f838740bb3a in ldap_pvt_tls_accept (sb=0x3530c00, 
ctx_arg=0x16fa600)
at tls2.c:421
#16 0x0043bfb5 in connection_read (s=12, cri=0x7f6f80344b10) at
connection.c:1367
#17 0x0043bb56 in connection_read_thread (ctx=0x7f6f80344b60, 
argv=0xc)
at connection.c:1279
#18 0x7f83873d877a in ldap_int_thread_pool_wrapper (xpool=0x1714000) at
tpool.c:688
#19 0x7f8386940e9a in start_thread () from
/lib/x86_64-linux-gnu/libpthread.so.0
#20 0x7f838666e4bd in clone () from /lib/x86_64-linux-gnu/libc.so.6
#21 0x in ?? ()

Thread 7 (Thread 0x7f6f7fb44700 (LWP 23455)):
#0  0x7f838694789c in __lll_lock_wait () from
/lib/x86_64-linux-gnu/libpthread.so.0
#1  0x7f8386943065 in _L_lock_858 () from
/lib/x86_64-linux-gnu/libpthread.so.0
#2  0x7f8386942eba in pthread_mutex_lock () from
/lib/x86_64-linux-gnu/libpthread.so.0
#3  0x7f83873d9d90 in ldap_pvt_thread_mutex_lock (mutex=0x7f8387626f30) 
at
thr_posix.c:296
#4  0x7f838740da54 in tlso_locking_cb (