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

Re: Dealing with embedded javascript libraries

W dniu 31.10.2011 14:49, Pau Garcia i Quiles pisze:
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


- 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.

For the record. I stated the reverse, what you described above was proposed by someone else. I on the other hand agree that we should:

1) Ship _bundled_ libraries that upstream provides. The rationale is that version is what upstream supports. I don't believe in our capacity to support random applications out there better than upstreams already do.


2) Have broad multi-version support (perhaps eventually at dpkg level), package multiple versions of javascript libraries, depend on the precise version that upstream used. The motivation for this is similar to my previous point except that it might be, theoretically, better to support security fixes. The more direct advantage is easier support for incompatible, co-installable versions of a single library.

I think that security aspect is moot because failing to find a proper package people will just revert to _not_ using dpkg for their web deployments and the world will NOT be a single bit more secure.

Best regards

Reply to: