Hi, I am quoting <https://wiki.gentoo.org/wiki/User:K_f/GLEP:Security>:
> == Abstract == > This GLEP outlines the purpose, responsibilities and abilities of the > Gentoo Security Project. > > == Motivation == > This GLEP aims to document the processes of the Security Project and > enpowering the project to operate on a wide scale across the Gentoo > tree, within the structure provided by this GLEP. I disagree with that. It looks like this GLEP was formed on base of GLEP:48 [1] but I think this is wrong (like I would withdraw GLEP:48 now that I read it). For example, the purpose and the process of a project shouldn't be part of any GLEP. These are project internal details and every project is free to change its process without a new GLEP approval. Also, for me the draft goes completely in the wrong direction. I would get rid of the entire "Security Project Lead" and "Joining the Project" paragraph: Gentoo security project is a project like any other Gentoo project: The team should decide in regular meetings how they want to do things. The team is encouraged to elect a lead each year like any other project is encouraged to do. In case of tied votes, the vote of the current lead will be counting twice to get a decision but this isn't special so we don't need to write it down for the security project. Because project lead may change each year, the absolute majority of the whole team must accept new members. Otherwise, the new project lead would be responsible for people who maybe in the project just because the previous lead liked them but he/she maybe don't trust them. But again, this is something the project would decide and shouldn't be handled in a GLEP. The "Security package version/revision bumps and package masks" looks relevant because it defines the "power" of the project: > * The Security Project does not want to override the maintainer's > autonomy, but if inactive might be required to fix a security > vulnerability by means of version bump or application of a patch in > a revision bump. I am not sure about this point. I am not aware of any GLEP/rule disallowing devs to touch packages of any other devs. When I did my quizzes I learned that you should have good reasons to do so and that you are responsible for any breakage. In other words: Only do that after you tried to contact the package maintainer (create a bug, write an email, try to talk to the maintainer/project in IRC...) but did not get a reply in time and always respect maintainer's coding preferences (i.e. don't rewrite the whole ebuild because you would do things differently when you just wanted to add a small patch fixing a build issue). In other words: Everyone is allowed to bump a package so we don't need to write down that security project is allowed to do that as well. It is different for QA project because QA members maybe rewrite a whole ebuild and ignore maintainer's preferences for project goals. > * If a vulnerability is unlikely to be fixed by upstream or the > package's maintainer it might require a package mask. Such mask > should never break the stable dependency tree. From my understanding the intention of this point is to make clear that security project members are allowed to remove an ebuild/package for ARCH users. I would get rid of the "such mask should never break stable dependency tree" because this a general rule. However, sometimes this might be required: Imagine an application (app-misc/awesome) which still depends on dev-lang/openssl-0.9.8 or any other ancient version of a dev-lang/* package. The application itself is fine and working but no one is providing an update to work with newer dependencies. Now the dependencies are EOL and a vulnerability was discovered. Because everything else has already migrated to a newer version no one is providing a patch. To get stable tree clean we would have to apply a package.mask. This would break the stable dependency tree so we would also need to take action against app-misc/awesome. This is something we should write down so everyone knows that the Gentoo security project has this power. > * These actions, performed on behalf of the Security Project, should > only be used if the Project finds it is in the best interest of > users and fellow developers to have the issue addressed as soon as > possible. Such action needs to be approved by the Security Project > Lead (or if a Deputy is appointed; the Deputy) This should be removed because this doesn't belong into a GLEP. That's how the project internally works. And if the team decide to change how it handle things this shouldn't require a new GLEP. "Subscription to security lists and acting on behalf of Gentoo", "Auditing and public reporting of issues in the name of Gentoo", "Embargoed lists" and "CVE Numbering Authority (CNA) status" don't belong into a GLEP. This is about the project's internal organization. See also: ========= [1] https://wiki.gentoo.org/wiki/GLEP:48 -- Regards, Thomas
signature.asc
Description: OpenPGP digital signature
