# Security Policy

## Supported Versions

| Version | Supported |
|---------|-----------|
| 3.x     | ✅ Active |
| 2.x     | ✅ Security fixes |
| 1.x     | ❌ End of life |
| 0.x     | ❌ End of life |

## Reporting a Vulnerability

If you discover a security vulnerability in PgClone, please report it responsibly:

1. **Do not** open a public GitHub issue for security vulnerabilities
2. Email the maintainer directly or use GitHub's private vulnerability reporting feature
3. Include a clear description of the vulnerability and steps to reproduce

We will acknowledge your report within 48 hours and provide a timeline for a fix.

## Security Considerations

PgClone operates with **superuser** privileges and handles database connections. Users should be aware of the following:

### Connection Strings

Connection strings passed to pgclone functions may contain passwords in plaintext. To avoid exposing credentials:

- Use `.pgpass` files or the `PGPASSFILE` environment variable instead of inline passwords
- Restrict access to pgclone functions to trusted users only
- Avoid logging connection strings in application logs

### SQL Injection — WHERE Clause

The `"where"` option in JSON parameters is validated against SQL injection patterns (DDL/DML keywords and semicolons are rejected) and executed inside a `READ ONLY` transaction on the source database. This provides two layers of protection:

- Only use `WHERE` filters with trusted input
- Do not pass user-supplied strings directly into the `"where"` option
- The keyword validation and read-only transaction wrapping (v2.2.1) prevent most injection attacks, but defense-in-depth is recommended

### Network Security

pgclone connects to remote PostgreSQL instances using `libpq`. Ensure:

- Firewall rules restrict which hosts can be reached
- Use SSL connections where possible (`sslmode=require` in connection strings)
- Source databases should grant minimal required privileges (read-only access is sufficient for cloning)

### Shared Memory

Async job state is stored in PostgreSQL shared memory. Job metadata (schema names, table names, progress) is visible to all database users who can call `pgclone_progress()` or query `pgclone_jobs_view`. This is expected behavior but should be considered in multi-tenant environments.