DSA candidates

2016-12-26 Thread Raphael Geissert
ansible/stable
--
apache2/stable
--
cairo/stable
--
ceph/stable
--
dhcpcd5/stable
--
imagemagick/stable
--
libav/stable
--
libgc/stable
--
libgd2/stable
--
libphp-phpmailer/stable
--
libtomcrypt/stable
--
libtorrent-rasterbar/stable
--
libvpx/stable
--
libwebp/stable
--
lshell/stable
--
monit/stable
--
mupdf/stable
--
mysql-connector-python/stable
--
potrace/stable
--
python-cryptography/stable
--
resteasy/stable
--
ruby2.1/stable
--
salt/stable
--
shadow/stable
--
sogo/stable
--
spip/stable
--
xen/stable
--
xrdp/stable
--
zendframework/stable
--
--
The above is a list of DSA candidates based on the tracker's information.
One should evaluate the candidates and either add them to dsa-needed.txt
or consider tagging them no-dsa.



Re: embedding openssl source in sslcan

2016-12-26 Thread Hans-Christoph Steiner

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 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
>>
>>
> 
>