* Martin Schulze: >> > What was the behaviour pre-sarge? >> > What is the behaviour post-sarge (or rather in sarge)? >> >> Do you mean "before and after the upstream security update"? The >> terms pre-sarge/post-sarge do not make much sense to me in this >> context, I'm afraid. > > Ok, so when did the behaviour change?
Upstream's security update changed the behavior, from "vulnerable" to "non-vulnerable", if you want. > Which behaviour is documented and hence expected? Like most software, shorewall comes with no formalized descriptions of its semantics. The exact behavior of the MAC verification feature is not documented because the documentation writer seemd to assume that it went without saying. So what goes without saying? As far as I can see, something like this: MAC verification is a further restriction which is performed in addition to the usual filtering rules, and not intended to replace it. After all, it's called "verification" and not "bypass". So, to answer your question: Users expect that MAC verification never makes the filter policy less restrictive. This is not the case if you set MACLIST_DISPOSITION to ACCEPT or MACLIST_TTL to a non-zero value. > Which behaviour is experienced by potentially buggy code? Buggy results? Sorry, I don't understand this question. >> (Note that I have yet to test Lorenzo's new package.) > > Are you in a position to do so? Sure, but the question is if you want to rely on the results. You don't seem to trust my judgement on this matter, for reasons I don't know. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
