Hello Logan,
Hope all is well on your side. Wanted to start a separate discussion on something downstream-facing that came up recently.
Context
I opened a discussion on the NetExec repo proposing to add ADWS as a first-class protocol, leveraging SOAPy as the wire-level implementation. The maintainer was positive about the idea but suggested the cleanest path is either using SOAPy directly as a dependency (rather than vendoring) or upstreaming the protocol into impacket.
Their exact words: "We could also use SOAPy directly if that is the best option (I don't have anything against adding additional dependencies per se)."
What I'd like to discuss
For NetExec to depend on SOAPy directly, it would help a lot to have it on PyPI as a stable package. Right now pipx install from git works fine for operators but creates friction for downstream tools (NetExec, certipy, potentially others) that would want a regular dependency declaration.
Would you be open to:
-
Publishing SOAPy on PyPI as a stable package?
-
Sharing the maintenance load if it helps , I'd be happy to take on the packaging plumbing (PyPI release flow, CI, version pinning) since I'd be one of the first downstream consumers anyway. You stay the lead/owner of course.
-
Picking a PyPI name; soapy is taken (astronomy lib), so we'd need an alternative. A few ideas:
soapy-adws
pyadws
adws-py
Open to whatever you prefer.
Side benefit
This would also let me drop the SOAPy vendoring from Soaphound.py, so it's not just about NetExec , the broader Linux offensive AD toolchain benefits.
Status
Totally understand if you don't have bandwidth or interest right now. I'll explore the other options on the NetExec side (as you mentioned, either impacket upstream or a native port with clear separation). I guess you are working on an Impacket integration.. That said, I still believe PyPI would be the cleanest and fastest path, both for NetExec and for SOAPy's reach.
Happy to keep this here or move to DM if easier.
Cheers,
Hello Logan,
Hope all is well on your side. Wanted to start a separate discussion on something downstream-facing that came up recently.
Context
I opened a discussion on the NetExec repo proposing to add ADWS as a first-class protocol, leveraging SOAPy as the wire-level implementation. The maintainer was positive about the idea but suggested the cleanest path is either using SOAPy directly as a dependency (rather than vendoring) or upstreaming the protocol into impacket.
Their exact words: "We could also use SOAPy directly if that is the best option (I don't have anything against adding additional dependencies per se)."
What I'd like to discuss
For NetExec to depend on SOAPy directly, it would help a lot to have it on PyPI as a stable package. Right now
pipx installfrom git works fine for operators but creates friction for downstream tools (NetExec, certipy, potentially others) that would want a regular dependency declaration.Would you be open to:
Publishing SOAPy on PyPI as a stable package?
Sharing the maintenance load if it helps , I'd be happy to take on the packaging plumbing (PyPI release flow, CI, version pinning) since I'd be one of the first downstream consumers anyway. You stay the lead/owner of course.
Picking a PyPI name;
soapyis taken (astronomy lib), so we'd need an alternative. A few ideas:soapy-adwspyadwsadws-pyOpen to whatever you prefer.
Side benefit
This would also let me drop the SOAPy vendoring from
Soaphound.py, so it's not just about NetExec , the broader Linux offensive AD toolchain benefits.Status
Totally understand if you don't have bandwidth or interest right now. I'll explore the other options on the NetExec side (as you mentioned, either impacket upstream or a native port with clear separation). I guess you are working on an Impacket integration.. That said, I still believe PyPI would be the cleanest and fastest path, both for NetExec and for SOAPy's reach.
Happy to keep this here or move to DM if easier.
Cheers,