Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[Eric W. Biederman]

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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/