How do we review the code nobody understands?

@Paul Yang yes, I agree, we seem to be doing this somewhat organically (if not consistently) already. I'd just be looking for a level of formalization, if for no other reason than to give new people the project a way to find/identify who those codeowners/maintainers are. In so far as approvals counting goes, that probably needs some discussion as to the actual mechanism (i.e. we would need some tooling changes so that people in code owners could be treated like comitters for the purposes of approval without giving them write access to the tree), but in general, I agree with the approach.

@Neil Horman Absolutely, this way is a very effective collaboration method of a 'community' for involving more people in

Has AI review been considered (i.e. copilot in GitHub)?

@Todd Short I highly agree with this

@Paul Yang I'm not opposed to adding copilot or codeQL or some such to our review process, but I would personally have to see some effective reviews from an AI before I placed anything close to the same trust that I would place in a maintainers file set of people to it.

I wasnt suggesting that OpenSSL resources need to know 'everything', it could be divided per platform for example.

I would suggest that if we are relying on code coming in from external sources for assembly that we should be a bit more strict when reviewing in terms of asking for more documentation/comments explaining the code and techniques used. A fair proportion of the contributors in this space seem to disappear over time.

It's possible to formally prove various things about the assembler. This will require a large effort at the start. But the result is going to be that we have a higher trust that the code does the right thing in corner cases.