On 2017-03-13 21:33, Rich Freeman wrote: > [...] > > And this is why I think you are talking past each other. Kristian is > thinking in terms of security being a special project, and Thomas is > thinking in terms of security being a normal project. Both are making > completely reasonable suggestions in those contexts.
Thank you for this good summary. Really appreciated. From my view, you got all the stances. > The two areas that I see as possibly pushing security towards being a > special project are: > 1. Masking or otherwise directly touching packages without waiting > for the maintainer if the timeline passes. Like said, clarifying the p.mask thing would be nice. Is it required? No, I don't think so. At the moment I still trust in the Gentoo project to find a solution in case we would have a situation like described [1]. But maybe I am too new and missed a fight ;-) > 2. Being able to represent Gentoo on special security mailing lists > that have tight distribution. (If somebody betrays this trust Gentoo > could find itself cut off from all such lists, so Gentoo should use > care here.) People trust people, not titles. While it is important to have a security contact, and we have security contacts listed [2], people will contact a dev they know/trust using established channels and don't check for current project lead. And this is a good thing. Yes, anyone with @gentoo.org address could do harm to the Gentoo project. You cannot prevent situations like that. If someone decides to do something stupid in the name of Gentoo he/she can do. All we can do is to clearly distance ourselves from the person and making clear using our channels that this is not Gentoo's position and that we have taken actions (any project may decide to kick someone; go to ComRel; go to Council... our process to deal with situations like that is well defined). When I am saying the security project isn't special I am saying this about the need of special privileges in the Gentoo world. Joining the project is special. At least I am not aware that there are other Gentoo projects where you have to pass an additional recruitment process (besides infra and QA project). This is needed because project members will get in touch with confidential information. People sharing information with Gentoo security project trust in Gentoo to handle that as expected. If someone manages to join Gentoo security project, become a full member and then starts to abuse gained knowledge (i.e. share/use confidential information), this would damages the trust in Gentoo for years. I.e. external sources would stop sharing information with Gentoo. But this is nothing a project lead can prevent. Also, if the project lead would be the only one responsible, what should happen in that case? Should the lead who failed because he/she trusted the wrong person also leave the Gentoo project and we are done? > I'll finally note that there is also a possible compromise. We might > make security somewhat special, but decide that its powers aren't that > important and so let it self-govern without forced Council > interaction. Even so we should probably create some avenue for appeal > so that the next time an argument comes up over whether long-term > masks vs overlays are the right solution people feel like they had > input into the decision. Sounds good for me. See also: ========= [1] https://archives.gentoo.org/gentoo-dev/message/46fdaade8901c2bda3197aaf0e7b5d87 [2] https://gentoo.org/support/security/#contact -- Regards, Thomas
signature.asc
Description: OpenPGP digital signature
