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ł
signature.asc
Description: OpenPGP digital signature
