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 wrote:
> Sebastian Andrzej Siewior 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
