Given that this would be useful for other tools, perhaps it's best to create an "openssl-insecure" package which would ship a version of openssl that has all the bells-and-whistles enabled (including the insecure ones). We would have to take care that nothing is unintentionally linked to the library. It would be a useful companion to software like testssl.sh (which has similar requirements to sslscan)
I certainly don't have strong feelings about this, especially given that I haven't done any of the work... Just a thought :) On Fri, Dec 23, 2016 at 9:53 AM, Moritz Mühlenhoff <j...@inutil.org> wrote: > Sebastian Andrzej Siewior <sebast...@breakpoint.cc> schrieb: > > Please use t...@security.debian.org if you want to reach the security > team, not debian-security@ldo. > > > tl;dr: Has anyone a problem if sslscan embeds openssl 1.0.2 in its > > source? > > That's for post-stretch, right? Right now it can simply link against > the 1.0.2 copy, > > Seems fine to me for that use case, and it won't need any security > updates to the embedded openssl copy for all practical purposes anyway. > > Cheers, > Moritz > > -- Cheers, Jonathan
