Hi, On Wed, Mar 4, 2015 at 10:46 AM, Kathy Lussier <[email protected]> wrote: > I really think we need to increase the transparency of these bugs > without compromising the security of our systems in the process. Any > site running Evergreen in a production environment should have a right > to know when a known security bugs affects their system, especially > when it comes to those bugs that have been left unresolved for many > months. Maybe we could allow one trusted person from each site > subscribe to security bugs or maybe there are other methods for > sharing this information for Evergreen sites. I would like to hear > thoughts from others on how we can improve transparency.
One avenue towards improving the transparency of the security process is to ensure that there is a clear process for joining the security team. I am putting forward the following definition of the team and criteria for membership, and I am issuing a public call for interested people to join the security team: --- BEGIN --- The purpose of the Evergreen security team is to review reports of specific security flaws in Evergreen, to write and test patches to fix or ameliorate those flaws, and to perform security releases. Membership in the Evergreen security team is available to individuals who meet all of the following conditions: (1) They request membership. (2) They promise to adhere to the consensus of the security team regarding when to publicly disclose security issues. (3) They promise to maintain the confidentially of discussions on the open-ils-security mailing list and security bugs on LaunchPad. (4) They promise to provide assistance to the security team. Such help can take the form of provide substantive commentary on reported security issues, writing patches, testing and reviewing them, writing security documentation, and assisting in the process of preparing and publicizing security releases. (5) They operate or support the operation of at least one production Evergreen system known to at least one other current member of the security team. (6) They already have access to various tools required to participating in a meaningful fashion, to wit: a registered account on LaunchPad and at least one public key registered with the Evergreen Git server. (7) The current members of the security team come to a consensus to admit the new member. The security team reserves the right to reject applications, and will explain their reasoning to the applicant if they should do so. Applications will be reviewed promptly. Membership applications may be made by contacting one of the current security team members; a list of the current members' names will be maintained on the Evergreen wiki. Violations of the promises in (2) and (3) may result in immediate expulsion from the security team. Membership in the security team belongs to individuals, not institutions. Membership comes with an expectation that each member will actively participate at least part of the time; it is not to be treated simply as a means of gaining early access to information about security vulnerabilities in Evergreen. The team membership list will be reviewed annually; members who have not made substantive contributions to the team may be dropped from the list, but are free to apply to rejoin. Members of the security team will have access to the following restricted resources in order to carry out their work: - membership in the private security group on LaunchPad, which will allow them to see and - a subscription and access to the private archives of the open-ils-security mailing list - access to the Git repositories hosting security patches in progress. --- END --- This can also be found at http://evergreen-ils.org/dokuwiki/doku.php?id=dev:security#security_team This proposal and invitation is offered in the hope that it will be a means for the security team as a whole to do better, but I recognize that it's also only a first step. It does embody certain assumptions, including: * some security issues need to be kept private for a period so that a fix can be released in an orderly fashion * a group of volunteers can manage private security issues in a timely fashion -- and this is where the security team has fallen down * an injection of one or more fresh volunteers can help revamp the group and its processes Each of these assumptions is debatable. While the current members of the security team who have participated in the discussion around this proposal have either assented to it or in one case, expressed neutrality, it does not, I think, represent the result of an enthusiastic consensus. Nonetheless, I think it is a way forward. Regards, Galen -- Galen Charlton Infrastructure and Added Services Manager Equinox Software, Inc. / The Open Source Experts email: [email protected] direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org
