Dear Master of OpenSSL
I would like to use openssl on arm7312.
But many crypt algorithm is asm for x386,
Could you tell me where I can get this code
for arm7323?
Best Regards.
mailto:[EMAIL PROTECTED]
Jack Luo
__
OpenSSL
In message [EMAIL PROTECTED] on Wed, 14 Aug 2002 09:31:15
+0200 (METDST), jackluomail via RT [EMAIL PROTECTED] said:
rt I would like to use openssl on arm7312.
rt But many crypt algorithm is asm for x386,
rt
rt Could you tell me where I can get this code
rt for arm7323?
Have you tried
In message [EMAIL PROTECTED] on Wed, 14 Aug 2002 09:31:15
+0200 (METDST), jackluomail via RT [EMAIL PROTECTED] said:
rt I would like to use openssl on arm7312.
rt But many crypt algorithm is asm for x386,
rt
rt Could you tell me where I can get this code
rt for arm7323?
Have you tried
Entirely depending on the untar utility used, the resulting files may
have variable length record format or stream_lf record format.
Stream_lf record format is the format that C programs output by
default. So, in testenc.com, it means that if Makefile.ssl has been
unpacked in variable
- Original Message -
From: OpenSSL-Bugs [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, August 14, 2002 3:31 PM
Subject: [openssl.org #221] AutoReply: for ARM
Greetings,
This message has been automatically generated in response to the
creation of a
I build it at a Linux RedHat R7.2
i386 machine, it build ok.
I just find the crypts subdirectory
have some asm directory.
Not try to compile by cross-compile
yet.
Jack Luo
- Original Message -
From: Richard Levitte - VMS Whacker via RT [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc:
Example: when working through the internal session cache we learn, that
the linked list is corrupted, we have dangling pointers and don't know
what is going on. This would touch all threads using the same SSL_CTX.
Thus: we don't know how to repair it - abort().
to make it more extreme: why
In message [EMAIL PROTECTED] on Wed, 14 Aug 2002 12:49:35
+0200 (MET DST), [EMAIL PROTECTED] said:
bodo bodo14-Aug-2002 12:49:35
bodo
bodo Modified:.CHANGES
bodo Log:
bodo add 'TODO' items
Don't these go into the STATUS file, usually?
--
Richard Levitte \
On Wed, Aug 14, 2002 at 12:52:37PM +0200, Richard Levitte - VMS Whacker wrote:
bodo bodo14-Aug-2002 12:49:35
bodo
bodo Modified:.CHANGES
bodo Log:
bodo add 'TODO' items
Don't these go into the STATUS file, usually?
Only when noone is really working on them at
I just committed a fix to all active branches. The change is
untested, but will be tomorrow morning.
This ticket is now resolved.
[levitte - Wed Aug 14 09:53:37 2002]:
Entirely depending on the untar utility used, the resulting files
may
have variable length record format or stream_lf
In message [EMAIL PROTECTED] on Wed, 14 Aug 2002
13:07:15 +0200, Bodo Moeller [EMAIL PROTECTED] said:
moeller On Wed, Aug 14, 2002 at 12:52:37PM +0200, Richard Levitte - VMS Whacker wrote:
moeller
moeller bodo bodo14-Aug-2002 12:49:35
moeller bodo
moeller bodo Modified:.
On Wed, Aug 14, 2002 at 01:24:32PM +0300, Arne Ansper wrote:
[...] what if some standalone application thinks that the
best solution for _its own_ problems is to reboot the machine? (happens
all the time under the windows btw, you install some crap and the
installer happily
[levitte - Tue Aug 13 08:20:51 2002]:
[[EMAIL PROTECTED] - Tue Aug 13 00:08:25 2002]:
To see what would happen next, I added a
#else
else if (strcmp(*argv, -dhe1024dsa) == 0) {}
in the option test sequence. It now runs all the tests quite
happily but
crashes with several error
Bodo Moeller wrote:
On Wed, Aug 14, 2002 at 01:24:32PM +0300, Arne Ansper wrote:
[...] what if some standalone application thinks that the
best solution for _its own_ problems is to reboot the machine? (happens
all the time under the windows btw, you install some crap and the
Date sent: Wed, 14 Aug 2002 13:51:43 +0100
From: Ben Laurie [EMAIL PROTECTED]
To: Arne Ansper [EMAIL PROTECTED]
Copies to: [EMAIL PROTECTED],
Bodo Moeller [EMAIL PROTECTED]
Subject:Re: cvs commit: openssl/util
On Tue, Aug 13, 2002 at 12:28:06PM +0200, via RT wrote:
Line 14 in util/pod2mantest should read:
try_without_dir=true
otherwise 'first iteration' in the for-loop is never executed.
The code as it currently is doesn't make too much sense
(try_without_dir could be totally abolished), but
On Wed, 14 Aug 2002, Ben Laurie wrote:
The point is that the application is now in an inconsistent state and
cannot reliably know anything. Even returning from a function could
cause an exploit. The only safe thing to do is abort (now I think about
it, probably die() shouldn't even print
Lutz Jaenicke wrote:
On Tue, Aug 13, 2002 at 07:45:30PM +0200, Bodo Moeller wrote:
On Tue, Aug 13, 2002 at 05:10:34PM +0100, Ben Laurie wrote:
Yes, and the application will continue as if it were sensible to do so.
In fact it *is* often sensible to do so because such supposedly
impossible
We now call pod2man directly if this works (without explicit invocation
of perl).
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
The buffer is _supposed_ to be big enough. We know of no path through
the code that should cause it to be not big enough. So if this condition
occurs something we don't understand has happened. Continuing under
these circumstances as if nothing were wrong strikes me as foolhardy.
If you
Bodo Moeller wrote:
On Tue, Aug 13, 2002 at 05:10:34PM +0100, Ben Laurie wrote:
Bodo Moeller wrote:
Ben Laurie [EMAIL PROTECTED]:
As noted elsewhere, I really object to returning internal errors!
It makes no sense to attempt to continue after the impossible has
occurred.
If we could be
Bodo Moeller wrote:
On Tue, Aug 13, 2002 at 08:09:02PM +0200, Lutz Jaenicke wrote:
On Tue, Aug 13, 2002 at 07:45:30PM +0200, Bodo Moeller wrote:
On Tue, Aug 13, 2002 at 05:10:34PM +0100, Ben Laurie wrote:
Yes, and the application will continue as if it were sensible to do so.
In fact it
EVP_DecodeBlock() [in crypto/evp/encode.c] returns the length of the result
of the base-64 decode. However this length is not the true length of the
result but includes any trailing fills ('=') so it's always 0 mod 3. This
obviously can cause errors in any processing on the result, e.g.
On Wed, Aug 14, 2002 at 05:05:27PM +0300, Arne Ansper wrote:
On Wed, 14 Aug 2002, Ben Laurie wrote:
The point is that the application is now in an inconsistent state and
cannot reliably know anything. Even returning from a function could
cause an exploit. The only safe thing to do is
Arne Ansper wrote:
Example: when working through the internal session cache we learn, that
the linked list is corrupted, we have dangling pointers and don't know
what is going on. This would touch all threads using the same SSL_CTX.
Thus: we don't know how to repair it - abort().
to make
On Wed, Aug 14, 2002 at 01:53:29PM +0100, Ben Laurie wrote:
The consistency checks don't detect that memory *has* been corrupted.
They detect that memory *would* be corrupted if the library simply
continued to do what it is doing. But if we return an internal error,
this does not actually
On Wed, Aug 14, 2002 at 01:57:32PM +0100, Ben Laurie wrote:
[...]
But for various other potential errors, we do know what happened
(e.g. a buffer has insufficient size) and we do know how to continue
without doing significant harm (abort this one TLS/SSL connection, and
in a way such that we
For most of the consistency checks that your patch added, a failure
would very likely indicate that there is an inconsistency in the
OpenSSL source code similar to the potential inconsistency discussed
above.
Precisely what happened with AES was added to OpenSSL; I reported an
internal
EVP_DecodeBlock() [in crypto/evp/encode.c] returns the length of the result
of the base-64 decode. However this length is not the true length of the
result but includes any trailing fills ('=') so it's always 0 mod 3. This
obviously can cause errors in any processing on the result, e.g.
Hi
Below is the error I got when I tried to build it
perl Configure VC-WIN32
...
ms\do_ms
...
...
nmake -f ms\ntdll.mak
...
...
and error..
link /nologo /subsystem:console /machine:I386 /opt:ref /dll /out:out32dl
l\ssleay32.dll /def:ms/SSLEAY32.def
Kenneth R. Robinette wrote:
Date sent:Wed, 14 Aug 2002 13:51:43 +0100
From: Ben Laurie [EMAIL PROTECTED]
To: Arne Ansper [EMAIL PROTECTED]
Copies to:[EMAIL PROTECTED],
Bodo Moeller [EMAIL PROTECTED]
Subject: Re:
Sorry, I don't know exactly which version these changes were made in.
I am upgrading from version `d' to version `g'.
I have the following differences in s3_clnt.c. The problems are that
the cryptlib.h header is in the crypto directory. Should I put this
on the include path when building the
On Wed, Aug 14, 2002 at 03:39:03PM +0100, Ben Laurie wrote:
So how did the buffer get to be too small?
Well, in one of the cases it was improper protocol data checking
(fixed in 0.9.6f). The others should really be impossible, but if
they ever become possible, this most likely is because of
Arne Ansper wrote:
On Wed, 14 Aug 2002, Ben Laurie wrote:
The point is that the application is now in an inconsistent state and
cannot reliably know anything. Even returning from a function could
cause an exploit. The only safe thing to do is abort (now I think about
it, probably die()
Bodo Moeller wrote:
On Wed, Aug 14, 2002 at 03:39:03PM +0100, Ben Laurie wrote:
So how did the buffer get to be too small?
Well, in one of the cases it was improper protocol data checking
(fixed in 0.9.6f). The others should really be impossible, but if
they ever become possible,
35 matches
Mail list logo
