Prevent resetting vote count on commit

[MINIMAN10000]

No description provided.

[amoffat]

Originally, I believed a change like this would allow someone to collect "yay" votes, then slip in a malicious change at the last minute and get approved. But because a new commit pushes the voting window out again ~2 hours, there doesn't seem to be any "last minute." 👍

[MINIMAN10000]

Alright thanks for the heads up on the new commit setting the voting window out 2 hours. But since #48 killed the server, doesn't that mean it went through?

Was there a 2 hour period where no one voted no? Did they think that it already had enough nay votes because the number of negative reactions looked overwhelmingly negative or did the PR slip through unnoticed during that 2 hour period.

[amoffat]

@MINIMAN10000

Did they think that it already had enough nay votes because the number of negative reactions looked overwhelmingly negative

I believe that's what happened. Take a look at the merge commit 9500e94. It was only counting votes after the most recent change, and attention had mostly died down.

[amoffat]

i honestly can't wait until this merges

[reddraggone9]

I'm not voting either way on this, but it should be noted that something similar to #48 may happen again for similar reasons (mostly because Github sorts PRs by creation date by default). Somebody could post something cool or funny with WIP in the title, get a fair number of up votes, and change the PR to something malicious a day later after it's fallen farther down the list. Then it'll be up to the people who are both watching that thread (or the entire repo) and awake to draw enough attention to it to drown out the previous upvotes before the window closes.

[reddraggone9]

I was too late. Oh, the humanity. Or is that irony because of the similarity of the situation to the theoretical attack I described?

[amoffat]

I agree with you @reddraggone9. I think this is one of those lesser evil situations. Doesn't seem to be a clean way to not have some chance of merging malicious code in through deception

[MINIMAN10000]

@reddraggone9 the way I saw it we either dealt with the fact that the voting numbers made people feel like they didn't need to vote it down which would result in passing the vote silently and what I have currently changed it to, we know the votes the PR. The only problem is what the PR could potentially change.

I would recommend to change the voting again. I have two recommendations

1. Look through the time on all votes. Only toss out the positive votes. Basically the opposite of how it was before this pull request.

This is part of the reason why I wanted this to be pulled, get_pr_comments since caused github to not send any comments before the requested time. I desire that we get all the votes from github and then parse them ourselves.

2. After a PR is passed instead of it immediately committing, chaosbot posts that the vote has passed and will enter a final voting period. People then vote on that chaos bot post which then finalizes the PR after the timer passes and it passes the second vote.