On 28/02/2016 7:52 a.m., joe wrote: > right Asserts is the best choice for critical function im with you define "critical". It is not always obvious. > on that in the other hand some function its not critical to have > asserts just trace() or some other function to notify the cache log Now your cache.log / syslog fills with many KB per request as someone DDoS your proxy with just a few bytes of input per request. That is called a DoS amplifier. Whole machine (not just Squid) crashes with disk space exhausted - DDoS successful after sending only a few dozen MB or GB of traffic. Keep in mind that DoS are reaching TB of traffic quickly, and the machine which dies may not be Squid but a separate logging server, and the nature of the crash may leave no clear evidence pointing back at the problem being Squid or the small-DDoS. There is no simple "do this" action to solve all _impossible_ situations. People like yourself jumping to quick solutions, or baseing them on outdated/wrong ideas without thinking the consequences over is why the topic of letting admin have any control at all is controversial in the first place. > for warning and do not halt just keep running its choice of what > function need to have asserts or if the function not critical just > notification will do as of compiled code but for testing in lab some > function still has bad bug asserts is good for it don't know if other > guys agree so.... If that were true no assertions would ever occur in production machines. We could thread the code with them and never worry. Perfect code and all that. The truth is as Alex said. That assertion happening is because an "impossible" situation happened in production. If it did happen in testing *at all* the dev changing the code would have removed the assertion and added code to handle that case. It simply did not happen in testing. The dev thought it was impossible, but had just enough paranoia to add an assert to bring attention to it if it did. This past weeks CVE is a very good example of that. Squid has rather extensive controls over the size of messages it received: * request_header_max_size and reply_header_max_size place an absolute limit of 64KB or less on any mesage *total* mime header size - multiple lines and surrounding syntax bytes all less than 64KB total. * each individual line of that header must also be within 64KB if by chance the admin chooses to raise that limit. * these are carefully checked and enforced on arrival of data from all network inputs *and* from disk cache. - in case someone fiddled with the disk entry. We have seen that happen. Reasonable to assume that its impossible to receive a HTTP message with single header line >64KB, yes? Well, no. CVE-2016-2569 still happens. A single message header line can reach far more than 64KB. The proof is an assertion. Oh, and handling that situation instead of assert/crash and restarting makes at least 3 other impossible situations / asserts happen later on for Squid (well, 3 that we know of so far). PS. Can you use some punctuation in future please. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
