Hi Joel, On Wed, Apr 03, 2024 at 08:53:21AM -0500, Joel Sherrill wrote: > On Wed, Apr 3, 2024, 3:09 AM Florian Weimer via Gdb <g...@sourceware.org> > wrote: > > > * Guinevere Larsen via Overseers: > > > > > Beyond that, we (GDB) are already experimenting with approved-by, and > > > I think glibc was doing the same. > > > > The glibc project uses Reviewed-by:, but it's completely unrelated to > > this. Everyone still pushes their own patches, and there are no > > technical countermeasures in place to ensure that the pushed version is > > the reviewed version. > > > > Or that there isn't "collusion" between a malicious author and reviewer. > Just tagging it approved or reviewed by just gives you two people to blame. > It is not a perfect solution either.
If those tags are given in a mailing list _and_ mails to the mailing list are PGP-signed, then you can verify that the tags were valid, and not just invented. And with signed commits you have a guarantee that one doesn't overwrite history attributing commits to other committers (it could happen with authors, and indeed it seems to have happened in this case, but if patches are sent via signed mail, then it's also verifyiable). In the email side, there are a few things to improve: For sending signed emails, there's patatt(5) (used by b4(5)), but it might not be comfortable to use for everyone. For those preferring normal MUAs, neomutt(1) is an alternative: <https://neomutt.org/feature/cli-crypto> And I have a few patches for improving the security of protected messages: <https://github.com/neomutt/neomutt/pull/4221> <https://github.com/neomutt/neomutt/pull/4227> And the corresponding security-vulnerability reports: <https://github.com/neomutt/neomutt/issues/4223> <https://github.com/neomutt/neomutt/issues/4226> <https://github.com/neomutt/neomutt/issues/4234> <https://github.com/neomutt/neomutt/issues/4236> <https://github.com/neomutt/neomutt/issues/4237> (I find it funny that I didn't know about this xz issue until yesterday, so not when I reported those issues, but they are interestingly related.) It would also be interesting to require showing range-diffs between patch revisions. They make it much more difficult to introduce a vulnerability after a reviewer has turned its mins into approving the patch. Of course, the patch could go in if the submitter lies in the range-diff and the vuln is undetected, but then it can be verified a posteriory to prove that there was a lie. I recently started applying all of these (signing all email, including patches, sign all commits and tags, and provide range-diffs), and it's not too uncomfrotable; I'd say it's even more comfortable than not doing it, as it allows me to easily roll back a patch to an older revision if I find I introduced a mistake, and find where I introduced it. Have a lovely day! Alex -- <https://www.alejandro-colomar.es/>
signature.asc
Description: PGP signature
