Switch to terminaltables3

[elboulangero]

From terminaltables3 README:

[terminaltables3] is a fork of the terminaltables project. Which is
archived and unmaintained. This library is in a new namespace but should
otherwise be a drop in replacement. Maintaining goals consist of
maintaining ecosystem compatibility, type annotations and responding to
community pull requests.

Debian has removed the old terminaltables projects and only provides terminaltables3 now (in next release Debian 14 forky, which is currently Debian testing). Other distros will probably do the same, or have done it already.

Note: I didn't test the change, and I updated poetry.lock by hand. Probably someone wants to double-check that what I did is correct.

[Marshall-Hallenbeck]

Hey thanks for the PR but if you are going to submit something, please test it before doing so. We have a PR template that you should also follow, and one of those steps is testing it yourself before submitting. I will be marking this as on hold until you can fill out the template and test this change for anything breaking.

[NeffIsBack]

Thanks for the update, gonna check and test it soon!

On a different note, glad that I can catch you here :)
Is there some way I can get in touch with you or someone else on the kali team regarding future releases on NetExec? I think it would really help with stability if I could get in touch with you guys when we prepare for updates. To be clear, I don't want to skip the issue process (I understand that this is important), just having a contact to quickly chat about building, testing and uploading the binaries would be really good to prevent things from breaking several times like in the last update.

[elboulangero]

Is there some way I can get in touch with you or someone else on the kali team regarding future releases on NetExec? I think it would really help with stability if I could get in touch with you guys when we prepare for updates. To be clear, I don't want to skip the issue process (I understand that this is important), just having a contact to quickly chat about building, testing and uploading the binaries would be really good to prevent things from breaking several times like in the last update.

Really the best contact point is https://bugs.kali.org/. The Kali team keeps an eye on the bug tracker daily.

Regarding testing: we can upload new major releases of netexec to kali-experimental if you want. Just remind us, ie. you could open a new bug on bugs.kali.org to notify us of a new release, and ask for it to be uploaded to kali-experimental first.

The purpose of kali-experimental is exactly that: to upload packages that we want to test before rolling it out. However, packages in kali-experimental are not very visible, nor advertised, so it's only people in the loop (eg. NetExec team) that are likely to know about it and test it.

Another thing: when a package is built for Kali, we run unit tests, and tests must pass for the build to succeed.So there's a level of QA there, but it's only as good as your own tests. A good way to increase quality is usually to increase test coverage. At the moment the command we run is python3.13 -m pytest -k 'not test_add_host and not test_update_host'.

[NeffIsBack]

Is there some way I can get in touch with you or someone else on the kali team regarding future releases on NetExec? I think it would really help with stability if I could get in touch with you guys when we prepare for updates. To be clear, I don't want to skip the issue process (I understand that this is important), just having a contact to quickly chat about building, testing and uploading the binaries would be really good to prevent things from breaking several times like in the last update.

Really the best contact point is https://bugs.kali.org/. The Kali team keeps an eye on the bug tracker daily.

If you say so we can continue like that. Just, sometimes the communication over the bug tracker felt sluggish, where things that (felt like) could have been solved with a few instant messages took days or even weeks, resulting in NetExec Kali being update much later than the original release. My goal would be to that kali is ready for the update at approximately the same time as the release is. I know you guys got a lot to do, but were just wondering how to speed things up, like chatting about which dependencies have to be upgraded etc. (I am absolutely happy to feed issues with the TLDR; that has been discussed.)

Regarding testing: we can upload new major releases of netexec to kali-experimental if you want. Just remind us, ie. you could open a new bug on bugs.kali.org to notify us of a new release, and ask for it to be uploaded to kali-experimental first.

The purpose of kali-experimental is exactly that: to upload packages that we want to test before rolling it out. However, packages in kali-experimental are not very visible, nor advertised, so it's only people in the loop (eg. NetExec team) that are likely to know about it and test it.

That sounds good, then i can properly test the binary before it goes live, hopefully preventing stuff like the last few bugs from happening.

Another thing: when a package is built for Kali, we run unit tests, and tests must pass for the build to succeed.So there's a level of QA there, but it's only as good as your own tests. A good way to increase quality is usually to increase test coverage. At the moment the command we run is python3.13 -m pytest -k 'not test_add_host and not test_update_host'.

Oh so you are using the tests in tests/test_smb_database.py from NetExec? Testing is a difficult topic especially with a versatile tool like NetExec. For now, the biggest testing suite we have are the e2e tests which I usually run before doing releases/building the binaries. These cover a lot of execution chains, however requiring a target domain (or service) to be run against. If you want to expand the testing suite we are happy to help/collaborate.

[Marshall-Hallenbeck]

Oh so you are using the tests in tests/test_smb_database.py from NetExec? Testing is a difficult topic especially with a versatile tool like NetExec. For now, the biggest testing suite we have are the e2e tests which I usually run before doing releases/building the binaries. These cover a lot of execution chains, however requiring a target domain (or service) to be run against. If you want to expand the testing suite we are happy to help/collaborate.

I've been looking into the tests and how we can potentially add in unit tests with a bunch of mocking. Might be a lot but I've had decent results with the new Opus 4.6 with writing tests on existing code, so I'm going to play around more with it.

@elboulangero when you run the unit tests, is pytest a requirement?