Shareaza Security Filter Problems

[skinvista]

AFAIK, IP and the new TR1 RegExp are the only functional Security filters.
Any MatchAny or MatchAll based filter is orphaned. Non-regexp filename, hash, size:ext:####, etc. are simply never tested, although iterated.

Specifically, CSecureRule::Match(const CShareazaFile* pFile) which handles them is only called from CSecurity::BanHelper and CSecurity::IsDenied( pFile ), which in turn are never used.

I haven't gone back to see where this breakage occured yet, but it seemed like a good time to also address performance problems etc. from various complaints.


Relatedly would be the filters themselves. For example, a lot of spam lately reports from bad/private blocks (192.168.0.0 etc.) Would there be any unintended consequences simply blocking them all, outside LAN mod?

(Unrelatedly, would anyone object if I committed PeerProject profile schema recognition to GProfile XML parsing (3 lines)? Don't know if that appears as self-serving or pragmatic moving forward.)

[ailurophobe]

Looks like a performance optimization to me. The basic problem with security manager is that if you check anything it iterates thru everything, so reducing the number of checks makes sense.

I guess the simplest way to fix Security would be to add some sort of a lookup hash table. A separate hash bin for every rule type and something like 64 or 128 for IP addresses (lowest 6 or 7 bits of the highest byte of address) and in every hash bin a VECTOR of SecurityRule pointers. The overhead of adding and removing a pointer from the correct bin should be minimal and the speed up would be around two orders of magnitude. And if this is not enough the IP address and hash rule bin vectors can be sorted for binary search.

[aaron_walkhouse]

This is why I recommended putting the IP lookup into it's own table. (binary tree, actually)
You can call that hundreds of times a second and get results in a few nanoseconds, making
it economical to check it for every upload, download, host connection and even search hits.

As for hash tables, I've got your best real-world test data right here.

[old_death]

I agree to aaron. The IP, keyword and regex filters should be treated separately for better performance. A binary lookup table would enable us to have a logarithmic growth for the lookup times, so that's the way to go.

Our security (and search) filtering might actually really profit from a complete rewrite, as it has grown with the time by adding more and more features in an inefficient (and buggy) manner. Remember also, that not every incoming information needs to be checked against all filters. For example, lots of packets need to be only compared to the IP filter (and packets from already connected neighbours don't need to be checked by IP filtering at all, BTW).

BTW, I think, the client/vendor code filtering should be moved from the upload settings to the security window. That would only be a logical thing to do. Also, it might be intelligent (+ adds consistency) to have a "DefaultFilters.xml" file whose rules would be loaded on complete security window clearing - ah yes, and we might want to add a link to clear all rules from the context menu directly, instead of having to scroll to select them all.

Additionally, implementing ctrl+A in the security window might be useful, too, as well as some view filtering (similar to the source filtering in the download window) might be a "nice to have".