The latest fork and stewardship of sslscan now lives here: https://github.com/dinotools/sslscan Reproducible: Always
(In reply to Jason A. Donenfeld from comment #0) > The latest fork and stewardship of sslscan now lives here: > https://github.com/dinotools/sslscan I suggest you cherry-pick the patches you want from there and propose them here. Both the original homepage and the SF page are still up and pointing the ebuilds at random forks is, er, random. What problem are you trying to solve?
+1 on switching to the dinotools fork. The original upstream at SF has not had a release in almost 6 years, and no patches in its SVN in almost 5 years. The link on the SF project page to the original author's page redirects to their generic company home page (N.B. maybe that is what it always did). Current dinotools fork includes STARTTLS support for multiple protocols (not just smtp), adds TLSv1.1 and TLSv1.2, adds checking for heartbleed, and has improved python version / platform support. Pretty extensive improvements. A diff -urP of sslscan-1.8.2 sslscan.git is twice the size of the original sslscan-1.8.2 tree.
Created attachment 400798 [details] Ebuild for the current git commit of DinoTools fork of sslscan
Created attachment 400800 [details, diff] Make python modules respect DESTDIR, fixing a sandbox violation This has been submitted upstream, but is needed for sslscan-1.10.3_pre20140626.
I've sent email to Ian, the original sslscan author, to clarify the current status.
(In reply to Hans de Graaff from comment #5) > I've sent email to Ian, the original sslscan author, to clarify the current > status. And he has indicated that he expects a new version to be release in month or so, so I'd rather wait for this version.
Given it has now been over 4 months perhaps we should give up and go with the dinotools version. If you feel you have to keep it perhaps we could use a different name?
The latest version in the tree fails to build with openssl-1.0.2g. /var/tmp/portage/net-analyzer/sslscan-1.8.2/temp/ccRntSZR.o: In function `testCipher': sslscan.c:(.text+0xbe2): undefined reference to `SSLv2_client_method' /var/tmp/portage/net-analyzer/sslscan-1.8.2/temp/ccRntSZR.o: In function `defaultCipher': sslscan.c:(.text+0x120d): undefined reference to `SSLv2_client_method' /var/tmp/portage/net-analyzer/sslscan-1.8.2/temp/ccRntSZR.o: In function `testHost': sslscan.c:(.text+0x21db): undefined reference to `SSLv2_client_method' sslscan.c:(.text+0x221b): undefined reference to `SSLv2_client_method' /var/tmp/portage/net-analyzer/sslscan-1.8.2/temp/ccRntSZR.o: In function `main': sslscan.c:(.text.startup+0x7c0): undefined reference to `SSLv2_client_method' /var/tmp/portage/net-analyzer/sslscan-1.8.2/temp/ccRntSZR.o:sslscan.c:(.text.startup+0xa0c): more undefined references to `SSLv2_client_method' follow collect2: error: ld returned 1 exit status
It has now been 6.5 years since the last release by upstream, and almost a year since the comments that a new release was imminent. Meanwhile sslscan appears pretty actively curated and developed here: https://github.com/rbsec/sslscan (note this seems to have "overtaken" the dinotools repo that myself and others had preferred a year ago). I'll attach an ebuild that uses that github repo. It builds fine against OpenSSL 1.0.2g, both without ssl2 support (the default) and with ssl2 support forced on (see bug #575548#c12).
Created attachment 427180 [details] Ebuild against the latest commit of a curated sslscan upstream.
Hey Hank. I think I might just take over this ebuild since Hans is pretty out to lunch here... The ebuild you attached is against a git revision. It looks like rbsec also has put out some releases, but not since September. Could you ping them and see if they'll make a new release for us, submit an ebuild, and then I'll put that in the tree?
It's about darn time: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a6462fc374341d9795e0e397989d81cdab588740 DONE.
Awesome, thank you!
