Versioning/Publishing of NetExec releases

[shaaati]

I know that it is advised to use nxc main branch for most use cases and that one of the main reasons for doing releases is to get new code into Linux distributions.

I am fine with this and ignore releases most of the time.

However, the most recent security issue shows a weakness of this approach imho. Because so much happened in main since the last release of 1.5.0, the patch release 1.5.1 isn't really a release that just fixes a security bug, but also contains several features.

Again, as I am mostly using main I don't really care about releases, but I feel that this must be pretty confusing for regular users that aren't that close with the project.

I don't know really know how this could be fixed though.

Option 1, just backporting the security issue to 1.5.0 and calling this release 1.5.1 would miss out on cool stuff that happened in the meantime, but would highlight the fact, that an important bug has been changed (clearly indicated by increasing the third number of the release version).

Option 2, calling this release 1.6.0 would more clearly show that there are functional changes as well. As a downside, it would be less clear that a (security) bug has been fixed. And if every bug fix would lead to a new minor release what is the benefit of using semantic versioning anyway?

I guess this could start a broader discussion about releases in general. What holds you back from pushing releases more often, allowing Linux distributions to more regularly pick up on the new stuff? Is it the added overhead of writing release notes?

I guess whatever you do, just don't end up like responder, which (accidentally?) introduced a fourth version digit some time in the past and is now stuck with it 😜

[Marshall-Hallenbeck]

Yeah you're right that if we followed semvar 100% it should have been 1.6 since it was more than just a small patch, but we've been keeping minor releases as our "big" releases, so it felt weird to do that.

This all comes down to the fact that it takes a lot of work to do a full release. Dependency changes require a lot of testing and working with the Kali team to make sure its not completely breaking, and the release cycle for Kali can take quite a while (I'm impressed how quickly they got the security patch out, but that might be due to zero dependency changes and the fact that it was a security patch).

If you haven't noticed, the 1.5 release notes haven't been done because we've historically done them by hand (@NeffIsBack does them these days, and it takes a long time). Him and I were just talking and I'm going to see if using AI can assist with that, which would cut down the overall time to release minor versions.

Personally I would love to see something like monthly minor releases, or maybe every 3 months instead of 6-8 months like we have (still better than the year+ of CME lol), but all of us do this in our free time, so life comes up and gets in the way.

[NeffIsBack]

However, the most recent security issue shows a weakness of this approach imho. Because so much happened in main since the last release of 1.5.0, the patch release 1.5.1 isn't really a release that just fixes a security bug, but also contains several features.

There hasn't happened much since the last release, so a full released wouldn't have been justified (as @Marshall-Hallenbeck said).

The solution is simple:

• Security issues should be applied directly to the last release instead of the HEAD of main: checkout 1.5.0, apply patch, release 1.5.1
• For the last release (1.5.1) it's fine to leave it as is, due to the low amount of changes. We will just do a full diff between 1.5.0 and 1.6.0 in the next release.

I guess this could start a broader discussion about releases in general. What holds you back from pushing releases more often, allowing Linux distributions to more regularly pick up on the new stuff? Is it the added overhead of writing release notes?

Yep definitely and as @Marshall-Hallenbeck said also all the background process is exhausting and time consuming. Releases take 2-3 full 8h days most of the time and add (imo) very little value to the project, besides publicity and updates to kali. That is the reason why the release cycle has stretched to >6 months now.

However, as you told me some time ago you would like to contribute, feel free to help me out with the patch notes. That could definitely increase the amount of releases.

[NeffIsBack]

Forgot to answer the question what takes so long when doing releases, so here is the list that has to be done to get a version out:

• Prepare dependency changes for the update to kali
• Make changes to the project (think of a release name, bump version in the python code, do the PR)
• Prepare the GitHub release notes (going through the PRs, check the title and explain a what has happened in more important PRs)
• Do social media posts
• Notify kali about the new release including the dependencies that have to be updated
• Write the feature rundown for the wiki

[shaaati]

First of all, I fully get the "we do it in our free time" argument. I wish I had a company big enough to sponsor a bit of your work.

Second: I deeply dislike this weird GitHub discussions thread feature because it makes it super hard to respond to multiple things at the same time 😛 .

As we got this out of the way, I'd like to say that I have no expectations of any kind. I just have this abstract feeling that nxc versioning "doesn't feel right". And I don't even know why I care, because I could just plainly use main (which I am doing btw. After all, @NeffIsBack maintains the update script that we use on our Kali pentest image 😛 ).

I have the impression that if a software offers releases, there is some expectation of "the public" about their meaning. Part of my feeling could come from the fact that I often see people asking for a specific feature they can't find, in a response to LinkedIn, X or some other post. Which is always because these people use the packaged version of their OS, no matter how prominently you advertise other preferred installation methods.

Anyway, I digress.
Alex' response makes me realize that you hold yourself up to a very high standard for what is essentially a "minor" version upgrade in SemVer terms.

I get the dependency stuff and that might very well be a pain point that one cannot easily fix. For the other arguments I'd like to add a few thoughts:

• does every release need a fancy version name?
• the more often you make smaller releases, the less complex GitHub release notes should become (might be naive thinking)
• does every minor release need a full-blown social media post? You post about notable PRs anyway in most cases.
• does every minor release need a full-blown Wiki feature rundown?

The amount of work that you put into a release doesn't really match what I would expect for a "minor" release.

One idea could be to reserve these tasks for "major" releases that could happen every once in a while. One could even argue that (almost) every PR could lead to a new minor version. You would then likely end up with something like the Linux kernel, where no individual release seems to be disruptive enough to warrant a new major version, but at some point the minor version number just gets annoyingly big.

Maybe changing dependency versions could be reserved for these major versions? That would give them a true meaning because they actually result in "breaking" changes. On the other hand this might mean holding some cool features back until the next major release.

Other software projects (e.g., Ubuntu, Kali), do release numbers based on dates instead of features, which is another option. Such numbers hold less implicit meaning about how much has changed in the meantime.

The more I think and write about this the more I get why there's also projects that just number their releases incrementally, or use the latest git commit hash as version. It's pretty damn complex 😅.

[NeffIsBack]

Second: I deeply dislike this weird GitHub discussions thread feature because it makes it super hard to respond to multiple things at the same time 😛 .

You can manually cite sentences by prepending > to the line. But yeah, not ideal

I get the dependency stuff and that might very well be a pain point that one cannot easily fix. For the other arguments I'd like to add a few thoughts:

• does every release need a fancy version name?

It does not NEED one, but it would be said to drop that tradition. Also, that's one of the tasks that can also easily distributed to the community (in the past i have sometimes just asked on the discord for example).

• the more often you make smaller releases, the less complex GitHub release notes should become (might be naive thinking)

It doesn't really make it less complex (or at least less time consuming) because you still have to go through nearly every single contribution to check what had been done. If this happens multiple times in smaller releases or one time in a bigger release doesn't change the amount. It increases the amount of work tho because of the general overhead of doing a release -> more releases means more work.

• does every minor release need a full-blown social media post? You post about notable PRs anyway in most cases.

Not necessarily, but when you already do a release then imo you should also notify people. That is at least the fun part about doing a release: people engaging and being excited about cool new stuff (on kali for example).

• does every minor release need a full-blown Wiki feature rundown?

No, but what's the point of doing a release when nobody knows what have changed. I always enjoyed reading release notes back in cme times when I didn't have to write them and I want to continue that for others. Also, I really hate it when companies put out new versions and just publish a "we did stuff" patch notes, without properly explaining what has been done.

But yes, this part is the most flexible one and the one i delay the most when i don't have the time to work on them (as currently happening for example). However, this is also the part where the load could probably be distributed most easily. For example, in the past @termanix often helped by creating a first draft on which I build upon to create the rundown. If anyone (including you @shaaati) is willing to help out with that, feel free to chime in.

The amount of work that you put into a release doesn't really match what I would expect for a "minor" release.

One idea could be to reserve these tasks for "major" releases that could happen every once in a while. One could even argue that (almost) every PR could lead to a new minor version. You would then likely end up with something like the Linux kernel, where no individual release seems to be disruptive enough to warrant a new major version, but at some point the minor version number just gets annoyingly big.

The way we have done it so far and I think that is a good approach is:

• Major versions are for breaking changes or major reworks, of which none have happened yet. I would probably do a major release if we either remove deprecated functionality and/or do major other works that justify such a release (merging/removing/adding protocols or deeply change the behaviour of nxc/nxcdb.
• Minor versions are for continues work including new features that doesn't break existing functionalities. Basically day-to-day work/improvements such as smaller protocols, modules, proto flags etc.
• Bug/patch versions for something like security issues or critical bugs. So far nearly none have happened and often the solution is to apply the patches to the kali version manually (which results in a new apt version btw) and simply merging them into main.

At the end of the day it doesn't matter how you call them. The work remains the same if called a "major" or "minor" version release. We have just opted for doing normal version bumps with minor version changes.

Maybe changing dependency versions could be reserved for these major versions? That would give them a true meaning because they actually result in "breaking" changes. On the other hand this might mean holding some cool features back until the next major release.

Checking and updating dependencies is not done out of fun :D These are required changes due to new features or bug fixes, so either you do a release with new features and upgrade dependencies or you don't. Again, the releases we do are your version of "major" releases and therefore simply require updates to the dependencies. E.g. here is a excerpt of the changes required for the last release (exluding simple version bumps for misc tools). See the kali issue for the release:

• PyNfsClient must be upgraded to v1.0.5. I thought that was automated with the cli that would pick new version tags from github, but it seems like this is not the case. Repo link: https://github.com/Pennyw0rth/NfsClient
• Impacket must be upgraded to commit 8925c2ce4657a5cecd57c2d0b08acb846d94c236
• Certipy must be patched so that the following commit is included: ly4k/Certipy@94c910d. This is due to a formatting when using certipy as lib inside of NetExec (module certipy-find), see: Allow python 3.10 and call print function for each line ly4k/Certipy#312

---

TLDR; Pretty much all of this can be summed up in the following gist: I don't think there is a structural problem of doing the releases. Releases just mean there is work to be done which costs time and energy. If we/you would like to have more frequent releases the workload must be distributed (because I don't have endless amounts of time). Other options would be to either work less on new features/PRs or strip down the quality of a release, none of which I am a fan of, either do it properly or don't do it at all. If the full workload remains my workload, new releases will likely happen in a frequency of 6-9 months, which imo is totally fine.