[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Statement(s) on libssl situation desired

Hash: SHA1

Nathanael Nerode wrote:
> luk@debian.org wrote:
>>Kurt Roeckx wrote:
> <snip>
>>>I intend to drop the libssl0.9.7-dev package in the next upload,
>>>which I hope to do soon.  I don't think it's a good idea to keep
>>>that -dev package around.  Unless the release team ask me to keep
>>>it around, I'll remove it.
>>I would be very surprised if the release team would ask you to keep it
>>around (due to conversations on IRC).
> Oh good grief.
> What are the plans for the libssl fiasco?  Consider this a formal request for 
> a statement.

Well, I'm in no position to give such, but I'll say what I think will

> 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!)  Is there an ETA for a 
> versioned version (ahem) in unstable?  Has it been accepted by upstream.  If 
> not, will it be done in Debian anyway?  Will it be done ASAP or are plans to 
> wait for upstream?

I think there will be versioned symbols one way or another. I don't
think there is an ETA at this time. AFAIK it has been accepted by
upstream, but only for 1.0.0. I think it will be introduced in Debian
anyway for 0.9.8.

> 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.  
> 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?)

I don't think anything will be done in the very near future to prevent
it from happening.

> 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.

If it can be avoided, it probably will be avoided...

> Finally, are there any plans to alleviate testing migration issues for 
> packages held up by this, and if so, how?

I think that testing migration will happen on the requirement that it
can be installed, not on if it could segfault or not.

Just my 2 cents.


- --
Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D
Fingerprint:   D5AF 25FB 316B 53BB 08E7   F999 E544 DE07 9B7C 328D
Version: GnuPG v1.4.2 (GNU/Linux)


Reply to: