Skip to content

Project Policies

Find the project's security reporting instructions, contribution guide, code of conduct and attribution notice below. For the terms that apply to the data, see the dataset licence and attribution.

Security Policy

This document describes how security issues are reported, handled, and communicated for PASSAGE.

Supported Versions

Security fixes are provided on a best-effort basis for older versions.

Reporting a Vulnerability

Please report suspected vulnerabilities privately.

Preferred contacts:

  • geoffrey.delhomme@thalesgroup.com
  • oss@thalesgroup.com

Please include:

  • A clear description of the issue and potential impact.
  • Affected versions/commit hash.
  • Reproduction steps or proof of concept (minimal and safe).
  • Any suggested remediation.

Important rules:

  • Do not publish exploit details in public issues, pull requests, or discussions.
  • If you already opened a public issue by mistake, contact maintainers immediately so details can be redacted.

Disclosure Policy

Our coordinated disclosure process is:

  1. Acknowledge report receipt (target: within 5 business days).
  2. Triage severity, impact, and affected scope.
  3. Prepare and validate a fix.
  4. Coordinate disclosure timing with the reporter when possible.
  5. Publish a fix and a public security note once users can mitigate.

For actively exploited or critical issues, timelines may be accelerated.

Security Update Policy

  • Security fixes are released as soon as practical.
  • Release notes will clearly identify security-relevant changes.
  • Users should upgrade to the latest supported version immediately after a security release.
  • Critical fixes may be shipped as dedicated hotfix releases.

To reduce security risk when contributing or deploying:

  • Use supported Python versions (>=3.11) and pinned dependencies (uv.lock).
  • Keep dependencies updated (uv sync --group dev).
  • Never commit credentials, API keys, or tokens.
  • Keep secrets in environment variables or local secret files (for example .env.secret, which is git-ignored).
  • Prefer least-privilege credentials (for example short-lived or scoped tokens).
  • Run project checks before pushing:
uv run pre-commit run --all-files
uv run ruff check src/ tests/
uv run pytest --cov

If your workflow uses PyTorch or other external ML tooling, follow upstream secure usage guidance and treat all external data/artifacts as untrusted inputs.

Security Best Practices for Contributors

  • Validate external files and datasets before processing.
  • Avoid executing untrusted notebooks or scripts.
  • Review dependency changes carefully in pull requests.
  • Minimize exposed data in logs, issues, and CI output.

Known Security Gaps and Future Enhancements

Current limitations (contributions welcome):

  • No dedicated automated secret-scanning hook is enforced in CI.
  • No dedicated automated dependency vulnerability gate is enforced in CI.
  • No signed release artifacts/attestations are published yet.

Contributing guidelines

Thank you for your interest in contributing to PASSAGE.

This document explains team organization, communication channels, and the contribution rules to follow before opening a pull request.

Team organization

passage repository is maintained by the Thales open-source team with a designated project lead.

Project communication channels:

  • GitHub Issues for bugs and concrete tasks.
  • GitHub Discussions for ideas and questions.
  • Code of conduct reports via geoffrey.delhomme@thalesgroup.com or oss@thalesgroup.com.

Roles

  • Project lead: defines technical direction, release priorities, and final arbitration.
  • Maintainers: triage issues, review pull requests, and merge accepted changes.
  • Contributors: propose and implement improvements (code, docs, tests, tooling).

How to become a contributor

  1. Read CODE_OF_CONDUCT.md.
  2. Fork and clone the repository.
  3. Set up the development environment and hooks:
uv sync --group dev
uv run pre-commit install
  1. Create a focused feature/... branch from develop.
  2. Implement your change with tests and documentation updates when relevant.
  3. Run checks locally, then open a pull request.

Contributor License Agreements

There is currently no separate CLA file in this repository.

By contributing, you confirm that:

  • You have the right to submit the contribution.
  • Your contribution can be distributed under this repository's MIT License.

Contributing code

Use small, focused commits and keep one logical change per pull request.

Recommended local workflow:

git checkout develop
git pull --ff-only
git checkout -b feature/your-change
uv run ruff check src/ tests/
uv run ruff format src/ tests/
uv run pytest --cov
uv run pre-commit run --all-files

Gitflow workflow

passage uses the Gitflow branching model.

flowchart LR
    M[main] --> H[hotfix/*]
    H --> M
    H --> D[develop]

    D --> F[feature/*]
    F --> D

    D --> R[release/*]
    R --> M
    R --> D

Reference: Atlassian Gitflow workflow

Branch roles:

  • main: production-ready history and release tags.
  • develop: integration branch for the next release.
  • feature/<name>: short-lived work branch created from develop, merged back into develop.
  • release/<version>: release preparation branch created from develop, then merged into both main and develop.
  • hotfix/<name>: urgent fix branch created from main, then merged into both main and develop.

Contributor rules with Gitflow:

  • Standard contributions must be opened as pull requests to develop.
  • Use feature/<name> for regular contributions.
  • Use hotfix/<name> only for urgent production fixes validated by maintainers.
  • Keep your branch synchronized with develop while your pull request is open.

Pull Request Checklist

Before requesting review, verify all items below.

License

  • My contribution is compatible with the MIT License in this repository.
  • I did not add third-party code or assets without proper licensing/attribution.

Coding style

  • uv run ruff check src/ tests/ passes.
  • uv run ruff format src/ tests/ has been applied.
  • uv run pre-commit run --all-files passes.
  • New code follows existing naming, structure, and readability conventions.
  • PR targets develop (or main only for approved hotfixes).

Testing

  • Relevant tests were added or updated.
  • Existing tests pass locally.
  • Coverage remains at or above the project threshold (80%).
Running sanity check
uv sync --group dev
uv run pre-commit install
uv run pre-commit run --all-files
Running unit tests
uv run pytest -m unit
uv run pytest --cov

Issues management

  • Search existing issues/discussions before opening a new thread.
  • Open one issue per bug or feature request to keep tracking clear.
  • For bug reports, include environment, steps to reproduce, expected behavior, and actual behavior.
  • Keep discussions technical and respectful, following the Code of Conduct.

Contributor Code of Conduct

Our Pledge

We as contributors and maintainers of the passage repository pledge to make participation in our project a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation.

We are committed to providing a welcoming and inspiring environment for all contributors, where constructive and respectful collaboration is prioritized.

Our Standards

Examples of behavior that contributes to a positive environment include:

  • Being respectful of differing viewpoints and experiences.
  • Gracefully accepting constructive criticism.
  • Focusing on what is best for the community.
  • Showing empathy and kindness towards other contributors.
  • Refraining from any discriminatory, disrespectful, or inappropriate conduct.

Examples of unacceptable behavior include:

  • The use of sexualized language or imagery and unwelcome sexual attention or advances.
  • Trolling, insulting or derogatory comments, and personal or political attacks.
  • Public or private harassment.
  • Publishing others' private information, such as a physical or email address, without explicit permission.
  • Other conduct which could reasonably be considered inappropriate in a professional setting.

Our Responsibilities

Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior.

Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned with this Code of Conduct, and to temporarily or permanently ban any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.

Scope

This Code of Conduct applies within all project spaces and to public spaces where an individual is representing the project or its community. Representation of the project may be defined by project maintainers.

Enforcement

Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project lead at geoffrey.delhomme@thalesgroup.com, or our Open Source team at oss@thalesgroup.com. All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident.

Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other project maintainers.

Attribution

This Code of Conduct is adapted from the Contributor Covenant, version 2.1, available at https://www.contributor-covenant.org/version/2/1/code_of_conduct.html.

PASSAGE Notices

PASSAGE generator code is released under the MIT License in LICENSE. Exported dataset artifacts, including the published dataset PASSAGE v1.0, inherit the JAXA ALOS AW3D30 obligations documented in DATASET_LICENSE.md.

Attribution for the dataset, as JAXA asks: The original data used for this product have been supplied by JAXA's ALOS World 3D–30m (AW3D30).

The documentation logo and favicon (docs/assets/logo.svg, docs/assets/favicon.svg) are original artwork of the PASSAGE project, released under the MIT License with the code.