>-----Original Message-----
>[mailto:[EMAIL PROTECTED] Behalf Of Brian Long
>Sent: Tuesday, January 31, 2006 5:58 AM
>To: openssl-dev@openssl.org
>Subject: Re: [openssl.org #1276] [PATCH] TLS Extensions - RFC 3546 (Try
>On Fri, 2006-01-27 at 15:23 +0100, Stephen Henson via RT wrote:
>> [EMAIL PROTECTED] - Fri Jan 27 15:01:56 2006]:
>> >
>> > This patch is adding support for TLS hello extensions and externally
>> > generated pre-shared key material to OpenSSL 0.9.8. This is
>> > based on the patch from Alexey Kobozev <[EMAIL PROTECTED]>
>> > (sent to openssl-dev mailing list on Tue, 07 Jun 2005
>15:40:58 +0300).
>> >
>> Note that some TLS extension code has recently been committed to the
>> HEAD (0.9.9-dev). So if this is to be included into OpenSSL it would
>> have to work with that.
>Is it true that openssl-0.9.7 and 0.9.8 are frozen with regards to
>features like TLS extensions?  Do you expect vendors like Red Hat or
>Suse to include and support patches like TLS extensions on their own
>once they have standardized on a version of openssl for their enterprise
>For example, Red Hat Enterprise Linux 4 was released almost 1 year ago
>and includes 0.9.7a plus all the security patches issue over the last
>year.  If I need the TLS extension patch officially supported by Red
>Hat, it would have to come from "upstream" -- your group -- or they
>would have to support it as a one-off patch.  I was hoping your group
>would accept it, but it appears your efforts are concentrated on 0.9.9-

Brian, let me butt-in here if I may.

The linux distribution managers for redhat, suse, and so on typically
will use the same version of major packages like openssl, apache,
sshd, and so on for every minor version release in that train.

As you noted, RHEv4 came out with 0.9.7   I would expect newer minor
releases of RHEv4 to come with newer 0.9.7 versions of openssl.

I would expect that when RHEv5 comes out that it would use openssl
version 0.9.8

Now, you want TLS support.  So you have a choice:

use RHEv4, delete their binary of openssl and all it's libraries,
along with all dynamically linked binaries supplied in RHEv4 that
are linked to the openssl libraries, compile the latest openssl
that has TLS support, then recompile all the binaries that you need
that are linked to this.

Use RHE version -future meaning wait for some version of RHE to come
out that supports TLS

Use some minimal Linux distro that does not inclue any ssl-aware apps
in it, and build the latest version of openssl with tls support, then
build what ssl-aware apps you want.

People use products like RHE because they want to pay someone for
a binary linus distro that has a bunch of pre-rolled programs in it,
rolled to some fixed, supportable definition.  People that do this
are happy to pay RH to patch their RHE v4 to get features they want,
which I think is where your TLS patches might be useful.

But, how RH does it, which incidentally is how the traditional major
UNIX vendors do it (like Sun) isn't how the Open Source community does

The open source community wants people like you, who are willing to
do the work, to put their efforts into the current code.  The features
you put into the current code will eventually percolate down to
packagers like RH and their customers.  But, you should not be concerned
with what RH is doing.  If RH wants to take TLS support from the latest
rev of openSSL and back-port it to RHE v4, that is their problem.  You
are making it your problem, and you need to know that this is going to
be wasted effort.  The OpenSSL developers cannot use your effort, because
your working with old code, and the RH people don't have customers
demanding TLS support in RHE v4, and so they aren't going to be
in your patches either.  Most likely, if RH did get a bunch of customers
wanting TLS, they would put their development effort into putting TLS
the next version of RHE, then tell all their customers to spend money to
upgrade to the new version of RHE.

It is not to the open source communitites benefit to have the opensssl
developers spend a lot of time back-porting new features to old openssl

It always distresses me when I see a cool feature patched into older
open source code, because I know it's a dead end.  I learned this myself
a few years ago when I spent a lot of effort porting ancient patches
to the mt command that supported moving the tape to a specific block
number.  Unfortunately I stupidly worked with production, not development
code, so when I finally got it all working, the development code had
so changed in that code section, all my effort was wasted also.
someone did put that support into mt, a few years later, fortunately,
but not using any of my work.

Anyway, I hope that you do take a look at the current openssl development
code and see if anything you worked on can be used there.


OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@openssl.org
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to