Gregory Stark wrote:
Oops, I meant 2246. And reading it more carefully, I agree with your
interpretation. The dictionary need not be reset. Compression state can and
should be maintained across records.
So, is anyone working on improving the zlib code according to these new
guidelines?
Hard to believe it might by true. Nevertheless
everything indicates there is a major design flaw
in BIO:
BIO sends FILE* pointer across dll boundary, causing
crash of statically linked version of libeay32.dll.
(At least on WINNT). To reproduce, modify the corresponding
compiler switch to /MT
In message [EMAIL PROTECTED] on Sun, 24 Nov 2002 11:38:09 +0100, ssl
mailing list [EMAIL PROTECTED] said:
ssl Hard to believe it might by true. Nevertheless
ssl everything indicates there is a major design flaw
ssl in BIO:
ssl
ssl BIO sends FILE* pointer across dll boundary, causing
ssl crash
In message [EMAIL PROTECTED] on Sun, 24 Nov 2002 10:10:26 +0100, Peter
'Luna' Runestig [EMAIL PROTECTED] said:
peter+openssl-dev Gregory Stark wrote:
peter+openssl-dev Oops, I meant 2246. And reading it more
peter+openssl-dev carefully, I agree with your interpretation. The
peter+openssl-dev
This is not a design flaw in the BIO. It is a requirement on Windows
that the DLLs be built with the same run-time library and threading
models as the application.
Hard to believe it might by true. Nevertheless
everything indicates there is a major design flaw
in BIO:
BIO sends FILE*
http://www.ietf.org/internet-drafts/draft-ietf-tls-compression-03.txt
defines the compression numbers to be:
enum { null(0), ZLIB(1), LZS(2), (255) } CompressionMethod;
Therefore proposed numbers have been issued. I suggest that OpenSSL
define the CompressionMethod numbers to be:
enum {
Building shared libraries with static C Run Time Libraries is a
disaster waiting to happen on many platforms. It is simply something
you should not do. Not just because of the problem you are describing
but because the C Run Time Libraries might be from completely
incompatible implementations.
Hi!
I have a small problem with SSL_get_error. This function starts like this:
int SSL_get_error(SSL *s,int i)
{
int reason;
unsigned long l;
BIO *bio;
if (i 0) return(SSL_ERROR_NONE);
/* Make things return SSL_ERROR_SYSCALL when doing SSL_do_handshake
* etc,
OpenSSL STATUS Last modified at
__ $Date: 2002/11/21 22:39:08 $
DEVELOPMENT STATE
o OpenSSL 0.9.8: Under development...
o OpenSSL 0.9.7-beta4: Released on November 19th, 2002
Debian GNU/Linux (kernel version
Hi all,
I have a client and a server, that sets SSL_CTX_set_cipher_list(ALL)
(and SSL_CTX_set_tmp_dh_callback()). With beta3 and beta4, that makes
the negotiated cipher to be ADH-AES256-SHA. I would expect something
like DHE-RSA-AES256-SHA instead (which I get if I do
In message 001601c2940a$deed1b60$06a8a8c0@dell8200 on Sun, 24 Nov 2002 16:43:12
-0600, pobox [EMAIL PROTECTED] said:
ghstark What will the current implementation of thedecompressor in
ghstark OpenSSL do in each of these cases?
Unless this can be determined, it can be tested by having several
The ms\mingw32.bat build fails with these undefines:
out/libcrypto.a(eng_all.o)(.text+0x9):eng_all.c: undefined reference to
`ENGINE_load_cswift'
out/libcrypto.a(eng_all.o)(.text+0xe):eng_all.c: undefined reference to
`ENGINE_load_chil'
out/libcrypto.a(eng_all.o)(.text+0x13):eng_all.c:
Hi Everyone,
On Tru64, while using the des_key_schedule structures for the private session key
encryption using a public key (of type RSA pub key), is there anything different I have
to code as opposed to the other machines. While I was debugging, the des_key_schedule
structures size returned
13 matches
Mail list logo
