What is the appropriate size for 'buf' in DSA_size()?
4 bytes is certainly not correct. My guess is that we want to support at
least 256 bits and so it needs to be at least 32 bytes. Does anyone
have a better recommendation?
Jeffrey Altman * Volunteer Developer Kermit 95 2.1 GUI availa
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 {
- 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 se
On Mon, Nov 25, 2002 at 09:54:13AM +0100, Richard Levitte - VMS Whacker via RT wrote:
>
> 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>
On Sun, Nov 24, 2002 at 08:17:35PM +0100, Peter 'Luna' Runestig wrote:
> 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 DH
OUTPUT OF ./config -t
Operating system: 9000/785-hp-hpux11
Configuring for hpux11
/usr/contrib/bin/perl ./Configure hpux11
Following the error reported by the command "make"
after running ./Configure hpux11-64bit-cc on a system HP-UX hpiv113 B.11.11 U 9000/785
2016775763 unlimited-user license
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
On Mon, Nov 25, 2002 at 10:22:37AM +0100, Romana Rubino via RT wrote:
>
> OUTPUT OF ./config -t
>
> Operating system: 9000/785-hp-hpux11
> Configuring for hpux11
> /usr/contrib/bin/perl ./Configure hpux11
>
> Following the error reported by the command "make"
> after running ./Configure hpux11-
Sorry
(See attached file: err)
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMA
[[EMAIL PROTECTED] - Mon Nov 25 11:14:15 2002]:
>
> Sorry
> (See attached file: err)
making all in crypto...
cc -I. -I../include -DTHREADS -D_REENTRANT +DA2.0W -g
-D_HPUX_SOURCE -Aa -Ae +ESlit -c cryptlib.c
(Bundled) cc: warning 480: The -g option is available only with the
C/ANSI C
I already have a gcc installed (that one GNU). Can you know it is ok?
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List
How can I force the use of gcc?
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAI
I try what your technician suggested me. I use now gcc but my compilation
failed because I don't have a file idea.h in my sources. See the message :
making all in crypto...
( echo "#ifndef MK1MF_BUILD"; \
echo " /* auto-generated by crypto/Makefile.ssl for crypto/cversion.c */"; \
[[EMAIL PROTECTED] - Mon Nov 25 12:02:08 2002]:
> I try what your technician suggested me. I use now gcc but my
> compilation
> failed because I don't have a file idea.h in my sources. See the
> message :
> making all in crypto...
> ( echo "#ifndef MK1MF_BUILD"; \
> echo " /* aut
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
"Lutz Jaenicke via RT" <[EMAIL PROTECTED]>@serv01.aet.tu-cottbus.de> on
25/11/2002 12.04.38
Please respond to [EMAIL PROTECTED]
Sent by: <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc: [EMAIL PROTECTED]
Subject: [openssl.org #363] another problem
> I don't know, what is going on
Jeffrey Altman via RT wrote:
> What is the appropriate size for 'buf' in DSA_size()?
>
> 4 bytes is certainly not correct.
Hi Jeffry,
I think it's correct :-)
int DSA_size(const DSA *r)
{
int ret,i;
ASN1_INTEGER bs;
unsign
Trying to rsync the cvs repository results in "Connection refused" & has
been doing so for the last few days.
--
__
| Brian Havard | "He is not the messiah! |
| [EMAIL PROTECTED] |
On Mon, Nov 25, 2002 at 12:10:14PM +0100, Romana Rubino via RT wrote:
> "Lutz Jaenicke via RT" <[EMAIL PROTECTED]>@serv01.aet.tu-cottbus.de> on
> 25/11/2002 12.04.38
>
> > I don't know, what is going on in your case. My copies of OpenSSL
> > include idea.h.
> > Anyway: you are somehow intermixing
Thanks. That is very reassuring.
>
> Jeffrey Altman via RT wrote:
> > What is the appropriate size for 'buf' in DSA_size()?
> >
> > 4 bytes is certainly not correct.
>
> Hi Jeffry,
>
> I think it's correct :-)
>
> int DSA_size(const DSA *r)
> {
> int ret,i;
Could you please send me the inlcude idea.h file?
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager
On Mon, Nov 25, 2002 at 01:49:15PM +0100, Romana Rubino via RT wrote:
>
>
> Could you please send me the inlcude idea.h file?
Please download a recent version of openssl (0.9.6g is the latest stable
release) from www.openssl.org. All required components are included.
Case closed,
Lutz
As I've already asked, where can I find this idea.h file? This ssl part is
inserted in a greather environmet, sure can be there a "bsave" component.
Sure I cannot compile my libssl.a library caused I cannot find idea.h.
__
Op
On Mon, Nov 25, 2002 at 02:06:13PM +0100, Romana Rubino via RT wrote:
> As I've already asked, where can I find this idea.h file? This ssl part is
> inserted in a greather environmet, sure can be there a "bsave" component.
> Sure I cannot compile my libssl.a library caused I cannot find idea.h.
A
[[EMAIL PROTECTED] - Sun Nov 24 19:52:37 2002]:
> 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);
>
> /* Mak
In message <[EMAIL PROTECTED]> on Mon, 25 Nov 2002 09:32:30
+0100 (MET), "Jeffrey Altman via RT" <[EMAIL PROTECTED]> said:
rt>
rt> What is the appropriate size for 'buf' in DSA_size()?
rt>
rt> 4 bytes is certainly not correct. My guess is that we want to support at
rt> least 256 bits and so it
In message <[EMAIL PROTECTED]> on Mon, 25 Nov 2002 09:32:30
+0100 (MET), "Jeffrey Altman via RT" <[EMAIL PROTECTED]> said:
rt>
rt> What is the appropriate size for 'buf' in DSA_size()?
rt>
rt> 4 bytes is certainly not correct. My guess is that we want to support at
rt> least 256 bits and so i
The code is the same in both 0.9.6- and 0.9.7-beta4. in 0.9.7-b4
there is an assertion added that is being triggered because the buf
size is considered too small. However, tracing through the calls
shows that even with a 160bit input only the first byte is ever
touched.
That does not mean other
The code is the same in both 0.9.6- and 0.9.7-beta4. in 0.9.7-b4
there is an assertion added that is being triggered because the buf
size is considered too small. However, tracing through the calls
shows that even with a 160bit input only the first byte is ever
touched.
That does not mean other
Jeffrey Altman wrote:
> The code is the same in both 0.9.6- and 0.9.7-beta4. in 0.9.7-b4
> there is an assertion added that is being triggered because the buf
> size is considered too small. However, tracing through the calls
> shows that even with a 160bit input only the first byte is ever
> tou
Jeffrey Altman wrote:
> The code is the same in both 0.9.6- and 0.9.7-beta4. in 0.9.7-b4
> there is an assertion added that is being triggered because the buf
> size is considered too small. However, tracing through the calls
> shows that even with a 160bit input only the first byte is ever
> to
In the current implementation of OpenSSL, compression/decompression state is
initialized and destroyed per record. It cannot possibly interoperate with
a compressor that maintains compression state across records. The
decompressor does care, unfortunately. The other way around could work,
though
Eric:
Thanks for your feedback. Please contribute your code. I suggest you
use
eayZLIBstream(226)
- Jeff
> In the current implementation of OpenSSL, compression/decompression state is
> initialized and destroyed per record. It cannot possibly interoperate with
> a compressor that maintai
Then the assertion should be removed because as it is now it will
always fail.
>
> Jeffrey Altman wrote:
> > The code is the same in both 0.9.6- and 0.9.7-beta4. in 0.9.7-b4
> > there is an assertion added that is being triggered because the buf
> > size is considered too small. However, traci
Then the assertion should be removed because as it is now it will
always fail.
>
> Jeffrey Altman wrote:
> > The code is the same in both 0.9.6- and 0.9.7-beta4. in 0.9.7-b4
> > there is an assertion added that is being triggered because the buf
> > size is considered too small. However, trac
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Le Saux, Eric
> In the current implementation of OpenSSL,
> compression/decompression state is
> initialized and destroyed per record. It cannot possibly
> interoperate with
> a compressor that maintai
Env: openssl-0.9.6g (9-aug-2002), VC6/masm, WinXP
Hi,
When you do BIO_push on a SSL BIO object, reference count (CRYPTO_LOCK_BIO)
is increased on next BIO object. The problem is when you later pop the SSL
BIO, then the reference count isn't decreased. This isn't a problem as long
as you're suppos
38 matches
Mail list logo
