Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 17 additions & 1 deletion CHANGELOG.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,6 +4,22 @@ All notable changes to this project will be documented in this file. The format

## [Unreleased]

## [1.0.0] - 2026-08-11

### Changed

- [#39](https://github.com/mohanagy/miftah/issues/39) Established the stable Semantic Versioning contract for documented configuration formats, CLI and MCP names, audit records, package exports, and the plugin API. The v1 candidate preserves the tested 0.5.8 runtime surface while promoting the compatibility, migration, documentation, security, and cross-platform gates accumulated across the pre-1.0 line.
- [#36](https://github.com/mohanagy/miftah/issues/36) Added a repeatable, research-only evaluation of MCP tool-description quarantine: exact descriptor drift is detected with canonical hashes, while a deliberately small heuristic corpus records both false positives and missed malicious descriptions. The published recommendation defers runtime quarantine until representative design-partner evidence shows acceptable value, approval churn, and recovery behavior; this prototype is not a production security control and does not claim protection after credentials reach an operator-approved upstream.

### Security

- [#373](https://github.com/mohanagy/miftah/issues/373) Updated the exact transitive security resolutions to `fast-uri` 3.1.5, `ip-address` 10.3.1, `hono` 4.12.34, `brace-expansion` 5.0.9, and `nanoid` 3.3.17 after newly disclosed host-confusion, SSRF/trust-classification, ReDoS, and denial-of-service advisories. Package contracts reject stale nested copies, and both production-only and full npm audits report zero known vulnerabilities without changing Miftah's runtime API.

### Validation

- The maintainer reported **5/5 completed external workflows**, **3 returning participants**, **3 unaided evaluators**, and a completed security report, then authorized closure of the related v1 issues. This release record preserves that as maintainer attestation: the participant records and completed report were not independently inspected during release preparation, and no additional provider, reviewer, severity, or remediation facts are inferred here.
- Publication remains protected: the finalized candidate is promoted from `development` to the exact current `main` commit, released as `v1.0.0`, and published only through protected OIDC publication with registry provenance, fresh-install, and signature verification recorded on #39.

## [0.5.8] - 2026-08-09

### Fixed
Expand Down Expand Up @@ -212,4 +228,4 @@ All notable changes to this project will be documented in this file. The format

## Release policy

Miftah is experimental and pre-1.0, so incompatible changes may occur between minor versions and must be called out here. For each release, maintainers move **Unreleased** entries into a dated version section, update `package.json` and `package-lock.json` together using npm tooling, and publish a GitHub release tagged `v<package-version>`. The release workflow publishes only after the tag, ancestry, tests, build, CLI smoke test, and package contents are verified.
Miftah 1.x follows Semantic Versioning for the public compatibility surfaces documented in the library, CLI, configuration, audit, MCP-management, and plugin references. Compatible fixes use patch releases, additive compatible features use minor releases, and incompatible public changes require a new major release with an explicit **Unreleased** entry and migration guidance. For each release, maintainers move **Unreleased** entries into a dated version section, update `package.json` and `package-lock.json` together using npm tooling, and publish a GitHub release tagged `v<package-version>`. The release workflow publishes only after the tag, ancestry, tests, build, CLI smoke test, and package contents are verified.
8 changes: 5 additions & 3 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -19,9 +19,9 @@ Claude, Cursor, or VS Code

Miftah itself has no cloud service or telemetry. It adds local profile selection, credential references, policy, approvals, redaction, diagnostics, and optional audit metadata around an upstream; it does not replace that upstream or widen what the upstream supports.

> **Status:** Miftah is experimental and pre-1.0. Interfaces and security behavior may change between minor versions. External multi-account and returning-user validation in [#25](https://github.com/mohanagy/miftah/issues/25) and [#88](https://github.com/mohanagy/miftah/issues/88) remains open.
> **Status:** Miftah 1.0 is the stable v1 release line. Documented public compatibility surfaces follow Semantic Versioning. The external workflow and security-review gates were closed by maintainer attestation in [#39](https://github.com/mohanagy/miftah/issues/39); the source participant records and completed security report are not published in this repository.

Already using Miftah? See [What is in 0.5 and how to use it](docs/whats-new-in-0.5.md) for the release's guided setup, profile-management, Console, OAuth, and upgrade paths.
Upgrading from Miftah 0.5? See [What is in 0.5 and how to use it](docs/whats-new-in-0.5.md) for the guided setup, profile-management, Console, OAuth, and upgrade paths introduced before the stable line.

## Is Miftah for you?

Expand Down Expand Up @@ -53,7 +53,7 @@ Install Miftah, then choose the terminal wizard or the browser Console. Both use
### 1. Install the current release

```bash
npm install -g @lubab/miftah@0.5.8
npm install -g @lubab/miftah@1.0.0
miftah version
```

Expand Down Expand Up @@ -165,6 +165,8 @@ Read the [Security boundary](docs/security.md) and [threat model](docs/threat-mo
- [OAuth guide](docs/oauth-support.md) — native remote OAuth and upstream-owned OAuth
- [CLI reference](docs/cli.md) — commands, diagnostics, exit codes, logs, and [Troubleshooting](docs/cli.md#troubleshooting)
- [Console guide](docs/console-api.md) — optional local dashboard and API
- [v1 external evaluation](docs/v1-evaluation.md) — privacy-safe workflows, unaided first-use checks, and returning-user evidence
- [independent security review brief](docs/independent-security-review.md) — review scope, deliverables, disclosure, and closure gates
- [Security boundary](docs/security.md), [Threat model](docs/threat-model.md), [OAuth and Console security design](docs/oauth-console-threat-model.md), and [Architecture](docs/architecture.md)
- [profile credential isolation](docs/config.md#profile-credential-isolation), [routing context](docs/config.md#routing-context), and [provider routing matchers](docs/config.md#provider-routing-matchers)
- [Provider adapters](docs/provider-adapters.md), [plugins](docs/plugins.md), and [library API](docs/library-api.md)
Expand Down
2 changes: 1 addition & 1 deletion docs/cli.md
Original file line number Diff line number Diff line change
Expand Up @@ -10,7 +10,7 @@ Usage: miftah [command] [options]

The root command list includes `serve`, `dashboard`, `console`, `validate`, `doctor`, `schema`, `setup`, `init`, `migrate-config`, `profile list|set-default|set-description|rename|remove|test`, `connection add|list|status|test`, `auth connect|reauth|disconnect`, `list-tools`, `test-profile`, `logs`, `audit-export`, `audit-verify`, and `version`. With no command, Miftah runs `serve`.

Documented command names, options, JSON success forms, and exit categories are compatibility contracts. An incompatible CLI removal, rename, required-option change, or semantic output change requires the pre-1.0 deprecation/removal process in the [public compatibility policy](library-api.md#compatibility-policy).
Documented command names, options, JSON success forms, and exit categories are compatibility contracts. An incompatible CLI removal, rename, required-option change, or semantic output change requires a new major release and the deprecation/removal process in the [public compatibility policy](library-api.md#compatibility-policy).

`--help` and `-h` print help and exit successfully. They can appear before or after a command. Help never reads configuration, resolves secrets, or starts an upstream.

Expand Down
2 changes: 1 addition & 1 deletion docs/config.md
Original file line number Diff line number Diff line change
Expand Up @@ -20,7 +20,7 @@ Version `"2"` is the prior canonical non-OAuth format. Version `"3"` keeps its e

For version 1, the migrator changes only aliases with proven equivalent behavior: `"http"` becomes `"streamable-http"`, the plaintext opt-in moves to `secrets.allowPlaintextSecrets`, and redundant force-on redaction declarations are removed. It fails closed for conflicting plaintext options or unrelated unsupported fields rather than discarding them. A version-2 input preserves the existing configuration while changing only the format version; it never infers native OAuth from a static `Authorization` header. A version-3 input is validated and reported as unchanged; `--write` then creates no backup and performs no write.

Versions 1 and 2 will remain accepted through at least the first published pre-1.0 minor release after version 3 ships. Removing either version requires a later minor release, an **Unreleased** changelog entry, and a documented explicit migration path. Keep a byte-for-byte historical fixture for every supported released format in release CI.
Versions 1, 2, and 3 remain accepted throughout the Miftah 1.x release line. Removing version 1 or 2 requires a new major release, an **Unreleased** changelog entry, and a documented explicit migration path. Keep a byte-for-byte historical fixture for every supported released format in release CI.

For strict starter configurations, use the versioned `init` catalog rather than treating generic command examples as trusted upstream recommendations. The [preset and client compatibility matrix](presets-and-clients.md) records exact pins, required inputs, upstream provenance, and the validation boundary for every catalog entry.

Expand Down
70 changes: 70 additions & 0 deletions docs/independent-security-review.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,70 @@
# Independent security review brief

This brief defines the external review required by issues #37 and #39 and records the evidence boundary for the maintainer's completion attestation. It turns the public [threat model](threat-model.md) into a reviewable engagement without inventing report details that were not supplied to the repository.

## Target and independence

The engagement baseline is the published `@lubab/miftah@0.5.8`; the stable release candidate is `@lubab/miftah@1.0.0`. The maintainer and reviewer must record the exact commit and package version under review, the upstream dependencies or fixtures used, the operating systems exercised, and the review dates. The v1 release candidate must receive either a final review at its exact commit or a reviewer-accepted delta review from the recorded baseline.

The reviewer supplies an independence declaration covering employment, contribution, financial, and other material relationships with Miftah and its maintainers. A maintainer self-review, automated scanner, dependency report, or AI-only review is useful input but does not satisfy this independent gate.

## Recorded review status

On 2026-08-11, the maintainer reported that the security report was completed and explicitly authorized closure of #37. That statement is recorded as maintainer attestation. The completed report, reviewer attribution and independence declaration, target commit, severity counts, remediation or retest record, public completion summary, and v1 candidate delta acceptance were not supplied for this release-preparation session and therefore were not independently inspected. Maintainer attestation or deidentified records alone do not close the independent-review criterion in #39. This status does not create or infer the missing facts; #39 must retain the exact protected-release evidence and any reviewer-approved final-candidate reconciliation used for publication.

## Review scope

Review the security claims and boundaries in [`threat-model.md`](threat-model.md), [`security.md`](security.md), and the OAuth and Console threat model. At minimum, cover:

- configuration schema, migration, safe writes, permissions, symlink and replacement races;
- secret references, environment and OS-vault boundaries, credential envelopes, and redaction;
- child-process launch and shutdown, executable resolution, Windows job containment, and output handling;
- profile, runtime, connection, OAuth, and container isolation, including wrong-account and cross-profile failure paths;
- local HTTP, Console authorization, Origin and CSRF checks, loopback OAuth callback validation, state, issuer, PKCE, timeout, and cancellation;
- routing, policy, approvals, connection locking, identity evidence, and fail-closed behavior;
- audit integrity and the documented limits of local tamper evidence;
- plugins, provider adapters, package contents, dependency and supply-chain boundaries;
- denial-of-service, resource exhaustion, malformed upstream messages, and cleanup behavior.

Include relevant Linux, macOS, and Windows paths when the implementation differs. The review may exclude a live third-party provider or unsupported client only when the report names the exclusion and explains how fixtures, code review, or residual risk cover it.

## Expected methods

The reviewer chooses the exact method, but the report must distinguish source review, automated testing or scanning, manual adversarial testing, and documentation analysis. Exercise negative paths and boundary violations, not only happy-path behavior. Validate important claims against the packaged artifact as well as source when packaging can change the result.

Miftah maintainers provide architecture and setup help, answer scope questions, and reproduce findings. They do not constrain severity, suppress an in-scope result, or author the reviewer's conclusions.

## Deliverables and disclosure

The reviewer provides:

1. a private report with target identifiers, scope, exclusions, methods, findings, severity and rationale, affected versions, reproduction guidance, and recommended remediation;
2. a remediation-verification addendum that records the exact fix commit or package for every critical or high finding and the independent reviewer's retest result or written acceptance;
3. a public completion summary naming the reviewer or organization when permitted, review dates, target, scope, exclusions, severity counts, remediation status, and residual limitations without exploit-enabling detail;
4. the signed or otherwise attributable independence declaration.

Send vulnerability details through the private process in [`SECURITY.md`](../SECURITY.md). Do not open a public GitHub issue with credentials, private provider data, or an unpatched exploit. Public issue #37 should link only the completion summary and safe remediation evidence.

## Closure gate

The review gate closes only when:

- the external reviewer has delivered the required report and independence declaration;
- there is no unresolved critical or high-severity finding in the reviewed v1 target;
- every critical or high finding has an exact remediation commit, regression test where practical, and independent reviewer retest or written verification acceptance by that reviewer;
- the public completion summary states the exact target, scope, exclusions, severity counts, and remediation status;
- any change between the reviewed target and the v1 release candidate has been included in the review or accepted by the independent reviewer through a documented delta assessment.

Medium and lower findings must have a documented disposition, owner, and timeframe. Acceptance of residual risk must name the decision maker and rationale. Passing existing CI or publishing this brief does not satisfy the gate.

## Maintainer handoff checklist

- [ ] Freeze and record the exact review target.
- [ ] Provide build, test, architecture, threat-model, and safe fixture instructions.
- [ ] Confirm a private reporting channel and response contacts from `SECURITY.md`.
- [ ] Receive and archive the independence declaration and private report.
- [ ] Triage findings without changing reviewer-authored severity evidence.
- [ ] Remediate and add regression coverage.
- [ ] Obtain independent reviewer verification or written acceptance by that reviewer.
- [ ] Publish the safe completion summary and link it from #37.
- [ ] Reconcile the final v1 candidate against the reviewed target before closing #39.
Loading