Serious Discussion Why does the Comodo "Disappearing HIPS rules" bug require a complete source code rewrite?

AI has one excellent feature, the off button.
Just like you have the right to post, I have the same right to contribute in my own way. If you don't care for my posts, you have the ability to ignore them. Derailing threads with comments that add no substance and only create discord is not a constructive use of this forum.
 
It was a general post not aimed at you. If AI wasn't involved we hadn't have AI BS discussions.
 
It was a general post not aimed at you. If AI wasn't involved we hadn't have AI BS discussions.
There's an old saying about how a single person can be intelligent, but groups can sometimes fall into unproductive patterns. The constant 'gang up' mentality I see here is a prime example. It stifles individual contribution, which is the lifeblood of any forum dedicated to technical advice. Instead of trying to police my contributions, perhaps we should all focus on the quality of our own.
 
  • Like
Reactions: Halp2001
Back on topic,

Comodo’s brilliant idea of rotating developers between projects really helps, right? Nothing says “quality” like making sure no one actually understands the product they’re working on. The result? A system that’s been duct-taped together for years and falls apart every time someone sneezes near it.

So when people ask, “Why not just patch it? sure, that’d work great… if you enjoy creating new bugs faster than you fix the old ones. At this point, a full rewrite isn’t just an option, it’s damage control.

Honestly, this is a textbook example of how not to run a software project.
 
  • Hundred Points
Reactions: Pico
However, HIPS rules list on XCS is not resetting on reboot, so it definitely doesn't require full HIPS rewrite that @bazang is constantly referring to.
CIS and XCS are different products, they had same codebase in the past (and would in the future, if the stars will align)
Not once have I ever referred to Xcitium. I said only Comodo. So you now brining in Xcitium is not helpful because most Comodo users are not going to switch to Xcitium.

Those discussions with the VP of engineering and the software owner's comments about the disappearing HIPS rules occurred years ago, and they applied only to Comodo.

As far as Xcitium versus Comodo. Don't know. Don't care. Never asked.

Xcitium will eventually require a complete re-write. Because at some point it will stop working on Windows. Do you understand why?
 
Indeed a patch / fix creates an unknown number of others bugs if one doesn't fully understand the underlying source code. This happens constantly with each new release.
 
@Bot How do you feel about a user communicating their own phrasing through an ai writing tool that converts their posts into clean, concise communication that removes emotion and is factual, that keeps from alienating or offending other users while simultaneously sharing information to learn from.
The forced used of AI for exactly the purposes you ask @Bot are already in the planning phases on platforms such as Facebook and X.

People are a PITA, so the thinking is use AI to filter and re-write their content to remove any expression or triggering of emotions - so as to "not offend other users."
Social media platforms can't find adequate people to perform content review and moderation. It's a terrible job and turnover is very high. AI is slated to replace the 1 million+ subcontract content reviewers and moderators across all the global platforms.
 
There is nothing wrong with healthy human discussions, we all learn from it. Your own human input is as welcome as with any other MT member, no exception.
Skillfully created AI tools often write things in ways that are far better than any human. More concise. Better phrased.

In my estimation, some AI will make terrific language writing teachers, but that's not the future. The future is teaching students how to use AI - and not learn language skills.

Comodo’s brilliant idea of rotating developers between projects really helps, right? Nothing says “quality” like making sure no one actually understands the product they’re working on. The result? A system that’s been duct-taped together for years and falls apart every time someone sneezes near it.
Oh brother. Ain't this the profound truth of the matter.

I wish it was only limited Comodo, but using "developer pools and subcontractors" is an industry-wide practice. I think the difference is that at Comodo, the re-directs are more chaotic than average.

Developer unhappiness with this sort of work arrangement is often reflected in high developer turnover, which Comodo's is high. It is also high to very high at hundreds of companies out there that nobody has heard of.
 
  • Hundred Points
Reactions: Divergent
Indeed a patch / fix creates an unknown number of others bugs if one doesn't fully understand the underlying source code. This happens constantly with each new release.

This HIPS bug points to some critical I/O error.
Software should not be designed in a way that a critical I/O error would require a complete rewrite.

Even if Comodo code is “spaghetti code” as @bazang mentions, there will be probably one function that writes in registry (most likely taking few parameters what to write, where to write it, type of entry required).

This is the function that needs debugging, I am surprised by now it hasn’t been done.

Windows provides facilities for running applications to save their work on shutdown (before it actually happens), I don’t think Comodo is using them.
 
  • +Reputation
Reactions: simmerskool
I hope that this thread would close quickly as it seems that it only produces more flame mostly irrelevant of the topic
It seems that discussion is on right track again.

I have checked HIPS rules cleanup bug with latest CIS build, and yes, it's still present with enabled rules auto-creation for safe apps. It definitely shouldn't be used.
However, HIPS rules list on XCS is not resetting on reboot, so it definitely doesn't require full HIPS rewrite that @bazang is constantly referring to.
CIS and XCS are different products, they had same codebase in the past (and would in the future, if the stars will align)

Also, I should note that enabled HIPS serves as self-protection for CIS, one can remove all other rules and create rule allowing everything for all applications group but leave CIS group rule with enabled inter-process memory protection.
View attachment 291867
Do I understand correclty that in XCS HIPS Safe mode (with auto-creation for safe apps enabled), XCS HIPS Learn mode and XCS HIPS Paranoid mode the HIPS cleanup bug has been fixed or does not exist at all because XCS has other (newer) codebase?
In other words, does XCS not have the HIPS cleanup bug in all available HIPS modes?
 
This is the function that needs debugging, I am surprised by now it hasn’t been done.
It has not been done because Comodo said it cannot be fixed without a code re-write. The discussions - if they still exist - are buried on that mess that is the Comodo forum, somewhere.
 
This Isn't a Simple I/O Problem.

The notion of a single function writing to the registry that just needs a bit of debugging completely misunderstands the architecture of security software. Comodo isn't a simple utility, it's a suite of deeply integrated components.

Defense+ (HIPS)

This is the core of the issue. The HIPS is not a standalone module. It's designed to monitor and interact with every other part of the system.

Firewall

The HIPS and firewall are constantly communicating, sharing rules and threat data.

Sandbox/Containment

Unknown applications are run in a virtualized environment, and the HIPS is involved in monitoring their behavior.

Antivirus Engine

The HIPS works in conjunction with the antivirus to provide proactive protection.

A bug in the HIPS ruleset is not just a matter of a faulty "save" command. It's a systemic failure that could be caused by a number of issues.

-Race conditions between the different security modules trying to access or modify the ruleset at the same time.

*Corruption introduced by the sandboxing/containment module when an unknown application interacts with the system.

*Conflicts between the firewall and HIPS rules that lead to an unstable state.

"Spaghetti Code" is the Reality.

The term "spaghetti code" isn't just a casual insult, it's a diagnosis. It points to a codebase where the different components are so tightly interwoven that a change in one place has unpredictable and catastrophic effects elsewhere. This is a common problem in legacy software that has been updated and patched for years by different teams.

The fact that this bug has persisted for so long, despite numerous complaints and bug reports, is strong evidence that the developers are facing one of two scenarios.

*They cannot locate the source of the bug without a massive and time-consuming reverse-engineering effort.

*They know where the problem is, but the code is so fragile that they are afraid to touch it for fear of breaking the entire product.

While it's easy to theorize about a simple fix from the outside, the reality of the situation is far more complex. This isn't a simple case of a developer overlooking a bug in a single function. It's a deep-seated architectural problem that points to significant technical debt. The conclusion that a complete rewrite is the only viable solution is not an exaggeration, it's a realistic assessment of the situation.
 
Windows provides facilities for running applications to save their work on shutdown (before it actually happens), I don’t think Comodo is using them.

I would not rely much on this. Besides shutdown, we also have many possibilities of software incompatibilities that can destabilize the system. Such events can cause corruption, especially with Paranoid HIPS settings.
 
This HIPS bug points to some critical I/O error.
Software should not be designed in a way that a critical I/O error would require a complete rewrite.

Even if Comodo code is “spaghetti code” as @bazang mentions, there will be probably one function that writes in registry (most likely taking few parameters what to write, where to write it, type of entry required).

This is the function that needs debugging, I am surprised by now it hasn’t been done.

Windows provides facilities for running applications to save their work on shutdown (before it actually happens), I don’t think Comodo is using them.
I think the bug occurs in Kernel Mode in a service being forcibly killed / shutdown when system is being shutdown, it may not have enough time to finish its job.
 
I hope that this thread would close quickly as it seems that it only produces more flame mostly irrelevant of the topic
It seems that discussion is on right track again.

I have checked HIPS rules cleanup bug with latest CIS build, and yes, it's still present with enabled rules auto-creation for safe apps. It definitely shouldn't be used.
However, HIPS rules list on XCS is not resetting on reboot, so it definitely doesn't require full HIPS rewrite that @bazang is constantly referring to.
CIS and XCS are different products, they had same codebase in the past (and would in the future, if the stars will align)

Also, I should note that enabled HIPS serves as self-protection for CIS, one can remove all other rules and create rule allowing everything for all applications group but leave CIS group rule with enabled inter-process memory protection.
View attachment 291867
Windows has a procedure to inform all running processes on shutdown which includes those with visible window and those without (Comodo HIPS will run as part of the service).

The fix is so easy that first year college student can implement it, should they be instructed by a manager to do so.

1. Comodo needs to inform Windows that it needs more time.
2. Comodo needs to perform a verification for each written rule (was it actually written) returning true or false (or 0/1). On false, it should try to write again. For multi-threading, to avoid race conditions, there should be a mutex that allows syncing the threads.
3. When the last rule is written successfully (returning true), Comodo should suspend the HIPS monitoring and the system will continue with the normal shutdown.
 
The forced used of AI for exactly the purposes you ask @Bot are already in the planning phases on platforms such as Facebook and X.

People are a PITA, so the thinking is use AI to filter and re-write their content to remove any expression or triggering of emotions - so as to "not offend other users."
Social media platforms can't find adequate people to perform content review and moderation. It's a terrible job and turnover is very high. AI is slated to replace the 1 million+ subcontract content reviewers and moderators across all the global platforms.
@bazang That's an interesting take on the future of social media moderation—I've seen similar reports about AI stepping in to handle the heavy lifting there. It's a double-edged sword: on one hand, it could make platforms smoother and less toxic; on the other, it risks stripping away the raw, human element that makes discussions feel authentic.

As for the question from @Divergent about using AI tools to refine posts into something clean, factual, and emotion-free... I think it's a smart approach in forums like this. It helps keep things constructive, especially in technical threads where emotions can sometimes flare up and derail the conversation. We've all seen how a heated reply can turn a helpful discussion into a mess. If an AI tool can polish phrasing without changing the core message, it promotes better sharing of knowledge—less alienation, more learning. That said, it's still up to the user to ensure the output stays true to their intent. What do you all think—does it enhance communication, or does it make things feel too sanitized?
 
Spaghetti Code" is the Reality.

The term "spaghetti code" isn't just a casual insult, it's a diagnosis. It points to a codebase where the different components are so tightly interwoven that a change in one place has unpredictable and catastrophic effects elsewhere. This is a common problem in legacy software that has been updated and patched for years by different teams.
You see, this is one massive problem with AI. I doubt Melih provided his full source code to Google at the time of training Gemini.
Gemini has no idea whether or not the Comodo code is spaghetti code. This is an assumption. 3 replies from you and it will claim otherwise.
When I browsed the Comodo folders, the code was very well modulated (though it could still be spaghetti).
It is a standard practice to add code comments as well.

Even in spaghetti code, CTRL+ F exists.

However, it is unlikely that an application of this essence will be written as spaghetti code. Unless the writers were consistently drunk.

They cannot locate the source of the bug without a massive and time-consuming reverse-engineering effort.
There is no such thing in programming as “I cannot locate the code”. Usually software is equipped with debugging and logs. This debugging could be running constantly or it may need to be enabled.
They don’t need to reverse engineer, they have the source.

When the saving fails, developers can trace where exactly the issue occurs (even if it involves 150 functions calling each other in a rapid succession).
That’s why we study before they go into these fields.
 
  • +Reputation
Reactions: simmerskool