Create SECURITY.md #321
Create SECURITY.md #321
Conversation
Add triggers to .github/workflows/
This commit updates the Android workflow file `.github/workflows/android.yml` to use the `ubuntu-latest` runner image instead of `ubuntu-18.04`.
Update Android workflow to use ubuntu-latest
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Summary of Changes
Hello @Skl5gtrdd4, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!
This pull request introduces a SECURITY.md file to the repository. This document serves as the standard place for users and contributors to find information regarding which versions of the project are currently supported with security updates and how to properly report security vulnerabilities.
Highlights
- New Security Policy Document: Adds a
SECURITY.mdfile to the repository root. - Standard Security Sections: The new file includes standard sections for listing supported versions and providing instructions on how to report vulnerabilities.
Using Gemini Code Assist
The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.
Invoking Gemini
You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.
| Feature | Command | Description |
|---|---|---|
| Code Review | /gemini review |
Performs a code review for the current pull request in its current state. |
| Pull Request Summary | /gemini summary |
Provides a summary of the current pull request in its current state. |
| Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in issue comments and review comments. |
| Help | /gemini help |
Displays a list of available commands. |
Customization
To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.
Limitations & Feedback
Gemini Code Assist is currently in preview and may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments to provide feedback.
You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.
Footnotes
-
Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configureGemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩
There was a problem hiding this comment.
Code Review
This pull request introduces a SECURITY.md file, which is a commendable step towards defining the project's security posture. The file uses a standard template structure. My review primarily focuses on the need to populate this template with project-specific information to make it truly useful. Key sections, such as 'Supported Versions' and 'Reporting a Vulnerability', currently contain placeholder text and example data. It is crucial to replace these with accurate details pertinent to this project. No specific Markdown style guide was provided in the review context, so the feedback is based on general best practices for creating clear, complete, and actionable security documentation.
| Use this section to tell people how to report a vulnerability. | ||
|
|
||
| Tell them where to go, how often they can expect to get an update on a | ||
| reported vulnerability, what to expect if the vulnerability is accepted or | ||
| declined, etc. |
There was a problem hiding this comment.
The 'Reporting a Vulnerability' section currently contains placeholder instructions. This is a critical part of your security policy. Please replace this generic text with specific, actionable guidance for your project. Users need to know exactly how to report security concerns.
Consider including:
- The precise method(s) for reporting (e.g., a dedicated security email address, instructions for private issue tracker submission).
- Expected response timelines for acknowledging reports and providing updates.
- What specific information should be included in a vulnerability report to make it effective (e.g., affected versions, steps to reproduce, potential impact).
- The project's process for handling reported vulnerabilities, including how decisions on acceptance/rejection are made and your disclosure policy.
| Use this section to tell people how to report a vulnerability. | |
| Tell them where to go, how often they can expect to get an update on a | |
| reported vulnerability, what to expect if the vulnerability is accepted or | |
| declined, etc. | |
| <!-- TODO: Provide clear and specific instructions for reporting security vulnerabilities. | |
| Key details to include: | |
| - Contact method(s) for reporting (e.g., [email protected]). | |
| - Expected response timelines (e.g., acknowledgment within 48 hours). | |
| - Essential information to include in reports (version, reproduction steps, impact). | |
| - The project's vulnerability handling and disclosure process. --> |
| Use this section to tell people about which versions of your project are | ||
| currently being supported with security updates. |
There was a problem hiding this comment.
This descriptive text for the 'Supported Versions' section is currently a placeholder. It's important to replace it with specific information detailing which versions of this project are actively supported with security updates and for how long. Users rely on this to understand the security status of different versions.
| Use this section to tell people about which versions of your project are | |
| currently being supported with security updates. | |
| <!-- TODO: Clearly state which versions of this project receive security updates and their support lifecycle. --> | |
| | 5.1.x | :white_check_mark: | | ||
| | 5.0.x | :x: | | ||
| | 4.0.x | :white_check_mark: | | ||
| | < 4.0 | :x: | |
There was a problem hiding this comment.
The version information in this table (e.g., 5.1.x, 5.0.x) appears to be example data. Please update these rows with the actual versions of your project and their current security support status (e.g., using ✅ for supported, ❌ for unsupported). Accurate version support information is crucial for users.
| | 5.1.x | :white_check_mark: | | |
| | 5.0.x | :x: | | |
| | 4.0.x | :white_check_mark: | | |
| | < 4.0 | :x: | | |
| | <!-- TODO: Project Version (e.g., 1.2.x) --> | <!-- TODO: :white_check_mark: or :x: --> | | |
| | <!-- TODO: Project Version (e.g., 1.1.x) --> | <!-- TODO: :white_check_mark: or :x: --> | | |
| | <!-- TODO: Older Version Range (e.g., < 1.0) --> | <!-- TODO: :x: --> | | |
| | <!-- Add more rows as needed for your project's versions --> | <!-- --> | |
3 participants
1f4d271