Re: embedding openssl source in sslcan
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.
> 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 <firstname.lastname@example.org> wrote:
>> Sebastian Andrzej Siewior <email@example.com> schrieb:
>> Please use firstname.lastname@example.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
>> 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.