Files
GTI_GERENCIADOR_FISCAL/fiscal/docs/superpowers/specs/2026-09-16-firebird-mission-00e-design.md
T
gti d21a9d1140 Add 'fiscal/' from commit '102ba84500dbd9655a0471288c3e278652593ca9'
git-subtree-dir: fiscal
git-subtree-mainline: d95165fc8f
git-subtree-split: 102ba84500
2026-09-29 14:43:23 -03:00

4.3 KiB

Mission 00E: Threat Model, FDB Provenance, and Real Discovery

Goal

Formalize the trusted-process threat model, validate the actual fdb module provenance and Firebird client compatibility, then run read-only discovery only against D:\PROJETOS\GTISISTEMAS\Projeto\TESTESOFICIAIS.FDB.

Threat model

TRUSTED_PROCESS = TRUE: only versioned application code runs in the process; there are no untrusted plugins, user-provided scripts, external eval/exec, or externally selected dynamic imports. Deliberate introspection or monkey patching by code that already has arbitrary Python execution is equivalent to application compromise and is outside this component's boundary.

The boundary protects against implementation mistakes, accidental unauthorized operations, arbitrary SQL exposed to normal callers, parameter-to-SQL injection, routine execution, wrong database selection, unintended writes, and dependency shadowing/import mistakes.

API boundary

The public API exposes only structured catalog operations and catalog-issued bounded sampling. It exposes no execute(sql), query(sql), raw_execute, operation-registration mutator, procedure/UDF invocation, arbitrary clauses, or alternate database path. The registry remains module-private, immutable, and centrally constructed. Python internals are not treated as a cryptographic sandbox.

The old SQL parser is offline-only diagnostic/test code. It has no authority to approve runtime SQL. Internal Firebird query templates may use legitimate CAST, aggregates, joins, and grouping because they are selected by fixed operation keys owned by the project.

Provenance gate

Before any database connection, inspect the actual import fdb module:

  • fdb.__file__ and fdb.__package__;
  • module version and importlib.metadata distribution/version/location;
  • interpreter, working directory, sys.path, and PYTHONPATH;
  • local fdb.py, fdb directory, and unexpected .pth shadowing candidates.

The imported module must correspond to the expected installed distribution and version, without ambiguous duplicate installations. The installed Firebird client/server evidence must match the selected driver compatibility. Any ambiguity blocks before import/use of the driver for database access.

Connection and discovery

After the provenance and safety gates pass, connect only to the authorized FDB, using the installed compatible client and a Firebird read-only transaction. Run the minimal identity operation first and compare the engine-reported identity to the authorized target. Then collect catalog metadata through structured operations, use only catalog-issued sample identities, and inspect product, stock, fiscal, image, incremental, trigger, and procedure metadata without executing routines or reading BLOB contents.

Correlate the ERP UI fields NCM, CFOP, CST ICMS, ICMS rate, CEST, CSOSN, PIS/COFINS, IPI, origin, IAT, incidence, and IPPT to table, column, type, domain/FK, dependencies, triggers, evidence, and confidence. Classify each as CONFIRMED, INFERRED, or UNKNOWN. Generate a real fingerprint only from sanitized complete evidence; otherwise use SCHEMA_UNKNOWN.

Evidence and safety

  • Only D:\PROJETOS\GTISISTEMAS\Projeto\TESTESOFICIAIS.FDB may be opened.
  • External ERP files, services, registry, DLLs, and configuration are read-only.
  • APPLICATION_DDL_DML_WRITES = 0.
  • OTHER_DATABASES_ACCESSED = 0.
  • ERP_FILES_MODIFIED = 0.
  • No credentials, original ERP database path, raw BLOB/image, full rows, or unnecessary customer/commercial data enters source or reports.
  • No fiscal API, image API, Windows service, scheduler, product UPDATE, or migration is implemented.

Verification and outcome

Tests cover the public API, registry immutability, SQL non-authority, quoted-identifier and routine cases, legitimate internal expressions, path allowlisting, provenance/shadowing, client compatibility, structured reader, sampling, fingerprint, and discovery. The final report includes provenance, client/engine facts, connection result, schema mappings, image/incremental/ trigger evidence, tests, Git state, and real gaps. Missing credentials, ambiguous provenance, compatibility failure, identity mismatch, or incomplete discovery results in MISSION_00_BLOCKED without a database connection or fallback to another database.