> On Feb 25, 2019, at 11:20 PM, Rich Persaud <pers...@gmail.com> wrote: > > On Feb 25, 2019, at 10:14, George Dunlap <george.dun...@citrix.com> wrote: >> >> This is an attempt to do a 'post-mortem' on XSA-283, to find out how >> the error came about, and consider what changes we could make to code >> / processes to prevent such errors from happening in the future. The >> Security Team hopes to make it a habit to perform such analyses in the >> future. > > ... > >> There was no public review of this patch; the commit contains no R-b >> or A-b. Keir's only comment on the patch before committing it was to >> note that it conflicted with a different patch and ask for a rebase. > > Would it be useful to count/triage commits without R-b or A-b?
It would be easy to do, but I doubt it would turn up anything useful; essentially it would turn into “With-Keir” and “After-Keir”, as the discipline that nothing get checked in without an [RA]-b was introduced after Keir sort of faded from the scene. I’m not sure that Keir was in the habit of adding [RA]-b tags to commits even when they were given. So a search of the tree for all commits without [RA]-b tags would likely just turn up everything for the first 6-8 years of Xen development; not particularly useful if looking for further potential issues (which is, I assume, the goal of your suggestion). The reason I pointed it out was that *in general*, I don’t think exhorting reviewers to be “more vigilant” is that helpful; but it does seem to me that in this particular case, it’s likely that our modern reviewing process would have flagged this as at least ugly / unnecessary (even if the reviewer didn’t spot the potential security issue). That said — perhaps something that would be concretely useful would be to ask maintainers to regularly look at the commits that introduced security issues, so that they can get a feel concretely for what sorts of patterns to look for. -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
