Re: [Pkg-openssl-devel] Statement(s) on libssl situation desired
* Steve Langasek ([EMAIL PROTECTED]) [051015 01:39]: On Sat, Oct 15, 2005 at 12:52:08AM +0200, Christoph Martin wrote: Finally, are there any plans to alleviate testing migration issues for packages held up by this, and if so, how? The way to alleviate testing migration issues is by getting openssl097 and openssl updates into testing ASAP. They will probably have to go into testing together, because of the move of the openssl binary from one source package to the other, which means openssl needs to be reuploaded with symbol versionining support and then both packages need to be allowed to get built on all architectures and settled long enough that we can be comfortable pushing them into testing. AFAICS, openssl097 will go into testing by itself as soon as the -dev-package is rened out, and it is built on ia64 (and of course, old enough). For openssl itself - well, we need of course resolve this RC-bug (i.e. get library versioning working). Cheers, Andi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-openssl-devel] Statement(s) on libssl situation desired
On Fri, Oct 14, 2005 at 04:38:53PM -0700, Steve Langasek wrote: On Sat, Oct 15, 2005 at 12:52:08AM +0200, Christoph Martin wrote: Finally, are there any plans to alleviate testing migration issues for packages held up by this, and if so, how? The way to alleviate testing migration issues is by getting openssl097 and openssl updates into testing ASAP. They will probably have to go into testing together, because of the move of the openssl binary from one source package to the other, which means openssl needs to be reuploaded with symbol versionining support and then both packages need to be allowed to get built on all architectures and settled long enough that we can be comfortable pushing them into testing. What I'm wondering about was the need for a Conflict between libssl0.9.7 and libssl0.9.8. I think we should do it, but it's going to make migration to testing alot harder, but hopefully the last time. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-openssl-devel] Statement(s) on libssl situation desired
On Sat, Oct 15, 2005 at 01:11:17PM +0200, Kurt Roeckx wrote: What I'm wondering about was the need for a Conflict between libssl0.9.7 and libssl0.9.8. I think we should do it, but it's going to make migration to testing alot harder, but hopefully the last time. Having talked to with the release team on IRC, we agreed that we should not add a Conflict. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: [Pkg-openssl-devel] Statement(s) on libssl situation desired
Packages built against the unversioned libssl0.9.8 will, when run on a system with versioned libssl0.9.8, either pick up the symbols from libssl0.9.7 (wrong) or not find their symbols (segfault). Accordingly, all packages linked against the current libssl0.9.8 are in trouble and will need rebuilds. Correction; I got my versioning rules wrong. They'll work fine if libssl0.9.7 is *not* installed, but will pick up the symbols from it if it is installed. Which is seriously bad. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: [Pkg-openssl-devel] Statement(s) on libssl situation desired
On Sat, Oct 15, 2005 at 03:39:08PM -0400, Nathanael Nerode wrote: Packages built against the unversioned libssl0.9.8 will, when run on a system with versioned libssl0.9.8, either pick up the symbols from libssl0.9.7 (wrong) or not find their symbols (segfault). Accordingly, all packages linked against the current libssl0.9.8 are in trouble and will need rebuilds. Correction; I got my versioning rules wrong. They'll work fine if libssl0.9.7 is *not* installed, but will pick up the symbols from it if it is installed. Which is seriously bad. Please note that libssl0.9.7 and libssl0.9.8 have a different SONAME. There can only be a problem when a program (indirectly) links to both of them. In that case, there isn't even an option not to install both of them. If a program is linked to both of them, and it was not linked to a lib with versioned symbols, there really isn't much you can tell about which symbols it's going to pick. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: [Pkg-openssl-devel] Statement(s) on libssl situation desired
[EMAIL PROTECTED] wrote: Please note that libssl0.9.7 and libssl0.9.8 have a different SONAME. There can only be a problem when a program (indirectly) links to both of them. In that case, there isn't even an option not to install both of them. If a program is linked to both of them, and it was not linked to a lib with versioned symbols, there really isn't much you can tell about which symbols it's going to pick. Right. Thanks for being clearer than me. Consider the fate of a binary built against libssl0.9.8 with unversioned symbols, once libssl0.9.8 with versioned symbols is installed. Suppose also that libssl0.9.7 -- with unversioned symbols -- is indirectly linked in (very likely in complicated situations like KDE, and because libssl may be dlopened). The dynamic linker will resolve the unversioned symbols from the binary -- supposed to be, at least in some cases, libssl0.9.8 symbols -- to the unversioned symbols it finds, namely, the ones in libssl0.9.7. This is bad if the ABI has actually changed between 0.9.7 and 0.9.8, as it will lead to tricky-to-track-down bugs at runtime. It would be best, therefore, if nothing were built against libssl0.9.8 until the libssl0.9.8 with versioned symbols is available (after which everything will be hunky-dory). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-openssl-devel] Statement(s) on libssl situation desired
Hi Nathanael, Nathanael Nerode schrieb: Note the following apparent facts: * libssl0.9.7 and libssl0.9.8, if linked in the same binary, will cause unpredictable failure due to symbol conflicts. * This could be fixed if libssl0.9.8 had versioned symbols, which it doesn't yet. * I see from pkg-openssl-devel that the plans are to version the symbols in libssl0.9.8. Is this a settled decision yet? (If so, good!) I think in the Debian openssl team it is settled that we want versioned symbols. I have build a first version and it is working. Is there an ETA for a versioned version (ahem) in unstable? I think it can be released in the next days. We want to have some more discussion and testing. And we don't want to make a hasty move and brake other things. Has it been accepted by upstream. We got no answer from upstream yet. If not, will it be done in Debian anyway? I think we will do it anyway. I would only prefere to have it settled with upstream, know how they plan to implement it so that we do not have to change everything if they introduce it. Will it be done ASAP or are plans to wait for upstream? We will definitely not wait until upstream releases a version. If we are planning to wait until upstream accepts this, what will be done to deal with the problem in the meantime? Packages built against the unversioned libssl0.9.8 will, when run on a system with versioned libssl0.9.8, either pick up the symbols from libssl0.9.7 (wrong) or not find their symbols (segfault). Accordingly, all packages linked against the current libssl0.9.8 are in trouble and will need rebuilds. This is not true. I just checked it with versionend and unversioned openssl binary and libraries: unversioned binary with versioned libraries just works fine, no complain, no crash. versioned binary with unversioned libraries results in a warning and also works find. Please see also http://lists.debian.org/debian-devel/2005/10/msg00278.html and followups. However, currently there is *nothing* preventing yet more packages being built against it. Are there plans to deal with this? (Perhaps, at the least, a warning message to d-d-a telling people not to upload packages built against libssl0.9.8 at this time?) One could do this. It may also be nontrivial to identify such packages after versioned libssl0.9.8 goes into the archive (all packages depending on libssl0.9.8 will require an audit of their symbols to see whether they were built against the versioned version). This may be avoided by a shlibs bump or package name change for the versioned libssl0.9.8. A shlibs bump should be done, yes. But I don't want to change the package name. I think it is not necessary. Finally, are there any plans to alleviate testing migration issues for packages held up by this, and if so, how? ? Christoph -- Christoph Martin, EDV der Verwaltung, Uni-Mainz, Germany Internet-Mail: [EMAIL PROTECTED] Telefon: +49-6131-3926337 signature.asc Description: OpenPGP digital signature
Re: [Pkg-openssl-devel] Statement(s) on libssl situation desired
On Sat, Oct 15, 2005 at 12:52:08AM +0200, Christoph Martin wrote: Finally, are there any plans to alleviate testing migration issues for packages held up by this, and if so, how? The way to alleviate testing migration issues is by getting openssl097 and openssl updates into testing ASAP. They will probably have to go into testing together, because of the move of the openssl binary from one source package to the other, which means openssl needs to be reuploaded with symbol versionining support and then both packages need to be allowed to get built on all architectures and settled long enough that we can be comfortable pushing them into testing. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
