On 6/28/19 11:56 AM, Rhonda D'Vine wrote: > Please don't abuse backports for bugfixes that belong in stable. This > won't solve the issues for users of stable. Backports is for newer > features in software, not for offering bugfixes for stable. >
Perhaps you didn't read my next point? "For important bugs [..] buster-stable" > Custom chains aren't really something exotic like you try to imply. > Most tools that offer a bit more of a complex possibility to maintain > your firewall settings are using them. And if a simple iptables-restore > can trigger this segfault for a setup that is far from exotic then it's > a regression that appears through the change of the tool that should > rather ring alarm clocks instead of trying to downplay the issue, in my > opinion. :/ > I think I didn't explain myself enough. Let me try again. Usecase that triggers this bug: === 8< === * define a custom chain * flush all rules of that custom chain (not required, because the chain was just created) * add a rule to that custom chain === 8< === i.e, this file: *filter :NEW-OUTPUT - [0:0] -A OUTPUT -j NEW-OUTPUT -F NEW-OUTPUT -A NEW-OUTPUT -j ACCEPT COMMIT The problem here is the '-F CUSTOMCHAIN' call just after creating it. This -F call is pointless, because the chain was just created and is thus empty. This call to flush the chain that was just created is what is causing the bug. Again, this is not the general case. Is a valid use case, indeed. But is not something most people would use. I'm not negating the bug, but this is my rationale for lowering the severity. For completeness, usecase that doesn't trigger this bug: === 8< === * define a custom chain * add a rule to that custom chain === 8< === I.e, this file: *filter :NEW-OUTPUT - [0:0] -A OUTPUT -j NEW-OUTPUT -A NEW-OUTPUT -j ACCEPT COMMIT This is the general case of defining and using a custom chain. This is bugfree. > I know that the release is happening next week, and I understand that > it is considered too late to do anything right now - but please think > about the impact of this for the first point release. > All bugs are annoying. All bugs break someone workflow/usecase. They are bugs for a reason :-) Severity of bugs can be put into perspective depending on how common the workflow is, and this is clearly not a common case for the reasons explained above. That being said, the last upstream release contains the fix (which will be backported to buster-backports) and I'm already working on discovering which concrete patch fixes it for a potential inclusion into buster-stable.
