Re: Lua [in]security and the distributors

[Hisham <h@...>]

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