rust-py-audit 0.3.2__tar.gz → 0.4.0__tar.gz

rust_py_audit-0.4.0/.github/workflows/release.yml

@@ -0,0 +1,328 @@
+name: CI / Release
+
+# Push e PR rodam `lint` + `test` e param por aí. Os jobs de build são
+# liberados por uma tag `v*` ou por um `workflow_dispatch` manual — o segundo
+# existe para o ensaio no TestPyPI, abaixo.
+#
+# **Só a tag publica no PyPI de produção.** O job `release` é o único guardado
+# apenas por `startsWith(github.ref, 'refs/tags/')`, sem a cláusula de
+# dispatch: um disparo manual constrói tudo e vai para o TestPyPI, nunca para
+# o índice de verdade. Publicação no PyPI não se desfaz, então essa assimetria
+# é proposital.
+on:
+  push:
+    branches: [main]
+    tags:
+      - "v*"
+  pull_request:
+  workflow_dispatch: {}
+
+permissions:
+  contents: read
+
+jobs:
+  # O lint faz parte do portão de release, não de um workflow paralelo.
+  # Nos repositórios de workflow único, um `lint` vermelho ao lado de uma
+  # publicação bem-sucedida seria ruído difícil de ler — a leitura passa a ser
+  # inequívoca: vermelho significa que não publicou.
+  #
+  # A toolchain é fixa, não "stable": com `-D warnings`, um clippy mais novo
+  # no runner reprova código que ninguém tocou, e a CI ficaria vermelha por
+  # conta do calendário. Subir este número vira uma mudança deliberada.
+  lint:
+    name: fmt + clippy
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: dtolnay/rust-toolchain@1.88.0
+        with:
+          components: rustfmt, clippy
+      - uses: Swatinem/rust-cache@v2
+      - name: cargo fmt
+        run: cargo fmt --all -- --check
+      # clippy só checa tipos, não linka, então --all-features é seguro aqui
+      # (diferente do `cargo test`, que precisa de --no-default-features).
+      - name: cargo clippy
+        run: cargo clippy --all-targets --all-features -- -D warnings
+
+  # Nothing gets built, and nothing reaches PyPI, until this passes. Publishing
+  # to PyPI is irreversible: a bad wheel cannot be replaced, only yanked.
+  test:
+    name: Test (Rust + Python)
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: dtolnay/rust-toolchain@stable
+      - uses: actions/setup-python@v5
+        with:
+          python-version: "3.12"
+
+      # --no-default-features drops extension-module, which tells the linker to
+      # leave libpython symbols undefined. That is correct for the wheel but
+      # produces a test binary that cannot link on Linux.
+      - name: Rust unit tests
+        env:
+          PYO3_PYTHON: python
+        run: cargo test --no-default-features --lib
+
+      - name: Build, install the extension and run the Python tests
+        # `pip install` drives the maturin build backend, so it compiles the
+        # Rust extension and installs it (plus the dev extras) into the
+        # runner's Python — no virtualenv needed, unlike `maturin develop`,
+        # which aborts when it cannot find one.
+        run: |
+          python -m pip install --upgrade pip
+          python -m pip install ".[dev]"
+          python -m pytest
+
+  linux:
+    runs-on: ubuntu-latest
+    if: startsWith(github.ref, 'refs/tags/') || github.event_name == 'workflow_dispatch'
+    needs: [test, lint]
+    strategy:
+      matrix:
+        target: [x86_64, aarch64]
+    steps:
+      - uses: actions/checkout@v4
+      - uses: PyO3/maturin-action@v1
+        env:
+          # `ring` (puxado por `rustls`, via `reqwest`) falha ao cross-compilar
+          # sua assembly pregenerada para aarch64 dentro do container manylinux
+          # do maturin-action: o cross-gcc não define `__ARM_ARCH` por padrão
+          # nesse ambiente, e o preprocessor de `ring` exige essa macro
+          # (erro: "ARM assembler must define __ARM_ARCH"). Forçar a macro via
+          # CFLAGS é o workaround padrão para esse problema conhecido — não
+          # afeta o build x86_64 (a env var é específica do target aarch64).
+          CFLAGS_aarch64_unknown_linux_gnu: -D__ARM_ARCH=8
+        with:
+          target: ${{ matrix.target }}
+          args: --release --out dist --find-interpreter
+          manylinux: auto
+      - uses: actions/upload-artifact@v4
+        with:
+          name: wheels-linux-${{ matrix.target }}
+          path: dist
+
+  musllinux:
+    runs-on: ubuntu-latest
+    if: startsWith(github.ref, 'refs/tags/') || github.event_name == 'workflow_dispatch'
+    needs: [test, lint]
+    strategy:
+      matrix:
+        target: [x86_64, aarch64]
+    steps:
+      - uses: actions/checkout@v4
+      - uses: PyO3/maturin-action@v1
+        with:
+          target: ${{ matrix.target }}
+          args: --release --out dist --find-interpreter
+          manylinux: musllinux_1_2
+      - uses: actions/upload-artifact@v4
+        with:
+          name: wheels-musllinux-${{ matrix.target }}
+          path: dist
+
+  windows:
+    runs-on: windows-latest
+    if: startsWith(github.ref, 'refs/tags/') || github.event_name == 'workflow_dispatch'
+    needs: [test, lint]
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-python@v5
+        with:
+          architecture: x64
+      - uses: PyO3/maturin-action@v1
+        with:
+          target: x64
+          args: --release --out dist --find-interpreter
+      - uses: actions/upload-artifact@v4
+        with:
+          name: wheels-windows-x64
+          path: dist
+
+  macos:
+    runs-on: macos-latest
+    if: startsWith(github.ref, 'refs/tags/') || github.event_name == 'workflow_dispatch'
+    needs: [test, lint]
+    strategy:
+      matrix:
+        target: [x86_64, aarch64]
+    steps:
+      - uses: actions/checkout@v4
+      - uses: PyO3/maturin-action@v1
+        with:
+          target: ${{ matrix.target }}
+          args: --release --out dist --find-interpreter
+      - uses: actions/upload-artifact@v4
+        with:
+          name: wheels-macos-${{ matrix.target }}
+          path: dist
+
+  sdist:
+    runs-on: ubuntu-latest
+    if: startsWith(github.ref, 'refs/tags/') || github.event_name == 'workflow_dispatch'
+    needs: [test, lint]
+    steps:
+      - uses: actions/checkout@v4
+      - uses: PyO3/maturin-action@v1
+        with:
+          command: sdist
+          args: --out dist
+      - uses: actions/upload-artifact@v4
+        with:
+          name: wheels-sdist
+          path: dist
+
+  # Ensaio da troca OIDC, sem tocar no índice de produção. É o que permite
+  # descobrir um publisher mal cadastrado num lugar onde nada é irreversível —
+  # no PyPI, um nome de arquivo publicado nunca pode ser reusado.
+  #
+  # ⚠️ Precisa do seu próprio publisher, cadastrado no TestPyPI (que é uma
+  # conta separada do PyPI), com owner/repo, workflow `release.yml` e
+  # environment `testpypi`.
+  #
+  # Não há verificação pós-upload aqui de propósito: o que se está validando é
+  # a troca de token, e o TestPyPI expira distribuições — reprovar por um
+  # arquivo que o índice de teste descartou seria alarme falso.
+  publish-testpypi:
+    name: Publish to TestPyPI (ensaio)
+    runs-on: ubuntu-latest
+    if: github.event_name == 'workflow_dispatch'
+    needs: [lint, test, linux, musllinux, windows, macos, sdist]
+    environment: testpypi
+    permissions:
+      id-token: write
+    steps:
+      - uses: actions/download-artifact@v4
+        with:
+          pattern: wheels-*
+          path: dist
+          merge-multiple: true
+      - uses: pypa/gh-action-pypi-publish@release/v1
+        with:
+          repository-url: https://test.pypi.org/legacy/
+          packages-dir: dist
+          skip-existing: true
+
+  release:
+    name: Publish to PyPI
+    runs-on: ubuntu-latest
+    if: startsWith(github.ref, 'refs/tags/')
+    needs: [lint, test, linux, musllinux, windows, macos, sdist]
+
+    # Trusted publishing (OIDC). Não existe mais `secrets.PYPI_API_TOKEN` aqui:
+    # o GitHub emite um JWT curto afirmando repositório, workflow e ref, e o
+    # PyPI o troca por um token de upload válido por poucos minutos e só para
+    # este projeto. Some o segredo de longa duração que, se vazasse, publicaria
+    # até alguém revogá-lo à mão.
+    #
+    # ⚠️ Os três valores abaixo precisam bater EXATAMENTE com o publisher
+    # cadastrado em PyPI → Manage → Publishing:
+    #   owner/repo .... robertolima-dev/rust-py-audit
+    #   workflow ...... release.yml   (o nome deste arquivo)
+    #   environment ... pypi
+    # Divergência em qualquer um deles é rejeitada na troca do token.
+    environment: pypi
+    permissions:
+      id-token: write
+
+    steps:
+      - uses: actions/download-artifact@v4
+        with:
+          pattern: wheels-*
+          path: dist
+          merge-multiple: true
+      - uses: actions/setup-python@v5
+        with:
+          python-version: "3.12"
+      # `requests` é só para a verificação pós-upload, mais abaixo. A maturin
+      # não é mais instalada aqui: quem publica agora é a action oficial do
+      # PyPA, que é a que sabe fazer a troca OIDC.
+      - name: Install the verification dependency
+        run: python -m pip install --upgrade requests
+
+      # A sanity check before anything leaves the runner: publishing an
+      # incomplete set is worse than not publishing, because PyPI never lets a
+      # filename be reused — a half-uploaded version can only be completed,
+      # never replaced.
+      - name: Verify the artifact set is complete
+        run: |
+          set -euo pipefail
+          ls -la dist/
+          test -n "$(find dist -name '*.tar.gz' -print -quit)" \
+            || { echo "::error::sdist ausente — abortando antes de publicar"; exit 1; }
+          wheels=$(find dist -name '*.whl' | wc -l)
+          echo "wheels: $wheels"
+          test "$wheels" -ge 7 \
+            || { echo "::error::só $wheels wheels; esperado >= 7 (2 linux, 2 musl, 1 win, 2 macos)"; exit 1; }
+
+      # O PyPI devolve 500 transitório com frequência suficiente para importar,
+      # e o upload é arquivo por arquivo: uma falha no meio deixa a versão
+      # publicada pela metade. `skip-existing` é o que torna a segunda
+      # tentativa segura — sem ele, ela morre nos arquivos que já subiram.
+      #
+      # São dois passos explícitos em vez de um wrapper de retry porque o
+      # trusted publishing exige a action oficial, e ela não dá para acionar
+      # por linha de comando de dentro do `nick-fields/retry`. Mesma forma que
+      # o `rust_py_cache` e o `rust_py_rate_limit` já rodam.
+      - name: Publish to PyPI (attempt 1)
+        id: publish1
+        continue-on-error: true
+        uses: pypa/gh-action-pypi-publish@release/v1
+        with:
+          packages-dir: dist
+          skip-existing: true
+
+      - name: Wait before retrying
+        if: steps.publish1.outcome == 'failure'
+        run: sleep 45
+
+      - name: Publish to PyPI (attempt 2)
+        if: steps.publish1.outcome == 'failure'
+        uses: pypa/gh-action-pypi-publish@release/v1
+        with:
+          packages-dir: dist
+          skip-existing: true
+
+      # Proves the release is actually complete, rather than trusting an exit
+      # code that a partial upload can still produce.
+      - name: Verify every file reached PyPI
+        run: |
+          set -euo pipefail
+          python - <<'PY'
+          import os, sys, glob, time, requests
+          version = os.environ["GITHUB_REF_NAME"].lstrip("v")
+          # Só .whl e .tar.gz: são os únicos tipos de arquivo que o PyPI hospeda.
+          # `pypa/gh-action-pypi-publish` deixa um .publish.attestation por
+          # distribuição em dist/ depois de publicar (atestados PEP 740, que
+          # sobem junto do arquivo, não como arquivo próprio). Um glob amplo os
+          # conta como "faltando no PyPI" e reprova uma release que deu certo.
+          #
+          # ⚠️ Isto deixou de ser precaução e passou a valer aqui: com trusted
+          # publishing a action gera os atestados, coisa que o `maturin upload`
+          # não fazia. O recorte veio do alarme falso da rate_limit 0.2.1
+          # (P1-9) e é o que impede esta migração de reprovar o primeiro
+          # release por um motivo inventado.
+          local = {
+              os.path.basename(p)
+              for pattern in ("dist/*.whl", "dist/*.tar.gz")
+              for p in glob.glob(pattern)
+          }
+          url = f"https://pypi.org/pypi/rust-py-audit/{version}/json"
+          for attempt in range(6):          # PyPI's JSON API is cached
+              response = requests.get(url, timeout=30)
+              if response.status_code == 200:
+                  remote = {f["filename"] for f in response.json()["urls"]}
+                  missing = local - remote
+                  if not missing:
+                      print(f"OK: {len(remote)} arquivos publicados na {version}")
+                      sys.exit(0)
+              else:
+                  missing = local
+              print(f"tentativa {attempt + 1}: faltam {len(missing)}")
+              time.sleep(20)
+          print("::error::faltaram arquivos no PyPI:")
+          for name in sorted(missing):
+              print(f"  - {name}")
+          sys.exit(1)
+          PY

{rust_py_audit-0.3.2 → rust_py_audit-0.4.0}/.gitignore

@@ -9,3 +9,7 @@ build/
 *.pyd
 .pytest_cache/
 *.jsonl
+*.jsonl.lock
+
+# macOS
+.DS_Store

rust_py_audit-0.4.0/CHANGELOG.md

@@ -0,0 +1,201 @@
+# Changelog
+
+Todas as mudanças relevantes deste projeto são registradas aqui.
+
+O formato segue [Keep a Changelog](https://keepachangelog.com/pt-BR/1.1.0/),
+e o versionamento segue [SemVer](https://semver.org/lang/pt-BR/).
+
+## [0.4.0] — não publicada
+
+Cadeia de hashes segura com vários processos (**P2-4**).
+
+### Corrigido
+
+- **Vários workers no mesmo JSONL quebravam a cadeia.** Cada processo
+  encadeava no `last_hash` que tinha em memória; com gunicorn ou
+  `uvicorn --workers`, dois eventos saíam com o mesmo `previous_hash` e o
+  `verify()` acusava `broken_chain` num arquivo que ninguém adulterou. O modo
+  de falha era silencioso até alguém rodar `verify()`. Reproduzido na 0.3.3
+  com 4 processos × 50 eventos: `{'valid': False, 'error_index': 1,
+  'reason': 'broken_chain'}`. Na 0.4.0 o mesmo teste dá `valid: True` com os
+  200 eventos.
+
+### Adicionado
+
+- **Lock de arquivo entre processos** (`fs2`: `flock` no Unix, `LockFileEx` no
+  Windows) num `<file_path>.lock` ao lado do log — à parte, porque o
+  `flush_pending()` troca o JSONL por `rename` e um lock no próprio arquivo
+  ficaria preso ao inode antigo. Com o lock, o logger confere se o arquivo
+  cresceu desde o seu último append; se cresceu, relê o último hash **só do fim
+  do arquivo**. O handle do `.lock` fica aberto no logger, então o custo do
+  caminho comum não mudou (~29 µs por `log()`, medido antes e depois).
+- **`fsync`** no construtor (padrão `False`). Com `True`, o `log()` só volta
+  depois de o evento estar no disco. Custa ~3,3 ms por evento no macOS
+  (`F_FULLFSYNC`), por isso é opt-in.
+- A reescrita atômica do `flush_pending()` agora faz `sync_data` antes do
+  `rename`, para uma queda de energia não deixar o arquivo final truncado.
+
+### Compatibilidade
+
+- Nenhum parâmetro existente mudou. Aparece um arquivo `<file_path>.lock` ao
+  lado do JSONL nos modos `local`/`hybrid`.
+- Em `mode="hybrid"` com vários workers, a entrega ao ImmutableLog acontece
+  dentro do lock (o hash enviado depende do anterior), então os `log()` dos
+  workers passam a se serializar também no tempo de rede.
+- Arquivos já gravados por vários workers em versões anteriores continuam
+  falhando no `verify()` a partir do primeiro entrelaçamento — o que eles têm
+  é o defeito antigo, não um efeito desta versão.
+
+## [0.3.3] — não publicada
+
+Correção do passo de verificação pós-upload introduzido na 0.3.2, mais o
+trabalho de licença e lint de 12/08/2026 (**P1-4** e **P1-6**).
+
+### Alterado
+
+- **Publicação migrada para trusted publishing (OIDC).** O `release.yml` não
+  usa mais `secrets.PYPI_API_TOKEN`: o GitHub emite um JWT curto afirmando
+  repositório, workflow e ref, e o PyPI o troca por um token de upload válido
+  por poucos minutos e restrito a este projeto. Acaba o segredo de longa
+  duração que, se vazasse, publicaria até ser revogado à mão.
+
+  O passo de upload deixou de ser `maturin upload` dentro de um
+  `nick-fields/retry` e passou a ser dois `pypa/gh-action-pypi-publish`
+  explícitos (`continue-on-error` na primeira, `if: outcome == 'failure'` na
+  segunda) — a action oficial é a que faz a troca OIDC, e não dá para acioná-la
+  por linha de comando de dentro do wrapper de retry. `skip-existing: true`
+  mantém a segunda tentativa idempotente. É a mesma forma que `rust_py_cache` e
+  `rust_py_rate_limit` já rodam.
+
+  ⚠️ **Depende de configuração no PyPI**, e os valores têm que bater exatamente:
+  `robertolima-dev/rust-py-audit`, workflow `release.yml`, environment `pypi`.
+  O modo de falha é seguro — sem o publisher cadastrado, o job falha na troca
+  do token, depois de construir tudo e antes de qualquer arquivo sair do
+  runner. Nada é publicado pela metade.
+
+  💡 A partir daqui a release passa a gerar **atestados PEP 740**, que o
+  `maturin upload` não gerava. A verificação pós-upload já estava preparada:
+  ela só conta `*.whl` e `*.tar.gz` desde a 0.3.2, recorte que nasceu do alarme
+  falso da `rate_limit` 0.2.1. Sem ele, este primeiro release por OIDC seria
+  reprovado por um motivo inventado.
+
+- **Ensaio no TestPyPI por `workflow_dispatch`.** Job `publish-testpypi` novo,
+  na forma que o `rust_py_rate_limit` já tem: um disparo manual constrói a
+  matriz inteira e publica no índice de teste, para validar a troca de token
+  num lugar onde nada é irreversível.
+
+  Para isso, os cinco jobs de build passaram de
+  `if: startsWith(github.ref, 'refs/tags/')` para
+  `... || github.event_name == 'workflow_dispatch'` — sem essa mudança um
+  disparo manual não construiria wheel nenhuma e o ensaio ficaria sem o que
+  publicar.
+
+  ⚠️ **O job `release` deliberadamente NÃO ganhou a cláusula de dispatch.** A
+  assimetria é a proteção: disparo manual vai ao TestPyPI, só a tag chega ao
+  PyPI de produção.
+
+### Adicionado
+
+- **Job `lint`** (`cargo fmt --check` + `cargo clippy -D warnings`) no
+  `release.yml`, com `needs: [test, lint]` em todos os jobs de build e no de
+  publicação — o lint barra a release, igual ao `test`. A toolchain é fixa
+  (`dtolnay/rust-toolchain@1.88.0`) e não `stable`: com `-D warnings`, um
+  clippy mais novo no runner reprovaria código que ninguém tocou.
+- **`clippy.toml` e `Makefile`** compartilhados com os outros quatro
+  `rust_py_*`. O `clippy.toml` sobe `too-many-arguments-threshold` para 10:
+  os construtores PyO3 espelham a assinatura Python, e reagrupar em struct
+  para agradar o lint pioraria a API que o usuário vê.
+
+### Corrigido
+
+- **Metadado de licença ausente no PyPI.** A 0.3.2 está publicada com
+  `license_expression: null` e `license: ""` — ou seja, sem metadado de
+  licença nenhum, só o classifier. A causa raiz não era a forma no
+  `pyproject.toml` (que já usava `license = "MIT"`), e sim a **maturin velha**:
+  versões anteriores à 1.14 não emitem `License-Expression`. O piso do
+  `[build-system]` subiu de `>=1.5` para `>=1.14`, entrou
+  `license-files = ["LICENSE"]` e o classifier `License :: OSI Approved` saiu,
+  por ser mutuamente exclusivo com `License-Expression` no Metadata 2.4.
+  Verificado: o `dist-info` gerado agora traz `License-Expression: MIT` e o
+  texto da licença em `licenses/LICENSE`.
+
+- **Formatação.** `cargo fmt --all` aplicado — eram 38 blocos divergentes, de
+  longe o maior dos cinco. Mudança puramente de formatação, sem efeito em
+  comportamento; os 50 testes Rust seguem passando.
+
+### Conhecido
+
+- `src/audit_logger.rs` ganhou um `#![allow(clippy::useless_conversion)]` de
+  módulo. **Não é código a corrigir:** o lint aponta o *tipo de retorno* de
+  `log`, `verify` e `flush_pending`, mas a conversão está no código que
+  `#[pymethods]` gera — a macro do pyo3 0.22. `#[allow]` no bloco `impl` e na
+  função foram testados e não silenciam, porque o código gerado fica fora do
+  `impl`. `cache` (0.24), `monitor` (0.25) e `scheduler` (0.29) não emitem o
+  aviso, o que confirma ser artefato da versão. O `allow` sai com o **P3-2**.
+
+### Corrigido — pipeline (0.3.2)
+
+- **Falso negativo na verificação pós-publicação.** O passo comparava
+  `glob("dist/*")` com o que estava no PyPI. Nada quebrou aqui — o
+  `maturin upload` não deixa arquivo extra em `dist/` —, mas o glob amplo é
+  frágil: qualquer arquivo novo no diretório reprovaria uma release que deu
+  certo, que foi exatamente o que aconteceu no `rust_py_rate_limit`. O passo
+  agora só considera `*.whl` e `*.tar.gz`, os únicos tipos de arquivo que o
+  PyPI hospeda.
+
+- **Os testes passam a rodar em push e PR.** O `release.yml` é o único workflow
+  destes repositórios e só disparava em tag, então o job `test` só rodava na
+  hora do release — protegia a publicação, mas só avisava do problema no pior
+  momento. Agora o workflow também dispara em `push` para `main` e em
+  `pull_request`, e os jobs de build e o de publicação ganharam
+  `if: startsWith(github.ref, 'refs/tags/')`. Essa guarda corrige um risco que
+  existia antes: o job de release **não tinha `if:`**, então um
+  `workflow_dispatch` manual a partir de um branch teria publicado no PyPI.
+
+**Não vai ao PyPI sozinha:** a 0.3.2 está lá completa e esta versão só
+mexe no pipeline. O número fica reservado e sai com a próxima mudança que
+valha uma tag.
+
+## [0.3.2] - 2026-08-11
+
+Release de infraestrutura: nada muda no comportamento da biblioteca.
+
+### Corrigido
+
+- **A publicação não roda mais sem teste.** O `release.yml` era o único
+  workflow do repositório e só tinha jobs de build: `git push --tags`
+  publicava no PyPI sem nenhum `cargo test` nem `pytest`. Agora existe um job
+  `test` e todos os jobs de wheel, o de sdist e o de release declaram
+  `needs: test`. (BACKLOG2 P1-1)
+- **O upload aguenta o 500 do PyPI.** O upload é arquivo por arquivo e sem
+  transação — uma falha no meio deixa a versão publicada pela metade, e o PyPI
+  nunca permite reusar um nome de arquivo. O passo de publicação agora tem
+  retry (4 tentativas), continua usando `--skip-existing` para ser idempotente,
+  confere o conjunto de artefatos **antes** de subir qualquer coisa (aborta se
+  faltar o sdist) e valida contra a API do PyPI **depois**, listando nome por
+  nome o que não chegou. (BACKLOG2 P1-9)
+
+### Adicionado
+
+- Este `CHANGELOG.md`. (BACKLOG2 P1-5)
+
+## [0.3.1] e anteriores
+
+Sem changelog retroativo. O histórico do que entrou em cada versão está no
+`ROADMAP.md`, e o das mudanças no `git log`.
+
+Resumo do que o projeto entrega hoje:
+
+- `AuditLogger` com log append-only em JSONL e cadeia de hashes encadeada.
+- `verify()` para detectar adulteração da cadeia.
+- Integração com o ImmutableLog nos modos remoto e híbrido.
+- Middlewares para FastAPI e Django.
+- Wheels `abi3-py310` — uma wheel por plataforma, válida da 3.10 em diante.
+
+### Limitação conhecida (não corrigida nesta versão)
+
+⚠️ **Múltiplos processos escrevendo no mesmo arquivo quebram a cadeia.** Cada
+processo mantém seu próprio `last_hash` em memória e não há `flock` no append,
+então dois workers gunicorn apontando para o mesmo JSONL produzem uma cadeia
+inconsistente — e `verify()` acusa corrupção. O modo de falha é silencioso até
+alguém rodar `verify()`. Ver **P2-4** no `BACKLOG2.md`.

{rust_py_audit-0.3.2 → rust_py_audit-0.4.0}/Cargo.lock

@@ -517,6 +517,16 @@ dependencies = [
  "percent-encoding",
 ]
 
+[[package]]
+name = "fs2"
+version = "0.4.3"
+source = "registry+https://github.com/rust-lang/crates.io-index"
+checksum = "9564fc758e15025b46aa6643b1b77d047d1a56a1aea6e01002ac0c7026876213"
+dependencies = [
+ "libc",
+ "winapi",
+]
+
 [[package]]
 name = "futures-channel"
 version = "0.3.32"
@@ -1597,8 +1607,9 @@ dependencies = [
 
 [[package]]
 name = "rust_py_audit"
-version = "0.3.2"
+version = "0.4.0"
 dependencies = [
+ "fs2",
  "httpmock",
  "pyo3",
  "reqwest",

{rust_py_audit-0.3.2 → rust_py_audit-0.4.0}/Cargo.toml

@@ -1,6 +1,6 @@
 [package]
 name = "rust_py_audit"
-version = "0.3.2"
+version = "0.4.0"
 edition = "2021"
 description = "Auditoria de eventos com cadeia de hashes (SHA-256) para apps Python, core em Rust via PyO3."
 license = "MIT"
@@ -60,6 +60,11 @@ time = { version = "0.3", features = ["formatting", "parsing", "serde-well-known
 # (OpenSSL via "native-tls") evita exigir libssl-dev/headers do sistema
 # em cada plataforma onde o wheel é compilado/distribuído.
 reqwest = { version = "0.12", default-features = false, features = ["blocking", "json", "rustls-tls"] }
+# fs2: lock de arquivo entre processos (`flock` no Unix, `LockFileEx` no
+# Windows). Serializa o append da cadeia quando vários workers (gunicorn,
+# uvicorn --workers) gravam no mesmo JSONL. `File::lock` da std resolveria,
+# mas só estabilizou no Rust 1.89 e a CI fixa 1.88.
+fs2 = "0.4"
 
 [dev-dependencies]
 # httpmock: servidor HTTP local de mentirinha, usado só em `cargo test`

rust_py_audit-0.4.0/Makefile

@@ -0,0 +1,68 @@
+# Makefile compartilhado dos `rust_py_*`.
+#
+# Existe para que a CI e a pessoa rodem exatamente o mesmo comando. Quando o
+# lint da CI diverge do lint local, quem perde é sempre quem abriu o PR.
+#
+# A toolchain NÃO é fixada por `rust-toolchain.toml` de propósito: esse arquivo
+# vale para toda invocação do cargo, inclusive a dos containers manylinux do
+# release, e um download de toolchain no meio de uma publicação no PyPI é risco
+# sem contrapartida. A fixação vive no job de lint da CI, que é onde
+# `-D warnings` realmente morde. Localmente, use uma stable recente.
+
+PYTHON ?= python3
+
+# Fixa qual Python o pyo3 usa na compilação. Sem isto ele pega o primeiro do
+# PATH, que pode não ser o mesmo do `make dev` — e aí o binário de teste linka
+# contra uma libpython e o pytest roda contra outra.
+export PYO3_PYTHON ?= $(PYTHON)
+
+# No macOS o binário de `cargo test` carrega a libpython em runtime, e o dyld
+# não a encontra sozinho: o erro é `Library not loaded: @rpath/libpython3.X.dylib`,
+# em SIGABRT, depois de compilar com sucesso — parece falha de teste e não é.
+# Os caminhos padrão entram junto porque definir DYLD_FALLBACK_LIBRARY_PATH
+# *substitui* a lista default do dyld em vez de acrescentar a ela (senão o
+# erro seguinte é libiconv.2.dylib).
+PY_LIBDIR := $(shell $(PYTHON) -c 'import sysconfig; print(sysconfig.get_config_var("LIBDIR") or "")' 2>/dev/null)
+export DYLD_FALLBACK_LIBRARY_PATH := $(PY_LIBDIR):/opt/homebrew/lib:/usr/local/lib:/usr/lib
+
+.PHONY: help dev test lint fmt clippy test-rust test-python clean
+
+help:
+	@echo "make dev          instala o pacote em modo editável com os extras de dev"
+	@echo "make test         cargo test + pytest"
+	@echo "make lint         cargo fmt --check + cargo clippy -D warnings"
+	@echo "make fmt          aplica a formatação (escreve nos arquivos)"
+
+# `pip install` aciona o backend maturin, compila a extensão e instala.
+# Ao contrário de `maturin develop`, não exige um virtualenv ativo — que é
+# exatamente a armadilha que custou um release do monitor (ver P1-9).
+dev:
+	$(PYTHON) -m pip install --upgrade pip
+	$(PYTHON) -m pip install -e ".[dev]"
+
+test: test-rust test-python
+
+# --no-default-features desliga `extension-module`, que impede o binário de
+# teste de linkar contra a libpython no Linux. --lib porque os testes de
+# integração precisam do módulo nativo, e esses ficam do lado Python.
+test-rust:
+	cargo test --no-default-features --lib
+
+test-python:
+	pytest -q
+
+lint: fmt-check clippy
+
+.PHONY: fmt-check
+fmt-check:
+	cargo fmt --all -- --check
+
+clippy:
+	cargo clippy --all-targets --all-features -- -D warnings
+
+fmt:
+	cargo fmt --all
+
+clean:
+	cargo clean
+	rm -rf dist build *.egg-info .pytest_cache