Below msg is a re-send to the correct address [EMAIL PROTECTED] -- Sorry for
mailing it to the wrong place!! /Jonas
- Original Message -
From: Jonas Sundgren [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, November 26, 2002 2:43 AM
Subject: BUG ?: ssl_bio.c increase reference
I have disabled Heimdal support from Configure. It's possible to
force the use of Heimdal, but that comes with warnings.
This ticket is now resolved.
[[EMAIL PROTECTED] - Tue Nov 19 16:10:23 2002]:
Hi,
I tried these configuration options:
--with-krb5-flavor=Heimdal \
I can understand wanting to disable the use of sockets. I can't
understand why OCSP or speed should be disabled, however. Please
explain.
[[EMAIL PROTECTED] - Sat Nov 23 19:46:14 2002]:
Hi,
This patch makes it possible to build apps/openssl without the
speed
and ocsp programs and
Applied. Thanks.
This ticket is now resolved.
[[EMAIL PROTECTED] - Tue Nov 19 20:25:21 2002]:
The following minor problems need to be corrected in 0.9.7 b4
compiled
against the MIT Kerberos distribution:
diff -cw openssl-0.9.7-beta4\ssl/kssl.h openssl-0.9.7-beta4-
modified\ssl/kssl.h
Eric Cronin via RT wrote:
At one point in time, RSA_PKCS1_PADDING was evidently #defined as '11',
the size in bytes of the extra room needed for PKCS1 padding in an RSA
block. In the current CVS version of OpenSSL it is #defined to 1 and
is just used as a selector in switch statements.
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
Your analysis is correct. Thanks. I've just committed a change.
This ticket is now resolved.
[[EMAIL PROTECTED] - Fri Nov 22 10:27:03 2002]:
At one point in time, RSA_PKCS1_PADDING was evidently #defined as
'11',
the size in bytes of the extra room needed for PKCS1 padding in an
RSA
Chris Brook wrote:
Forget my previous email. destest is actually only passing 29 bytes I see,
so the predicted ciphertext will of course be wrong if I pass 32 bytes for
encryption.
So what was the correct test entry in the end?
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
[levitte - Thu Nov 21 23:09:40 2002]:
Hmm... I think I'm gonna call this a showstopper. It's way too
late
tonight to fix it in a panic and do a panic release. That's just
not
the right way.
So, if noone else does it, I'm fixing this problem within the next
few
days, and releasing
Hi Lutz,
How can I get one SGC certificate for my testing? Using
Openssl can I create one or do you aware of any other tools?
Please help me in this.
Thanks
Josephine
__
OpenSSL Project
I set the plaintext and ciphertext strings to 32 characters as below and
test_evp is now OK, encrypt/decrypt.
Chris Brook
// DES CBC tests (from destest)
DES-CBC:0123456789abcdef:fedcba9876543210:37363534333231204E6F7720697320746
I played around with the testssl script in the tests directory and the
following change seems to take care of the no-dh issue so that the tests run
to completion. This is the last section of the script:
###
if ../apps/openssl no-dh; then
Again I want to clarify this point: the issue is in the way ZLIB is used by
OpenSSL, not in ZLIB itself. The compressor's state is built and destroyed
on every record because OpenSSL uses ZLIB's compress() call, which in turn
calls the lower-level deflateInit(), deflate() and deflateEnd()
I played around with the testssl script in the tests directory and the
following change seems to take care of the no-dh issue so that the tests run
to completion. This is the last section of the script:
###
if ../apps/openssl no-dh; then
Salut Eric,
Thanks for describing what you're up to and thanks (in advance) for
contributing your implementation(s). OpenSSL is used for a lot more than
building free webservers, despite misconceptions to the contrary, and
having an reasonably-optimal zlib compression layer right there in the
Hi,
I am working on trying to build the libraries (libcrypto and libssl) to
run on an embedded system with limited storage. To give you an idea, i have
approximately 1.5 megabytes of diskspace in the system. I need to reduce the
footprint of the libraries as much as possible.
Hi,
I am working on trying to build the libraries (libcrypto and libssl) to
run on an embedded system with limited storage. To give you an idea, i have
approximately 1.5 megabytes of diskspace in the system. I need to reduce the
footprint of the libraries as much as possible.
On Tue, Nov 26, 2002 at 02:00:43PM -0500, Geoff Thorpe wrote:
Thanks for describing what you're up to and thanks (in advance) for
contributing your implementation(s). OpenSSL is used for a lot more
than building free webservers, despite misconceptions to the contrary,
and having an
Adding ERR_clear_errors() into SSL_read() etc seems to be the correct
approach. It is already handled this way in _accept(), _connect(), but
not that obvious, because it is found e.g. in ssl3_accept() which is
called depending on the method selected.
You will often find ERR_clear_errors()
Adding ERR_clear_errors() into SSL_read() etc seems to be the correct
approach. It is already handled this way in _accept(), _connect(), but
not that obvious, because it is found e.g. in ssl3_accept() which is
called depending on the method selected.
You will often find ERR_clear_errors()
This is not a bug, so I'm killing the ticket. Please discuss this
on [EMAIL PROTECTED]
[[EMAIL PROTECTED] - Tue Nov 26 17:34:03 2002]:
Hi Lutz,
How can I get one SGC certificate for my testing? Using
Openssl can I create one or do you aware of any other tools?
Please help me
the test 'trsa' in the testsuite fails on ia64:
testing rsa conversions
p - d
p - p
d - d
make[1]: *** [test_rsa] Error 1
make[1]: Leaving directory
`/usr/src/packages/BUILD/openssl-0.9.7_beta4/test'
make: *** [tests] Error 2
I managed to reproduce the problem
We're making test on DUnix Tru 64 and we had problem with this library:
make test result:
test BN_sqr
Square test failed!
Our op. sys is: OSF1 link.softax.local V5.1 732 alpha
our compiler is:
Compaq C V6.3-025 on Compaq Tru64 UNIX V5.1 (Rev. 732)
I failed to reproduce the problem with
We're making test on DUnix Tru 64 and we had problem with this library:
make test result:
test BN_sqr
Square test failed!
Our op. sys is: OSF1 link.softax.local V5.1 732 alpha
our compiler is:
Compaq C V6.3-025 on Compaq Tru64 UNIX V5.1 (Rev. 732)
I failed to reproduce the problem with
No, I get exactly same error:
NIST curve P-521 -- Generator:
x =
0xC6858E06B70404E9CD9E3ECB662395B4429C648139053FB521F828AF606B4D3DBAA14B5E77EFE75928FE1DC127A2FFA8DE3348B3C1856A429BF97E7E31C2E5BD66
y =
On Wed, 27 Nov 2002, Andy Polyakov wrote:
No, I get exactly same error:
NIST curve P-521 -- Generator:
x =
0xC6858E06B70404E9CD9E3ECB662395B4429C648139053FB521F828AF606B4D3DBAA14B5E77EFE75928FE1DC127A2FFA8DE3348B3C1856A429BF97E7E31C2E5BD66
y =
In message [EMAIL PROTECTED] on Wed, 27 Nov 2002 00:14:42 +0100, Andy
Polyakov [EMAIL PROTECTED] said:
appro I managed to reproduce the problem under nue (IA-64 emulator for Linux)
appro and with gcc 2.96 (the one found in nue-fs-1.2-1). It's a compiler bug:
appro
appro ***
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 gcc so that it supports both. Which one will be
default? To ensure that
On Wed, 27 Nov 2002, Andy Polyakov wrote:
No, I get exactly same error:
NIST curve P-521 -- Generator:
x =
0xC6858E06B70404E9CD9E3ECB662395B4429C648139053FB521F828AF606B4D3DBAA14B5E77EFE75928FE1DC127A2FFA8DE3348B3C1856A429BF97E7E31C2E5BD66
y =
29 matches
Mail list logo
