secure v2.0.0rc1: presets redesign, ASGI/WSGI middleware, and header updates

.github/workflows/tests.yml

@@ -21,5 +21,9 @@ jobs:
         uses: actions/setup-python@v5
         with:
           python-version:  ${{ matrix.python }}
+      - name: Install toolchain
+        run: pip install ruff
       - name: Unit tests
         run: python -m unittest tests/*/*.py
+      - name: Lint
+        run: ruff check secure tests

CHANGELOG.md

@@ -9,6 +9,26 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 - Placeholder for upcoming changes.
 
+## [2.0.0] - 2025-12-13
+
+### Breaking Changes
+
+- The `Secure` API now requires Python 3.10+ and uses the new builder-style header modules with full typing; this release replaces the previous legacy surface and removes the older cookie-centric helpers.
+
+### Added
+
+- Comprehensive validation pipeline helpers (`allowlist_headers`, `deduplicate_headers`, `validate_and_normalize_headers`) and typed presets for `Secure`.
+- New header builder coverage for modern headers (CSP, Permissions Policy, COEP, etc.) with deterministic outputs.
+- Async-safe `set_headers_async` support for both method-call and mapping-style response objects plus helper mocks and contract tests.
+
+### Testing
+
+- Added full contract tests for the header builders along with end-to-end coverage for `Secure` usage and response integration.
+
+### Docs
+
+- Expanded README with usage examples, advanced pipeline guidance, and updated framework integration references.
+
 ## [1.0.1] - 2024-10-18
 
 ### Fixed

CODE_OF_CONDUCT.md

@@ -0,0 +1,38 @@
+# Code of Conduct
+
+This Code of Conduct applies to all `secure` community spaces.
+
+## Our Pledge
+
+We’re committed to a welcoming, safe, equitable community for everyone. Treat others with respect and assume good faith.
+
+## Expected Behavior
+
+- Be kind, constructive, and professional.
+- Respect different viewpoints and experiences.
+- Take responsibility for your actions and help repair harm.
+- Give and accept feedback gracefully.
+
+## Unacceptable Behavior
+
+- Harassment, threats, or hate/discrimination.
+- Personal attacks, sexualized behavior, or stereotyping.
+- Sharing someone’s private information without consent.
+- Impersonation, misleading identity, or evasions of enforcement.
+- Spam/promotional content outside community norms.
+
+## Reporting
+
+Report issues to **caleb@typeerror.com**. Maintainers will review reports promptly and handle them as confidentially as possible.
+
+## Enforcement
+
+Maintainers may take action appropriate to the situation, including warnings, temporary limits, suspension, or a permanent ban.
+
+## Scope
+
+Applies in project spaces (issues, PRs, discussions, chats) and when representing the project publicly.
+
+## Attribution
+
+Adapted from the Contributor Covenant v3.0: https://www.contributor-covenant.org/version/3/0/

CONTRIBUTING.md

@@ -0,0 +1,64 @@
+# Contributing
+
+Thanks for helping make `secure` better. The following guidance keeps contributions aligned with the project’s release-quality standards.
+
+## Development environment
+
+1. Create a virtual environment and activate it:
+   ```bash
+   python -m venv .venv
+   source .venv/bin/activate
+   ```
+2. Install the package in editable mode so local changes are picked up automatically:
+   ```bash
+   pip install -e .
+   ```
+3. Install the tooling used by the project:
+   ```bash
+   pip install ruff
+   ```
+   _Optional:_ `uv` is the package manager used by the project for releases; you can use `uv add ...` to manage dependencies, but it is not required for local development.
+
+## Running tests, linting, and formatting
+
+- **Run unit tests:** `python -m unittest tests/*/*.py`
+- **Run the linter:** `ruff check`
+- **Apply formatting / fix issues:** `ruff format`
+
+Run these commands before opening a pull request. If you rely on a different Python version, keep it within the supported range (Python 3.10+).
+
+## Adding a header document
+
+1. Add a new guide under `docs/headers/` named after the header (for example, `docs/headers/example_header.md`).
+2. Mirror the structure of the existing header docs:
+   - Start with a **Purpose** section that explains the header’s intent.
+   - Describe the **Default behavior** and mention how the builder models that default.
+   - Show a **Using with `Secure`** example and describe the builder API with method names.
+   - Include **Resources** / **Attribution** and any security caveats.
+3. Link the new document from `docs/README.md` (under the Security Headers list) so readers can discover it easily.
+4. Ensure code snippets use the public API (`from secure import ...`), reference the appropriate response types, and avoid framework-specific terminology unless a callout is necessary.
+
+## Adding a framework example
+
+1. Update `docs/frameworks.md`:
+   - Add the framework to the table of contents.
+   - Include a short intro describing the framework’s model (WSGI vs ASGI, sync vs async).
+   - Provide at least one working example showing how to wire `Secure` (middleware, hooks, or response-level helpers).
+   - Mention the correct response type (`Response`, `JSONResponse`, etc.) or highlight that you are working with the framework’s default response object.
+2. If the framework needs extra instructions (e.g., disabling Uvicorn’s `Server` header), document them in the same section.
+3. Keep the tone focused on security headers rather than broader framework guidance.
+
+## Commit conventions
+
+- Keep commit messages short (<72 characters) and in the imperative (e.g., `docs: clarify defaults`).
+- Prefix doc-only changes with `docs:` so reviewers immediately know the scope.
+- Reference any related issue or PR in the description when applicable.
+- Run linting/tests before committing to minimize follow-up work.
+
+## Pull request checklist
+
+- [ ] I have run `python -m unittest tests/*/*.py` locally (or a representative suite) and addressed any failures.
+- [ ] I have run `ruff check` and `ruff format` (when formatting attr).
+- [ ] Documentation updates describe the new behavior (new header docs, framework guidance, etc.).
+- [ ] If applicable, I have updated the release notes/CHANGELOG entry for new user-visible behavior.
+- [ ] My changes follow the project’s security and contribution guidelines (this document).