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?
Cheers
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 and
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
s
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+op
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. P
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, w
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
SSL_CTX_set_cipher_list
- Original Message -
From: "Jeffrey Altman" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Sunday, November 24, 2002 8:26 AM
Subject: Re: OpenSSL and compression using ZLIB
> http://www.ietf.org/internet-drafts/draft-ietf-tls-compression-03.
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 sev
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: undefined
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 two
14 matches
Mail list logo