Re: Tomcat + HttpClient + SSL + tcnative-1.dll issues?
Stacy Johnson (stacjohn) wrote: Are there any known issues when using the Apache HttpClient to send https requests to Tomcat running with tcnative-1.dll? Perhaps different SSL stacks causing issues? Nope, it was an bug in tcnative. See: http://svn.apache.org/viewvc?rev=605571view=rev The fix is included with 1.1.12 Regards, Mladen __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1629] BUG: SSLv3 only client broken with some servers
OpenSSL 0.9.8g SSLv3 only client (with tlsext support compiled in) is broken when communicating with some servers. Example: openssl s_client -ssl3 -connect irc.mozilla.org:6697 -debug CONNECTED(0003) write to 0x67f3c0 [0x6891b0] (111 bytes = 111 (0x6F)) - 16 03 00 00 6a 01 00 00-66 03 00 47 60 56 dc 7a j...f..G`V.z 0010 - f6 39 00 47 08 6c 19 46-2e b6 c9 85 b6 68 88 59 .9.G.l.F.h.Y 0020 - e3 0e 79 96 df e1 68 ff-ea d0 0a 00 00 38 00 39 ..y...h..8.9 0030 - 00 38 00 35 00 88 00 87-00 84 00 16 00 13 00 0a .8.5 0040 - 00 33 00 32 00 2f 00 9a-00 99 00 96 00 45 00 44 .3.2./...E.D 0050 - 00 41 00 05 00 04 00 15-00 12 00 09 00 14 00 11 .A.. 0060 - 00 08 00 06 00 03 02 01-00 00 04 00 23# 006f - SPACES/NULS read from 0x67f3c0 [0x6849a0] (5 bytes = 5 (0x5)) - 15 03 00 00 02. read from 0x67f3c0 [0x6849a5] (2 bytes = 2 (0x2)) - 02 28 .( 5468:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1053:SSL alert number 40 5468:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:530: -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Administrivia and seasons greetings
Guenter Knauf wrote: Hi Lutz, Replies to active tickets are handled automatically. I've a ticket open where I posted a couple of times updates: http://rt.openssl.org/index.html?q=1611 but nothing of these appear here on the list - although they are properly listed with #1611... can you tell me what I'm probably doing wrong? I don't know what goes wrong for you. All of the mails have been sent to the mailing list: I have checked both my personal mailbox as well as public mail archives. Hint: my Thunderbird marked the mails as possible SCAM. Do you have any automatic SPAM filter? Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
wrong signatures in d2i_RSAPublicKey man pages
Hi list, please have a look here: http://www.freebsd.org/cgi/query-pr.cgi?pr=docs/118902 Comments? Please CC me, since I'm not on the list. Regards, -- Pietro Cerutti PGP Public Key: http://gahr.ch/pgp signature.asc Description: OpenPGP digital signature
[PROPOSAL] provide 7z snapshot archives for download
Hi, the 7-Zip archiver has recently become very popular because of its good compression rate; f.e. recent snapshot is about 34% smaller when packed with 7z compared to tar.gz: -rw-r--r-- 1 root root 2484981 Jan 5 17:28 openssl-SNAP-20080105.7z -rw-r--r-- 1 root root 3781438 Jan 5 17:27 openssl-SNAP-20080105.tar.gz For Linux there's a 7za source and binary commandline available from here: http://p7zip.sourceforge.net/ The Win32 GUI and commandline version is available from here: http://www.7-zip.org/ I dont want to propose here to just replace tar.gz with 7z, but I think it would be cool if we could have most recent snapshot additionally in 7z format. Guenter. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: [PROPOSAL] provide 7z snapshot archives for download
Hi, the 7-Zip archiver has recently become very popular because of its good compression rate; f.e. recent snapshot is about 34% smaller when packed with 7z compared to tar.gz: -rw-r--r-- 1 root root 2484981 Jan 5 17:28 openssl-SNAP-20080105.7z -rw-r--r-- 1 root root 3781438 Jan 5 17:27 openssl-SNAP-20080105.tar.gz I'm not sure if the popularity of 7-Zip is high enough to justify the effort. But the benefit is significant. I ran some tests of an OpenSSL build using default settings for all compressors. It looked like this (higher is better): Tar: 1.0 (reference) Tar+Compress: 2.7 Zip: 3.0 Tar+Zip: 4.9 Tar+GZip: 5.0 Tar+BZip2:6.2 Tar+LRZ: 7.2 Tar+7-Zip:7.3 7-Zip:7.4 A 7-Zip download will be 15% faster (and use 15% less bandwidth) than a BZip2 download and 1/3 faster than a GZip download. 7-Zip has an advantage over the other formats (except zip) in that it combines compression with archiving, making it (at least in theory) easier to manipulate the compressed archive. I'm not sure this matters anymore given how fast typical computers are and how much memory they have compared to the size of these files. The real surprise (to me, anyway) is how bad zip did on its own. I believe this is because zip compresses each file independently. This makes tar+zip provide much better compression. DS __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [PROPOSAL] provide 7z snapshot archives for download
On Sunday 06 January 2008, David Schwartz wrote: Hi, the 7-Zip archiver has recently become very popular because of its good compression rate; f.e. recent snapshot is about 34% smaller when packed with 7z compared to tar.gz: -rw-r--r-- 1 root root 2484981 Jan 5 17:28 openssl-SNAP-20080105.7z -rw-r--r-- 1 root root 3781438 Jan 5 17:27 openssl-SNAP-20080105.tar.gz I'm not sure if the popularity of 7-Zip is high enough to justify the effort. But the benefit is significant. I ran some tests of an OpenSSL build using default settings for all compressors. It looked like this (higher is better): i really dont think the 7z archive format is widely accepted in any sort of numbers that would convince posting of a .7z archive. however, i would point out that lzma (the compression algorithm that the 7z archive format employs) is gaining traction in the open source world via the lzma-utils package. this provides a set of utilities with the same general interface as gzip/bzip2. for example, the autotool packages have integrated native support for it as have a number of other core projects in the GNU world. it also has the advantage of working seamlessly with existing utilities: gzip -c -d openssl-SNAP-20080105.tar.gz | tar xf bzip2 -c -d openssl-SNAP-20080105.tar.bz2 | tar xf lzma -c -d openssl-SNAP-20080105.tar.lzma | tar xf people know `tar`, they dont know `7z` 3781438 openssl-SNAP-20080105.tar.gz 2495545 openssl-SNAP-20080105.tar.lzma 2484981 openssl-SNAP-20080105.7z looks to me like tar+lzma is the way to go, not 7z -mike signature.asc Description: This is a digitally signed message part.
RE: [PROPOSAL] provide 7z snapshot archives for download
looks to me like tar+lzma is the way to go, not 7z In my quick test, lzma got a 7.6, beating 7z by a negligible margin. I think it largely comes down to whether any of these are popular enough to justify the effort of offering in that format. We've been down this road before in the transition from compress to gzip and then from gzip to bzip2. DS __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [PROPOSAL] provide 7z snapshot archives for download
On Sunday 06 January 2008, David Schwartz wrote: looks to me like tar+lzma is the way to go, not 7z In my quick test, lzma got a 7.6, beating 7z by a negligible margin. I think it largely comes down to whether any of these are popular enough to justify the effort of offering in that format. We've been down this road before in the transition from compress to gzip and then from gzip to bzip2. sure, i perfectly understand there's more to it than just 1 more file, what's the big deal. please dont take my comments as you need to get on this!. i'm just trying to direct things such that if you do decide to start supporting/transitioning to a new format, it's the right one looking at things long term and such. if there is a new compression standard coming up in the open source world, i believe it's going to be lzma-utils. imo, .lzma is the only thing worth considering at this time. wait a few releases of openssl and you'll get a better feel for how viable lzma is (or isnt). conversely, i'd put hard cash that 7z will not supplant tar ... after all, that is what the comparison actually is. 7z is an archiver (that also does compression). tar is an archiver. bzip2/gzip/lzma do compression. tar+lzma ftw :). side note, lzma typically is slower during compression, but faster/leaner during decompression. which is what matters in this scenario -- the packager compresses once while everyone else decompresses many many times. a few more data points from glancing at wikipedia ... Inno Setup, NSIS, and RPM include lzma in the latest releases -mike signature.asc Description: This is a digitally signed message part.
