lkml.org 
[lkml]   [2009]   [May]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option
    tridge@samba.org 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


    \
     
     \ /
      Last update: 2009-05-04 07:45    [W:0.027 / U:2.588 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site