Yes, I'm interrested with the source.
Thank you very mush.
Michiels Olivier
-Original Message-
From: Greg Dowd [mailto:[EMAIL PROTECTED]]
Sent: jeudi 1 mars 2001 19:54
To: '[EMAIL PROTECTED]'
Subject: RE: TimeStamping
In our implementation, we defined our own policy OID under our
On Thu, Mar 01, 2001 at 07:23:04PM +0100, Richard Levitte - VMS Whacker wrote:
The printout will be:
28:error:140750DD:SSL routines:SSL23_CONNECT:ssl23 doing session id
reuse:s23_clnt.c:132:
... or something very similar.
The reason for all this is actually that ssl23_get_method()
In diagnosing some OpenSSH crashes on Redhat 6.2 systems, I have
tracked a problem to a binary incompatability between Redhat's OpenSSL
packages and OpenSSL packages built by myself.
My RPM packages are pretty basic, they just do a
./Configure --prefix=/usr --openssldir=%{openssldir} linux-elf
On Fri, Mar 02, 2001 at 12:30:05PM +0100, Richard Levitte - VMS Whacker wrote:
From: Lutz Jaenicke [EMAIL PROTECTED]
Lutz.Jaenicke The (needed) fix should have one side effect (from
Lutz.Jaenicke conclusion, I did not try it): Since the SSL_connect()
Lutz.Jaenicke is now performed with
From: Damien Miller [EMAIL PROTECTED]
djm I am wondering if this is enough to break structure alignment. If
djm so, is there any way of making OpenSSL more robust in the face of
djm different compiler options?
Hmm, I think I saw some structure members that do not get in place
when certain NO_*
Damien Miller wrote:
In diagnosing some OpenSSH crashes on Redhat 6.2 systems, I have
tracked a problem to a binary incompatability between Redhat's OpenSSL
packages and OpenSSL packages built by myself.
My RPM packages are pretty basic, they just do a
./Configure --prefix=/usr
Hmm, I think I saw some structure members that do not get in place
when certain NO_* macros are defined. I can do a chek of that...
I remember back when it was SSLeay and I had some folks at OSF, and then
later on at CertCo, asking that the NO_* macros only disable the
implementation, not the
From: Rich Salz [EMAIL PROTECTED]
rsalz I remember back when it was SSLeay and I had some folks at OSF, and then
rsalz later on at CertCo, asking that the NO_* macros only disable the
rsalz implementation, not the data structures. This was one of the reasons
rsalz why.
Actually, I see no
I'm porting the library (0.9.6) to an embedded device without a /dev/random.
I've undefined DEVRANDOM in e_os.h but this only results in the following
error:24064064:random number generator:SSLEAY_RAND_BYTES:PRNG not seeded
If I hard code some bytes into the RAND_poll function using the
Actually, I see no reason why one should leave the data structures
around...
Do you mean "should not" ?
One reason for removing them is that it makes it very easy to see if you
accidentally included implementation code -- it will fail to compile.
On the other hand, there are drawbacks. In
Hi Graeme,
I've had the same problem. What I did was feed the entropy pool with
anything I could find that was at least a bit 'random'. Yes, almost all
these things are highly dependent on your embedded environment.
So I editted RAND_poll() to add to the pool:
* Hardware Realtime Clock data
[Resend] Was Not Able To Take Last Entry.. Please Fill Out Again.
Hey... We Haven't Talked In So Long!! How Have You Been?
Thought I would Forward you this email!
I usually delete these but I opened this one, like what I saw,
and thought you would like to see this.
Insh_Allah wrote:
I've had the same problem. What I did was feed the entropy pool with
anything I could find that was at least a bit 'random'.
I suggest the content of the stack on any architecture where there are
asynchronous interrupts that will store content in your local stack.
Easiest
Hi Jean-Marc,
- Original Message -
From: "Jean-Marc Desperrier" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, 02 March, 2001 16:39
Subject: Re: What to do when there is no /dev/random ??
[...]
I suggest the content of the stack on any architecture where there are
asynchronous
From: Rich Salz [EMAIL PROTECTED]
Subject: Re: Binary incompatability caused by different compiler flags
Date: Fri, 02 Mar 2001 10:00:11 -0500
Message-ID: [EMAIL PROTECTED]
rsalz Actually, I see no reason why one should leave the data structures
rsalz around...
rsalz
rsalz Do you mean "should
Insh_Allah wrote:
I suggest the content of the stack on any architecture where there are
asynchronous interrupts that will store content in your local stack.
They are architectures where a context switch is made after every interrupt, and
the local stack is not used.
They are architectures
You mean where external application fiddle in the structures
themselves?
No. I mean that if the IDEA_KEY_SCHEDULE typedef is #if'd out from
idea.h, then you can be pretty confident that you're not inadvertently
doing any IDEA implementation. I meant only with OpenSSL code itself.
BUT, that
Hi Jean-Marc,
- Original Message -
From: "Jean-Marc Desperrier" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, 02 March, 2001 17:57
Subject: Re: What to do when there is no /dev/random ??
They are architectures where a context switch is made after every
interrupt, and
the
Richard Levitte - VMS Whacker wrote:
Are __declspec(dllexport) and __declspec(dllimport) really needed in
the OpenSSL library (see e_os2.h)? From the reading I've done, it
seems it's not needed when you use a .def file, which we do.
This was discussed some time ago, but I'm not sure we
From: Dr S N Henson [EMAIL PROTECTED]
drh I did a few tests which suggest you definitely need
drh __declspec(dllimport) to access global variables in DLLs but not for
drh functions. Though it has been pointed out that it may produce more
drh efficient code: I haven't tried that though.
OK,
I would have much
prefered if the whole __declspec() business could be magically taken
away, but it doesn't look like a possibility...
I don't think that's possible -- you don't normally get magic #define's
turned on for DLL vs static, e.g.
On the other hand, I'd like to see it like this:
I'm forwarding a previous message concerning this issue:
- Original Message -
From: Richard Levitte - VMS Whacker [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Thursday, January 04, 2001 11:50 AM
Subject: Re: Windows, DLLs and variables.
From: "Rob Neff" [EMAIL
On Fri, Mar 02, 2001, [EMAIL PROTECTED] wrote:
levitte 02-Mar-2001 13:17:58
Modified:ssl s23_meth.c
Log:
For SSLv2, return the SSLv2 method, not the SSLv23 method. This way,
it's possible to reuse an SSLv2 session.
You did not apply this change to the stable tree,
23 matches
Mail list logo
