Security and secure contribution#

The repository’s canonical vulnerability-reporting process is defined in SECURITY.md. This page explains what contributors can expect from the public maintenance workflow.

Report vulnerabilities privately#

Use the private security advisory form for suspected vulnerabilities. Do not open a public Issue, put exploit details in a pull request, or include credentials and private data in public comments. A reproducible report should identify the affected version or commit, describe the impact briefly, and use reproduction steps that contain no secrets.

Public maintenance controls#

The repository uses layered safeguards:

  • Dependabot alerts and security updates for dependency vulnerabilities;

  • locked-environment auditing and pip-audit in CI;

  • secret scanning and push protection where supported by the repository plan;

  • CodeQL Default setup for Python and GitHub Actions, using the default query suite on standard GitHub-hosted runners;

  • protected main with required CI and security checks, resolved review conversations, linear history, and an independent approval plus latest-push approval when a second maintainer is available. A single-maintainer repository disables those review-dependent requirements and uses the public Review 1 / Review 2 protocol instead of self-approval or an admin bypass.

These controls complement one another. A passing check does not replace maintainer review, and a new alert is reviewed before it is resolved or classified.

PyPI publishing#

Package releases use PyPI Trusted Publishing through GitHub Actions OIDC. The workflow is .github/workflows/publish_package.yml, the GitHub environment is pypi, and the PyPI publisher is scoped to the SoichiroYamane/gsplot repository and that workflow filename. The workflow builds distributions in a job without OIDC access, transfers them as an artifact, and gives only the separate publish job id-token: write plus contents: read.

The PyPI publisher must be configured before a release is published. Keep the legacy PYPI_API_TOKEN secret only as a temporary rollback path until a safe TestPyPI rehearsal or production upload confirms the trusted publisher. Remove that secret after verification; do not add it to new workflows or expose it in logs. See the PyPI Trusted Publishers documentation for the external configuration and security model.

Plan and implement changes safely#

Security and dependency work is tracked in a public Issue before substantial changes begin. The Issue records scope, non-goals, acceptance criteria, and public-safe residual risk; the linked pull request records implementation status and validation evidence. Maintainers use a requirements/risk review and a complete-diff/verification review before merging.

Contributors should keep workflow permissions least-privileged, avoid secrets in pull-request jobs, preserve full action references, and disclose only the configuration and evidence needed to review the change.