[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Dealing with embedded javascript libraries



On Thu, Oct 27, 2011 at 1:28 AM, Ian Jackson
<ijackson@chiark.greenend.org.uk> wrote:

> The difficulty is that if we end up with ten different versions of
> some random javascript library, when it turns out to have a security
> vulnerability we need to somehow backport the patch to each of those
> ten versions.
>
> And here "we" means the security team, not the people who uploaded the
> ten versions in the first place.
>
> So this is rather unpalatable.

What's the alternative?

It seems that we only have two choices:

- Either all packages use the same version of the JavaScript library
(what we have been doing until now, which results in some packages not
working properly due to changes in the JavaScript library that
manifest only in some situations in runtime). This is essentially what
we do with C, C++, etc libraries, btw: the whole Debian is built
against the same zlib, same glibc, same libpng, etc

or

- Each package works with the upstream-bundled version of the
JavaScript library (and then we have the problem of backporting
security fixes). The advantage being we are sure the application works
as expected because it has been tested by upstream.


I'm not sure what's worse: a malfunctioning application or an insecure one.


Zygmunt's proposal of adding unit testing, etc to upstream is a noble
one but highly unrealistic, IMHO.


-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)


Reply to: