Otto Kekäläinen <o...@debian.org> writes: > If you are concerned about the PR being updated without you noticing it > (very unlikely), you can git pull it locally, review locally and git > push on mainline, which with all modern Forges will automatically close > the PR/MR/issue.
Yes, that would also work. That's not what people using forges *actually do*, though, which I believe was Ted's point. Nor do people advocate forges because they're advocating that workflow; quite to the contrary, people who want others to use forges generally want them to review MRs directly on the forge for a host of other reasons. > Using real git commits with SHA hashes, signatures, SSH key protected > pulls and pushes, multiple server logs on who did what etc is easily > more secure than using plaintext emails. Ted's workflow doesn't rule out signatures, SSH-key-protected pushes, and other similar security properties. I suspect it usually terminates them at Ted (the reviewer) rather than the original author, which has pluses and minuses. As I said explicitly, it does give up some tracing of the origin of the original MR, in favor of removing a lot of complexity and potential for security issues in the chain of custody between the review and the commit. This is a trade-off; people will have different opinions about which is more valuable. I personally agree with Ted that the chain of custody is a very nice security property and the way that he does patch review via email is more secure than the way people normally use forges. (Personally, I consider it much less *convenient*, but that's a different argument.) As I said in my original message, you can claw back some similar properties if you configure the forge very carefully, but most people do not. > The big question here you seem to avoid commenting on is what is the > workflow you expect the next generation to seriously adopt? I didn't comment on that because I don't have an opinion on it. I only commented about the security analysis that you did, which I believe is wrong. There is a tendency in these discussions to assert that one's preferred workflow is strictly better on every possible axis, there are no legitimate trade-offs, and the other person's workflow is simply wrong. This tendency annoys me, so sometimes I say something when I think people are oversimplifying. I don't disagree with many of your arguments in favor of forges. I use forges myself quite heavily. But they are not strictly better; Ted's approach is more secure than the normal forge workflow. Life is full of trade-offs, and I think arguments go better when they're acknowledged. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
