[BUG] Security rules can't block some hits from Gnutella

[diztrancer]

String and regex rules can't block some hits from Gnutella:

Rule "\.au$" can't block "some shit superhit.au" from Gnutella.

Same for ".mov" or "." spam

Why ???

[raspopov]

Pleas don't use regexp rules for such simple cases, its about 100 times slower than basic content rules.

[diztrancer]

I don't uses regex in my "production" filter. But ".au" string filter also can't block Gnutella ".au" spam

[cyko_01]

I have also noticed this. The files come up first without an extension and then are renamed with the extension .au or .mov . Also, the appropriate icons for those file-types are not displayed, only the generic question mark icons. I considered filtering all files without extensions but wasn't sure how to do it as a security filter

[ailurophobe]

The filter is applied to the file name and if the file name returned by the search hit does not contain the extension... I think that if you add, delete, or edit any security rule, the filter should get applied to the file names, and these removed. If so there is a missing call to security in the code doing the renaming... I RG it would be metadata processing, which I also RG includes MIME type or something similar.

[cyko_01]

[ailurophobe]

It would still be Shareaza code doing the renaming without a security check, for a different reason, but that is irrelevant.

[ivan386]

Shareaza use file name from first hit even if it banned. If file have other hits without banned words Shareaza show this file whith name from firs hit.

[mojo85]

How about extensions, for the most part this doesn't change ... and what I witnessed is that a blocked extension sometimes still gets through.

In such a scenario, could a temp ban based on the hash of the file be created on the first hit of a matching result ... this way the filename is blocked and so is the hash temporarily?