The sslscan port does not work when the security/openssl port is compiled without support for SSLv2. This is a new (and very useful) feature of openssl. Running sslscan yields the following error: /usr/local/bin/sslscan: Undefined symbol "SSLv2_client_method" Rebuilding the sslscan port fails when SSLv2 support is turned off. There might be other affected ports. Once sslscan didn't work, I rolled back to openssl with SSLv2 support compiled in and have not continued testing.
Notifying maintainer of sslscan. The comment about "could affect other ports" will be lost as the maintainer of sslscan can't do anything about that.
I emailed the maintainer before making the bug report and got no response. Should I create a report for openssl saying the change could affect other ports that depend on it? It would be more high profile, but again I don't think maintainers of those other ports would necessarily notice, and it's not the openssl maintainer's fault, is it? Spamming every port that uses openssl and might have a problem doesn't really sound useful either.
Leif, I'd suggest opening an issue report specifically for security/openssl, proposing at least an update to the SSLv2 OPTION description, perhaps warning the user that it may break dependent ports. If it were me, I'd also report the issue to sslscan authors, to get support for the lack of SSLv2 upstream. Ultimately I believe these kinds of issues will become more prevalent and upstream projects will end up needing to support it in the long term. You're right in your assessment that creating in-advance issues here for every port that is affected is probably a bit too much at the moment. In the meantime, let's try our best to nip as much of it in the bud at the root as we can (security/openssl)
Thanks for the suggestions. I did my best to contact the original authors (I hope the addresses I found are still valid) and I added a bugzilla entry for security/openssl here: <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193482> Hope it helps!
I contacted the original author and he is no longer working on sslscan. He suggested that the version that has the best chance of being maintained is https://github.com/ioerror/sslscan or any of the forked projects. Hope that's helpful.
Fixed in bug #198401 changeset 382059