Closed anthraxx closed 2 years ago
I think Caleb is registering pwncat-cs
on PyPi and migrating to poetry
See https://github.com/calebstewart/pwncat/pull/149
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:
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:
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). 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.
There's two problems:
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.
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.
What are peoples' thoughts on leaving the Python module name as
pwncat
but changing the entrypoint script name? The reason I ask is that:
- 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).- 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
andpc
; of whichpwncat
conflicts).The first problem should be solved by
v0.5.0
with the change topwncat-cs
as the package name. The second problem could be solved by changing the entrypoint topwncat-cs
as well. I find this cumbersome to type/read, but that is augmented by the alternative names ofpcat
andpc
, 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:
pwncat
binarypc
as pcat
looks short enoughThank you very much for openly discussing solutions. I'm very happily looking forward to be the first distro that packages this awesome tool.
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:
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.
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/versionsFeature 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: