Seems like a decent idea for this, if other packages need an insecure openssl. As for making it hard to link to, the .so can be put into a non-standard dir so it has to be explicitly enabled both with a -lcrypto-insecure and -L/usr/lib/openssl-insecure.
.hc Jonathan Yu: > 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 >> >> > >
