tridge@xxxxxxxxx writes: > Hi Al, > > > Practical consequences of establishing that kind of precedent (applying > > a patch on the grounds of nothing but vague references to possibly > > legal problems, with author explicitly refusing to explain exact reasons) > > can also be non-trivial... And I'm not sure that it won't have legal > > ones as well, while we are at it. > > You are absolutely right. For that reason, I expect that anyone who > does finally make the decision to include this patch, or something > like it, will have had a long discussion with a lawyer first, and will > fully understand the reasons for it. > > Meanwhile though, there is something we can do here in public, which > is to discuss the technical merits of the proposed patch. It might be > that you or someone else can come up with a better technical approach. > > I also realise that discussing the technical merits of a patch without > first establishing the exact non-technical reasons for the patch is > difficult, but as Hirofumi-san has shown, it is possible. Great now we go from security theater to patent theater. And even more it appears to be a shed painting project. Fun to watch but no real content. The reality is that without a clear understanding of what the bug is it is impossible to review the code to see if it actually fixes the bug. So from a purely code side it is impossible to see if it the patch does what is intended. >From the few reports I have heard that the actual bug is not in the linux kernel code but rather it sounds like a denial of service attack against the implementation of http://uscode.house.gov/. With the attackers being able to inject a few bogus values, and cause lots of mayhem. Now in the linux kernel we work around lots of bugs from lots of different sources, and this may be a place to work around someone else's bug. This does not appear to be a context where anyone is concerned about a 0 day exploit, so we don't need to rush. Further the functionality has been the same in the same in all places for a long time, and all of the pieces are at least in theory open to public review. So this should be a reasonable context for a public discussion. The only reason I can see for not ultimately talking about things publicly is if this is one company making shady deals with another company in which case I do not see why the maintenance burden for those decision should fall on the linux community as a whole. So for the same reasons we always want a good description of the reasons for a change in the linux kernel, to ensure we understand what the change is for and can properly review it. To ensure that the submitter knows what they are talking about we need a good change description. My experience with special cases and running around the normal process is that it always produces an inferior result. This case seems no different. So please let's treat a bug as a bug and make certain that everyone knows what is going on, and that this isn't an attempt to foist maintenance off someones purely local hack off onto the greater linux community. Given the continual rate of change in the linux kernel whatever that config option is supposed to protect will inevitably bitrot unless it is clear what it is protecting, and someone bothers to test and verify it. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
