Arch Linux

In a previous thread,  FS#14903 , it came up that simply removing the perl dependency from openssl may break some of the >200 other packages which depend on it, if they happen to require Perl but don't directly depend on it. So, I grabbed these lists from the official repo.
The following depend on openssl and not perl:
aircrack-ng, apache, archboot, argyllcms, axel, badvpn, bigloo, bind-tools, bip, bitcoin-tx, boinctui, borg, cgit, coreutils, couchdb, cowpatty, dsniff, dspam, easy-rsa, efitools, elinks, encfs, erlang, erlang-nox, erlang200, exim, fdm, fetchmail, fossil, freerdp, freetds, galera, gambas3-gb-openssl, gftp, gnustep-base, gsoap, gwenhywfar, haproxy, hostapd, httping, httrack, iperf3, ipmitool, iputils, keepalived, ldns, lib32-openssl, libarchive, libesmtp, libevent, libexosip2, libircclient, libmariadbclient, libmesode, libperconaserverclient, librabbitmq-c, libsasl, libshairport, libshout, libssh2, libstrophe, libtorrent, libvncserver, libwebsockets, lua-sec, lua51-sec, lua52-sec, lynx, medusa, mktorrent, monit, nghttp2, nginx, nginx-mainline, ngircd, nmap, ntp, open-isns, opendkim, openimageio, openntpd, opensips, openslp, openvswitch, opusfile, p3scan, pam_mount, parity, parrot, partimage, pixiewps, pkcs11-helper, podofo, postgresql-libs, powerdns, powerdns-recursor, prosody, proxytunnel, pulseaudio-zeroconf, pwsafe, pypy, pypy3, python, python-pyopenssl, python2, python2-pyopenssl, radare2, restbed, rkt, ruby, s-nail, sbsigntools, scrypt, shairport-sync, siege, slimjet, slowhttptest, slrn, socat, sofia-sip, ssmtp, stellarium, stunnel, tarantool, tarsnap, tcltls, tcpdump, tcpflow, testdisk, thc-ipv6, thrift, tinc, tnftp, uboot-tools, unshield, vde2, vpnc, w3m, webfs, wimlib, xmlsec, yara, zathura-pdf-mupdf

The following depend on openssl and one or more of the above (given), and not perl:
archboot (a lot of things), bind (bind-tools), curl (libssh2), dovecot (libmariadbclient, postgresql-libs), ejabberd (erlang-nox), esmtp (libesmtp), hydra (libmariadbclient, postgresql-libs), libasr (libevent), libvirt (libsasl, python2), mariadb-clients (libmariadbclient), mongodb (libsasl), mosquitto (libwebsockets), mutt (libsasl), nsd (libevent), ntop (libevent, python2), open-iscsi (open-isns), openssh (ldns), openvpn (pkcs11-helper), ostree (libarchive), poco (libmariadbclient), postfix (libmariadbclient, libsasl, postgresql-libs), postgresql-old-upgrade (postgresql-libs), pyrit (python2), python2-m2crypto (python2), ruby-eventmachine (ruby), sslsplit (libevent), swi-prolog (libarchive), testssl.sh (bind-tools, coreutils), tor (libevent), unbound (libevent), virtualbox (python2), x11vnc (libvncserver)

The following depend on openssl, depend on curl and/or libssh2, and don't depend on perl:
arch-audit, cower, dovecot, ettercap, ettercap-gtk, lastpass-cli, libcurl-compat, libgit2, libvirt, mupdf, strongswan, synergy, unrealircd, virtualbox

Even assuming that Ruby, Python, and their dependents don't use Perl, there's still >150 packages (not counting THEIR dependents) which need to be checked for Perl usage. Alternatively, in what I think is the safest move, annoy their maintainers by moving the perl dependency to each of them.

It would be nice feature for small docker images.

So they are two issues at hand here: openssl depending on perl for almost no reason, and then lots of packages not depending on perl because relying on openssl (which they depend upon) to do it for them.

We need to fix the second one at distro level (by forbidding transient dependencies) before changing openssl deps is doable.

However, not that coreutils for instance is in your above list, and removing this package from a system seems a bad idea. So I’m afraid that your initial goal (avoiding perl) is unreachable.

Sorry, I didn't understand,
are you saying that coreutils requires perl (not the package, but actually)?

looking through the /usr/bin/ files from coreutils, I can't see anything using perl as a script or linked to perl.

Sorry, I misread the first line (if they happen to require Perl but don't directly depend on it). I thought the list was package requiring Perl but not depending on it, actually it’s just packages potentially depending on Perl.

According to my calculations there are currently

6473 packages which depend on openssl in one way or another, and
4204 which depend on perl in one way or another (not including via openssl)

There are 3540 packages that depend on openssl but do not otherwise have perl in their dependency tree, list is attached.

Of course this says nothing about whether a package assumes that pacman is installed...

I'm inclined to think, anyway, that assuming core works and we trial things in testing for a bit, this should be doable. In the meantime, I've discovered three packages that link to libperl.so and do not depend on it except through openssl:

irssi
=> /usr/bin/irssi
openldap
=> /usr/lib/slapd
postgresql-old-upgrade
=> /opt/pgsql-10/lib/hstore_plperl.so
=> /opt/pgsql-10/lib/plperl.so

I rewrote c_rehash in bash to fix this [1] but indeed - c_rehash isn't needed at all anymore as it is already included in the openssl binary itself.

if packages depend on openssl they shouldn't assume perl is installed as well. If they do, that can only be found & fixed by removing perl from the requirements of openssl

please fix this

1. https://github.com/openssl/openssl/pull/10123

I wrote a dumb script to try to exit 0 if a package either links to libperl, or has a file containing a shebang line and which invokes perl (via shebangs or bash subprocesses or whatever): https://paste.xinu.at/BIUF8eN/
(The actual check is dumb as a rock, and simply tries to see if the literal string '\bperl\b' exists with regular expression \b word boundaries.)

Now I'm running the following loop on dragon, which has a full package mirror:

for i in /srv/ftp/pool/*/*.pkg.tar.xz; do if ! bsdtar -xOf "$i" .PKGINFO | grep -qE '^(opt)?depend = .*perl.*'; then bin/detect-perl-in-package.sh "$i" && echo "$i: depends on perl"; fi; done

Let's see what happens. I *think* in theory this should tell us everything (plus false positives, sigh).

Found the final list of packages which somehow mention perl. Note: there are false positives, for example python has a .py file which mentions its algorithm is "is based on the perl module Text::Unidecode".

it will need to be further filtered...

EDIT: paste link updated to https://paste.xinu.at/PZ3QnT/

I'm sporadically updating this list with details of what I've detected in each package, this list can be found at https://pkgbuild.com/~eschwartz/perl-stuff.txt

Some packages are marked as false positives (occasionally with details), others have recommended guidance, or notes on which files need perl (but it's not always clear if those files are important).

We're down to 32 packages which still need to be checked off of https://www.archlinux.org/todo/perl-transient-openssl-dependencies/

Once those are resolved, we should be able to safely assume everything that uses perl depends on it. At that point, openssl could drop its dep or move it to an optdepends.

The todolist is now resolved.

Great! I'll commit a new split packages this weekend. Atm I have it it split into openssl, openssl-doc and openssl-perl.

We could probably just either

- make Perl an optdepends "for the c_rehash script"
- replace the c_rehash script with a tiny shell script that invokes `openssl rehash "$@"`

The latter relies on the fact that openssl-rehash is an identical, modern built-in C implementation of c_rehash.pl

As for replacing c_rehash: My reasoning here would be not to deviate from upstream too much if possible.
As for splitting the package I looked into what other distros like Fedora or Debian do. I tendo o lean towards a separate package instead of using optdepends as it is more explicit and you do not end up with partly invalid package.

Why would you look into what other distros do, other distros by definition don't follow the Arch Way.

Modern code depending on modern openssl versions should really just be sed'ing all invocations of 'c_rehash' to 'openssl rehash'. I've actually done it for one project (which is partly written in perl either way). I think an optdepends would be plenty fair here. We do it for lots of other scripts.

This change would either way break users, since they would be missing the program if they rely on it.