We currently build nodejs with a shared v8 (which obviously is all good). Today I ran into a unresolved symbol-issue with node-geoip. Looking loser into it, I linked my nodejs against v8 3.15.x, while upstream currently links (statically) against 3.11.x. We really should follow these abi versions since they apparenly are different enough. node 0.8.x currently links against v8 3.11.x node 0.9.x (which turns into 0.10 soon) links against 3.15.x. I suggest making these RDEPEND, and thereby re-introducing older versions of v8 into gentoo-x86. One way of looking up what version of v8 node uses through the ebuild could be by looking at deps/v8/src/version.cc, where you'll find something in style with (taken from node 0.8.17): #define MAJOR_VERSION 3 #define MINOR_VERSION 11 #define BUILD_NUMBER 10 #define PATCH_LEVEL 25 Thoughts?
I have no objection as a maintainer to keeping an old copy of v8 around for nodejs. One problem is that we won't get any security fixes for older v8 branches once the corresponding Chrome version has been abandoned. How does the nodejs project deal with it? Do they cut releases in response to security bulletins?
I haven't seen (In reply to comment #1) > I have no objection as a maintainer to keeping an old copy of v8 around for > nodejs. > > One problem is that we won't get any security fixes for older v8 branches > once the corresponding Chrome version has been abandoned. > > How does the nodejs project deal with it? Do they cut releases in response > to security bulletins? Are there known security issues with v8 3.11.10.25? I haven't seen backports in nodejs that wasn't synced with upstream. In other words, they bump v8 version and release a new version of nodejs. They have some floating patches on top of v8, but those are performance related (and they strive to get them accepted upstream). You can find the difference here: https://github.com/joyent/node/commits/v0.8/deps/v8 My suggested route here is to go with the latest available of a minor release, even if node is trailing a patchlevel or two. For node 0.8, this doesn't have any implications since they're on the latest patchlevel; just pointing out for future references.
(In reply to comment #2) > Are there known security issues with v8 3.11.10.25? The Chrome release notes frequently cite V8 vulnerabilities. For the latest release: http://googlechromereleases.blogspot.com/2013/01/stable-channel-update.html """ [164565] High CVE-2012-5153: Out-of-bounds stack access in v8. Credit to Andreas Rossberg of the Chromium development community. [150545] High CVE-2013-0836: Crash in v8 garbage collection. Credit to Google Chrome Security Team (Cris Neckar). The security issues in V8 have been fixed in v8-3.14.5.3. """ http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-5153 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-0836 I personally have no way to know if the fixes have been back-ported.
(In reply to comment #3) > > """ > [164565] High CVE-2012-5153: Out-of-bounds stack access in v8. Credit to > Andreas Rossberg of the Chromium development community. > > [150545] High CVE-2013-0836: Crash in v8 garbage collection. Credit to > Google Chrome Security Team (Cris Neckar). > > The security issues in V8 have been fixed in v8-3.14.5.3. > """ > > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-5153 > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-0836 > > I personally have no way to know if the fixes have been back-ported. I'll have to investigate whether this is relevant or not. In a way, this should be a bigger concern for nodejs (if applicable) than its gentoo packaging. I will keep this bug updated.
Ok, so. After talking to some people, they refer to most parts of v8 (that gets CVE's) are N/A for node since it's not embedded in the browser. If any applicable security issue is found, it should be reported to upstream and they'll take care of it. I guess that makes it a bit tricky if we look at v8 as a shared library since others can link to it too. With that said, I still don't know if any of the reports is applicable. I would assume no since nodejs hasn't had an bug reported about it, nor patches applied. Suggestions on how to move on?
I would like to hear from the other chromium team members on this.
(In reply to comment #5) > Ok, so. After talking to some people, they refer to most parts of v8 (that > gets CVE's) are N/A for node since it's not embedded in the browser. Some people... I wonder who are they. Generally I think most v8 issues are applicable, that's why we also stabilize v8 and include it in the GLSA. Upstream's advice is to always use the latest version by the way. It's not really backporting-friendly, and v8-3.11 seems ancient now. I'm against putting vulnerable v8 versions back in the tree. I could be interested in talking with nodejs upstream about their v8 update strategy. I think that's better route.
(In reply to comment #7) > (In reply to comment #5) > > Ok, so. After talking to some people, they refer to most parts of v8 (that > > gets CVE's) are N/A for node since it's not embedded in the browser. > > Some people... I wonder who are they. Generally I think most v8 issues are > applicable, that's why we also stabilize v8 and include it in the GLSA. > > Upstream's advice is to always use the latest version by the way. It's not > really backporting-friendly, and v8-3.11 seems ancient now. > > I'm against putting vulnerable v8 versions back in the tree. > > I could be interested in talking with nodejs upstream about their v8 update > strategy. I think that's better route. Hey Paweł, thanks for your feedback! "Some people" was isaacs, the 'official' maintainer replying to me over irc. I could have created an official upstream issue, but prefer having a casual discussion on the subject. For the next node branch (0.9 resulting in 0.10 in the next week(s)), 3.15.xx will be the way to go. They tried using the 3.16.xx, but had problems from an architectural point of view (found out by daily following their commit stream). I won't debate their choices, nor question them. If we don't have the option to use a shared library, we have no other option than to use the static link already part of the nodejs package. I'd rather avoid breaking ABI than having unconfirmed security problems. I suggest you create an upstream ticket re v8 bindings at https://github.com/joyent/node/issues if you want to debate their security policy since it isn't very related to our gentoo package. I'm interested in solving ABI incompatibility compared to upstream packaging, not revamping upstream's policies. Please keep me (the ticket) posted on how it goes!
Hello again. I'd really like to avoid other users getting ABI issues. If this is a potential security issue, I think that discussion should take place elsewhere, or at a new bug where the main issue isn't ABI breakage because of linking to newer versions of a dep. The way I see it, we have two options: 1) introduce older v8, from the 3.11.x branch in use at node 0.8, and use the 3.15.x for 0.9. 2) statically link against the bundled v8 in the nodejs package. I'd really like to go with #1. Thoughts?
(In reply to comment #9) I think the chromium team is in agreement that adding an old v8 version to the tree is not an option due to the security problem. If you want to build against an old and possibly vulnerable bundled library, that's up to the nodejs maintainer(s). Another option would be to mask nodejs-0.8 if it does not function properly with a supported version of v8.
(In reply to comment #10) > (In reply to comment #9) > > I think the chromium team is in agreement that adding an old v8 version to > the tree is not an option due to the security problem. Noted. Since we're implying that there is a security problem here, I'd like to see that confirmed somehow. I've spoken to nodejs developers and they couldn't. > > If you want to build against an old and possibly vulnerable bundled library, > that's up to the nodejs maintainer(s). Ok. We'll discuss this option. > > Another option would be to mask nodejs-0.8 if it does not function properly > with a supported version of v8. Not sure why mask would be the right way here. There's a lot of other ebuilds that link to specific versions of other packages. I totally understand that having a v8 library with security issues in-tree is unwanted, even if the only user is nodejs and issues were N/A. If that's the case, I'd still like to establish it instead of playing assumption games.
If we don't hear from the maintainers soon, I'll just go ahead and modify the nodejs ebuild to use the bundled v8. That's better than having a broken package.
My take is still that we introduce an older version of v8 to gentoo-x86. I haven't heard of any security issues from the node community about their preferred versions. Perhaps google could level up here and be a bit more detailed as to what versions of v8 applies to each security bug? None the less, this bug shouldn't be about potential security issues. Patrick, what's your 2c?
(In reply to comment #13) Other than the security issue, v8 would probably need to be slotted, or users could not install nodejs and chromium at the same time.
I had a quick chat with patrick in IRC, and he would also prefer to use the shared v8 library. I think we need a separate bug assigned to the chromium team to hash that issue out.
We've (me, patrick and floppym) come to the conclusion that its probably best to use the bundled v8 for now. Lets see what the future gives.
