@Gene I checked the Vendor List and File Rating list. They seem fine, nothing wrong with that. Microsoft Corporation is on the list.
Now this is where it gets a little strange: as part of the update process, the file OfficeClickToRun.exe (and all others) are moved into the destination folder. At the time Comodo alerts me, the file ‘OfficeClickToRun.exe’ is already moved, and because of that Comodo cannot verify the signature of the file => Comodo treats is as ‘not trusted’ => Alert
This happens on all computers here, no idea why or why it does not happen on yours.
The workaround:
I created a File Group that contains only the path with the wildcard. I assigned the HIPS rule to this File Group instead of the wildcard path directly => Now it works
So is seems to me there is something wrong with how HIPS handles the rule when directly assigned to the path with the wildcard(s), vs when assigned to a File Group
So, Wildcards broken, just in some ‘edge cases’ or not at all?
My HIPS setup relies heavily on wildcards due to Microsofts SystemApps and WinApps getting a new /version/ folder for every update, as well as some other "#¤ software.
As well as inside the app rules, there would be wildcards in the various rules (folder access, process execution, etc…)
I’m on 8012 but considering upgrading to a more recent version (assuming it doesn’t have some nasty regression, such as the last time I updated and the certificates expired…)
For me at least, wildcards in HIPS are broken for some cases.
I wasn’t able however to pinpoint the exact problem as to what cause a wildcard to work or not in HIPS.
I have some working wildcard rules in HIPS, and some don’t. But all rules where the wildcard replaces version numbers with dots are broken.
Comodo broke HIPS wildcard support in folder paths; * no longer works like it used to. Firewall rules still do. Your options: use environment variables (%PROGRAMFILES%), make separate rules per version, or use hash-based rules. No patch will restore the old * behavior.
