[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-hackers
Subject:    Re: What is the status of the FreeBSD development process now?
From:       Theron <theron.tarigo () gmail ! com>
Date:       2022-11-05 4:56:14
Message-ID: 53d29778-ce06-22c6-40a8-5023443f976f () gmail ! com
[Download RAW message or body]

On 11/4/22 18:14, iio7@tutanota.com wrote:
> It's great that things have improved, but without a clear set of rules, such that nothing
> gets into the current branch from a committer that hasn't been reviewed by at least
> another developer, the problem will just repeat itself.
> All it takes is that when someone has made a commit, someone else has to look it through,
> provide an "OK", and then it can get into current, without the "OK", it stays out of current.
>
> This is not a guarantee, but at least something like the wireguard problem, would most likely
> be prevented in the future.

It's not clear that you have any suggested solution for the "problem" as 
you have defined it.  The wireguard commit was signed off by an 
independent reviewer, for what that was worth.  It wasn't the exact 
version that was committed, but in largely the same problematic state.  
Whether the committer could have committed something substantially 
different from the contents of the review thus circumventing the review 
process was not the problem in this case.

Furthermore, the newly added module presented a vulnerability *when 
loaded*; this was not an introduction of a vulnerability in existing 
configurations of systems running current.  It's simply not reasonable 
to expect current to remain thoroughly stable and secure after blindly 
enabling newly landed features and to do so on a production system is 
highly irresponsible.  Review of current is ongoing from time of 
committed features to feature-freeze for the bugfix-only review period 
and eventual release.

[prev in list] [next in list] [prev in thread] [next in thread]