Hi,
Am 2. Januar 2017 11:35:30 MEZ, schrieb Thijs Kinkhorst :
>On Fri, December 23, 2016 18:53, 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
On Fri, December 23, 2016 18:53, 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 f
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 b
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
librar
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 c
tl;dr: Has anyone a problem if sslscan embeds openssl 1.0.2 in its
source?
sslscan [0] as packaged in Debian currently relies on external libssl as
provided by the openssl package. The openssl package disables support
compression, SSLv2 and SSLv3 which is good but it also means that
sslscan can no
6 matches
Mail list logo
