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

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.


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 <jmm@inutil.org> wrote:
>> Sebastian Andrzej Siewior <sebastian@breakpoint.cc> schrieb:
>> Please use team@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

Reply to: