rbsec
Refactor the codebase
While I've been working to revamp the codebase for OpenSSL 3.0 (which actually works up to OpenSSL 3.4 as well), there are some opportunities to refactor the codebase to reduce copy/pastes and abstract some of the OpenSSL pieces a bit further. Chugging in a nearly 6k lines in sslscan.c, it might also serve to break it apart into multiple files as well. @rbsec, If I were to undertake that effort, would there be objection to accepting that? I would of course be open to any review and feedback on the approach, but I want to ask before I sink some effort into it. Thanks!
Chugging in a nearly 6k lines in sslscan.c, it might also serve to break it apart into multiple files as well.
In that case, it would be very well worth it to get a Docker test environment working. That way you can test your changes in pieces vs. find out at the very end that everything is broken.
A standard Ubuntu VM that you install Docker on might be the easiest path for you.
The fact that sslscan is largely comprised of a single ~6k line file of C is....not ideal. I think it was ~2k lines when I first started doing stuff with it a decade ago, and it's just slowly grown since then. The code is pretty messy in places, and I'm sure there are endless ways that it could be improved. I make no claims to be good developer of any kind, and certainly not a good C developer.
As you've probably noticed, sslscan isn't really a project that I have much time for nowadays (and to be blunt, I don't have a huge amount of motivation to focus on it) - hence why a lot of the improvements in recent years have been from jtesta who's done some fantastic work on it.
I have thought in the past about trying to clean up the codebase, but I'm reluctant to start on a major undertaking with it, and I'm also unsure about whether it's really worth trying to invest too much time and effort in it - because if I was going to write something like this from scratch then C probably wouldn't be the language I'd choose, as it just make many things so much harder than they should be (just look at the argument parsing or XML output code, for instance). But then there are some advantages of a tool that can be statically compiled (and cross-compiled for Windows) without needing something like a Python runtime.
Anyway, the point I'm meandering around is that I'm very happy to accept those kind of improvements as long as they're not breaking the existing Linux (and probably Windows) build - but it's not really something that I have a huge amount of time to contribute to. And I certainly wouldn't blame you if you decide it would be a better use of time to write a new scanning tool from scratch rather than trying to clean up several decades of legacy code.
