Proposal: deregulate secteam, random team

Bryan Drewery bdrewery at
Mon Mar 5 21:08:13 UTC 2018

On 3/2/2018 11:12 PM, Conrad Meyer wrote:
> 3. Lift access restrictions on security bugzilla to all src
> committers.  More security-interested eyeballs can be triaging,
> prototyping, reviewing, and evaluating security solutions.

I agree with your analysis and that secteam has been a slow broken
blackbox for as long as I can remember.  However I think the 'opening to
all' ideas won't work as we just saw how "trusted" we all really are.
We've had developers compromised before as well.  Getting on
embargoes/NDA will require that we actually have a trusted group of
people who can view these issues.  I think it's one thing to grant all
developers access to Coverity but another to see ones that have been
analysed and reported already.

Anecdotally, I was mailed about a security bug last year and replied
with my suggestions on how to tackle it.  Then a few months ago I was
given access to the bug and effectively it's on me now to fix it.  So
I'm seeing how broken it all is.  I need to make time to address it, but
IMO there is no "security team" that is actively working on bugs.  There
is only effectively a project manager that is herding people to work on
the bugs as needed.  We may have some people there that are respected
for reviews as well.  The slow review problem is very old.  We climbed
uphill to get Pkg and Poudriere deployed and had all of these overly
complex schemes for package signing rather than keeping things simple.
I'm happy with where it is but still think TLS for some of the solutions
would have been simpler for the first implementation.  I don't even
remember anymore what tradeoffs we made in Poudriere to get past a
security review but it was somewhat informal; let's fix things we know
they may complain about (which is good anyway) but in the end I'm not
sure a review was actually done for Poudriere and we just moved forward.
 I forget.  I do know tinderbox underwent a grueling review which
effectively killed it.  I seem to recall for Poudriere that any kind of
web server with a server-side application was verboten by secteam at the
time but that kind of blanket rule was just unhelpful and lazy.  Having
a real design discussion about sandboxing/privsepping a web application
piece and restricting it from using exec() never happened, only a
blanket rule.

I'm saying that I agree that we need a <lot> more people on the team but
we need to be careful about going too far as it may hurt us actually
getting into embargoes.  Secteam has often seemed to me to be 1 person,
maybe 3, who are overly burdened.

I think we could split up some of the roles of secteam though.  I don't
think the security team officer needs to be the one to signoff on every
review.  I think we could easily just have a mailing list of interested
security people who want to review new implementations, like arch@ in a
way.  As for secret bugs that won't work but the right people could
still be brought in as needed.

Lastly the lack of status updates on Meltdown/Spectre is an
embarrassment.  This is not a statement on the implementation or testing
time, but only on the project communication about it.

Bryan Drewery

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <>

More information about the freebsd-arch mailing list