Re: Lua [in]security and the distributors

[Jonas Thiem <jonasthiem@...>]

FWIW: the Red Hat people appeared to be rather surprised and were happy
to file a CVE request themselves. It is as if they just had been waiting
for someone to come by (or a big red warning on the Lua page, just
saying) to notify them they overlooked it.

Regards,
Jonas Thiem

On 08/28/2014 11:49 PM, Hisham wrote:
> On 28 August 2014 18:10, Jonas Thiem <jonasthiem@googlemail.com> wrote:
>> Yes, but in practise all linux users would hate me for shipping Lua when
>> their system already has it,
> 
> No, they won't. Chill. Users in general don't even know which
> libraries the code they're running uses. Distro maintainers might have
> issues with it because you're replicating a library — in _those_
> cases, if/when they contact you about, then you can discuss the issue
> with them, giving your reasons for having a patched library,
> suggesting them to patch the system version, etc.
> 
> There are many sensible approaches to the issue. The one you're
> insisting on (big red warning in the web page) is one of them, but not
> the only one, and it has its pros and cons: users in practice won't
> visit every website of every library the programs they use include
> just to check for big red warnings; distro maintainers are aware of
> issues and have their own different procedures to dealing with them
> (as we saw in this thread — for example, for some of them it takes a
> CVE to consider something a practical security issue worth of a
> downstream patch). The "problem with the website" is just your opinion
> on how to go about the issue; for what is worth the Lua website could
> have been a single link to the .tar.gz file with nothing else; it
> would still be a valid website. Others will say that acknowledging the
> issue and fixing it in the next version is enough and then it's up to
> downstream to handle it.
> 
> Lua has a good track record on this kind of issues, a page with known
> bugs and patches, and very strict API/ABI policies in patch versions.
> Having been on both sides of the upstream/downstream discussions
> (upstream as the developer of LuaRocks, htop, etc.; and downstream as
> a distro maintainer for GoboLinux), I consider that the Lua team does
> a decent job concerning relationship with downstream. Could it be
> better? Sure — they have avoided some tough decisions in the past
> (such as naming of libraries) that has led to incompatibilities among
> distros. But their act in a consistent and disciplined way (i.e. they
> really do the things they say the do, and don't do the things they say
> they don't).
> 
> My practical suggestion is: If you consider the build of Lua shipped
> by distros to be inappropriate for your use cases, bundle your own.
> Unlike other so-called scripting languages, Lua is actually designed
> for that. Most distros won't even notice the extra kbytes in your
> sources. For the ones that do and consider that an issue, assuming
> your project grows popular enough for them to want to assign a
> downstream maintainer and package it, then you'll have a communication
> channel open to discuss and solve the issue.
> 
> My abstract advice is: Relationships between upstream and downstream
> are always delicate, diplomatic matters, since we're often dealing
> with criticism of each other's work. One always needs to balance it
> with recognition for one's goodwill on investing their time on it.
> Upstream is sharing the product of their creativity; downstream is
> going through the effort of making it widely available. Both deserve
> respect and being listened to. The position of the end user, when
> their needs are not fulfilled, is also delicate. Who's to blame?
> Downstream? Upstream? Are they even in a position to blame someone?
> One might be justified in saying they're not, but that's just because
> "blaming" is the wrong word: users do have a voice, once we realize
> that both upstream and downstream's work aims at end users (and it
> goes full circle because developers are users too). It's a delicate
> chain of cooperation that depends on goodwill; being confrontational
> about it never helps.
> 
> tl;dr: calm down, we're all trying to cooperate here. :)
> 
> -- Hisham
>