Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 10 Mar 2015 15:05:49 +0000
From: John Haxby <john.haxby@...cle.com>
To: oss-security@...ts.openwall.com
Subject: Re: PEP-466 common compatible implementation. (was
 ... CVE-2015-1777)

On 10/03/15 10:59, Michael Samuel wrote:
> I'm happy to help work on this.
> 
> The two ways to attack this seem to be:
> 
> 1) Use alternatives for the ssl module, and a new package has a
> higher priority version of the module.
> 
> 2) Include both versions of the module under different names, and
> have a script that symlinks the correct one in place.  This may work
> better in chroot environments, etc.

I think the second one with alternatives thrown in would work well.

Individual applications that want to behave correctly can use the new
module.   Existing applications can use the old module (by default) or
the new module (if alternatives is configured that way).  That way
existing applications that depend on the old broken behaviour will still
work (albeit no more securely

I admit I haven't used alternatives much (ie never in anger) but this
does sound like an approach that will give a clean mechanism across
distros.   Certainly better than my ill-thought-out wild guess.

Alexander: is this the right place to discuss nitty-gritty details or
should be take the discussion elsewhere?

jch

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ