Conrad Meyer
2018-03-03 07:12:00 UTC
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 — 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
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 — 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