Re: [gentoo-dev] Re: qa last rites -- long list
El dom, 11-01-2015 a las 08:11 -0500, Rich Freeman escribió: [...] The main issue I see is that the main objective of using games.eclass is to keep games being used by people in games group... but this point if broken as soon as we allow packages to not use that eclass and, then, I see no advantage at all on not deprecating games.eclass (even not killing it immediatly... but at least to let people know that it's deprecated finally) (I am thinking in repoman warning about that eclass usage as it does for old python eclasses and many more) But I guess this should be moved back to current games team and maybe QA as I agree escalating it to the Council directly looks excessive
Re: [gentoo-dev] Re: qa last rites -- long list
On Sat, Jan 10, 2015 at 9:16 AM, Pacho Ramos pa...@gentoo.org wrote: But I must admit I lost the track of this issue some time ago and I don't remember why the eclass is still allowed and then both policies are being used in parallel depending on the maintainer, that is the reason I haven't suggested the Council to deprecate games.eclass finally :/ There is an immediate reason for this, and a deeper underlying issue. (IMHO.) The immediate issue was that the Council was dealing with a crisis with the games herd and wanted to take the minimum initial action to break the logjam. That meant removing the requirement that all games have to be under the control of the herd, but not interfering with how the herd itself was managed. There have been some attempts since to try to get a games team organized, but so far I don't think there has been much interest in that. It would be far better for a bunch of devs interested in games to get together, work out how to clean up the mess, and do it versus just having the council step into that role with a club. If that doesn't get anywhere then we can always revisit the situation and ask whether the current games policies are a serious problem, and if so should we turn that into some kind of QA issue with mandatory cleanup. In general, though, we try to aim for minimal-interference at the Council level. That brings me to... The deeper underlying issues, IMHO, might have something to do with the fact that a distro that is designed around letting every user have it their own way tends to lead to a culture of developers who all want to have everything their own way as well. :) That, and things like this: Projects may well conflict with other projects. That's okay. [1] games.eclass is really just one more manifestation of this, though a more obvious one. How many foo-cleaner/foo-updater/etc scripts do we have out there now for things that aren't cleanly updated by portage, and how consistent is the syntax from one to the next? There are many package-to-package inconsistencies with how things get done. Of course, most of those aren't the result of outright disagreements. In general we tend to leave many things up to maintainers to do the right thing and I think that most of us tend to like it that way. I think the areas for Council involvement are ones like: 1. Outright conflict between maintainers/projects. 2. Cases where maintainers aren't really in active conflict, but consistency would benefit everybody and isn't particularly onerous to achieve. 3. Decisions that really affect the direction of the distro as a whole. [1] - https://wiki.gentoo.org/wiki/GLEP:39 -- Rich
Re: [gentoo-dev] Re: qa last rites -- long list
El vie, 09-01-2015 a las 23:31 +0100, Michał Górny escribió: [...] If I don't misremember Council allowed finally people to not be mandated by that games team policies and, then, I guess that could finally allow to drop that security issue no? :/ If it were that simple... but we need to clean up that long-outstanding mess. And we have no guarantees someone won't bring it back to us since the eclasses are still allowed to be used. I agree with you, I was focusing on that concrete issue as that bug is around for years, but I neither understand why games.eclass is not deprecated completely as current situation will only spread the problem of some games being handled following a different policy than others, and leading to inconsistencies :( But I must admit I lost the track of this issue some time ago and I don't remember why the eclass is still allowed and then both policies are being used in parallel depending on the maintainer, that is the reason I haven't suggested the Council to deprecate games.eclass finally :/
Re: [gentoo-dev] Re: qa last rites -- long list
On Thu, 8 Jan 2015 09:16:36 -0600 William Hubbs willi...@gentoo.org wrote: Rich is correct, maintainers are no longer bound by the games team policy. I didn't know this. If that's the case, I'd like to proxy-maintain nethack. I'll try and prepare the neccessary ebuild changes. Luis Ressel pgpDC_qIfUsBS.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Re: qa last rites -- long list
Dnia 2015-01-08, o godz. 10:45:33 Pacho Ramos pa...@gentoo.org napisał(a): El mié, 07-01-2015 a las 19:19 -0500, Jonathan Callen escribió: [...] The only reason there is a security issue with nethack (and other games like it) on Gentoo, and only on Gentoo, is that the games team policy requires that all games have permissions 0750, with group games, and all users that should be allowed to run games be in the games group. Nethack expects that it have permissions 2755 (or 2711), with group games and that *no* users are members of that group, so it can securely save files that are accessible to all users during gameplay (bones files) and ensure that the user cannot access/change their current save file. These two expectations are incompatible with each other, and end up creating a security issue that upstream would never expect (as no users can be in the games group traditionally). If I don't misremember Council allowed finally people to not be mandated by that games team policies and, then, I guess that could finally allow to drop that security issue no? :/ If it were that simple... but we need to clean up that long-outstanding mess. And we have no guarantees someone won't bring it back to us since the eclasses are still allowed to be used. -- Best regards, Michał Górny pgpTSTGKbffBL.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Re: qa last rites -- long list
On Thu, Jan 8, 2015 at 4:45 AM, Pacho Ramos pa...@gentoo.org wrote: El mié, 07-01-2015 a las 19:19 -0500, Jonathan Callen escribió: [...] The only reason there is a security issue with nethack (and other games like it) on Gentoo, and only on Gentoo, is that the games team policy requires that all games have permissions 0750, with group games, and all users that should be allowed to run games be in the games group. Nethack expects that it have permissions 2755 (or 2711), with group games and that *no* users are members of that group, so it can securely save files that are accessible to all users during gameplay (bones files) and ensure that the user cannot access/change their current save file. These two expectations are incompatible with each other, and end up creating a security issue that upstream would never expect (as no users can be in the games group traditionally). If I don't misremember Council allowed finally people to not be mandated by that games team policies and, then, I guess that could finally allow to drop that security issue no? :/ This is correct, if the maintainer wishes. -- Rich
Re: [gentoo-dev] Re: qa last rites -- long list
El mié, 07-01-2015 a las 19:19 -0500, Jonathan Callen escribió: [...] The only reason there is a security issue with nethack (and other games like it) on Gentoo, and only on Gentoo, is that the games team policy requires that all games have permissions 0750, with group games, and all users that should be allowed to run games be in the games group. Nethack expects that it have permissions 2755 (or 2711), with group games and that *no* users are members of that group, so it can securely save files that are accessible to all users during gameplay (bones files) and ensure that the user cannot access/change their current save file. These two expectations are incompatible with each other, and end up creating a security issue that upstream would never expect (as no users can be in the games group traditionally). If I don't misremember Council allowed finally people to not be mandated by that games team policies and, then, I guess that could finally allow to drop that security issue no? :/
Re: [gentoo-dev] Re: qa last rites -- long list
On Thu, Jan 08, 2015 at 05:53:47AM -0500, Rich Freeman wrote: On Thu, Jan 8, 2015 at 4:45 AM, Pacho Ramos pa...@gentoo.org wrote: El mié, 07-01-2015 a las 19:19 -0500, Jonathan Callen escribió: [...] The only reason there is a security issue with nethack (and other games like it) on Gentoo, and only on Gentoo, is that the games team policy requires that all games have permissions 0750, with group games, and all users that should be allowed to run games be in the games group. Nethack expects that it have permissions 2755 (or 2711), with group games and that *no* users are members of that group, so it can securely save files that are accessible to all users during gameplay (bones files) and ensure that the user cannot access/change their current save file. These two expectations are incompatible with each other, and end up creating a security issue that upstream would never expect (as no users can be in the games group traditionally). If I don't misremember Council allowed finally people to not be mandated by that games team policies and, then, I guess that could finally allow to drop that security issue no? :/ This is correct, if the maintainer wishes. Rich is correct, maintainers are no longer bound by the games team policy. Since this is a popular game, I urge someone to take it over and fix the issue. If I were taking it over, I would immediately look into rewriting the ebuild to not use games.eclass. William signature.asc Description: Digital signature
Re: [gentoo-dev] Re: qa last rites -- long list
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/07/2015 04:19 PM, Jonathan Callen wrote: On 01/07/2015 12:15 PM, Matt Turner wrote: On Wed, Jan 7, 2015 at 7:57 AM, William Hubbs willi...@gentoo.org wrote: On Wed, Jan 07, 2015 at 06:49:56AM -0500, Philip Webb wrote: 150106 William Hubbs wrote: This one is perfectly safe on a single-user system : please leave it there. I'm not opposed to it staying in the tree under one of these conditions: 1) fix it and remove the mask or 2) remove the mask and add ewarns to the ebuild Remove the mask that people have to see and actively disable in order to install the software and replace it with ewarn messages that they likely won't read? I don't see the problem with versions with security vulnerabilities masked in the tree. nethack in particular has been masked in the tree since 2006, so we have some precedence. The only reason there is a security issue with nethack (and other games like it) on Gentoo, and only on Gentoo, is that the games team policy requires that all games have permissions 0750, with group games, and all users that should be allowed to run games be in the games group. Nethack expects that it have permissions 2755 (or 2711), with group games and that *no* users are members of that group, so it can securely save files that are accessible to all users during gameplay (bones files) and ensure that the user cannot access/change their current save file. These two expectations are incompatible with each other, and end up creating a security issue that upstream would never expect (as no users can be in the games group traditionally). Is Nethack's group expectation hard-coded? If not, then what's stopping nethack from using another, self-made group (like 'nethack') to arbitrate the bones files? If it *is* hard-coded, then can we produce a (hopefully simple) patch? -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBAgAGBQJUrjCEAAoJEJUrb08JgYgHlQYH/RmOzRLebkffwJ3efcR7sCw7 i/CU1vBoHdyW86Us3X/PwYl47GSPKaiLTMhTnPNOtQP4wqdkHTXrG4fvQfLKP7Lg RC8EkR0kgkdBSVqJIt70Gfxu0fV0o55rOf2bYcDC+RF1HLMWNTQ/e8SkcfDmUAum EMRJnqUq3dsiIWbr/WeR27XWxlFz1Oo/jjIoGWvO6JodkZnsHbFlCalycAI1xQv5 05BecTx0FDwC1xWrdt3+UaoyrvOrIqz5mxiGM6B+WgEMU8OyURFprljX8a21WuFV RcipixJvIKvxEmbI+cC0T9bapRfA1NBW+r6nVk1wsGiJwhJ2biF2HVS+ZwN9Y34= =lEkc -END PGP SIGNATURE-
