Re: LSB inclusion of OpenSSL
In message <[EMAIL PROTECTED]> on Mon, 7 Nov 2005 14:00:17 +0100, "Dr. Stephen Henson" <[EMAIL PROTECTED]> 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. E Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] 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 openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: LSB inclusion of OpenSSL
On Mon, Nov 07, 2005, Richard Levitte - VMS Whacker wrote: > In message <[EMAIL PROTECTED]> on Mon, 7 Nov 2005 13:37:19 +0100, "Dr. > Stephen Henson" <[EMAIL PROTECTED]> 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 openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: LSB inclusion of OpenSSL
In message <[EMAIL PROTECTED]> on Mon, 7 Nov 2005 13:37:19 +0100, "Dr. Stephen Henson" <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] 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 openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: LSB inclusion of OpenSSL
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 openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: LSB inclusion of OpenSSL
In message <[EMAIL PROTECTED]> on Mon, 7 Nov 2005 12:45:15 +0530, Pradosh Adoni <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] 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 openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: LSB inclusion of OpenSSL
On 10/27/05, Richard Levitte - VMS Whacker <[EMAIL PROTECTED]> wrote: > In message <[EMAIL PROTECTED]> on Thu, 27 Oct 2005 18:49:53 +0530, Pradosh > Adoni <[EMAIL PROTECTED]> 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 openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Shared library version numbers [Was: LSB inclusion of OpenSSL]
... 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 openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Shared library version numbers [Was: LSB inclusion of OpenSSL]
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 openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Shared library version numbers [Was: LSB inclusion of OpenSSL]
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 openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Shared library version numbers [Was: LSB inclusion of OpenSSL]
On Sat, Oct 29, 2005 at 02:45:51PM +0100, [EMAIL PROTECTED] 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 openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Shared library version numbers [Was: LSB inclusion of OpenSSL]
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 openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Shared library version numbers [Was: LSB inclusion of OpenSSL]
On Sat, Oct 29, 2005 at 03:12:24AM +0100, [EMAIL PROTECTED] 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 openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Shared library version numbers [Was: LSB inclusion of OpenSSL]
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 openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Shared library version numbers [Was: LSB inclusion of OpenSSL]
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 openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Shared library version numbers [Was: LSB inclusion of OpenSSL]
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 openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: LSB inclusion of OpenSSL
Richard Levitte - VMS Whacker wrote:
In message <[EMAIL PROTECTED]> on Thu, 27 Oct 2005 11:01:23 -0400, Johnny Lam
<[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: LSB inclusion of OpenSSL
In message <[EMAIL PROTECTED]> on Thu, 27 Oct 2005 11:01:23 -0400, Johnny Lam
<[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
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 openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: LSB inclusion of OpenSSL
In message <[EMAIL PROTECTED]> on Thu, 27 Oct 2005 18:49:53 +0530, Pradosh Adoni <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] 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 openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: LSB inclusion of OpenSSL
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@openssl.org/msg19662.html http://www.mail-archive.com/openssl-dev@openssl.org/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 <[EMAIL PROTECTED]> __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
LSB inclusion of OpenSSL
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@openssl.org/msg19662.html http://www.mail-archive.com/openssl-dev@openssl.org/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 openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
LSB inclusion of OpenSSL
Hi, Carrying forward from earlier discussion threads which I have linked here for reference - http://www.mail-archive.com/openssl-dev@openssl.org/msg19662.html http://www.mail-archive.com/openssl-dev@openssl.org/msg19158.html though it has been fairly established that the 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 openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
