Hallo,
this patch has 2 changes for s_client:
* It adds the command line param -Verify to terminate the
ssl handshake if peer verify fails.
* It adds the additional flag "manual" to the param -starttls,
giving the complete initial handshake in user hands,
For example exim4 needs at least th
On 11/10/2005 03:03 PM, Richard Koenning wrote:
> Rüdiger Plüm wrote:
>
>> are there any plans to add support for rfc3546 (Transport Layer
>> Security (TLS) Extensions),
>> especially Server Name Indication to openssl in the near future?
>
>
> See the mail in this list from Peter Sylvester wit
john via RT wrote:
Why is it that the static locks have not been removed completely for
0.9.8? If it is to keep some backward compatibility with older apps,
or ones that see no reason to change, would it not be preferable if
the whole of openssl was compatible in this way, including the en
Hi Richard,
Thanks for taking a look at this.
> [guest - Thu Oct 6 11:55:10 2005]:
>
> > This stops our engine working with the openssl application (as it
> > registers a lock debugging callback) and Apache 2.x (and other apps
> > too no doubt)
>
> That's because those applications don't
We are using OpenSSL to implement S/MIME. When we sign and
encrypt a message we use an intermediate memory BIO to hold the message.
The same is true when we decrypt and verify a message. If the message we
are processing is large (>200K) we find that the performance is very
bad.
Quoting Andy Polyakov <[EMAIL PROTECTED]>:
> Concensus was that the failure is caused by a hardware
> deficiency. What's your hardware?
Mostly Sun Ultra 10s, running Solaris 8. I can produce the error on more than
one host, too.
> - state which platform line was used, run 'openssl version -a' t
(and doesn't affect any non-linux platform anyway).
How come it turns from unsure "should be portable" to definitive
"doesn't affect" so easily:-)
Do mind smilies in my previous post:-)
What I tried to say was that the extra section is ignored on platforms that do
not use a recent binutils t
>without filing a bug, just wanted to notice that after successful
> installation OpenSSL-0.9.8a on linux 32, "openssl version" produces:
> OpenSSL 0.9.6b [engine] 9 Jul 2001
> while for linux 64
> OpenSSL 0.9.7a Feb 19 2003
Well, it means that you ether failed to upgrade or you keep
I'm using 0.9.8a with the latest OpenSSH 4.2 on Solaris 8. Sometimes the ssh
client will dump core.
There was a report on OpenSSH list last year about intermittent failures
on multi-CPU UltraSPARC system. It was not as fatal as core dump, but it
was sporadic. They asserted that ssh worked reli
Rüdiger Plüm wrote:
are there any plans to add support for rfc3546 (Transport Layer Security (TLS)
Extensions),
especially Server Name Indication to openssl in the near future?
See the mail in this list from Peter Sylvester with the subject "TLS
Extension support - Server Name Indication" fr
On Fri, Oct 28, 2005 at 04:07:32PM +0300, Claudiu Dragalina-Paraipan wrote:
> I have noticed that BIO_do_connect doesn't start the connection upon
> call, instead the connection is established on the first BIO_puts, in
> my case.
> I am not sure if this is a bug or not, but I have traced it to
> bs
Hi, here's one more cleanup prior to my larger patch:
Remove the inclusion of from crypto/rand/rand_unix.c.
--
Johan Gill, [EMAIL PROTECTED]
Index: crypto/rand/rand_unix.c
===
RCS file: /home/johane/openssl/cvs/openssl/crypto/rand/r
Hello list,
I'm using 0.9.8a with the latest OpenSSH 4.2 on Solaris 8. Sometimes the ssh
client will dump core. Typically, I see this when connecting to the native sshd
running on a Solaris 9 machine.
(gdb) where
#0 0xff1fe914 in bn_sub_words () from /usr/local/ssl/lib/libcrypto.so.0.9.8
#1 0x
13 matches
Mail list logo
