The current SECURITY.md file is minimal and only lists two contact email addresses. While this provides a basic way to get in touch, expanding it could significantly improve the responsible disclosure process, prevent low-quality reports, and save the maintainers' time.
I would like to suggest expanding SECURITY.md to cover a few essential aspects. Here are some specific ideas that the team could consider adding:
- Scope and Eligible Versions: Clarify which branches or versions are eligible for security reports (e.g., whether a vulnerability must be reproducible on the
master and/or dev branch or the latest stable release to be considered).
- Definition of a Security Issue (Threat Model): Define what actually constitutes a security vulnerability in the context of Unicorn. For example, explicitly mentioning:
- Memory safety issues within the Unicorn that can be triggered by the guest code (for example, out-of-bounds accesses in the helper functions of the target architecture)
- Defects in the TCG frontends/optimizer/backends that could lead to host memory corruption or sandbox escapes.
- Host process crashes (DoS) triggered directly by guest code execution.
- Distinguishing these from minor guest-level emulation inaccuracies.
- Communication Methods and Integration with PyPI: Since GitHub Security Advisories (GHSA) / Private Vulnerability Reporting are currently disabled for this repository, email is the only option. It would be helpful to clarify if PGP encryption is expected (however that can be an issue, since it may require maintainers to share a private key with each other)
- Alternatively, consider enabling GitHub's Private Vulnerability Reporting. Since the official unicorn package is hosted on PyPI, leveraging GHSA would allow the team to coordinate advisory disclosures that automatically sync with the Python Packaging Advisory Database. This ensures Python users get immediate Dependabot alerts when security patches are released.
As someone who has previously contributed to fixing crashes in the dev branch and actively fuzzes Unicorn (including differential fuzzing on dev and pr2349-rebased branches), I notice a strong need for these guidelines. Having a clear SECURITY.md will help contributors like myself know exactly how to triage found issues (e.g., distinguishing between a public bug report/pull request and a private security disclosure).
On a related note, since many architectural updates and bug fixes are actively developed in separate feature and development branches, it would be highly beneficial to clarify which branch should be considered the primary target for security auditing at any given moment. Knowing the general timeline or strategy for merging major updates into the master branch would greatly help researchers coordinate their efforts and avoid reporting issues that may already be addressed in development.
Do note that the points above are simply suggestions. Feel free to add, remove, and modify any of these as you wish. Thank you for your time and hard work on maintaining Unicorn!
The current SECURITY.md file is minimal and only lists two contact email addresses. While this provides a basic way to get in touch, expanding it could significantly improve the responsible disclosure process, prevent low-quality reports, and save the maintainers' time.
I would like to suggest expanding SECURITY.md to cover a few essential aspects. Here are some specific ideas that the team could consider adding:
masterand/ordevbranch or the latest stable release to be considered).As someone who has previously contributed to fixing crashes in the
devbranch and actively fuzzes Unicorn (including differential fuzzing ondevandpr2349-rebasedbranches), I notice a strong need for these guidelines. Having a clear SECURITY.md will help contributors like myself know exactly how to triage found issues (e.g., distinguishing between a public bug report/pull request and a private security disclosure).On a related note, since many architectural updates and bug fixes are actively developed in separate feature and development branches, it would be highly beneficial to clarify which branch should be considered the primary target for security auditing at any given moment. Knowing the general timeline or strategy for merging major updates into the master branch would greatly help researchers coordinate their efforts and avoid reporting issues that may already be addressed in development.
Do note that the points above are simply suggestions. Feel free to add, remove, and modify any of these as you wish. Thank you for your time and hard work on maintaining Unicorn!