On Thu, Jan 05, 2017 at 09:39:16PM +0100, Sebastian Andrzej Siewior wrote:
> On 2016-12-31 17:35:47 [+0100], Julien Cristau wrote:
> > Is this really something we need to be shipping? If yes, I'd personally
> > really like this to get an explicit exemption from normal policy by the
> > security te
On 2016-12-31 17:35:47 [+0100], Julien Cristau wrote:
> Is this really something we need to be shipping? If yes, I'd personally
> really like this to get an explicit exemption from normal policy by the
> security team, so please talk to them (debian-security@ldo is not it).
I have been made aware
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
On Sun, Jan 01, 2017 at 04:37:48PM +0100, Raphael Hertzog wrote:
> On Sat, 31 Dec 2016, Julien Cristau wrote:
> > On Thu, Dec 22, 2016 at 13:37:11 +0100, Sebastian Andrzej Siewior wrote:
> >
> > > tl;dr: Has anyone a problem if sslscan embeds openssl 1.0.2 in its
> > > source?
> > >
> > > sslscan
On Sat, 31 Dec 2016, Julien Cristau wrote:
> On Thu, Dec 22, 2016 at 13:37:11 +0100, Sebastian Andrzej Siewior wrote:
>
> > 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
On Thu, Dec 22, 2016 at 13:37:11 +0100, Sebastian Andrzej Siewior wrote:
> 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 supp
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
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
9 matches
Mail list logo
