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.

@goll: As you elaborate, this package is using pip to install nassl, therefore it is actually packaging binaries compiled by upstream. See nassl repository, especially the bin directory. Symlinking /opt/sslyze/sslyze_cli.py to /usr/bin/sslyze works fine for me (see sslyze-git PKGBUILD), apparently no need to package in standard paths here. The advantage clearly is getting rid of an unneeded indirection.

@fabianz: The launcher is still here because pip installs nassl under ./lib and I think it's best it stays in a non-standard path such as /opt. I don't see what advantage would be gained by using a symlink. The last version that had upstream binaries was 0.12. The package is using upstream release tarballs.

The indirect launcher is not needed anymore, as https://github.com/nabla-c0d3/sslyze/pull/65 was merged upstream. Also, I want to humbly ask you to consider modifying this PKGBUILD for a full source build (using upstream release tarballs or git tag checkouts) instead of repackaging upstream binaries (working build code is in sslyze-git package). Otherwise, I want to suggest that this package should be renamed to sslyze-bin, and a proper sslyze package be created.

@hardfalcon: Arch doesn't use sh by default, it's a symlink to bash: $ ls -l /usr/bin/sh lrwxrwxrwx 1 root root 4 Nov 23 21:20 /usr/bin/sh -> bash

Would it be possible to replace #!/usr/bin/bash with #!/bin/sh in the PKGBUILD? The indirect launcher script doesn't use anything that a standard POSIX shell doesn't provide, so bash shouldn't be required.

@luckdragon: Yeah, dissing peoples work that was made available for free and without any warranty surely is the right way to go… Seriously, nobody wasted two hours of your life but yourself. Nobody forced you to use this PKGBUILD. If you decide to use it do it at your own risk and don't blame people who made it available initially. That being said: The issue you reported was valid and the PKGBUILD was changed accordingly. Thanks.

The person who wrote this original package wasted 2 hours of my life that I will never get back now, thanks to a python script I was writing to call sslyze that would not work when adding the --xml option with a relative path. What was the bug? Is the problem with my script? With sslyze? A bug in the python programming language? Nope, none of those. Yes, lets change directories in a shell script silently without warning. That sounds like a brilliant. fucking. idea. Dear maintainer, please update the PKGBUILD to this, so that future people don't have my problem: pkgname='sslyze' pkgver=0.12 pkgrel=2 pkgdesc="Fast and full-featured SSL scanner." arch=('i686' 'x86_64') url=('https://github.com/nabla-c0d3/sslyze') license=('GPL2') 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=('1bb34e313a93c57264171446e0bd6c89cf8828c9') sha1sums_x86_64=('a8f3f7b7b728281611793c380055c027318c4a47') 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 -type f -name '*.py' -print0 | xargs -0 sed -i 's/python/python2/' # Create an indirect launcher in /usr/bin mkdir -p "$pkgdir/usr/bin" cat << EOF > "$pkgdir/usr/bin/sslyze" #!/usr/bin/bash python2 /opt/sslyze/sslyze.py \$@ EOF chmod 755 "$pkgdir/usr/bin/sslyze" }

I just migrated this package to AUR4. If the original maintainer (goll) wants it back I will transfer the ownership back of course. Otherwise I will keep maintaining it.

I just uploaded the package sslyze-git to AUR which manages to compile nassl from source. Since the current releases (v0.10) date back to Sep. 2014, I preferred to create a git package instead. Since nassl has to be identical in version to sslyze and states "Do NOT use for anything serious" on its github page, I refrained from making it a separate package for now. You should nonetheless be able to gain some hints on how to compile nassl from my PKGBUILD in order to use the source release tarballs instead of the binary releases for this package.