Otto Kekäläinen <o...@debian.org> writes: > Sure it is more convenient to, you as you most likely have some well > optimized Emacs email setup going on. But more secure? Surely signed > commits and a system that tracks real git commits and who pushed what > from where is more secure than plain-text patches in e-mail.
In general, no. Using a forge introduces numerous opportunities for race conditions (reviewing a PR and having someone else update it before you merge it, for instance) and compromises of other systems (the forge shows you something different than what it would merge when you press the merge button). It is then possible to configure the forge to eliminate those again, but it has to be done carefully and nearly all users of forges do not do so. In contrast, if you carefully review a diff that is sitting locally on your computer because, for instance, it is in your email, and then you apply exactly that diff that you reviewed rather than pulling it from somewhere else or clicking on a button on a web site, this is indeed inherently more secure. It reduces the security risk to only compromise of your local system and your own failure to understand the diff that you're reviewing, both of which are going to be an issue under most review systems and are mostly not avoidable. You generally lose some other ancillary properties (cryptographically-attested authorship, for instance), but in terms of the security of the code itself, it's generally a better approach. I think you're assuming that because email itself is insecure, Ted's approach is less secure, but Ted's point is that he's doing a detailed code review and therefore doesn't care very much about anything that happens upstream of that. It's the code review that creates the security properties he's after, and doing that locally in his email produces a very tight and close chain of custody between the code review and the commit, whereas a forge weakens that chain of custody considerably. All of security is a trade-off and a lot of people prefer the user experience of a forge for other reasons and are willing to accept the additional security risk or carefully configure the forge for the security properties they want. Those folks are not wrong to do that. It is to a very large extent a matter of opinion about competing trade-offs. But if what you care about the most is ensuring that the code that was reviewed is the code that was committed, Ted's approach is going to win in most security scenarios that I can think of. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
