Skip Menu |
 
Ticket metadata
The Basics
Id: 1365
Status: open
Priority: 0/
Queue: OpenSSL-Bugs

Custom Fields
Milestone: (no value)
Subsystem: (no value)
Severity: (no value)
Broken in: (no value)

People
Owner: Kurt Roeckx (no email address)
Requestors: Jan Pazdziora
Jan Pazdziora
Cc:
AdminCc:

Attachments
openssl-0.9.8b-ipv6-bio.patch2
openssl-0.9.8b-ipv6-bio.patch4

More about the requestors

Jan Pazdziora

Comments about this user: No comment entered about this user
Groups this user belongs to
  • Unprivileged
  • Everyone

Jan Pazdziora

Comments about this user: No comment entered about this user
Groups this user belongs to
  • Unprivileged
  • Everyone

New reminder:
Subject:
Owner:
Due:

Dates
Created: Tue Jul 18 13:33:56 2006
Starts: Not set
Started: Tue Jul 18 14:06:13 2006
Last Contact: Thu Jan 31 20:54:06 2008
Due: Tue Jul 18 13:33:56 2006
Closed: Not set
Updated: Mon Jul 14 18:59:19 2014 by Kurt Roeckx



Date: Thu, 13 Jul 2006 10:54:27 +0200
From: Jan Pazdziora <jpr-ossl@adelton.com>
To: rt@openssl.org
Cc: tmraz@redhat.com
Subject: PATCH: Adding IPv6 support to s_client and s_server
Download (untitled) / with headers
text/plain 1.3k

Hello,

attached please find a patch that makes it possible to use IPv6
addresses with openssl's s_client and s_server. The patch is against
openssl-0.9.8b as found in the Fedora Core Rawhide
openssl-0.9.8b-3.src.rpm package.

Without this patch, using IPv6-only hostname fails with

$ openssl s_client -connect 'ipv6hostname:443'
gethostbyname failure
connect:errno=0

and using IPv6 address fails with

$ openssl s_client -connect '[::FFFF:195.30.6.166]:https'
getservbyname failure for :FFFF:195.30.6.166]:https
usage: s_client args

With this patch, the command line parameters are correctly processed
and used, for hostnames, IPv6 addresses and IPv4 mapped addresses,
using a bracket notation:

$ openssl s_client -connect '[::FFFF:195.30.6.166]:https'
CONNECTED(00000003)
depth=0 /ST=The Internet/O=The OpenSSL Project/CN=www.openssl.org/emailAddress=openssl-team@openssl.org
[...]

The Red Hat maintainer of the openssl package (Cc:) is ready to apply
the patch for the next Fedora Core, which would give the IPv6 feature
to people who do not want to compile and patch their software. But we
wanted to make sure that such a change will be seen as a correct thing
to do by the OpenSSL Team.

Therefore, I'd welcome your opinion about the patch and a possibility
of it being applied to the core openssl source.

Yours,

--
Jan Pazdziora
Date: Tue, 18 Jul 2006 11:17:15 +0200
From: Jan Pazdziora <jpazdziora@redhat.com>
To: rt@openssl.org
Cc: tmraz@redhat.com
Subject: Re: IPv6 support in openssl's BIO
Download (untitled) / with headers
text/plain 1.1k
On Thu, Jul 13, 2006 at 04:26:29PM +0200, Richard Levitte - VMS Whacker wrote:
Show quoted text
>
> > OK. I suggest I prepare a patch that will not change them (they will
> > be IPv4-only), will mark them with #ifndef OPENSSL_NO_DEPRECATED, and
> > will not add them to the .pod. Sounds reasonable?
>
> Yes.
>
> > How about the problem of BIO_set_conn_ip/BIO_get_conn_ip being
> > IPv4-only? Do you prefer BIO_set_conn_ipv6/BIO_get_conn_ipv6 as their
> > IPv6-only counterparts, or some other way? How heavily is BIO_* used
> > and how heavily are BIO_set_conn_ip/BIO_get_conn_ip used?
>
> They aren't used at all in OpenSSL itself, as far as I can see. As
> for the rest of the world, your guess is as good as mine.
>
> They way they work, I think that IPv6 variants is the way to go.

Greetings,

the patch to change IPv4-only functions and structures to AF-agnostic
in the BIO part of openssl is attached to this mail (Reguest Tracker
will presumably strip it) and can also be found at

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=198737

Comments, or inclusion in the openssl distribution, are welcome.

Yours,

--
Jan Pazdziora

Message body is not shown because sender requested not to inline it.

Download (untitled) / with headers
text/plain 1.4k
I'm taking a look at it. Don't worry about RT "stripping" the
attachment, that's just for outgoing email. The patch is in the
database, and I just downloaded it.

[jpazdziora@redhat.com - Tue Jul 18 13:33:56 2006]:

Show quoted text
> On Thu, Jul 13, 2006 at 04:26:29PM +0200, Richard Levitte - VMS
> Whacker wrote:
> >
> > > OK. I suggest I prepare a patch that will not change them (they
> will
> > > be IPv4-only), will mark them with #ifndef OPENSSL_NO_DEPRECATED,
> and
> > > will not add them to the .pod. Sounds reasonable?
> >
> > Yes.
> >
> > > How about the problem of BIO_set_conn_ip/BIO_get_conn_ip being
> > > IPv4-only? Do you prefer BIO_set_conn_ipv6/BIO_get_conn_ipv6 as
> their
> > > IPv6-only counterparts, or some other way? How heavily is BIO_*
> used
> > > and how heavily are BIO_set_conn_ip/BIO_get_conn_ip used?
> >
> > They aren't used at all in OpenSSL itself, as far as I can see. As
> > for the rest of the world, your guess is as good as mine.
> >
> > They way they work, I think that IPv6 variants is the way to go.
>
> Greetings,
>
> the patch to change IPv4-only functions and structures to AF-agnostic
> in the BIO part of openssl is attached to this mail (Reguest Tracker
> will presumably strip it) and can also be found at
>
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=198737
>
> Comments, or inclusion in the openssl distribution, are welcome.
>
> Yours,


--
Richard Levitte
levitte@openssl.org
Date: Thu, 20 Jul 2006 13:14:37 +0200
From: Jan Pazdziora <jpazdziora@redhat.com>
To: Richard Levitte via RT <rt@openssl.org>
Cc: openssl-dev@openssl.org
Subject: Re: [openssl.org #1365] Re: IPv6 support in openssl's BIO
RT-Send-Cc:
On Tue, Jul 18, 2006 at 02:06:12PM +0200, Richard Levitte via RT wrote:
Show quoted text
>
> I'm taking a look at it. Don't worry about RT "stripping" the
> attachment, that's just for outgoing email. The patch is in the
> database, and I just downloaded it.

Richard,

I prepared new version of the patch.

Fixes:

- indentation -- I did the previous patch with -b, which was
not exactly clever;

- OPENSSL_free(*host_ptr) replaces OPENSSL_free(*port_ptr);

- freeaddrinfo(res0) is now in the err:;

- NI_MAXHOST instead of INET6_ADDRSTRLEN + 16.

Changes:

The patch also changes the logic in conn_state, to go back to
BIO_CONN_S_CREATE_SOCKET from later stages, provided there are some
more records in res left.

The patch also no longer adds those *_ipv6 functions, so that
changes to the ABI are minimal. Those two functions can always be
added any time later on.

I can also generate just an incremental patch from the previous
patch2, if you prefer.

Are you aware of any software which actually uses the BIO networking?
I'm affraid I did not test these code paths beyond compile.

Yours,

--
Jan Pazdziora

Message body is not shown because sender requested not to inline it.

Date: Thu, 20 Jul 2006 18:06:54 +0200
From: Andy Polyakov <appro@fy.chalmers.se>
To: openssl-dev@openssl.org
Cc: Richard Levitte via RT <rt@openssl.org>
Subject: Re: [openssl.org #1365] Re: IPv6 support in openssl's BIO
RT-Send-Cc:
Download (untitled) / with headers
text/plain 1.4k
I want to point out that there is rudimentary IPv6 support in HEAD
already. Well, it depends on new DSO_global_lookup, but it's not the
point I want to emphasize.

Show quoted text
> I prepared new version of the patch.

- struct sockaddr_in server,client;
+ struct addrinfo *res, *res0, hints;

Typically unacceptable. You think exclusively about your platform and
disregard the fact that there might be platform, which don't have struct
addrinfo declared. All such changes should be *conditional*. Switching
to generic struct sockaddr complemented with #ifdef EAI_FAMILY and
#ifdef AF_INTE6 seemed to be appropriate for HEAD. Is there reason to do
something different in 098?

Then keep in mind our workflow. Functional changes go to HEAD, then and
only then possibility of backport to one or more stable branches is
considered. I personally would also allow for some time between commit
to HEAD and backport, so that some feedback can be gathered.

For reference. As for DSO_global_lookup. It might appear dubious to Unix
programmer, but it's not as uncommon in Windows, when program is
compiled with one set of headers is linked with elder system library at
run-time. That's where DSO_global_lookup is expected to fill in. Of
course one also has to double-check that corresponding structures are
compatible (which was done) and do appropriate things if not (turned to
be unnecessary in given case). So that changes can be made conditional
even at run-time... A.
Date: Fri, 21 Jul 2006 09:07:03 +0200
From: Jan Pazdziora <jpazdziora@redhat.com>
To: Andy Polyakov via RT <rt@openssl.org>
Subject: Re: [openssl.org #1365] Re: IPv6 support in openssl's BIO
RT-Send-Cc:
Download (untitled) / with headers
text/plain 2.7k
On Thu, Jul 20, 2006 at 06:04:37PM +0200, Andy Polyakov via RT wrote:
Show quoted text
>
> I want to point out that there is rudimentary IPv6 support in HEAD
> already. Well, it depends on new DSO_global_lookup, but it's not the
> point I want to emphasize.

It is a very good point. I didn't know about it and I look at it right
now.

Show quoted text
> > I prepared new version of the patch.
>
> - struct sockaddr_in server,client;
> + struct addrinfo *res, *res0, hints;
>
> Typically unacceptable. You think exclusively about your platform and
> disregard the fact that there might be platform, which don't have struct
> addrinfo declared. All such changes should be *conditional*. Switching
> to generic struct sockaddr complemented with #ifdef EAI_FAMILY and
> #ifdef AF_INTE6 seemed to be appropriate for HEAD. Is there reason to do
> something different in 098?

Not really.

I sent a patch to provide a solution for platforms that have addrinfo.
Basically, if you do not have addrinfo, you cannot expect IPv6 to
work. I was looking for a feedback about this particular solution for
platforms that support IPv6.

Supporting legacy platforms was not my primary goal _at this time_
-- what I wanted were comments about the IPv6 functionality. It is
clear that some conditional branching might be needed, but I'd prefer
to focus on it once the target (IPv6 solution) is agreed on.

Show quoted text
> Then keep in mind our workflow. Functional changes go to HEAD, then and
> only then possibility of backport to one or more stable branches is
> considered. I personally would also allow for some time between commit
> to HEAD and backport, so that some feedback can be gathered.

May I suggest that this is added to the www.openssl.org webpages, so
that even people outside of The OpenSSL Core and Development Team know
that they should be always targeting HEAD, not the last released
version? The problem with HEAD is that it is a moving target and
slightly harder for people from outside to hit it.

Show quoted text
> For reference. As for DSO_global_lookup. It might appear dubious to Unix
> programmer, but it's not as uncommon in Windows, when program is
> compiled with one set of headers is linked with elder system library at
> run-time. That's where DSO_global_lookup is expected to fill in. Of
> course one also has to double-check that corresponding structures are
> compatible (which was done) and do appropriate things if not (turned to
> be unnecessary in given case). So that changes can be made conditional
> even at run-time... A.

As DSO_global_lookup is currently only used for getaddrinfo and
freeaddrinfo -- is it really a problem on Windows? Microsoft seems to
lists these functions as available and supported for all Windows
versions that are currently supported by Microsoft.

--
Jan Pazdziora
Date: Fri, 21 Jul 2006 11:25:32 +0200
From: Andy Polyakov <appro@fy.chalmers.se>
To: rt@openssl.org
Subject: Re: [openssl.org #1365] Re: IPv6 support in openssl's BIO
RT-Send-Cc:
Download (untitled) / with headers
text/plain 2.3k
Show quoted text
> I sent a patch to provide a solution for platforms that have addrinfo.
> Basically, if you do not have addrinfo, you cannot expect IPv6 to
> work.

My comment was not about having IPv6 working without addrinfo, but about
not breaking platforms which don't have one.

Show quoted text
> I was looking for a feedback about this particular solution for
> platforms that support IPv6.

And feedback is "no, it's not the way it should be done, because we
can't have different branches for platforms that have addrinfo and those
which don't."

Show quoted text
> Supporting legacy platforms was not my primary goal _at this time_

Well, it is ours at all times and you have to respect that:-) Well, the
goal is not really support legacy platform at all costs, but rather not
discontinue if compatibility can be achieved by maintaining certain
discipline.

Show quoted text
>> For reference. As for DSO_global_lookup. It might appear dubious to Unix
>> programmer, but it's not as uncommon in Windows, when program is
>> compiled with one set of headers is linked with elder system library at
>> run-time. That's where DSO_global_lookup is expected to fill in. Of
>> course one also has to double-check that corresponding structures are
>> compatible (which was done) and do appropriate things if not (turned to
>> be unnecessary in given case). So that changes can be made conditional
>> even at run-time...
>
> As DSO_global_lookup is currently only used for getaddrinfo and
> freeaddrinfo -- is it really a problem on Windows? Microsoft seems to
> lists these functions as available and supported for all Windows
> versions that are currently supported by Microsoft.

OK, to be absolutely sincere. It's not about what Microsoft [or RedHat]
supports for the moment, but about exercising above mentioned
discipline. It's not about looking for excuses, but exploring maximum
possible extent of portability. Is it possible to write code which
adapts itself to run-time environment? Regardless whether run-time is
supported by vendor or not? How complicated is it? Forget that you're
RedHat employee, become programmer instead:-) But this is getting
off-topic. DSO_global_lookup was not the point I wanted to emphasize!
DSO_global_lookup is mentioned only because you'll have to cope with it
in HEAD branch. The main point is that changes of this character should
be *conditional* for backward compatibility and you have to play by this
rules. A.
Date: Fri, 21 Jul 2006 11:40:54 +0200
From: Jan Pazdziora <jpazdziora@redhat.com>
To: Andy Polyakov via RT <rt@openssl.org>
Subject: Re: [openssl.org #1365] Re: IPv6 support in openssl's BIO
RT-Send-Cc:
Download (untitled) / with headers
text/plain 1.1k
On Fri, Jul 21, 2006 at 11:23:11AM +0200, Andy Polyakov via RT wrote:
Show quoted text
>
> off-topic. DSO_global_lookup was not the point I wanted to emphasize!
> DSO_global_lookup is mentioned only because you'll have to cope with it
> in HEAD branch.

I can see now that IPv6 support is in the HEAD branch, I assume it
will be included in some openssl release in the future, therefore there
is no need for the change that I sent. I am sorry I did not notice the
code in HEAD before I sent my original question and original patch.

Show quoted text
> The main point is that changes of this character should
> be *conditional* for backward compatibility and you have to play by this
> rules. A.

I have no problems with making changes conditional. The patch can
be changed to a conditional one, I was seeking comment about IPv6 code
_at the moment_, focusing on the IPv6 functionality.

Anyway, the patch for BIO is not needed, please disregard it. I've
submitted another patch, rt #1361, for apps/ part. Again, it is
getaddrinfo-only solution and I'd appreciate your comment about the
code, provided I will make it conditional once the getaddrinfo
code path is okayed.

--
Jan Pazdziora
Subject: [openssl.org #1361] PATCH: Adding IPv6 support to s_client and s_server
Date: Thu, 31 Jan 2008 14:40:41 -0500
To: rt@openssl.org
From: Hyong Shim <hyongsop@research.telcordia.com>
Hi,

Has this patch been applied to s_client and s_server in 0.9.8g?

Thanks,

--Hyong