Skip to content
This repository was archived by the owner on Jul 10, 2025. It is now read-only.
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 2 additions & 1 deletion .github/workflows/android.yml
Original file line number Diff line number Diff line change
Expand Up @@ -15,6 +15,7 @@
name: Android CI

on:
workflow_dispatch:
push:
branches: [ master ]
pull_request:
Expand All @@ -24,7 +25,7 @@ jobs:

build:
name: Build
runs-on: ubuntu-18.04
runs-on: ubuntu-latest

steps:
- uses: actions/checkout@v1
Expand Down
1 change: 1 addition & 0 deletions .github/workflows/copy-branch.yml
Original file line number Diff line number Diff line change
Expand Up @@ -5,6 +5,7 @@ name: Duplicates main to old master branch
# Controls when the action will run. Triggers the workflow on push or pull request
# events but only for the main branch
on:
workflow_dispatch:
push:
branches: [ main ]

Expand Down
21 changes: 21 additions & 0 deletions SECURITY.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,21 @@
# Security Policy

## Supported Versions

Use this section to tell people about which versions of your project are
currently being supported with security updates.
Comment on lines +5 to +6

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

high

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.

Suggested change
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. -->


| Version | Supported |
| ------- | ------------------ |
| 5.1.x | :white_check_mark: |
| 5.0.x | :x: |
| 4.0.x | :white_check_mark: |
| < 4.0 | :x: |
Comment on lines +10 to +13

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

high

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.

Suggested change
| 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 --> | <!-- --> |


## Reporting a Vulnerability

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.
Comment on lines +17 to +21

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

critical

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.
Suggested change
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., security@example.com).
- 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. -->