mirror of
https://github.com/pgsty/minio.git
synced 2026-08-09 15:53:28 +03:00
Feng Ruohang
fd2ca1c6d2
README, README_ZH, SECURITY, COMPLIANCE, CONTRIBUTING, NOTICE, code_of_conduct, the vulnerability and PR-etiquette documents, the GitHub issue and pull request templates, and the docs/ tree all present Silo as the product. The Grafana dashboards under docs/metrics/prometheus/grafana/ have their panel titles and descriptions rebranded while every minio_* query, label and expression is left alone, so existing alerts and recording rules keep matching. The distinction the review demanded is applied per hit rather than by search-and-replace: - Product and command text becomes Silo and silo: install and run instructions, systemd examples, compose services, download links, badges. - Protocol and interface text keeps MinIO: MINIO_* variables, minio_* metrics, x-minio-* headers, /minio/* routes, .minio.sys, arn:minio, and API field and error names. - Attribution keeps MinIO and gains the fork's own: the AGPL obligations, original copyright, CREDITS and NOTICE stay, with the modification notice added alongside rather than replacing them. - Historical and third-party references are left as facts, not rewritten for brand tidiness. README and README_ZH each carry an explicit non-affiliation notice, document the side-by-side package migration including the /etc/systemd/system/silo.service.d/10-legacy-user.conf drop-in for keeping a legacy UID/GID, and state that recursive chown is never performed. The trademark attribution uses the policy's approved "based on MinIO technology" wording, not the shortened form the policy rejects. github.com/pgsty/minio links are left in place and labelled transitional. The repository has not been renamed, and rewriting them now would produce documented URLs that 404 until the cutover; they change in the cutover commit together with the goreleaser release target, the OCI source label and the raw-content branch. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
38 lines
1.5 KiB
Markdown
38 lines
1.5 KiB
Markdown
# Vulnerability Management Policy
|
|
|
|
This document describes how the Silo maintainers investigate,
|
|
assess, and remediate reported vulnerabilities affecting this fork, any
|
|
directly shipped component, or a direct / indirect dependency used by this
|
|
repository.
|
|
|
|
## Scope
|
|
|
|
This policy covers vulnerability reports opened by repository maintainers or
|
|
external third parties against Silo itself, its release artifacts, or
|
|
dependencies that materially affect this fork.
|
|
|
|
It defines the information needed for triage and the expected remediation
|
|
workflow for supported fixes.
|
|
|
|
## Vulnerability Management Process
|
|
|
|
A useful vulnerability report should contain the following information:
|
|
|
|
- The project / component that contains the reported vulnerability.
|
|
- A description of the vulnerability. In particular, the type of the
|
|
reported vulnerability and how it might be exploited. Alternatively,
|
|
a well-established vulnerability identifier, such as a CVE or GHSA ID, can
|
|
be used instead.
|
|
|
|
Based on the report, the Silo maintainers investigate:
|
|
|
|
- Whether the reported vulnerability exists.
|
|
- The conditions that are required such that the vulnerability can be exploited.
|
|
- Which releases, branches, or deployment paths are affected.
|
|
- The steps required to fix the vulnerability.
|
|
|
|
If the vulnerability exists in this fork itself, the maintainers will, when
|
|
feasible, fix the issue or implement reasonable countermeasures such that the
|
|
vulnerability can no longer be exploited. Fork-specific upgrade notes and
|
|
security advisories are published in `docs/security/advisories.md`.
|