From owner-freebsd-arch@freebsd.org Sat Mar 3 07:12:09 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 24070F45C0D for ; Sat, 3 Mar 2018 07:12:09 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id B225F71FFD for ; Sat, 3 Mar 2018 07:12:08 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 736F0F45C0A; Sat, 3 Mar 2018 07:12:08 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4F5F3F45C07 for ; Sat, 3 Mar 2018 07:12:08 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-it0-f41.google.com (mail-it0-f41.google.com [209.85.214.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E3D9471FFA for ; Sat, 3 Mar 2018 07:12:07 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-it0-f41.google.com with SMTP id w19so4144540ite.0 for ; Fri, 02 Mar 2018 23:12:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:from:date:message-id :subject:to:content-transfer-encoding; bh=6ytfk+bnxc2vC40GCJizBzd8121W3YUYkxoCj2jWbj8=; b=H5Jl3QO+yAkhcpsli1PGkevgKy9OC4GBVRFg6FFq2PAx4auQq7YPaz6aQ1Ra49BqaD cGaHaEFT6d+6e4hA92BfGebOSQJt67W3uByeid40l7dMCQpcpTWDkKfJJASMSvlblU1/ 0e+fEWoxgd/ONPfykAaBkwcbZzF/hIKZHS/biCP6WXbnPsihP0xl17Gh10u9OX5+qZzu zWiNm7V5dZ9xr1rJndnxCUd6MQUh7O678qinGoDsRJ7wVtu0QdJDFpFysOgiSJG3/VVH WNn3A8/TdwYVoqGSSvs5o8hXFH66ksV831rwMt+VnXLeYyn9PKMneHffVTX2BGCNqGDJ kNiQ== X-Gm-Message-State: AElRT7EFPtgyvCSVxcSht+nhSzs5zPTncWmLs9SVXsfNtjmiLDq9D/fB f1FDEezdD2sYuXxx9f5zrz04zh/S X-Google-Smtp-Source: AG47ELudPgNyKlDkDUqGHKWG+AqCrLQNhhS3S7fqOKQCk/UfUvKs6ZsEURFLqYkdTGm0a4Ida699Jw== X-Received: by 10.36.166.10 with SMTP id q10mr5665658ite.132.1520061121464; Fri, 02 Mar 2018 23:12:01 -0800 (PST) Received: from mail-it0-f50.google.com (mail-it0-f50.google.com. [209.85.214.50]) by smtp.gmail.com with ESMTPSA id u129sm1762409itb.5.2018.03.02.23.12.01 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Mar 2018 23:12:01 -0800 (PST) Received: by mail-it0-f50.google.com with SMTP id w19so4144530ite.0 for ; Fri, 02 Mar 2018 23:12:01 -0800 (PST) X-Received: by 10.36.92.205 with SMTP id q196mr2112408itb.135.1520061121040; Fri, 02 Mar 2018 23:12:01 -0800 (PST) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 10.2.30.149 with HTTP; Fri, 2 Mar 2018 23:12:00 -0800 (PST) From: Conrad Meyer Date: Fri, 2 Mar 2018 23:12:00 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Proposal: deregulate secteam, random team To: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2018 07:12:09 -0000 Hi all, Being on secteam, essentially a post-release engineering team, is a thankless job no one wants to do. It's largely keeping quiet about embargoes and issuing patches and EN to releases. However, due to a number of factors, our secteam can't seem to operate effectively. We struggle to communicate effectively to the wider FreeBSD organization and the community; we seem unable to reliably produce patches by the time embargoes lift. Some factors help explain this: 1. First and foremost: we're not always getting included in embargoes anymore. This is exemplified by the Spectre/Meltdown FUBAR. 2. secteam is tiny and workload tends to alternate suddenly between "no work" and "everything is on fire." Are there more than *two* active members at this time? No one on secteam is full time. 3. Historical policies about not commenting on active vulns when a patch was not prepared. This is just historical stupidity we haven't managed to leave behind =E2=80=94 if a vuln is being exploited in the wild,= we *must* comment on it. Even if we have to say, "we don't have a mitigation prepared yet and don't have an ETA." This kind of policy makes secteam look not just opaque, but foolish. 4. FreeBSD is dying ;-). The lack of communication is killer. Maybe secteam is incredibly active and efficient, but *no one can tell*, because they have zero communication with the rest of the project. Adding on to the burden: for some bizarre reason, we've also foisted the responsibility of code review of arbitrary parts of the kernel tree on this post-release engineering team via SVN commit hook. (And, segueing into the subject of this email, the random team as well). Secteam hardly has time to triage security bugs and issue ENs. Turn around time on any code review involving secteam is measured in *weeks* or *months.* Meanwhile, there is a wide body of security-conscious developers who are capable of reviewing and evaluating crypto and security code. They may not be interested in pushing ENs to releases, or their availability may be irregular. But they may be motivated to help, and are totally unable to contribute in the status quo framework. Furthermore, the review-gating ends up as a big double standard. Anyone in the outgroup waits weeks on even the most trivial change to be reviewed, but secteam or random team members are free to jump in and commit things that breaks the tree with no review. (Not to name any names, but, r285422. And all commits with "Approved by: so (/dev/random blanket)" in the commit message are examples of this special privilege, if not a sure sign of breakage.) I propose deregulating secteam and random team and stripping them of their review authority. 1. Remove "blocking reviewer" (Phab Herald and svn commit hooks) status for teams that can't demonstrate consistent, timely review. That's all of the above mentioned teams. 2. Active pruning of inactive team members. If membership is too low to meet the mandate of the teams, *padding the membership with inactive members does not fix the problem*. 3. Lift access restrictions on security bugzilla to all src committers. More security-interested eyeballs can be triaging, prototyping, reviewing, and evaluating security solutions. a. If there are ports security issues tracked in security bugzilla, access can be extended to relevant porters on a bug-by-bug person-by-person basis. 4. Maybe just get rid of security bugzilla entirely? Tracking our security bug work in the open at least provides transparency, and maybe transparency helps motivate results. Flameproof pants on; please go ahead and bikeshed. Yours, Conrad