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.

AsamK, thank you for the updated PKGBUILD! I tweaked it a bit and uploaded it. I started working on it based on ajs124's comment, so I tried to update the sslyze PKGBUILD and build a nassl package but after a lot of debugging and patching it still wouldn't build and it all got backlogged :/

Here's a version of the PKGBUILD file that deals better with both architectures: pkgname='sslyze' pkgver=0.10 pkgrel=1 pkgdesc="Fast and full-featured SSL scanner." arch=('i686' 'x86_64') url=('https://github.com/nabla-c0d3/sslyze') license=('GPLv2') depends=('python2') source_i686=("https://github.com/nabla-c0d3/sslyze/releases/download/release-${pkgver}/${pkgname}-${pkgver/./_}-linux32.zip") source_x86_64=("https://github.com/nabla-c0d3/sslyze/releases/download/release-${pkgver}/${pkgname}-${pkgver/./_}-linux64.zip") sha1sums_i686=('d9ed490681d44c4c9d69a03ecb0bf4283c0de7c1') sha1sums_x86_64=('5b17aee4802f3c4bbc74b8e10f131522a4dbb320') prepare() { find $srcdir/$pkgname/ -type d -exec chmod 755 {} + } package() { # Install files in /opt mkdir -p "$pkgdir/opt/sslyze" cp -a $srcdir/${pkgname}/. $pkgdir/opt/sslyze find $pkgdir/opt/sslyze -name '*.py' -print0 | xargs -0 sed -i 's/env python/env python2/g' # Create an indirect launcher in /usr/bin mkdir -p "$pkgdir/usr/bin" cat > "$pkgdir/usr/bin/sslyze" << EOF #!/bin/bash cd /opt/sslyze && python2 sslyze.py \$@ EOF chmod 755 "$pkgdir/usr/bin/sslyze" }

There are quite some things wrong with this pkgbuild. Why does it download the binaries for both architecture? Pacman can deal with that very nicely, now [1]. And why binaries in the first place? This package isn't called sslyze-bin… I know they use nassl, but that's open-source too, so why not create a package for that and depend on it? unzip isn't necessary either, bsdtar can deal with zips. [1]: http://allanmcrae.com/2014/12/pacman-4-2-released/

@azrdev: sslyze uses its own OpenSSL wrapper (nassl), which is in a different, untagged git repo. I don't want to make a tagged PKGBUILD depend on an untagged git repo. Pre-compiled packages are now different for x86 and x86_64, and due to dropbox url management, distributed on two different urls. I'm giving up. If someone wants to adopt this package, I suggest to create an sslyze-git one, depending on a to-be created nassl-git one.

Why via dropbox? Github can zip the whole repo for us, you could as well do a simple git clone.

Updated to version 0.6. This tool is now distributed via dropbox (cf. http://nabla-c0d3.blogspot.fr/2013/01/sslyze-v06.html)