Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make a formal time period and process for patch review #12

Open
addisoncrump opened this issue Aug 3, 2023 · 0 comments
Open

Make a formal time period and process for patch review #12

addisoncrump opened this issue Aug 3, 2023 · 0 comments

Comments

@addisoncrump
Copy link

addisoncrump commented Aug 3, 2023

To ensure that the fix which is applied is complete, the reporter should be given a fixed means by which to access and review patches before it is merged and the advisory is published. In this way, we can ensure:

  • correct documentation regarding an incident
  • correct patch notes
  • the fix is complete and does not contain any missed scenarios

When reporting the rust-lang/regex untrusted regex DoS, there was ample time to review the fix -- and we found that it was indeed incomplete, and were able to remediate it before the advisory and patch were published. Also, the advisory, patch notes, and documentation regarding the incident are perfectly correct. Given that experience, I would say that, from my perspective, the use of GitHub security advisory system with hidden forks for patches is a good review platform. Additionally, a week of fix review time is a good minimum to ensure that all sides have fully considered the ramifications of the fix.

@addisoncrump addisoncrump changed the title Make a formal time period and process for reporter patch review Make a formal time period and process for patch review Aug 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant