On 2017-04-27 21:32:42 [+0200], Kurt Roeckx wrote: > I'm not suggesting to add libwww-curl-perl. > > I'm not sure why we have things in /usr/lib/ssl/misc/, which > doesn't sound like a useful place to put things. > > Note that there are actually manpages for them, so maybe we should > move them to /usr/bin/? > > We should probaby get rid of the whole /usr/lib/ssl/
So some apps from within that folder got removed in 1.1 https://github.com/openssl/openssl/commit/b8a9af68819f1cc51155cdeabe8bbf8242e8b3ee since nobody screamed for things like c_name maybe nobody cares. Looking at https://packages.debian.org/sid/amd64/openssl/filelist we have just /usr/lib/ssl/certs /usr/lib/ssl/misc/CA.pl /usr/lib/ssl/misc/tsget /usr/lib/ssl/openssl.cnf /usr/lib/ssl/private and everything but the misc folder are symlinks to /etc/ssl. So if we get openssl+libssl patched we could get rid of the symlinks. So then we have just the misc folder with CA.pl an tsget. CA.pl seems to be referenced by "things" like http://sources.debian.net/src/kopanocore/8.1.0-3/installer/linux/ssl-certificates.sh/?#L23 and we may may have some users. My guess is that most people have either wrappers around openssl or something else. Even openvpn brings the "easyrsa" thingy. And then there is tsget which I have no idea what it does and how usefull it is. I am in between nuking both tools from orbit (including the manpage) and moving them to /usr/bin. Do you thing that they are usefull? google brings either the source code or the manpage. I miss a blog entry where someone explains why he is doing what he is doing :) > But I think we shouldn't change anything for stretch, except maybe > changing from perl to perl-base. Correct. If I get around it I would open an unblock request (around Monday) asking the release team if they want the perl-base dependency instead of perl for Stretch of this is fine with you. > Kurt Sebastian