Dealing with history containing sensitive info posted accidentally

[Cleop]

Taken from: https://github.com/dear-github/dear-github/issues/129

Original question on this issue: what do we do to handle cases where sensitive info is posted accidentally?

Some comments from the issue above:

if someone posts sensitive information in a comment and then redacts it later (or the company redacts it for them, or a bot, etc.) then it shouldn't be there to show in the history as a safety consideration.

What if the ability to permanently delete content was limited to the comment author and repository owners only? Then make the editing occurrences (person and time only, no content) visible no matter what.

Regarding sensitive data redaction, although I think it somewhat a red herring, perhaps give the repository owner authority to delete segments which would then show up as [REDACTED] in the content history view.

---

As a github-backup user admin I want to be able to edit the history of comments giving a reason for doing so so that I can remove any disrespectful or confidential information that may be accessible.

As @nelsonic says, this would not delete the comment history but make it inaccessible to non-admins so that other "Admins" can still see the original comment (with the sensitive data) just so that: (a) a "rogue" Admin does not maliciously remove things from issues or add additional acceptance criteria (one of the original issues we are trying to remedy) (b) the other Admins can see what constitutes a "bad comment". (c) other Admins can "revert" the Edit if they deem it was unnecessary This is related to: dear-github/dear-github#113 ("GitHub Permissions are Broken")

• [ ] An admin role exists
• [ ] I can log in as an admin
• [ ] An admin can click to edit a version of a comment
• [ ] The admin can edit the version of the comment (in a text area) and then save it to update the version that displays.
• [ ] The admin must list a reason for making the edit

TBD:

• should all users be able to see when an admin has made an edit?
• and should they be able to see the reason why?

[nelsonic]

@Cleop great point! (thank you for opening this issue!) This is a consideration / requirement we should add to our "backlog" and address as soon as we face the use-case ourselves (or when a "paying customer" of the GH Backup Service/App requests it!)

In the case of "security credentials" like a password or AWS token, firstly, people should "know better" ... (people should be trained to be security-conscious) but in the case where something disrespectful/insulting is posted, the repository "Admin" (anyone who can administer the project) should be able to EDIT the history of comments but they are required to leave a "commit message" explaining why they are editing the History. Furthermore other "Admins" can still see the original comment (with the sensitive data) just so that: (a) a "rogue" Admin does not maliciously remove things from issues or add additional acceptance criteria (one of the original issues we are trying to remedy) (b) the other Admins can see what constitutes a "bad comment".
(c) other Admins can "revert" the Edit if they deem it was unnecessary This is related to: https://github.com/dear-github/dear-github/issues/113 ("GitHub Permissions are Broken")