PyneHub logoPyneHub
All legal documents

PyneHub Security Policy

Last updated: July 18, 2026

This policy describes how PyneHub secures its supply chain, scans uploads, signs and verifies artifacts, guides on-device app safety, and controls access to logs. Report vulnerabilities to [email protected].

1. Reporting a vulnerability

  • Email [email protected] with details and reproduction steps.
  • Please allow reasonable time for remediation before public disclosure (coordinated disclosure). Do not exploit issues beyond what is needed to demonstrate them, and do not access other users' data.
  • We acknowledge reports promptly and keep reporters informed.

2. Supply-chain & upload scanning controls

Every uploaded app artifact SHOULD pass the following automated checks before it is published. Failures cause the artifact to be quarantined (not downloadable) and reviewers to be notified.

Control Purpose Example tooling
SCA (Software Composition Analysis) Detect known-vulnerable / disallowed dependencies npm audit, osv-scanner, pip-audit, Trivy
Static analysis / linting Detect insecure patterns and quality issues eslint, bandit (Python), semgrep
Secret scanning Catch leaked keys/tokens/credentials in code gitleaks, trufflehog
Antivirus / malware scan Detect known malware signatures clamscan (ClamAV)
Checksum generation Integrity verification on device sha256sum

Controls run in an isolated CI/worker with no production credentials. See the Integration Checklist (README / task response) for the pipeline steps.

3. Artifact integrity & signing

3.1 SHA-256 checksums (required)

  • On upload, compute and store the SHA-256 hash of each artifact alongside its record (the App/audit metadata already captures file hashes).
  • Publish the checksum with the app so the on-device client can verify it.
# Generate
sha256sum pynehub-app-1.0.0.tar.gz > pynehub-app-1.0.0.tar.gz.sha256
# Verify (on device or in CI)
sha256sum -c pynehub-app-1.0.0.tar.gz.sha256

3.2 Optional GPG signing (recommended for releases)

# Maintainer signs the artifact (detached, armored signature)
gpg --armor --detach-sign --local-user [email protected] pynehub-app-1.0.0.tar.gz
# Publish pynehub-app-1.0.0.tar.gz.asc alongside the artifact
# Verify with the published PyneHub public key
gpg --verify pynehub-app-1.0.0.tar.gz.asc pynehub-app-1.0.0.tar.gz

Publish the PyneHub release public key at a stable URL (e.g., https://pynehub.com/pgp-key.txt) so clients and developers can verify.

3.3 On-device verification (client)

The pynehub.py client SHOULD, after download and before install:

  1. Recompute the SHA-256 of the downloaded artifact.
  2. Compare it to the checksum provided by the hub; abort install on mismatch.
  3. If a GPG signature and the PyneHub public key are present, verify the signature; warn or abort on failure.

4. On-device sandboxing & runtime permissions (guidance)

Apps distributed via PyneHub run on the user's phone. We recommend:

  • Least privilege: apps request only the permissions they need; document required permissions in app metadata.
  • Sandboxing: where the platform supports it, run apps under confinement (e.g., Flatpak sandbox / bubblewrap, systemd sandboxing options such as ProtectHome, ProtectSystem, NoNewPrivileges, seccomp filters).
  • Filesystem & network scoping: avoid unrestricted home/filesystem access; prefer portals / user-consented file access. Disclose network endpoints.
  • No silent escalation: apps must not request root or escalate privileges without explicit, informed user action.
  • Transparency: the client should show the app's declared permissions and publisher before install.

5. Role-based access control (RBAC) for logs and admin

  • Access to audit/transaction logs is restricted to the admin role. Non-admin developers can see only their own app activity, not raw logs containing others' IPs/device identifiers.
  • Enforce RBAC at the API layer (server-side session check), not only in the UI. Existing pattern: getAdminSession() gate on /api/admin/* routes.
  • Apply least privilege to operator accounts; require 2FA for admins.
  • Log administrative access to logs ("who viewed/exported logs") as its own audit event.

6. Data protection alignment

  • Passwords stored as bcrypt hashes; TLS/HTTPS enforced in transit.
  • Log retention and incident retention follow legal/pynehub.config.yaml.
  • See legal/PRIVACY_POLICY.md for lawful basis and data-subject rights and legal/INCIDENT_RESPONSE.md for breach handling.

7. License-conflict remediation

If scanning surfaces a dependency with a license incompatible with Apache-2.0 (e.g., GPL/AGPL), do not change the project license unilaterally. Record it in legal/THIRD_PARTY_LICENSES.md, open a review item, evaluate replacement or isolation of the dependency, and consult legal counsel.