Re: [gentoo-dev] does v8 shared library make sense with current upstream approach?

On 9/25/13 1:16 AM, Peter Volkov wrote:
> But could you comment on how hard it'll be to slot v8 shared library?
> Keeping libraries bundled is a security nightmare.

Slotting v8 would be hugely impractical and rather a misuse of SLOTs.

Slotting makes sense when there are at most 2-3 major versions, each
with its own release series, that are incompatible, but packages can
depend on one or another series. Thing gtk2 vs. gtk3 for example, or
maybe some Java libraries.

With v8 API and ABI breaks can (and we've seen that) be introduced even
between patch version increments like a.b.c.x vs. a.b.c.y. Trying to
slot that would be totally equivalent to bundling at the cost of
increased complexity (more custom changes compared to upstream - also
headers would need to be handled somehow, currently we don't have a good
way for that, especially one that would be consistent across distros).

Finally, note that v8 upstream only supports the latest stable v8.
Slotting would require us to keep old, _known_ to be vulnerable versions
of v8 in the tree. Backporting of patches isn't always
possible/feasible, and even then for complex and fast moving software
it's not guaranteed to fix all the issues (some security bugs might have
been fixed in more recent versions without realizing security implications).

At least with bundling upstream _may_ track v8 security vulnerabilities
and do something with their copy. With slotting we'd have _known_
vulnerable v8 versions right there in the tree. That'd be a security
nightmare.

Please let me know if you have more questions. At this moment I'm
confident slotting does not address the problem. More deeper, upstream
changes should be made, and I'll be working on that but it's going to
take time.

Paweł