In dtsl1_cler_queues() , the data field of the item in
s-d1-buffered_app_data.q is incorrectly treated as hm_fragment *, it should
be DTLS1_RECORD_DATA *
--
qun-yingdiff --git a/ssl/d1_lib.c b/ssl/d1_lib.c
index 2287ba6..7d9d91f 100644
--- a/ssl/d1_lib.c
+++ b/ssl/d1_lib.c
@@ -202,9 +202,12 @@
In dtsl1_cler_queues() , the data field of the item in
s-d1-buffered_app_data.q is incorrectly treated as hm_fragment *, it should
be DTLS1_RECORD_DATA *
--
qun-ying
diff --git a/ssl/d1_lib.c b/ssl/d1_lib.c
index 2287ba6..7d9d91f 100644
--- a/ssl/d1_lib.c
+++ b/ssl/d1_lib.c
@@ -202,9 +202,12 @@
Hi,
My colleague found this bug in d1_lib.c:dtls1_clear_queues().
Where the data field of the item pop from s-d1-buffered_app_data.q
is treated as hm_fragment, which result in segmentation fault when
free.
Attached is a attempted fix.
--
qun-yingdiff --git a/ssl/d1_lib.c b/ssl/d1_lib.c
index
Hi,
Not sure if you are aware of this entry regarding the big number operation:
http://www.securityfocus.com/archive/1/530120/30/30/threaded
I tested a few of them on my Slackware 64 14.1 (openssl 1.0.1e),
bn_ulong and bn_mod_add got Floating point exception
bn_shift got Segmentation
wow this is amazing you should look into it
http://www.finance15dynews.net/biz/?read=9549969
__
OpenSSL Project http://www.openssl.org
Development Mailing List
wow this is intense you should give it a look
http://www.finance15cinews.net/biz/?news=6820364
__
OpenSSL Project http://www.openssl.org
Development Mailing List
wow this is pretty crazy you should check it out
http://www.finance15dynews.net/biz/?read=5845066
__
OpenSSL Project http://www.openssl.org
Development Mailing List
wow this is amazing look into this
http://www.finance15elnews.net/biz/?news=1625431
__
OpenSSL Project http://www.openssl.org
Development Mailing List
wow this is crazy you should look into this
http://www.spacnews.net/biz/?read=4828380
__
OpenSSL Project http://www.openssl.org
Development Mailing List
I encounter compilation error when compiling for ARM platform wth OpenSSL
1.0.1a:
make -f ../Makefile.shared -e \
APPNAME=openssl OBJECTS=openssl.o verify.o asn1pars.o req.o dgst.o dh.o
dhparam.o enc.o passwd.o gendh.o errstr.o ca.o pkcs7.o crl2p7.o crl.o rsa.o
rsautl.o dsa.o dsaparam.o ec.o
With fixed in http://cvs.openssl.org/chngview?cn=22455. seems compile ok。
--
qun-ying
- Original Message -
From: zhu qun-ying quny...@yahoo.com
To: openssl-dev@openssl.org openssl-dev@openssl.org
Cc:
Sent: Thursday, April 19, 2012 2:57:05 PM
Subject: Re: [openssl.org #2792
Hi,
While working on DTLS, in d1_both.c:dtls1_get_message_fragment():787~866
There are calls to OPENSSL_assert (line 787):
/* read handshake message header */
i=s-method-ssl_read_bytes(s,SSL3_RT_HANDSHAKE,wire,
DTLS1_HM_HEADER_LENGTH, 0);
if (i = 0)
I supplied some of the info for that article and I wrote PKCS#12 for
OpenSSL so I'd say yes OpenSSL PKCS#12 implementation is reasonably
secure with the usual precautions, i.e. not picking obvious or guessable
passwords.
OpenSSLs implementation uses high mac and encryption iteration counts
They should be sufficient. Certificates are usually public knowledge
anyway so using weak or no encryption on them is harmless but if you
want to use strong encryption on it you can, however some of the older
export browsers wont import 3DES encrypted certificates.
Steve.
My concern is
I am actually quite new to the Crypto world, just about 2 months. While reading
Peter Gutmann's article on breaking PKCS#12 formatted file, I am wondering is
the implementation of OpenSSL's PKCS#12 routines subject to the same attack.
What's the most secure format could be used under OpenSSL to
It magically worked once for me. But then when I try to rebuild the whole thing
from scratch, (unpack the source, apply the patch, update the .num file, do the
configuration with rc5 and idea turn off), it does not work again. The generated
libeay32.def still has the entry.
--
(~._.~) Öì Ⱥ Ó¢
Richard Levitte - VMS Whacker wrote:
I've placed mkdef.diff in ftp://ftp.stacken.kth.se/pub/random/levitte,
please apply it and try again. It also contains a corrected libray.num.
This one works smoothly with VC and mingw32.
Thanks.
--
(~._.~) Öì Ⱥ Ó¢ (Qun-Ying) (65) 874-6743
a conservative non-zero value for the number of bytes of
entropy that may be provided by each block of data fed to
RAND_add() based upon an examination of the data structures.
zhu qun-ying, would you please apply this patch and confirm to
[EMAIL PROTECTED] that it compiles on VC6 and mwing32
OpenSSL 0.9.6-beta2 17 Sep 2000
built on: Mon Sep 18 19:52:26 SGT 2000
platform: solaris-sparcv9-gcc
options: bn(64,32) md2(int) rc4(ptr,char) des(idx,cisc,16,long) idea(int) blowf
ish(ptr)
compiler: gcc -fPIC -DTHREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -mcpu=ultr
asparc -O3
Richard Levitte - VMS Whacker wrote:
Very odd. Yes, if those -x switches were illegal, the compiler is
probably old. But I find it really off that asm/md5-sparcv8plus.o
didn't get built. Could you check if you got it or md5-sparcv9.o
somewhere at all?
No. the file fail to compiled. :(
Test passed on Slackware 7.0 (kernel 2.2.17)
OpenSSL 0.9.6-beta2 17 Sep 2000
built on: Mon Sep 18 23:14:24 SGT 2000
platform: linux-elf
options: bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long) idea(int)
blowfish(idx)
compiler: gcc -fPIC -DTHREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H
for Mingw32 under NT:
It fails at this stage after using the new rand_win.c, the same place that fail
on beta1.
... ...
ranlib out/libcrypto.a
(cd ./..; PERL=perl make -f Makefile.ssl asm/lib.cpp)
make[1]: Makefile.ssl: No such file or directory
make[1]: *** No rule to make target
I have checked with mingw32 developers. The reason tlhelp32.h is not in the
distribution because of its win95 only nature. In will never work under NT
4.0(SP6). I don't know whether mingw32 will include that header and lib in
future.
I am using gcc version 2.95.2 19991024 (release) for the
I am using VC 6, 0.9.6-beta1 with rand_win.c(version 1.9 from the CVS).
I encounter the following error while building the library:
link /nologo /subsystem:console /machine:I386 /opt:ref /dll /out:out32dl
l\ssleay32.dll /def:ms/SSLEAY32.def @d:\TEMP\nmc00217.
Creating library
But it is broken in NT 4.0. The condition I patched in will commented out the
code only for NT version less than 5. It is still included under Win2k and
Win95. And for NT 4 (I am not sure about 3.5), we may properly need to use the
NT only PSAPI to do the similar job.
Jeffrey Altman wrote:
Richard Levitte - VMS Whacker wrote:
Relying on compile-time options is not really the best, since binaries
can be transported between the different Windows variants (and if you
look at the code, we've definitely made it more and more dynamic in
that sense).
So, is there a dynamic way
There are some way to determine the running OS, quote from the Win32 FAQ:
5.1.5 How can I tell what version of windows I'm running?
With the function GetVersionEx(). This fills in a structure indicating whether
or not the OS is NT, and what the version number of the OS is
BOOL InWinNT()
Jeffrey Altman wrote:
Correct. But none of this is needed in this case. If the function
GetCursorInfo() (for example) is not supported on NT4, then the
attempt to load its function pointer with
cursor = (GETCURSORINFO) GetProcAddress(user,"GetCursorInfo");
will fail. This is
Richard Levitte - VMS Whacker wrote:
Hmm, let me get this straight: from what I understand of this
conversation, tlhelp32.h is needed only to declare things for the heap
walking code. Is there a way to still be able to do the heap walking
without having to include tlhelp32.h? If that's a
Line 8 of file util/pl/Mingw32.pl
$rm='rem'; # use 'rm -f' if using GNU file utilities
^-- should change to somthing more meaningful to track down the error.
--
(~._.~) Öì Ⱥ Ó¢ (Qun-Ying) (65) 874-6743
( O ) TrustCopy Pte Ltd / Kent Ridge Digital Labs
()~*~() 21 Heng Mui
Richard Levitte - VMS Whacker wrote:
From: zhu qun-ying [EMAIL PROTECTED]
qyzhu Line 8 of file util/pl/Mingw32.pl
qyzhu $rm='rem'; # use 'rm -f' if using GNU file utilities
qyzhu ^-- should change to somthing more meaningful to track down the error.
Suggestions?
This is a bug
As more information on the mingw32 platform:
The code needed tlhelp32.h is for win95 only not for NT.
the tlhelp32.h is suppose only work in Win95 and later, not in NT at least 4.0.
It is said to to be supported under NT 5.0.
--
(~._.~) Öì Ⱥ Ó¢ (Qun-Ying) (65) 874-6743
( O )
Under mingw32:
I managed to by pass the 95 only code, but I don't know how it will affect the
RAND_poll() function, I believe the behaviour changes. I conditionally comment
out the offensive code. (attached is my patch)
The patch is against CVS version 1.9 of the file rand_win.c.
But I
tests passed
test a^b%c implementations
./exptest
...
...
done
cat
./p ./p.clear differ: char 2, line
34 matches
Mail list logo
