LSB inclusion of OpenSSL

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

LSB inclusion of OpenSSL

Pradosh Adoni
Hi,

(I had sent this mail earlier, but it didn't seem to make it to the list )

Carrying forward from earlier discussion threads  which I have linked
here for reference -
http://www.mail-archive.com/openssl-dev@.../msg19662.html
http://www.mail-archive.com/openssl-dev@.../msg19158.html

though it has been fairly established that the resulting ABI will in all
probabilty break in forthcoming (major) versions, It would be good to
know if there exists some sort of  timeline or roadmap on when these
issues will be addressed.
for eg. Of the current list of interfaces which ones are most
definitely going to be deprecated in future versions ?

There was also discussion (but no definite commitment) of hiding data
structures in future versions, Is this still a possibilty ? . Does it
make sense to include these structures in the LSB if they are going to
be addressed in the future ?

thanks,

-- Pradosh Adoni
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: LSB inclusion of OpenSSL

jlam-2
Pradosh Adoni wrote:

>
> (I had sent this mail earlier, but it didn't seem to make it to the list )
>
> Carrying forward from earlier discussion threads  which I have linked
> here for reference -
> http://www.mail-archive.com/openssl-dev@.../msg19662.html
> http://www.mail-archive.com/openssl-dev@.../msg19158.html
>
> though it has been fairly established that the resulting ABI will in all
> probabilty break in forthcoming (major) versions, It would be good to
> know if there exists some sort of  timeline or roadmap on when these
> issues will be addressed.
> for eg. Of the current list of interfaces which ones are most
> definitely going to be deprecated in future versions ?
>
> There was also discussion (but no definite commitment) of hiding data
> structures in future versions, Is this still a possibilty ? . Does it
> make sense to include these structures in the LSB if they are going to
> be addressed in the future ?

What makes you think that the OpenSSL developers will go to the trouble
to do all this major surgery to their codebase when they won't do the
very simple thing of just properly versioning their shared libraries?
When the ABI changes, all that they need to do is to increase the major
version of the shared libraries.  It's *that* simple.  There doesn't
need to be any major modification of the sources -- just to a Makefile
here and there.

Understanding the attitude of the OpenSSL project as I do now towards
this, in my opinion, rather basic principle of software engineering, I
have decided that as the maintainer of the OpenSSL package in pkgsrc, I
  will just decide upon and assign proper shared library version numbers
for the libraries installed by OpenSSL.  I recommend that other projects
that use OpenSSL simply do the same.  I'm tired of our users getting
screwed over when the OpenSSL project recommends updating to the latest
teeny release of OpenSSL which still manages to break ABI compatibility
with previous teeny releases.

        Cheers,

        -- Johnny Lam <[hidden email]>
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: LSB inclusion of OpenSSL

Richard Levitte - VMS Whacker
In reply to this post by Pradosh Adoni
In message <[hidden email]> on Thu, 27 Oct 2005 18:49:53 +0530, Pradosh Adoni <[hidden email]> said:

pradosh.adoni> though it has been fairly established that the
pradosh.adoni> resulting ABI will in all probabilty break in
pradosh.adoni> forthcoming (major) versions, It would be good to know
pradosh.adoni> if there exists some sort of timeline or roadmap on
pradosh.adoni> when these issues will be addressed.

There is no timeline.  You can't really expect one from a volunteer-
driven project, as it hugely depends on the spare time of the
controling participants.

pradosh.adoni> for eg. Of the current list of interfaces which ones
pradosh.adoni> are most definitely going to be deprecated in future
pradosh.adoni> versions ?

For the longest time, we have recommended to use the EVP interface
rather than lower level crypto functions.  However, not even the EVP
interface has been safe from incompatible changes, BUT those changes
have been comparatively few.

pradosh.adoni> There was also discussion (but no definite commitment)
pradosh.adoni> of hiding data structures in future versions, Is this
pradosh.adoni> still a possibilty ? . Does it make sense to include
pradosh.adoni> these structures in the LSB if they are going to be
pradosh.adoni> addressed in the future ?

I've done such an attempt once, and it really opened a can of worms.
I don't quite remember what structure I tried to hide, and that's not
really important.  The important thing to realise is that while it's
certainly possible to do, given enough time and resources, it's a HUGE
project to take on.

It's quite possible that it can be done in smaller increments.
Unfortunately, there's always the risk that structure references are
more deeply tangled than one might think, so something that looks
small to begin with have a real possibility to open a can of worms and
turn out to be a HUGE thing.

I've thought for a long time that what's really needed is a rewrite
that keeps the strong points of OpenSSL while doing the rest better.
I started tinkering on something like that a while ago, and have come
a part of the way.  I was actually going to finish up the first part
enough to be able to present it, but have been held up by work.  It
has the blessing of the rest of the OpenSSL team.  Take a look at
http://www.netcrypto.org/common/ for a quick briefing.

Keep in mind that I haven't updated those pages in a while (a year?),
so some details are outdated or incomplete.

Cheers,
Richard

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

--
Richard Levitte                         [hidden email]
                                        http://richard.levitte.org/

"When I became a man I put away childish things, including
 the fear of childishness and the desire to be very grown up."
                                                -- C.S. Lewis
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: LSB inclusion of OpenSSL

Richard Levitte - VMS Whacker
In reply to this post by jlam-2
In message <[hidden email]> on Thu, 27 Oct 2005 11:01:23 -0400, Johnny Lam <[hidden email]> said:

jlam> What makes you think that the OpenSSL developers will go to the
jlam> trouble to do all this major surgery to their codebase when they
jlam> won't do the very simple thing of just properly versioning their
jlam> shared libraries?

Hmm, there's quite a lot of negativity flowing around these mailing
lists lately...

jlam> When the ABI changes, all that they need to do is to increase
jlam> the major version of the shared libraries.  It's *that* simple.
jlam> There doesn't need to be any major modification of the sources
jlam> -- just to a Makefile here and there.

Right now, we have it depend on the version number.  An please tell
what the correct format for a soname is.  On some Unixen, it seems
like the correct format is libfoo.so.{x}.{y}, where x and y has very
specific meaning: the program that was linked against libfoo.so.{x}.{y}
can run against libfoo.so.{x}.{y+n} for all n = 0, 1, ..., oo.  On
other Unixen, the program that was linked with a library with a
specific soname must run against a library with the exact same
soname.  Others have just one number.  Others yet place the version
information somewhere completely different.  And I'm sure there are
more methods that I haven't even heard of.

But I'll take up the cue and see what we can do that works
everywhere.  But it's not just changing a Makefile a little here and
there.  If you want to help, please tell us how it should look on your
specific platform.  At some point, we'll have a knowledge database
that covers at least most of the platforms we support or try to
support.

Cheers,
Richard

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

--
Richard Levitte                         [hidden email]
                                        http://richard.levitte.org/

"When I became a man I put away childish things, including
 the fear of childishness and the desire to be very grown up."
                                                -- C.S. Lewis
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: LSB inclusion of OpenSSL

jlam-2
Richard Levitte - VMS Whacker wrote:
> In message <[hidden email]> on Thu, 27 Oct 2005 11:01:23 -0400, Johnny Lam <[hidden email]> said:
>
> jlam> What makes you think that the OpenSSL developers will go to the
> jlam> trouble to do all this major surgery to their codebase when they
> jlam> won't do the very simple thing of just properly versioning their
> jlam> shared libraries?
>
> Hmm, there's quite a lot of negativity flowing around these mailing
> lists lately...

I'm sorry.  You're right -- I was unneedlessly negative, and I apologize.

> jlam> When the ABI changes, all that they need to do is to increase
> jlam> the major version of the shared libraries.  It's *that* simple.
> jlam> There doesn't need to be any major modification of the sources
> jlam> -- just to a Makefile here and there.
>
> Right now, we have it depend on the version number.  An please tell
> what the correct format for a soname is.  On some Unixen, it seems
> like the correct format is libfoo.so.{x}.{y}, where x and y has very
> specific meaning: the program that was linked against libfoo.so.{x}.{y}
> can run against libfoo.so.{x}.{y+n} for all n = 0, 1, ..., oo.  On
> other Unixen, the program that was linked with a library with a
> specific soname must run against a library with the exact same
> soname.  Others have just one number.  Others yet place the version
> information somewhere completely different.  And I'm sure there are
> more methods that I haven't even heard of.

Libtool works across many, many Unixen, and has picked a consistent
versioning scheme for libtool archives from which the correct soname
version is derived on a platform-specific basis.

> But I'll take up the cue and see what we can do that works
> everywhere.  But it's not just changing a Makefile a little here and
> there.  If you want to help, please tell us how it should look on your
> specific platform.  At some point, we'll have a knowledge database
> that covers at least most of the platforms we support or try to
> support.

I think that OpenSSL strives to work on more platforms that libtool does
actually does at the moment, but I think the project is best served if
it uses libtool to build OpenSSL for everywhere that it does work, and
to fall back on the home-grown code for where libtool doesn't work.  I
have a lot of experience adding libtool support to many packages for
pkgsrc, and I would be happy to contribute the above solution to the
OpenSSL project if such a change were seriously considered.

        Cheers,

        -- Johnny Lam <[hidden email]>
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Shared library version numbers [Was: LSB inclusion of OpenSSL]

Andy Polyakov
In reply to this post by Richard Levitte - VMS Whacker
Please note that there is explicit question to couple of subscribers
posed in this message. Others should feel free to correct and complement.

> Right now, we have it depend on the version number.  An please tell
> what the correct format for a soname is.  On some Unixen, it seems
> like the correct format is libfoo.so.{x}.{y}, where x and y has very
> specific meaning: the program that was linked against libfoo.so.{x}.{y}
> can run against libfoo.so.{x}.{y+n} for all n = 0, 1, ..., oo.

You refer to scheme when versioning is encoded into filename. As far as
I understand elder versions of some BSD flavors [most notably pre-ELF
OpenBSD] and SunOS 4 are/were using this scheme. In present OpenSSL
context the only thing one can do in this case is to either number as
.so.97, .so.98, .so.100 or use dumb numbers such as .so.1, .so.2,
.so.3... Read current OpenSSL .so versioning is effectively broken in
these systems, because run-time linker won't object linking 0.9.7
application with 0.9.8 shared object.

> On
> other Unixen, the program that was linked with a library with a
> specific soname must run against a library with the exact same
> soname.

You refer to most widely used [at least all ELF-based systems] scheme.
Upon compile time linker looks up libfoo.so, pulls an DT_SONAME or
similar field from there and puts it into application binary as is.
DT_SONAME will be looked up by run-time linker and is expected to be
present on library search path, period. DT_SONAME can contain as many
numbers as you like and it even doesn't have to be called
libfoo.so.1.2.3, it can as well be 3.2.1.foo.bar. In present OpenSSL
context it works only as long as DT_SONAME contains full version, i.e.
.so.0.9.7, .so.0.9.8, .so.1.0.0. This it what we currently have. Read
current OpenSSL .so is expected to work on these systems.

Commonly this scheme is complemented with a *convention* to tag with one
[or two] digits and let .so.x[.y] be a symbolic link to .so.x[.y].z,
where z can actually be any number, but conventionally it ascends. To
protect against descending numbers some kind of additional subversioning
is implemented, at least Linux, Tru64 and IRIX has it.

Now question to Johnny Lam [who is complaining that we don't bump
versions] and Christoph Martin [who suggests to add versioning on all
symbols]. What exactly didn't work for you? As far as I understand both
NetBSD and Debian are ELF-based so it should have worked... Does it
simply conflict with your less-than-three-numbers convention [not that
something is wrong with such convention, I'm just asking!] or is there
some other reason? I'm not saying that that we refuse to change .so
versioning in any way, all I want is to do things for right and
recognized reasons, not just upon "we have had some problems." Well, in
PAM case I can imagine problem with GLOBAL_OFFSET_TABLE being
"cross-polluted" by 0.9.7 and 0.9.8 being *both* mapped into same
application. Is it the case? Can you elaborate on which symbols were
overloaded? You can figure this out by examining dynamic name tables *in
pam modules* with objdump -T.

> Others have just one number.

Can anybody refer to an actual example of such system? That would limit
DT_SONAME [or its analogue] to single number after suffix or in any
other way at all? I'm not saying that there is no such implementation, I
just wonder which one is it... On such system the only possible solution
would [again] be to tag as 97, 98, 100 or independent numbers such as 1,
2, 3...

> Others yet place the version
> information somewhere completely different.

MacOS has analog to DT_SONAME and additionally implements internal
"minimally required version" tagging, when shared object is tagged with
"compatiblity version" and "current version" tags, each containing up to
three digit fields [first is 16 bits, second and third - 8 bits]. In
present OpenSSL context it works only as long as shared object contains
full version in its name and additionally is tagged with full version,
e.g. 0.9.7, 0.9.8, etc. One has opportunity to omit the third number
only upon 1.0 release. It should be noted that even though 0.9.8 tags
with full version, 0.9.7 tags with 0.9.0 in "compatibility version,"
which is error-prone. However! OpenSSL encodes "DT_SONAME" with full
version number, so it should work?

As for Tru64. Even though analog to DT_SONAME exists, we don't seem to
use it. On Tru64 OpenSSL .so versioning appears to be broken...

> But I'll take up the cue  and see what we can do that works
> everywhere.

Then it would have to be the least common denominator: 97, 98, 100 or
independent numbers such as 1, 2, 3:-) A.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Shared library version numbers [Was: LSB inclusion of OpenSSL]

Kurt Roeckx
On Fri, Oct 28, 2005 at 09:46:30AM +0200, Andy Polyakov wrote:
>
> Now question to Johnny Lam [who is complaining that we don't bump
> versions] and Christoph Martin [who suggests to add versioning on all
> symbols]. What exactly didn't work for you? As far as I understand both
> NetBSD and Debian are ELF-based so it should have worked...

The current soname is libssl.so.0.9.8, the previous one was
libssl.so.0.9.7.

A single library or binary ussually doesn't end up linked to both
of those, but some binaries do end indirectly linking against
both sonames.

Any ELF object (library, progam) can have DT_NEEDED records in it,
saying it's using symbols from that.  Say libA links against
libssl.so at the time the soname is libssl.so.0.9.7 and adds an
DT_NEEDED for it.  Then you also install libssl.so.0.9.8, you
link a program progA against both libA and libssl.so.

So you have:
progA
 - DT_NEEDED: libssl.so.0.9.8
 - DT_NEEDED: libA
libA:
 - DT_NEEDED: libssl.so.0.9.7

Now, if you load progA, it loads: libssl.so.0.9.8, libA, and
libssl.so.0.9.7, because libA needs it.

Then when the dynamic linker looks for a symbol, it looks at it
by name.  It will go over all objects to see if it exists in it.
It will use the symbol from the first library it finds it in.

This means, that a symbol that libA requires, and _should_ get
from libssl.so.0.9.7, can also exist in libssl.so.0.9.8, and will
most likely be using that.  If libssl.so.0.9.8 has a different
ABI, this breaks.

The way to make sure that libA gets the symbol with the right
ABI, is to have all symbols have a unique name.  This can be done
with symbol versioning.  It then gets named "symbol@@version".
The runtime linker adds references to the versioned symbol, and
dynamic linker then looks for the versioned symbols.

This allows you to indirectly link to more than 1 version of the
library without having to worry about the ABI having changed.

There are also more advanced things you can do with symbol
versioning, but those are not what we want.  Atleast not at this
time.  The only thing we want here is to have a unique name for
all symbols.

> Well, in
> PAM case I can imagine problem with GLOBAL_OFFSET_TABLE being
> "cross-polluted" by 0.9.7 and 0.9.8 being *both* mapped into same
> application.

There have been problems reported breaking pam, but I don't know
the details about it.  It most likely was fixed by relinking the
affected modules against the new libssl.


Kurt

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Shared library version numbers [Was: LSB inclusion of OpenSSL]

Stefan.Neis@t-online.de
In reply to this post by Andy Polyakov
        Hi,

> Then when the dynamic linker looks for a symbol, it looks at it
> by name.  It will go over all objects to see if it exists in it.
> It will use the symbol from the first library it finds it in.
>
> This means, that a symbol that libA requires, and _should_ get
> from libssl.so.0.9.7, can also exist in libssl.so.0.9.8, and will
> most likely be using that.  If libssl.so.0.9.8 has a different
> ABI, this breaks.
>
> The way to make sure that libA gets the symbol with the right
> ABI, is to have all symbols have a unique name.  This can be done
> with symbol versioning.  It then gets named "symbol@@version".
> The runtime linker adds references to the versioned symbol, and
> dynamic linker then looks for the versioned symbols.

If you "simply" use the "-Bsymbolic" flag when building libA, doesn't
that solve the problem as well?  And in a more portable way, since
vrsioned symbols don't exist on "many" platforms?
AFAIK, the idea of the flag is that the library doesn't automatically
doesn't resolve its symbols against the "global" symbols from the
main program or other libs loaded, but only against those libs that
it was linked against.

        Regards,
                Stefan


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Shared library version numbers [Was: LSB inclusion of OpenSSL]

Kurt Roeckx
On Sat, Oct 29, 2005 at 03:12:24AM +0100, [hidden email] wrote:

>         Hi,
>
> > Then when the dynamic linker looks for a symbol, it looks at it
> > by name.  It will go over all objects to see if it exists in it.
> > It will use the symbol from the first library it finds it in.
> >
> > This means, that a symbol that libA requires, and _should_ get
> > from libssl.so.0.9.7, can also exist in libssl.so.0.9.8, and will
> > most likely be using that.  If libssl.so.0.9.8 has a different
> > ABI, this breaks.
> >
> > The way to make sure that libA gets the symbol with the right
> > ABI, is to have all symbols have a unique name.  This can be done
> > with symbol versioning.  It then gets named "symbol@@version".
> > The runtime linker adds references to the versioned symbol, and
> > dynamic linker then looks for the versioned symbols.
>
> If you "simply" use the "-Bsymbolic" flag when building libA, doesn't
> that solve the problem as well?  And in a more portable way, since
> vrsioned symbols don't exist on "many" platforms?
> AFAIK, the idea of the flag is that the library doesn't automatically
> doesn't resolve its symbols against the "global" symbols from the
> main program or other libs loaded, but only against those libs that
> it was linked against.

No it doesn't. In fact, -Bsymbolic really should be avoided since
it opens alot more problems that it solves.


Kurt

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Shared library version numbers [Was: LSB inclusion of OpenSSL]

Stefan.Neis@t-online.de
In reply to this post by Andy Polyakov
        Hi,

> > If you "simply" use the "-Bsymbolic" flag when building libA, doesn't
> > that solve the problem as well?  And in a more portable way, since
> > vrsioned symbols don't exist on "many" platforms?
> > AFAIK, the idea of the flag is that the library doesn't automatically
> > doesn't resolve its symbols against the "global" symbols from the
> > main program or other libs loaded, but only against those libs that
> > it was linked against.
>
> No it doesn't. In fact, -Bsymbolic really should be avoided since
> it opens alot more problems that it solves.

OK, I'm lost...
What does it actually do?
It sure was the only way to get my PKCS#11 module to actually link against the
MD5 routines in the [static] library it used instead of having it reuse the
(incompatible) symbols with the same name contained in the Nescape/Mozilla
binary. And my conclusion from that observation was that unless you do know
enough details of all the binaries that will ever use your shared object in
advance, you want to link your shared object with -Bsymbolic ...

        Regards,
                Stefan




______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Shared library version numbers [Was: LSB inclusion of OpenSSL]

Kurt Roeckx
On Sat, Oct 29, 2005 at 02:45:51PM +0100, [hidden email] wrote:

>         Hi,
>
> > > If you "simply" use the "-Bsymbolic" flag when building libA, doesn't
> > > that solve the problem as well?  And in a more portable way, since
> > > vrsioned symbols don't exist on "many" platforms?
> > > AFAIK, the idea of the flag is that the library doesn't automatically
> > > doesn't resolve its symbols against the "global" symbols from the
> > > main program or other libs loaded, but only against those libs that
> > > it was linked against.
> >
> > No it doesn't. In fact, -Bsymbolic really should be avoided since
> > it opens alot more problems that it solves.
>
> OK, I'm lost...
> What does it actually do?
> It sure was the only way to get my PKCS#11 module to actually link against the
> MD5 routines in the [static] library it used instead of having it reuse the
> (incompatible) symbols with the same name contained in the Nescape/Mozilla
> binary. And my conclusion from that observation was that unless you do know
> enough details of all the binaries that will ever use your shared object in
> advance, you want to link your shared object with -Bsymbolic ...

It changes the order in which the dynamic linker searches for
symbols in objects files.  It tries to find the symbol in the
same object that is trying to use it.  Because the lookup order
is changed, you can get strange results you didn't expect.

The only thing -Bsymbolic can solve is that it would use symbols
from it's own object.


Kurt

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Shared library version numbers [Was: LSB inclusion of OpenSSL]

Kurt Roeckx
In reply to this post by Andy Polyakov
On Fri, Oct 28, 2005 at 09:46:30AM +0200, Andy Polyakov wrote:

>
> Now question to Johnny Lam [who is complaining that we don't bump
> versions] and Christoph Martin [who suggests to add versioning on all
> symbols]. What exactly didn't work for you? As far as I understand both
> NetBSD and Debian are ELF-based so it should have worked... Does it
> simply conflict with your less-than-three-numbers convention [not that
> something is wrong with such convention, I'm just asking!] or is there
> some other reason? I'm not saying that that we refuse to change .so
> versioning in any way, all I want is to do things for right and
> recognized reasons, not just upon "we have had some problems." Well, in
> PAM case I can imagine problem with GLOBAL_OFFSET_TABLE being
> "cross-polluted" by 0.9.7 and 0.9.8 being *both* mapped into same
> application. Is it the case? Can you elaborate on which symbols were
> overloaded? You can figure this out by examining dynamic name tables *in
> pam modules* with objdump -T.

If you want an example of things breaking because of the
transition from 0.9.7 to 0.9.8, look at:
http://bugs.debian.org/334180

In this case, libpq (from postgresql) was linked to libssl0.9.7,
and dovecot was linked to libpq and libssl0.9.8.

It gave some strange error message indicating it couldn't load
libz.so.

I really don't want to debug this, it's alot more easier to just
relink libpq against libssl0.9.8.


Kurt

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Shared library version numbers [Was: LSB inclusion of OpenSSL]

Andy Polyakov
In reply to this post by Andy Polyakov
>> But I'll take up the cue  and see what we can do that works
>> everywhere.
>
> Then it would have to be the least common denominator: 97, 98, 100 or
> independent numbers such as 1, 2, 3.

The above was referring to file suffixes. It should be noted that
there're platforms, which has no notion of versioning through file
suffix, most notably Windows. The only way to get it working on Windows
and similar platforms [if any] would be to encode the version into .DLL
file name, e.g. crypto098.dll, ...099.dll, ...100.dll [note that at
least in Windows context it doesn't prevent us from calling
corresponding .lib import library for crypto.lib]. In other words least
common denominator would be embedding version number into shared object
file name, not its extension. As it's unlikely to be accepted that Unix
developers would have link with -lcrypto100, we're stuck with multiple
versioning schemes in either case:-(

On a side note in respect to problem with cross-polution of global name
table from different versions of OpenSSL. Windows would be free from
this, because import tables are private to every mapped module, meaning
that two modules, one linked with 0.9.7 and another with 0.9.8, would
not interfere with each other. Just a side note! A.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Shared library version numbers [Was: LSB inclusion of OpenSSL]

Andy Polyakov
In reply to this post by Kurt Roeckx
>>... in
>>PAM case I can imagine problem with GLOBAL_OFFSET_TABLE being
>>"cross-polluted" by 0.9.7 and 0.9.8 being *both* mapped into same
>>application. Is it the case? Can you elaborate on which symbols were
>>overloaded? You can figure this out by examining dynamic name tables *in
>>pam modules* with objdump -T.
>
> If you want an example of things breaking because of the
> transition from 0.9.7 to 0.9.8, look at:
> http://bugs.debian.org/334180
>
> In this case, libpq (from postgresql) was linked to libssl0.9.7,
> and dovecot was linked to libpq and libssl0.9.8.

In other words it's exactly the case of "cross-pollution" of name space
by indirect link with different versions of OpenSSL .so. Thanks to
-Bsymbolic at least libcrypto.so.0.9.7 doesn't affect
libcrypro.so.0.9.8, but libcrypto.so.0.9.7 can affect libssl.so.0.9.8
[and/or vice versa].

For the record. I reckon that -Bsymbolic is more than appropriate in
OpenSSL context as it prevents overloading of inner calls by another
module. A.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: LSB inclusion of OpenSSL

Pradosh Adoni
In reply to this post by Richard Levitte - VMS Whacker
On 10/27/05, Richard Levitte - VMS Whacker <[hidden email]> wrote:

> In message <[hidden email]> on Thu, 27 Oct 2005 18:49:53 +0530, Pradosh Adoni <[hidden email]> said:
>
> pradosh.adoni> though it has been fairly established that the
> pradosh.adoni> resulting ABI will in all probabilty break in
> pradosh.adoni> forthcoming (major) versions, It would be good to know
> pradosh.adoni> if there exists some sort of timeline or roadmap on
> pradosh.adoni> when these issues will be addressed.
>
> There is no timeline.  You can't really expect one from a volunteer-
> driven project, as it hugely depends on the spare time of the
> controling participants.
Sorry ... this was more a shot in the dark than anything ... of course
one cannot expect  commitments in community driven projects (I'm not
trying to be sarcastic :) )...

> pradosh.adoni> for eg. Of the current list of interfaces which ones
> pradosh.adoni> are most definitely going to be deprecated in future
> pradosh.adoni> versions ?
>
> For the longest time, we have recommended to use the EVP interface
> rather than lower level crypto functions.  However, not even the EVP
> interface has been safe from incompatible changes, BUT those changes
> have been comparatively few.
so ,would it make more sense to standardize on the EVP interface as
opposed to the lower level functions ? This would force developers
seeking LSB certification to go by that recommendation, unfortunately
we can't say how well this would be accepted.
Or if we do standardize on the lower level stuff , then we would need
to indentify interfaces which are ABSOULTELY NOT going to change in
the coming versions, but I don't know how feasible that is ..

thanks,
-- pradosh
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: LSB inclusion of OpenSSL

Richard Levitte - VMS Whacker
In message <[hidden email]> on Mon, 7 Nov 2005 12:45:15 +0530, Pradosh Adoni <[hidden email]> said:

pradosh.adoni> so ,would it make more sense to standardize on the EVP
pradosh.adoni> interface as opposed to the lower level functions ?
pradosh.adoni> This would force developers seeking LSB certification
pradosh.adoni> to go by that recommendation, unfortunately we can't
pradosh.adoni> say how well this would be accepted.  Or if we do
pradosh.adoni> standardize on the lower level stuff , then we would
pradosh.adoni> need to indentify interfaces which are ABSOULTELY NOT
pradosh.adoni> going to change in the coming versions, but I don't
pradosh.adoni> know how feasible that is ..

I'd opt for a standardisation of the EVP interface.

Cheers,
Richard

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

--
Richard Levitte                         [hidden email]
                                        http://richard.levitte.org/

"When I became a man I put away childish things, including
 the fear of childishness and the desire to be very grown up."
                                                -- C.S. Lewis
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: LSB inclusion of OpenSSL

Dr. Stephen Henson
In reply to this post by Pradosh Adoni
On Mon, Nov 07, 2005, Pradosh Adoni wrote:

> > pradosh.adoni> for eg. Of the current list of interfaces which ones
> > pradosh.adoni> are most definitely going to be deprecated in future
> > pradosh.adoni> versions ?
> >
> > For the longest time, we have recommended to use the EVP interface
> > rather than lower level crypto functions.  However, not even the EVP
> > interface has been safe from incompatible changes, BUT those changes
> > have been comparatively few.
> so ,would it make more sense to standardize on the EVP interface as
> opposed to the lower level functions ? This would force developers
> seeking LSB certification to go by that recommendation, unfortunately
> we can't say how well this would be accepted.
> Or if we do standardize on the lower level stuff , then we would need
> to indentify interfaces which are ABSOULTELY NOT going to change in
> the coming versions, but I don't know how feasible that is ..
>

I'm assuming that by "ABSOULTELY NOT going to change in the coming versions"
means "not going to change in incompatible ways" rather that "not going to
change at all".

Some compatible changes may well be likely.

As for incompatible chanhes there is one nasty incompatibility with PKCS#11
which EVP might have to address if we ever need a full PKCS#11 ENGINE. Even
that though could be done in a compatible way.

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Funding needed! Details on homepage.
Homepage: http://www.drh-consultancy.demon.co.uk
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: LSB inclusion of OpenSSL

Richard Levitte - VMS Whacker
In message <[hidden email]> on Mon, 7 Nov 2005 13:37:19 +0100, "Dr. Stephen Henson" <[hidden email]> said:

steve> As for incompatible chanhes there is one nasty incompatibility
steve> with PKCS#11 which EVP might have to address if we ever need a
steve> full PKCS#11 ENGINE. Even that though could be done in a
steve> compatible way.

Without jumping through hoops and bending over backwards twice?

Cheers,
Richard

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

--
Richard Levitte                         [hidden email]
                                        http://richard.levitte.org/

"When I became a man I put away childish things, including
 the fear of childishness and the desire to be very grown up."
                                                -- C.S. Lewis
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: LSB inclusion of OpenSSL

Dr. Stephen Henson
On Mon, Nov 07, 2005, Richard Levitte - VMS Whacker wrote:

> In message <[hidden email]> on Mon, 7 Nov 2005 13:37:19 +0100, "Dr. Stephen Henson" <[hidden email]> said:
>
> steve> As for incompatible chanhes there is one nasty incompatibility
> steve> with PKCS#11 which EVP might have to address if we ever need a
> steve> full PKCS#11 ENGINE. Even that though could be done in a
> steve> compatible way.
>
> Without jumping through hoops and bending over backwards twice?
>

Probably more than that :-(

There are two PKCS#11 issue which are painful.

One is its handling of fork() which I've mentioned before.

The other is that its equivalent to EVP_CipherUpdate() and EVP_CipherFinal()
which can output data in arbitrary sizes whereas our stuff will never be more
than one block length larger than the input. I'm aware of some PKCS#11
implementations that buffer the input data until it reaches a few K in size
and then dumps the whole lot.

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Funding needed! Details on homepage.
Homepage: http://www.drh-consultancy.demon.co.uk
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: LSB inclusion of OpenSSL

Richard Levitte - VMS Whacker
In message <[hidden email]> on Mon, 7 Nov 2005 14:00:17 +0100, "Dr. Stephen Henson" <[hidden email]> said:

steve> The other is that its equivalent to EVP_CipherUpdate() and
steve> EVP_CipherFinal() which can output data in arbitrary sizes
steve> whereas our stuff will never be more than one block length
steve> larger than the input. I'm aware of some PKCS#11
steve> implementations that buffer the input data until it reaches a
steve> few K in size and then dumps the whole lot.

Ewwww....

Cheers,
Richard

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

--
Richard Levitte                         [hidden email]
                                        http://richard.levitte.org/

"When I became a man I put away childish things, including
 the fear of childishness and the desire to be very grown up."
                                                -- C.S. Lewis
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]