I just changed ./Configure line:
#linux64-sparcv9,sparc64-linux-gcc:-m64 -mcpu=v9 -DB_ENDIAN -DTERMIO
-O3 -fomit-frame-pointer -Wall
-DBN_DIV2W::-D_REENTRANT:ULTRASPARC::BN_LLONG RC4_CHAR RC4_CHUNK
DES_UNROLL BF_PTRasm/md5-sparcv9.o:,
by
linux64-sparcv9,gcc:-m64 -mcpu=v9
I've fixed the problem by adding a section in the PROBLEMS file. I
see no reason to support a buggy compiler by changing the OpenSSL code.
Ths ticket is now resolved.
[[EMAIL PROTECTED] - Tue Dec 3 14:17:08 2002]:
Seeing the bugs directory in the openssl tarball, I thought you
might be
In message [EMAIL PROTECTED] on Wed, 04 Dec 2002 09:08:07 +0100, Andy
Polyakov [EMAIL PROTECTED] said:
appro linux64-sparcv9,gcc:-m64 -mcpu=ultrasparc -DB_ENDIAN -DTERMIO -O3
appro -fomit-frame-pointer -Wall::-D_REENTRANT:ULTRASPARC::SIXTY_FOUR_BIT_LONG
appro RC4_CHAR RC4_CHUNK DES_UNROLL
Using the lynx browser compiled with openssl, the environment
variable SSL_CERT_FLLE seems to be ignored. If I place the trusted
root certificates in the default location, the application finds
them without difficulty. If placed in a non-default location,
setting the value of SSL_CERT_FILE to
On Tue, 3 Dec 2002, Doug Kaufman wrote:
Using the lynx browser compiled with openssl, the environment
variable SSL_CERT_FLLE seems to be ignored. If I place the trusted
root certificates in the default location, the application finds
them without difficulty. If placed in a non-default
appro linux64-sparcv9,gcc:-m64 -mcpu=ultrasparc -DB_ENDIAN -DTERMIO -O3
appro -fomit-frame-pointer -Wall::-D_REENTRANT:ULTRASPARC::SIXTY_FOUR_BIT_LONG
appro RC4_CHAR RC4_CHUNK DES_UNROLL BF_PTRasm/md5-sparcv9.o:,
Hmm, I assume we can make that change in Configure, eh?
My idea was to
Hi,
While using openssl to test caching of session id's, I noticed that the
session id of SSLv2 is not being extracted out of the message correctly.
The spec (http://wp.netscape.com/eng/security/SSL_2.html) says that the
server_finished message is of the following format:
char
In message [EMAIL PROTECTED] on Wed, 4 Dec 2002 09:24:39
+0100 (MET), [EMAIL PROTECTED] via RT [EMAIL PROTECTED] said:
rt Could someone verify independently that SSL_CERT_FILE doesn't
rt allow reading certificates in non-default locations?
I can verify, by looking at the code, that
In message [EMAIL PROTECTED] on Wed, 4 Dec 2002 09:24:39
+0100 (MET), [EMAIL PROTECTED] via RT [EMAIL PROTECTED] said:
rt Could someone verify independently that SSL_CERT_FILE doesn't
rt allow reading certificates in non-default locations?
I can verify, by looking at the code, that
Hi,
While using openssl to test caching of session id's, I noticed that the
session id of SSLv2 is not being extracted out of the message correctly.
The spec (http://wp.netscape.com/eng/security/SSL_2.html) says that the
server_finished message is of the following format:
char
Mark has kindly reported that the latest vms.mar works as expected on
VAX. This ticket is therefore resolved.
--
Richard Levitte
__
OpenSSL Project http://www.openssl.org
Development Mailing
I haven't heard any news about this. I also mailed ietf-tls asking
about this, but had no response there either. That means there will
most probably be no fix in 0.9.6h. 0.9.7 still has a week...
I think I'll change the miestone for this fix.
[[EMAIL PROTECTED] - Thu Nov 14 19:05:29 2002]:
[Note: for any time or time range given here, please assume swedish
time. If you live in a different timezone, please adjust the time
range appropriately]
Due to lack of time and a few last bug fixes to review, I'm moving the
release of 0.9.7 beta 5 to the evening of thursday 2002-12-05.
NOTICE:
Due to major works on the electrical power system in the university's
computer center on Dec 7 and 8 (Saturday, Sunday), the campus of BTU
Cottbus, Germany, cannot be reached from Friday evening, Dec 6, to Monday
morning, Dec 9 (shutdown and restart of the central router(s) by the
Patch applied and committed. This ticket is now resolved.
--
Richard Levitte
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated
Applied after having remove the dependencies on GNU make.
This ticket is now resolved.
[[EMAIL PROTECTED] - Tue Nov 19 16:46:24 2002]:
The following patch allows openssl-0.9.7 to compile under DJGPP. The
process was broken by two recent changes. Gisle's patch left out
some required headers.
System and version:
---
OpenSSL 0.9.7 BETA 4
Host: Debian woody (3.0)
Type:
-
Building , Configuration error
Description:
when configuring openssl with:
'./config -no-md5'
make depend fails because it includes
'md5.h' in 'test/hmactest.c' and 'ssl/s3_srvr.c'
ssltest.c doesn't currently build (from 0.9.7-stable branch) with GCC
2.95.x on Solaris/x86 platforms; failures are like:
gcc -I.. -I../include -fPIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN
-DHAVE_DLFCN_H -DOPENSSL_NO_KRB5 -O3 -fomit-frame-pointer -m486 -Wall
-DL_ENDIAN
testing with openssl-0.9.7-stable-SNAP-20021203 ...
in util/pl/VC-32.pl there is a line
$lib_cflag= -D_WINDLL -D_DLL;
which causes problems if the /MT option in $cflags is changed to /MT
(solution is to remove the -D_DLL in this senario).
since according to the help for VC7, /MD also
Whilst conducting some testing with OpenSSL 0.9.7beta4 and the nCipher
chil plugin, I observed the following issues:
1. Lack of threadsafety if app fails to support new OpenSSL dynamic locks
At the moment hw_ncipher.c uses the new OpenSSL dynamic lock code inorder
to implement the hwcrhk
System and version:
---
OpenSSL 0.9.7 BETA 4
Host: Debian woody (3.0)
Type:
-
Building , Configuration error
Description:
when configuring openssl with:
'./config -no-rc4'
make fails because it includes
'rc4.h' in 'crypto/engine/eng_openssl.c'
Reproduction:
build commands used (from a VS.NET command shell)
set path=%path%;c:\cygwin\bin
perl Configure VC-WIN32 threads zlib no-shared
ms\do_masm.bat
nmake -f ms\ntdll.mak
then drop the dlls from out32dll into an existing project, and it crashes.
openssl-0.9.6g compiled with exactly the
Andy Polyakov wrote:
...
Change to:
linux64-sparcv9,gcc:-m64 -mcpu=ultrasparc -DB_ENDIAN -DTERMIO -O3
-fomit-frame-pointer -Wall::-D_REENTRANT:ULTRASPARC::SIXTY_FOUR_BIT_LONG
RC4_CHAR RC4_CHUNK DES_UNROLL BF_PTRasm/md5-sparcv9.o:,
all test passed (./Configure linux64-sparcv9 no-asm
linux64-sparcv9,gcc:-m64 -mcpu=ultrasparc -DB_ENDIAN -DTERMIO -O3
-fomit-frame-pointer -Wall::-D_REENTRANT:ULTRASPARC::SIXTY_FOUR_BIT_LONG
RC4_CHAR RC4_CHUNK DES_UNROLL BF_PTRasm/md5-sparcv9.o:,
all test passed (./Configure linux64-sparcv9 no-asm without no-asm).
Next step is to add
I asked Eric Rescorla, and he agreed the section of the TLS RFC was
definitely unclear, but he wasn't totally sure which way it should go as
far as stripping any leading 0s before using the shared secret to generate
keys. It basically depends on what various implementations have decided to
do.
On Wed, 4 Dec 2002, Richard Levitte - VMS Whacker via RT wrote:
In message [EMAIL PROTECTED] on Wed, 4 Dec 2002 09:24:39
+0100 (MET), [EMAIL PROTECTED] via RT [EMAIL PROTECTED] said:
rt Could someone verify independently that SSL_CERT_FILE doesn't
rt allow reading certificates in
error in make:
libs='-L. '; for i in crypto; do \
( set -x; gcc \
-shared -o lib$i.so.0.9.7 \
-Wl,-soname=lib$i.so.0.9.7 \
-Wl,-Bsymbolic \
-Wl,--whole-archive lib$i.a \
-Wl,--no-whole-archive $libs -lc ) || exit 1; \
libs=$libs -l$i; \
done
+ gcc -shared -o
On Wed, 4 Dec 2002, Richard Levitte - VMS Whacker via RT wrote:
In message [EMAIL PROTECTED] on Wed, 4 Dec 2002 09:24:39
+0100 (MET), [EMAIL PROTECTED] via RT [EMAIL PROTECTED] said:
rt Could someone verify independently that SSL_CERT_FILE doesn't
rt allow reading certificates in
error in make:
oops!
Next step is to add shared lib bits. Therefore change to:
linux64-sparcv9,gcc:-m64 -mcpu=ultrasparc -DB_ENDIAN -DTERMIO -O3
-fomit-frame-pointer -Wall::-D_REENTRANT:ULTRASPARC::SIXTY_FOUR_BIT_LONG
RC4_CHAR RC4_CHUNK DES_UNROLL
Andy Polyakov wrote:
Does it build?
not:
+gcc -m64 -shared -o libcrypto.so.0.9.7 -Wl,-soname=libcrypto.so.0.9.7
-Wl,-Bsymbolic -Wl,--whole-archive libcrypto.a -Wl,--no-whole-archive
-L. -lc
libcrypto.a(dso_dlfcn.o)(.text+0x68): In function `dlfcn_load':
: undefined reference to `dlopen'
On December 3, 2002 03:09 am, Lutz Jaenicke via RT wrote:
On Mon, Dec 02, 2002 at 08:35:43PM +0100, [EMAIL PROTECTED] via RT
wrote:
Hmm. According to http://www.perldoc.com/perl5.6/pod/perlpod.html
there only exist =head1 and =head2, so the complaint is correct :-)
Geoff???
Hmm,
On Wed, 4 Dec 2002, Richard Levitte - VMS Whacker wrote:
Please try the 0.9.6 snapshots *today* or during the day tomorrow.
Quick bug fixes will be honored, others will only be applied to the
0.9.7 branch.
Any progress on getting rsync working again on dev.openssl.org?
I really prefer using
Does it build?
+gcc -m64 -shared -o libcrypto.so.0.9.7 -Wl,-soname=libcrypto.so.0.9.7
-Wl,-Bsymbolic -Wl,--whole-archive libcrypto.a -Wl,--no-whole-archive
-L. -lc
libcrypto.a(dso_dlfcn.o)(.text+0x68): In function `dlfcn_load':
: undefined reference to `dlopen'
Double oops:-) Of course
In message [EMAIL PROTECTED] on Wed, 4 Dec 2002 18:08:25
+0100 (MET), [EMAIL PROTECTED] via RT [EMAIL PROTECTED] said:
rt I can go and cripple the engine.pod documentation if absolutely necessary,
rt but it simply seems a somewhat shortsighted solution (even if
rt alliterative :-). IIRC there
In message [EMAIL PROTECTED] on Wed, 04 Dec 2002 18:28:11 +0100, Andy
Polyakov [EMAIL PROTECTED] said:
appro Great! Well, as long as we disregard the long-standing OpenSSL
appro deficiency such as lack of support for multiple-ABI platforms. I mean
appro one ultimately wants same headers working
In message [EMAIL PROTECTED] on Wed, 4 Dec 2002 18:08:25
+0100 (MET), [EMAIL PROTECTED] via RT [EMAIL PROTECTED] said:
rt I can go and cripple the engine.pod documentation if absolutely necessary,
rt but it simply seems a somewhat shortsighted solution (even if
rt alliterative :-). IIRC
I asked Eric Rescorla, and he agreed the section of the TLS RFC was
definitely unclear, but he wasn't totally sure which way it should go as
far as stripping any leading 0s before using the shared secret to generate
keys. It basically depends on what various implementations have decided to
do.
-J
In message [EMAIL PROTECTED] on Wed, 4 Dec 2002 20:24:30
+0100 (MET), Stephen Henson via RT [EMAIL PROTECTED] said:
rt The existing code could be fixed to handle other cases, for example by
rt dumping that BIO_gets() replacing with a BIO_read() loop and converting
rt the buffer in place.
In message [EMAIL PROTECTED] on Wed, 4 Dec 2002 20:24:30
+0100 (MET), Stephen Henson via RT [EMAIL PROTECTED] said:
rt The existing code could be fixed to handle other cases, for example by
rt dumping that BIO_gets() replacing with a BIO_read() loop and converting
rt the buffer in place.
MD5 is one of those algorithms that's used so much it isn't easy to
disable. However, you only had problems in two files with it, we're
apparently doing fine. I'll investigate and get back to you.
[[EMAIL PROTECTED] - Wed Dec 4 11:09:43 2002]:
System and version:
---
Fix committed. Thanks for the report.
This ticket is now resolved.
[guest - Wed Dec 4 11:18:25 2002]:
ssltest.c doesn't currently build (from 0.9.7-stable branch) with GCC
2.95.x on Solaris/x86 platforms; failures are like:
gcc -I.. -I../include -fPIC -DOPENSSL_THREADS -D_REENTRANT
Change committed. Thanks for the report.
This ticket is now resolved.
[[EMAIL PROTECTED] - Wed Dec 4 12:25:20 2002]:
System and version:
---
OpenSSL 0.9.7 BETA 4
Host: Debian woody (3.0)
Type:
-
Building , Configuration error
Description:
I've applied the VxWorks parts. The LynxOS part is too big at this
point. I will resolve this ticket, and would like to ask you to
concentrate the LynxOS development on 0.9.7 or 0.9.8.
Thanks for your effort.
[[EMAIL PROTECTED] - Tue Dec 3 13:54:54 2002]:
Hello!
This patch set includes
[[EMAIL PROTECTED] - Wed Dec 4 12:08:18 2002]:
Whilst conducting some testing with OpenSSL 0.9.7beta4 and the nCipher
chil plugin, I observed the following issues:
1. Lack of threadsafety if app fails to support new OpenSSL dynamic
locks
At the moment hw_ncipher.c uses the new
OK, I've now make a change that should take care of the assertion as I
imagined it. Could you please grab the next snapshot and test it? I'm
resolving this ticket, so please, if you find errors, generate a new bug
report.
--
Richard Levitte
I've changed the behavior so that it will FIRST try to get the file
pointed at with the environment variable. If the environment variable
wasn't set or loading the file failed, then the system default file will
be loaded. If that fails, an error is generated.
by_dir.c looks a little weird too,
OK, I've made that change.
This ticket is now resolved.
[[EMAIL PROTECTED] - Wed Dec 4 12:07:51 2002]:
testing with openssl-0.9.7-stable-SNAP-20021203 ...
in util/pl/VC-32.pl there is a line
$lib_cflag= -D_WINDLL -D_DLL;
which causes problems if the /MT option in $cflags is changed
I've changed the behavior so that it will FIRST try to get the file
pointed at with the environment variable. If the environment variable
wasn't set or loading the file failed, then the system default file will
be loaded. If that fails, an error is generated.
I don't think silently using
I've changed the behavior so that it will FIRST try to get the file
pointed at with the environment variable. If the environment variable
wasn't set or loading the file failed, then the system default file will
be loaded. If that fails, an error is generated.
I don't think silently using
In message [EMAIL PROTECTED] on Wed, 4
Dec 2002 21:08:43 -0500 (EST), Rich Salz [EMAIL PROTECTED] said:
rsalz I've changed the behavior so that it will FIRST try to get the file
rsalz pointed at with the environment variable. If the environment variable
rsalz wasn't set or loading the file
thnx
Louis Solomon
www.SteelBytes.com
- Original Message -
From: Richard Levitte via RT [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Thursday, December 05, 2002 12:37 PM
Subject: [openssl.org #380] VC-WIN32 build issue
OK, I've made that change.
This
On Wed, Nov 27, 2002 at 12:53:31AM +0100, Andy Polyakov wrote:
to facilitate building openssl on the x86_64 platform I suggest to apply
the attached patch.
+linux-x86_64, gcc:-DL_ENDIAN -DNO_ASM:
Linux/x86_64 suports two ABIs. As far as I understand it's perfectly
possible to compile
author has explicitely asked for a default certificate, through something
like 'X509_LOOKUP_load_file(lookup,NULL,X509_FILETYPE_DEFAULT)'. Note
the last argument.
Sure, but if they told you a filename and it contains garbage than I think
it's an error. If they told you a filename and it
53 matches
Mail list logo
