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-
Re: [gentoo-dev] Policy-level discussion for minimum versions on dependencies
On Wed, Nov 06, 2013 at 01:28:13PM -0500, Rich Freeman wrote: On Wed, Nov 6, 2013 at 11:15 AM, Alan McKinnon alan.mckin...@gmail.com wrote: I agree with this sentiment. It's always been my view that the needs of a package are driven by the package itself, not by the tree. Rationale: A package will build and run as long as it's own requirements are met regardless of what the tree states. ++, and to all that follows. I wouldn't go hunting down and bugging devs for every atom that doesn't specify a minimum version - this stuff isn't always easy to find. However, if somebody offers a minimum version I'd consider it a valid bug. As a maintainer, I start by checking the documentation for the software I was packaging and making the dependencies match the version requirements there. William signature.asc Description: Digital signature
[gentoo-dev] Drop net-analyzer/nagios-* to maintainer-needed
Hi, I see nobody seems to take care of nagios packages anymore. There are numerous bugs (and many of them are pending version bumps). Is the sysadmin@ herd still interested in this package? If not, could you please consider moving it to maintainer-needed@? Maybe users are interested in working with proxy-maintainers to bring this package up to date. https://bugs.gentoo.org/buglist.cgi?quicksearch=net-analyzer%2Fnagios -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang
Re: [gentoo-dev] Drop net-analyzer/nagios-* to maintainer-needed
On 11/8/2013 7:14 PM, Markos Chandras wrote: Hi, I see nobody seems to take care of nagios packages anymore. There are numerous bugs (and many of them are pending version bumps). Is the sysadmin@ herd still interested in this package? If not, could you please consider moving it to maintainer-needed@? Maybe users are interested in working with proxy-maintainers to bring this package up to date. https://bugs.gentoo.org/buglist.cgi?quicksearch=net-analyzer%2Fnagios If sysadmin@ doesn't want it, I know a user/potential dev who would be interested in maintaining it with me as a proxy. Just let me know. Chris reffett
Re: [gentoo-dev] Policy-level discussion for minimum versions on dependencies
On 8 November 2013 08:55, Rémi Cardona r...@gentoo.org wrote: Le jeudi 07 novembre 2013 à 10:44 +0100, Alexis Ballier a écrit : in short: if a package requires version X then the ebuild should require version X; it can be forgotten but it's a bug. That _is_ our policy. Since this thread was deemed necessary, apparently it's not. Or at least not clearly stated. Ebuilds should - at the very least - mirror what upstream's build script requires. And they do. Strictly spoken, we do not support ebuilds / versions that are not (or no longer) in the tree. If the user chooses to use ebuilds / versions we don't support, they are on their own. That said, we can do it as a courtesy to users, when it is brought to our attention. But it's more of an enhancement than a bug, in my opinion. -- Cheers, Ben | yngwin Gentoo developer
[gentoo-dev] Looking for app-i18n/poedit maintainer
Is anyone interested in maintaining poedit? It's currently covered by wxwidgets and I check in on it a couple times a year for bumps/stabilization, but I don't use it myself. Feel free to add yourself or take it over if you're interested. Thanks. -- Ryan Hillpsn: dirtyepic_sk gcc-porting/toolchain/wxwidgets @ gentoo.org 47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463 signature.asc Description: PGP signature
Re: [gentoo-dev] Suggestion: support the Dev team with system resources
Johann Schmitz er...@gentoo.org writes: Is it possible to run, say, mips on xen/whatever through some emulation layer or is real hardware a requirement for this archs? Yes, via qemu. But very slow, nearly unusable even on a powerful mainstream amd64 server.
