Re: [gentoo-dev] removing vulnerable versions of dev-lang/v8
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/11/13 12:22 AM, Paweł Hajdan, Jr. wrote: For some context of this please see http://thread.gmane.org/gmane.linux.gentoo.devel/88222 v8-3.20.17.7 fixes a memory corruption vulnerability, see http://googlechromereleases.blogspot.com/2013/10/stable-channel-update.html However, we still have v8-3.19 and even 3.18 in portage - this is probably an oversight when stabilizing new versions. Problem #1 is that sci-geosciences/osgearth-2.4 depends on =dev-lang/v8-3.18.5.14 (see https://bugs.gentoo.org/show_bug.cgi?id=484786 for context). It doesn't work with more recent v8, but it can be made to not depend on v8. Problem #2 is dev-db/drizzle having a v8 USE flag. The ebuild is actually broken for other reasons, see https://bugs.gentoo.org/show_bug.cgi?id=490216. I'd like that USE flag to be removed and v8 to always be disabled in drizzle. With that I'd like to proceed with hard masking v8. I'm working with upstream on better API stability, it seems to be working pretty well. That's still a very long way to ABI stability, if at all possible. Please comment on possible solutions for removing known vulnerable v8 versions from the tree. Paweł So, you're saying, drop v8 USE flags and deps from these two packages, and hard-mask? Makes sense to me... I'm still a little concerned about the potential security issues caused by embedded V8's in projects, but as we've already concluded in that other thread, there's no other way until the API stabilizes.. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlJ8+EcACgkQ2ugaI38ACPDZvwEAhQHhSovgSouf+TMnZrus1I4v svWFshpj9ZR6/EhvzH4A/izLFwlxfwcNrkwEkzOY7FBBAxh9zMPiOLZFGbcxtqKx =Tooi -END PGP SIGNATURE-
Re: [gentoo-dev] removing vulnerable versions of dev-lang/v8
On Fri, Nov 8, 2013 at 9:42 AM, Ian Stakenvicius a...@gentoo.org wrote: I'm still a little concerned about the potential security issues caused by embedded V8's in projects, but as we've already concluded in that other thread, there's no other way until the API stabilizes.. Yup. When a project uses a library with an unstable API, they're basically taking on a commitment to fork it unless upstream backports all fixes. If the alternative is re-implementing the library the project is no worse off (at least with embedded libs we know about the vulnerabilities). If there are other alternatives, then they should probably rethink their strategy. Rich
Re: [gentoo-dev] removing vulnerable versions of dev-lang/v8
On Fri, Nov 8, 2013 at 5:22 AM, Paweł Hajdan, Jr. phajdan...@gentoo.orgwrote: Problem #1 is that sci-geosciences/osgearth-2.4 depends on =dev-lang/v8-3.18.5.14 (see https://bugs.gentoo.org/show_bug.cgi?id=484786 for context). It doesn't work with more recent v8, but it can be made to not depend on v8. If made not to depend means bundle, is the bundled version any safer than the ebuild there? If the answer is no, you're now increasing the security issue. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] removing vulnerable versions of dev-lang/v8
Diego Elio Pettenò wrote: Problem #1 is that sci-geosciences/osgearth-2.4 depends on =dev-lang/v8-3.18.5.14 (see https://bugs.gentoo.org/show_bug.cgi?id=484786 for context). It doesn't work with more recent v8, but it can be made to not depend on v8. If made not to depend means bundle, is the bundled version any safer than the ebuild there? If the answer is no, you're now increasing the security issue. Based on my previous impression I OTOH assumed that Paweł meant disabling use of v8, but since I don't use either package I didn't look at the bug. Your email made me more curious, and as Paweł wrote the bug gives plenty of context, among other things Paweł has attached a patch there to disable v8 in osgearth. I think it's commendable that he doesn't settle for simply masking osgearth along with v8. //Peter
Re: [gentoo-dev] removing vulnerable versions of dev-lang/v8
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/08/2013 04:18 PM, Diego Elio Pettenò wrote: On Fri, Nov 8, 2013 at 5:22 AM, Paweł Hajdan, Jr. phajdan...@gentoo.org mailto:phajdan...@gentoo.org wrote: Problem #1 is that sci-geosciences/osgearth-2.4 depends on =dev-lang/v8-3.18.5.14 (see https://bugs.gentoo.org/show_bug.cgi?id=484786 for context). It doesn't work with more recent v8, but it can be made to not depend on v8. If made not to depend means bundle, is the bundled version any safer than the ebuild there? If the answer is no, you're now increasing the security issue. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu mailto:flamee...@flameeyes.eu — http://blog.flameeyes.eu/ https://github.com/gwaldron/osgearth/issues/333 in short: they kind of forked (I am not sure if there are any major modifications yet) it and do not plan to bundle it there is no release more current than osgearth-2.4, so I am fine with hardmasking/treecleaning osgearth I will not maintain a fork of v8. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSfVxtAAoJEFpvPKfnPDWzZ7EH/ib4oZPMLUTYDU0gvkC2NL9o XVvaSdD2lWbAi6ZTwS7RCqygGWoUu5duM4qAOpb/i+KcBgvmXiyDuoOarVFea0PW Si1StRzYf2aVitbdjTqUYlmynX5yiNFvnx5J3knZegzVpm1A9n2Dq2dnIeG7C7zO waWurRsOAdL+XAU3tNot1TepyZwojB3xz3w9k0YtuTTwHRX2vGQ7XM1MOnr9jrOy Is4x5naeau7P4t7Doi5+y9zj5ydshmEHeRm5Upt3DB6JO1WmPdA+8Z4ZmcOLiWUu tBLSqpxSf6TGaUbOop7hNWDWl8ptfrzoSyQjTu6fLHLSo+SMH4qToSEdOlpkqyc= =0K7T -END PGP SIGNATURE-
[gentoo-dev] removing vulnerable versions of dev-lang/v8
For some context of this please see http://thread.gmane.org/gmane.linux.gentoo.devel/88222 v8-3.20.17.7 fixes a memory corruption vulnerability, see http://googlechromereleases.blogspot.com/2013/10/stable-channel-update.html However, we still have v8-3.19 and even 3.18 in portage - this is probably an oversight when stabilizing new versions. Problem #1 is that sci-geosciences/osgearth-2.4 depends on =dev-lang/v8-3.18.5.14 (see https://bugs.gentoo.org/show_bug.cgi?id=484786 for context). It doesn't work with more recent v8, but it can be made to not depend on v8. Problem #2 is dev-db/drizzle having a v8 USE flag. The ebuild is actually broken for other reasons, see https://bugs.gentoo.org/show_bug.cgi?id=490216. I'd like that USE flag to be removed and v8 to always be disabled in drizzle. With that I'd like to proceed with hard masking v8. I'm working with upstream on better API stability, it seems to be working pretty well. That's still a very long way to ABI stability, if at all possible. Please comment on possible solutions for removing known vulnerable v8 versions from the tree. Paweł signature.asc Description: OpenPGP digital signature
