Wouldn't an easier way to fix this (without having to change the way review comments are set out) just be to only allow track "r+" comments if they're unedited? Github seems to support this facility according to the API documentation (just check if created_at and updated_at are the same). If a reviewer wants to backtrack on their review confirmation they can just delete the comment.
On Tue, Jun 25, 2013 at 11:17 AM, Graydon Hoare <[email protected]> wrote: > Hi, > > Some clever folks on #rust have pointed out that there is a (somewhat) > exploitable security flaw in the way bors consumes r+ comments. > Specifically, github permits a repository owner, in some circumstances > (which we can't quite figure out) to _edit comments of other people_ on > commits in their repository. > > This means that the following attack scenario would work: > > > DrEvil: Files a PR > Reviewer: Comments "this is awful!" on PR head-commit > DrEvil: Edits comment to "r+ p=100" and lands change > > So, to work around this I'll probably teach bors to require review > comments in a different fashion, such as "r+ <sha1>" on the PR itself, or > similar. In the meantime, reviewers beware: anything you say on the > head-commit of a PR can be rewritten by the submitter into an r+, so assume > that "commenting _at all_ implies approval". > > -Graydon > ______________________________**_________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/**listinfo/rust-dev<https://mail.mozilla.org/listinfo/rust-dev> >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
