PermitProbe v0.3.1

PermitProbe v0.3.1 release notes

PermitProbe v0.3.1 broadens deterministic website response coverage and hardens the credential,
local-file, and release boundaries used by one-shot assessments. The execution model remains
GET-only and policy-declared: discovery proposals and OpenAPI inventory never grant request
authority.

Browser and response contracts

Public resources can now require COOP, COEP, CORP, Origin-Agent-Cluster, and selected
Permissions-Policy features in addition to the existing HSTS, CSP, framing, referrer, cookie,
CORS, cache, JSON, status, and latency checks. Structured values, Vary, HSTS delta-seconds,
CORS origins, and cookie attributes are parsed completely and within explicit budgets.

Response schemas preserve exact finite decimal values and accept only the reviewed Draft 2020-12
keyword subset. Unsupported format assertions, alternate dialects, ignored keywords, invalid
Unicode, excessive numeric values, and ambiguous regular expressions now fail policy loading rather
than creating a constraint that appears enforced.

OpenAPI 3.0–3.2 inventory validates each referenced inline security scheme before classifying a
route as protected. It checks required API-key, HTTP, mutual-TLS, OAuth2, and OpenID Connect fields,
including version-specific flows, declared OAuth scopes, bounded HTTPS endpoints, and the different
non-OAuth requirement-array rules in OpenAPI 3.0 versus 3.1 and 3.2.

Credential and authorization boundaries

Bearer tokens and cookies remain in PermitProbe's delivery layer; Overstep receives only environment
references. Exploration providers cannot inherit any policy-referenced credential or request-header
environment variable, even when it was also named in the provider allowlist.

Cookie credentials use normalized, unambiguous name/value pairs for distinct-subject checks.
Resource policies reject duplicate rules for one role and anonymous own scope before either can
widen the expected authorization result.

Local files and artifacts

Policy, OpenAPI, baseline, report, and replay inputs must be bounded regular files. Handoff roots and
components are opened without following links, and portable bundle names reject Unicode/case
collisions, Windows device aliases and reserved characters, and overlong UTF-16 components.
Baseline, report, checkpoint, exploration-trace, and replay version fields require actual JSON
integers; booleans and numerically equal decimals cannot select a document format.

Reports, bundles, exploration state, scanner binaries, and starter files are assembled privately and
fsynced before publication. permitprobe init creates its directory with mode 0700 and both
starter files with mode 0600.

Release and CI supply chain

CI uses pinned actions and Ubuntu 24.04, CodeQL, dependency review, hash-locked binary dependencies,
and a hash-verified Gitleaks binary. It scans the clean checkout with fixed default rules before
build artifacts exist and does not honor repository suppression files or inline allow comments.

Publication executes verification code from trusted main, accepts only tags in main history, and
proves wheel and sdist code and metadata match that tag. Scanner publication is atomic and verifies
the executable digest. Release archive verification bounds decompressed sdist bytes, member counts,
individual files, and aggregate content before provenance comparison, and the GitHub Release may
contain only the two verified distributions. The isolated wheel gate also runs pip check after the
hash-locked install and before the packaged CLI is accepted. Artifact-only author names and author
or maintainer email fields are rejected when the reviewed project metadata does not declare them.
The complete metadata field set, values, ordering, and multiplicity must match the tag, so other
undeclared or duplicate artifact-only metadata is rejected as well. Source-distribution TAR
headers use neutral root ownership and cannot expose the local build account. Every smoke-test
Python subprocess uses isolated mode so inherited module paths, user-site packages, and other
PYTHON* settings cannot replace the distribution being verified.

Compatibility

The policy format remains version 1 and the report schema remains version 2. Existing explicit
contracts remain compatible, but policies that relied on duplicate role rules, unsupported JSON
Schema keywords or formats, ambiguous regular expressions, or incomplete OpenAPI security schemes
now fail closed and need correction.

Python 3.11 or newer and Gitleaks 8.30.1 remain required. PermitProbe still does not follow
redirects, execute discovered routes, issue write requests, validate signed-token cryptography, or
connect directly to a database.