Arch Linux User Repository

MarsSeed: You are correct and we should at least attempt a clean custom build instead of using pip packages. It may however cause even more issues with upstream's specific version requirements because we would then not only get issues with new Python releases but also with new releases of sslyze's dependencies.

There will be a first quick update later today, updating the package and making it work with Python 3.11. A better build process than using pip needs a bit more time and testing.

Update (2023/11/02): I've now looked into this more closely. Building sslyze "properly" is easily possible. However, creating a python-nassl package, which would be a dependency, is not that easy. Nassl still depends on OpenSSL 1.1 (https://github.com/nabla-c0d3/nassl/issues/114) and building against an already installed version of OpenSSL does not seem to be straightforward. So for now, I think sticking to an isolated installation in /opt using pip is the best we can do. If people disagree, I would be interested in concrete proposals for a proper python-nassl package.

MarsSeed: You are correct and we should at least attempt a clean custom build instead of using pip packages. It may however cause even more issues with upstream's specific version requirements because we would then not only get issues with new Python releases but also with new releases of sslyze's dependencies.

There will be a first quick update later today, updating the package and making it work with Python 3.11. A better build process than using pip needs a bit more time and testing.

Update (2023/11/02): I've now looked into this more closely. Building sslyze "properly" is easily possible. However, creating a python-nassl package, which would be a dependency, is not that easy. Nassl still depends on OpenSSL 1.1 (https://github.com/nabla-c0d3/nassl/issues/114) and building against an already installed version of OpenSSL does not seem to be straightforward. So for now, I think sticking to an isolated installation in /opt using pip is the best we can do. If people disagree, I would be interested in concrete proposals for a proper python-nassl package.

Don't use pip install in package(); it's not allowed by Arch Python package guidelines. Use python-build and python-installer.

The same game all over again for Python 3.10: nassl (a dependency of sslyze) is not yet available for 3.10. Tracked upstream here: https://github.com/nabla-c0d3/sslyze/issues/464

[Update] sslyze now is Python 3.9 compatible, so the following comment is obsolete.

Python 3.9 hit the Arch repositories and sslyze (or at least nassl which is a dependency) is not yet compatible with that. There is a version of Python 3.8 in AUR but unless there is strong demand, personally I'd rather just wait for an update of sslyze.

@jhu: sslyze is not yet compatible with Python 3.8, see

• https://github.com/nabla-c0d3/sslyze/issues/408
• https://github.com/nabla-c0d3/nassl/issues/50

I guess the hope is that this is solved timely. If not, the package needs to be changed to use python37 from AUR.

The package does not run and cannot be built anymore:

==> Starting package()...
Processing /tmp/trizen-jhu/sslyze/src/sslyze-2.1.4
ERROR: Could not find a version that satisfies the requirement nassl<2.3.0,>=2.2.0 (from sslyze==2.1.4) (from versions: 0.13.4.win32, 0.13.1, 0.13.2, 0.13.4, 0.13.5, 0.13.6, 0.13.7, 0.14.0, 0.14.1, 0.14.2, 0.15.0, 0.15.1, 0.16.0, 0.16.1, 0.16.2, 0.16.3, 0.17.0, 1.0.1, 1.0.2, 1.0.3)
ERROR: No matching distribution found for nassl<2.3.0,>=2.2.0 (from sslyze==2.1.4)
==> ERROR: A failure occurred in package().
    Aborting...
:: Unable to build sslyze - makepkg exited with code: 4

Thank you so much @Bevan!

Thanks to your answer I could see that my system was running pip2 by default, I just changed it and I could update sslyze.

Could you try building the package without yay (as described on https://wiki.archlinux.org/index.php/Arch_User_Repository#Installing_packages)?

If that does not work, please post the output of

• /usr/bin/pip --version
• head -n1 /usr/bin/pip
• pip list --user

Btw: I just updated the package to 2.1.3.

Hi @Bevan! Thank you for your answer. I haven't change my python configuration and if I remember well Arch runs Python 3 by default, I've checked the commands you said in case that any software did the change:

• which python:

  /usr/bin/python

• pacman -Qo $(which python):

  /usr/bin/python is owned by python 3.7.3-1

• python --version:

  Python 3.7.3

surrealistic: On first glance, this looks to me like setup.py is executed by python 2 instead of python 3 (there indeed the open() function had no encoding keyword). Do you have configured your system somehow that python 2 is the default?

If nothing comes to your mind, could you please run the following three commands and post their output here?

• which python
• pacman -Qo $(which python)
• python --version