Re: purpose and implementation of code reviews

[Patrice Dumas]

On Thu, Apr 04, 2024 at 05:13:32PM +0200, Bruno Haible wrote:
> Since last week [1], we have to add another benefit:
>   * It can detect (and thus avoid) evil behaviours from individual developers
>     (even co-maintainers).

I think that procedures for reviews with a purpose of better security,
in particular for the purpose you mention should be treated differently,
for two reasons.

1) The perimeter is different, security critical components correspond
   to a fraction of free software and of GNU software.  To take an example
   in GNU Texinfo, I think that install-info is critical, as it is run
   as root, and process external data (installed manuals), but I think
   thay the Info readers and Texinfo processors could only be used for
   security breaching in convoluted scenarios.

2) The requirements for a review are different.  To me the process
   should try to ensure that the review is done independently:
    - done by a different person as the code.  Not easy when contributors
      are only identified by a mail address
    - done by independent persons.  Even harder to make sure of.  There
      are probably criteria that can help here, for instance, old time
      contributors who have shown interest in the politics of the
      GNU project, are persons that have been met by others in real life
      are probably more trustful, but it is probably difficult to be
      certain that two contributors are not in cahoots.

I have zero knowledge on that issue, but if others have knowledge on how
a process of review could be setup such that it makes it more likely
that the reviews for security relevant code is done independently, that
would be nice.

-- 
Pat