calebstewart / pwncat

Fancy reverse and bind shell handler
https://pwncat.readthedocs.io
MIT License
2.63k stars 258 forks source link

avoid conflict: consider renaming the project space and main binary #177

Closed anthraxx closed 2 years ago

anthraxx commented 3 years ago

Is the feature related to a problem? Please describe.

As you may be aware, there is already a pwncat software which has already been packaged in multiple distros hence the other software blocks the namespace as well as the binaries. Forcing people to use a virtualenv instead of allowing easy installation via a package manager seems to be a shortcoming instead of a solution.

https://github.com/cytopia/pwncat https://pypi.org/project/pwncat/

This other software is already the single owner of the pwncat package space across those distros: https://repology.org/project/pwncat/versions

Feature Description

A perfect solution, as painful as it may sound, would be to rename the repository (github creates auto redirects) as well as rename the main pwncat binary to something that is not yet packaged in distros and pypi. It would be in my humble opinion very healthy for this awesome project top be able to get easily installed via various package managers across distros and Kali etc hence a rename would have more gain as disadvantages. A unique name will also make sure this software is found uniformly across different installation paths.

Potentially simply use pwncats? :smile_cat:

Thank you very much for your consideration. I know how painful this may sound, but I am a package maintainer and unfortunately I now can't as much as i would love to package this piece of software.

cheers :smile_cat:

Mitul16 commented 3 years ago

I think Caleb is registering pwncat-cs on PyPi and migrating to poetry See https://github.com/calebstewart/pwncat/pull/149

anthraxx commented 3 years ago

I think Caleb is registering pwncat-cs on PyPi and migrating to poetry See #149

Yes I've seen the pypi commit but that doesn't really resolve the issue so far. The best would be if the project has the same name as well as the binary. This would solve that this project has a uniform name across distros that package it. The unique binary is a pre requirement for any packaging tho.

pwncat-cs would also be possible for the repo/project as well as the binary. I frankly just try to get this distributed and try to propose some ideas as help :cat:

calebstewart commented 3 years ago

As @Mitul16 had mentioned, I had intended to push the package to PyPI under pwncat-cs. I know that's not ideal, but it was the best I could come up with.

I don't have an issue necessarily in changing the name, but I hadn't thought of anything that would be much better at this point.

What are peoples' thoughts on leaving the Python module name as pwncat but changing the entrypoint script name? The reason I ask is that:

  1. Cytopia's pwncat project is not actually a Python module. It's simply a script you can execute. There's no importable module (that I'm aware of or have seen).
  2. My pwncat project is specifically designed to be an importable module with the intent that users could embed it within their own exploit scripts.

I think pwncats could still be rather confusing, even if it does prevent naming conflicts when installed globally. pcat or pwncat-cs I think could be possible new names for the entrypoint(s), if people are okay with that.

In Summary

There's two problems:

The first problem should be solved by v0.5.0 with the change to pwncat-cs as the package name. The second problem could be solved by changing the entrypoint to pwncat-cs as well. I find this cumbersome to type/read, but that is augmented by the alternative names of pcat and pc, so I'm okay with it personally. It's unfortunate, but acceptable I suppose.

There's also the non-problem (imho) of the package name as imported from an external script. This does not have to match the PyPI package name, and in fact it can't if we go with pwncat-cs (since dashes aren't allowed). Because Ctyopia's pwncat doesn't implement an importable module at all, I don't think this is an issue and we can leave that python package name as is.

Does anyone have any opinions about the above? Positive or negative; I'm not offended, haha.

anthraxx commented 3 years ago

What are peoples' thoughts on leaving the Python module name as pwncat but changing the entrypoint script name? The reason I ask is that:

  1. Cytopia's pwncat project is not actually a Python module. It's simply a script you can execute. There's no importable module (that I'm aware of or have seen).
  2. My pwncat project is specifically designed to be an importable module with the intent that users could embed it within their own exploit scripts.

Could work for now, at least that would currently bring me one step closer to package it for the distro. However, fingers crossed if this remains like that and Cytopia's doesn't modularize it, that would become hack of a nightmare :cat2:

In Summary

There's two problems:

  • The PyPI package name.
  • The entrypoint names (currently installed as pwncat, pcat and pc; of which pwncat conflicts).

The first problem should be solved by v0.5.0 with the change to pwncat-cs as the package name. The second problem could be solved by changing the entrypoint to pwncat-cs as well. I find this cumbersome to type/read, but that is augmented by the alternative names of pcat and pc, so I'm okay with it personally. It's unfortunate, but acceptable I suppose.

Technically there are tree problems, two letter binaries nowadays are nearly always a bad idea. Sadly pc is already used across distros as well. pcat seems to not be used: https://repology.org/project/profile-cleaner/versions

Does anyone have any opinions about the above? Positive or negative; I'm not offended, haha.

I would still rename the repo to whatever you would like the distros to name their packages for your version. Like rename the repo to pwncat-cs as well f.e. So I think the best for now would be:

  1. rename the repository
  2. rename pwncat binary
  3. get rid of pc as pcat looks short enough

Thank you very much for openly discussing solutions. I'm very happily looking forward to be the first distro that packages this awesome tool.

calebstewart commented 3 years ago

Totally on board for renaming the repository. That's not an issue, but I don't think I will do that until v0.5.0 is ready for release and/or released. In my mind, that just makes the most sense (making a hard switch will be less confusing as opposed to a gradual change).

Regarding short binary names, I totally get that, and I'm fine with dropping pc. Those names were originally chosen to mirror the various forms of netcat, but that's obviously not a priority. Further, I don't think many people use them. Based on another issue, I think pcat might have actually gotten accidentally dropped from setup.py during a previous cleanup merge, but that's super easy to drop back in if we decide that it's useful/good.

I'm not sure if you're a Python developer or not (trying not to make assumptions here), but any recommendations on module naming scheme if we wanted to make a hard distinction between us and a possible future Cytopia module? We could make the name pwncat_cs which would be a valid Python module name. Underscores just feel aesthetically displeasing to my brain for module/library names when coding or interacting with applications.

Frankly, this entire conversation is based on aesthetics. In my mind, an ideal name (both binary and package name) is somewhere around 6-10 letters long with no dashes or underscores. That's normally long enough to convey uniqueness and/or purpose but still short enough to not be frustrating to type without tab-completion.

If I'm being honest with myself, there's nothing tying me to any form of the name pwncat at all. If people have other suggestions that are completely unrelated, I'm open to them. Making a big change like that now rather than later is probably good anyway.

Thank you very much for openly discussing solutions. I'm very happily looking forward to be the first distro that packages this awesome tool.

No problem, and thank you for bringing it up! If something is open source, it's for the community. I'm open to whatever is feasible and will help the community! :+1:

calebstewart commented 2 years ago

I just released v0.5.0 which renames the package to pwncat-cs, removes the pcat and pc entrypoints, and renames the entrypoint to pwncat-cs. This should resolve this naming conflict. For more details, see the Release Notes.