Publish to PyPI

[webknjaz]

Hello, it doesn't seem like anybody brought this up in the future, but would you be open in publishing this to PyPI so that after a simple pip install, the scripts would be invokeable? I'll be happy to contribute packaging and GHA automations for this as well as looking into unifying the CLI required for this to function. This would allow people to use it, without having to jump through the hoops of executing several commands to set up the environment in an out-of-standard manner. My motivation is that eventually it'd be nice to be able to integrate this into testing of web frameworks (I maintain CherryPy, Cheroot and aiohttp, for example).

[tomato42]

I'm not against the concept, the issue is that we have quite a few tools that need to be accessible after installation (combine.py, extract.py, analysis.py,...) and a lot of test scripts. Installing them into general PATH could easily be considered "polluting". while having simple tlsfuzzer combine as a wrapper that calls into combine.py would be rather easy to do, 95% of the worth of the projects is what's in scripts/.

How to make execution and discovery of those (you know, with tab-completion) easy is not something I have any experience with. Combine it with basically all of my focus for the past 4 years going towards Marvin Attack and yeah, such niceties are not stuff I end up working on.

That being said, if you have an idea how to solve all of it in a general way (one that won't require any, or at most, very little changes to scripts) I'm fully open to discussing it, and once we agree on solution, reviewing the PR and getting it merged.

[webknjaz]

So there are several ways this can be interfaced:

• exposing scripts through runpy: it's invocable via python -m tslfuzzer.combine
• exposing them as console-scripts prefixed with tlsfuzzer- would make for invocations like tlsfuzzer-combine
• and finally, one console-script tlsfuzzer with subcommands — so tslfuzzer combine would be the interface

All of above can be implemented and combined, of course. And it wouldn't pollute $PATH since everything would be auto-completed the same way. And in all cases, using any library for argument parsing would work. The second way should work exactly the same as it is now in terms of the arg completion.

As for the argparsing/CLI libs, the modern stdlib way is using argparse. And known third parties are Click and Typer. The Python 2.6 requirement has its limitations, though.

[tomato42]

ok, but this solves the issue of tools, it doesn't solve the issue for scripts.

yes, py2.6 is a limitation, and I'd rather not introduce additional dependencies: as the project is now, it and all dependencies can be put in a single tarball that requires just the python executable to execute

[webknjaz]

ok, but this solves the issue of tools, it doesn't solve the issue for scripts.

What do you mean? I thought I was talking about the scripts.

[webknjaz]

yes, py2.6 is a limitation, and I'd rather not introduce additional dependencies: as the project is now, it and all dependencies can be put in a single tarball that requires just the python executable to execute

What do you mean by that? Pure-python deps?

[tomato42]

What do you mean? I thought I was talking about the scripts.

by "scripts" I mean the files that live in scripts/ directory, they can't be loaded as modules, they have to be executed as standalone applications

by "tools" I mean the specific modules in the tlsfuzzer/ directory that can be loaded either as a module, or executed as standalone applications. Those should already work with runpy, so stuff like python -m tlsfuzzer.extract --help should work.

What do you mean by that? Pure-python deps?

for python-ecdsa and tlslite-ng (the only mandatory dependencies) to work, it's enough to do a symlink to the ecdsa and tlslite directory respectively from the tlsfuzzer repo checkout, then nothing needs to be installed on the system to run the scripts (with the exception of timing scripts). When working with old python releases (2.6, 2.7), that's a really convenient feature to have as pythons this old don't ship with pip by default and installing pip now on py2.6 is non-trivial. Old python compat is also the reason why I use getopt instead of argparse.