From ad3112b8cc59393fa75fe3ef5a52e6a199548840 Mon Sep 17 00:00:00 2001 From: Proxicon Date: Sat, 19 Sep 2026 19:32:43 +0200 Subject: [PATCH] docs: add NetClaw tenant MCP setup guide --- README.md | 173 +++++++++++++++-------- docs/netclaw.md | 212 ++++++++++++++++++++++++++++ tools/ci/check-public-disclosure.sh | 2 +- 3 files changed, 330 insertions(+), 57 deletions(-) create mode 100644 docs/netclaw.md diff --git a/README.md b/README.md index b8ce29ff..4cc08015 100644 --- a/README.md +++ b/README.md @@ -2,106 +2,167 @@ # RatelDesk -RatelDesk is a self-hosted, multi-tenant service-desk application built with ASP.NET Core and Blazor. It manages incidents, requests, changes, work logs, knowledge, email workflows, and optional AI-assisted operations. +RatelDesk is a self-hosted, multi-tenant service desk for incidents, requests, +changes, work logs, knowledge, email workflows, and optional AI assistance. +It is built with ASP.NET Core and Blazor, and starts simply: SQLite and local +accounts are enough for a new installation. -It starts with embedded SQLite and local accounts, with PostgreSQL, OIDC providers (including Authentik and Microsoft Entra ID), email, AI, MCP, telemetry, and orchestration available as optional deployment integrations. +Use this README to get running and choose a deployment path. The detailed +operator material lives in [self-hosting](docs/SELF_HOSTING.md), +[branding](docs/branding.md), and [release engineering](docs/releases.md). -## Quick start +## Start locally -Prerequisites: Docker with Compose, or the .NET SDK specified by [global.json](global.json). No database or identity-provider service is required for a new installation. Run these Compose commands from the root of a checked-out copy of this repository: +You need Docker with Compose, or the .NET SDK pinned in +[global.json](global.json). From a checkout of this repository, start the +default stack: ```bash docker compose -f docker/docker-compose.yml up --build ``` -Open `http://localhost:8111/`. A fresh instance opens the seven-step setup wizard automatically. Retrieve its setup code from the API container; this command finds the code using the API's configuration and does not change it: +Open `http://localhost:8111/`. On a fresh installation, RatelDesk opens the +setup wizard. Retrieve the one-time setup code from the API container: ```bash -docker compose -f docker/docker-compose.yml exec api dotnet /app/Helpdesk.API.dll --show-setup-code +docker compose -f docker/docker-compose.yml exec api \ + dotnet /app/Helpdesk.API.dll --show-setup-code ``` -Paste that code into **Unlock setup**, then choose storage, set the instance details, create the first administrator, optionally add branding, review, and finish. Sign in with the administrator email and password you just created. No authenticator or recovery code is needed for the initial login. Two-factor verification appears only for accounts that explicitly enabled it later in account settings. +Use the code to unlock setup, then choose storage, name the instance, and +create the first administrator. The setup code unlocks only the wizard; it is +not a login or MFA credential. Initial local-account sign-in does not require +an authenticator. MFA is requested only after an account enables it. -**Already deployed through a container manager?** You do not need a local Compose file or an interactive terminal. Run these commands on the Docker host, replacing `rateldesk-api-1` with the actual API container name from the first command: +If you deploy through a container manager, run the equivalent command on the +Docker host. Replace `rateldesk-api-1` with the name shown by `docker ps`: ```sh docker ps --format 'table {{.Names}}\t{{.Image}}' docker exec rateldesk-api-1 dotnet /app/Helpdesk.API.dll --show-setup-code ``` -If you are already inside the API container's `sh` terminal, run `dotnet /app/Helpdesk.API.dll --show-setup-code`. The Alpine image includes `sh`; Bash is not required. Open your application's public URL to continue setup. If retrieval fails, run the same command with `--setup-status` for the API version, configured state directory, and setup state without printing secrets. See [setup troubleshooting](docs/SELF_HOSTING.md#setup-code-and-container-troubleshooting) for missing state or an older image. These read commands require rc.5 or later. +Inside the API container, `dotnet /app/Helpdesk.API.dll --show-setup-code` is +enough; the image includes `sh`, not Bash. If the code cannot be retrieved, +run the command with `--setup-status` and follow the +[setup troubleshooting guide](docs/SELF_HOSTING.md#setup-code-and-container-troubleshooting). +These read-only commands require rc.5 or later. -The default Compose stack runs Web and API in Production mode with persistent SQLite, bootstrap, data-protection, and attachment volumes. It is explicitly configured for localhost HTTP so local-account cookies use the valid `RatelDesk.Local` name. Deploy HTTPS and remove `Authentication__AllowInsecureLocalhost` for public hosting. +The default Compose stack runs Web and API in Production mode over localhost +HTTP and persists SQLite, bootstrap, data-protection, and attachment volumes. +Its local-account cookie uses the valid `RatelDesk.Local` name. Public +deployments need HTTPS and must remove `Authentication__AllowInsecureLocalhost`. +For local .NET development, run API and Web with durable local paths; the same +`/setup` flow initializes a fresh database. -For local .NET development, run the API and Web projects with their configuration pointed at durable local paths. The same `/setup` flow initializes a fresh local database. +## Choose storage and a release path -## Released containers +SQLite is the simplest choice for a new instance. PostgreSQL is available for +larger or externally managed deployments, and is required for native ticket AI +Assistant chat. SQLite still supports webhook AI assistance and its history. -To run published images rather than build from source, select an exact published version and use the release Compose file: - -```bash -RATELDESK_VERSION=0.1.0 docker compose -f docker/docker-compose.release.yml up -d -``` - -Use an exact SemVer tag in production, or preferably replace tags with the published image digests. `latest` advances only for stable releases; prereleases never move it. See [release engineering](docs/releases.md) for versioning, build metadata, and release instructions. - -## Bundled PostgreSQL - -For a fresh installation with PostgreSQL, add the bundled sidecar overlay. Choose a unique password outside source control: +For a fresh bundled PostgreSQL installation, add the sidecar overlay and supply +a unique password outside source control: ```bash RATELDESK_POSTGRES_PASSWORD='replace-with-a-secret' \ - docker compose -f docker/docker-compose.yml -f docker/docker-compose.postgres.yml up --build + docker compose -f docker/docker-compose.yml \ + -f docker/docker-compose.postgres.yml up --build ``` -At `/setup`, select PostgreSQL and enter host `postgres`, port `5432`, database `rateldesk`, user `rateldesk`, and the password supplied above. For published images, replace the first Compose file with `docker/docker-compose.release.yml` and set `RATELDESK_VERSION` to an exact release tag. - -## External PostgreSQL +At `/setup`, select PostgreSQL and use host `postgres`, port `5432`, database +`rateldesk`, user `rateldesk`, and that password. For an external PostgreSQL +server, run the normal stack and enter its reachable, empty target in setup. +The full requirements for TLS, upgrades, backups, recovery, and unattended +initialization are in [self-hosting](docs/SELF_HOSTING.md#external-postgresql). -For an externally managed PostgreSQL database, start the normal source or release stack and enter its connection details at `/setup`; the API must be able to reach the database network. The target must be empty for a new setup. +To run published images rather than build from source, choose an exact release +version: ```bash -docker compose -f docker/docker-compose.yml up --build +RATELDESK_VERSION=0.1.0 docker compose -f docker/docker-compose.release.yml up -d ``` -Complete `/setup` with the external host, port, database, user, password, and TLS preference. For published images, replace the first Compose file with `docker/docker-compose.release.yml` and use an exact `RATELDESK_VERSION`. The included external overlay is for explicit unattended initialization and requires operator-supplied secrets; it never maps a fresh-install connection string directly into the normal runtime. See [self-hosting guidance](docs/SELF_HOSTING.md#external-postgresql) for preflight, unattended setup, upgrade, backup, and recovery requirements. +Use an exact SemVer version, or preferably published image digests, in +production. `latest` follows stable releases only; prereleases never move it. -## Configuration +## Operate safely -The main public configuration surfaces are: +Most first-run configuration belongs in the setup wizard. Deployment-owned +settings are supplied as environment variables or secret mounts. Common ones +include: -- `Database__Provider=Sqlite|PostgreSql`; an explicit PostgreSQL provider uses `ConnectionStrings__HelpdeskDb`, while a fresh SQLite installation is initialized through `/setup`. -- `Database__Sqlite__Path` for the SQLite file location when it is deployment-managed. -- `Authentication__Mode=Local|Oidc|Hybrid`; Local is the first-run default. -- `DataProtection__KeyRingPath` for a persistent, shared key-ring directory in production. -- `Authentication__Authentik__*` or `Authentication__Azure__*` for OIDC. -- `ExchangeEmail__*` for Microsoft Graph email delivery; set `ExchangeEmail__Enabled=true` only after supplying credentials. -- `ImapEmail__*` and SMTP configuration for inbound/outbound email workflows. -- `OTEL_EXPORTER_OTLP_ENDPOINT` and `OTEL_RESOURCE_ATTRIBUTES` for telemetry export. -- `RATELDESK_MCP_*` for isolated MCP clients. -- `Branding__*` for deployment-owned instance identity. See [branding](docs/branding.md). -- AI-provider and orchestration configuration through the administration UI or documented environment configuration. +- `Database__Provider` and `ConnectionStrings__HelpdeskDb` for an explicit + PostgreSQL deployment. +- `Authentication__Mode` and the Authentik or Microsoft Entra settings for + local, OIDC, or hybrid sign-in. +- `DataProtection__KeyRingPath` and `StorageOptions__RootPath` for durable + production storage. +- Email, telemetry, branding, AI, MCP, and orchestration settings when those + integrations are enabled. -`/tmp/rateldesk/keys` is a safe local fallback for data-protection keys. Production deployments must override it with a durable mounted volume or managed key store. Back up the SQLite data directory, bootstrap state, data-protection key ring, and attachments together. +`/tmp/rateldesk/keys` is a local fallback, not a production key store. Back up +the database, bootstrap state, data-protection keys, and attachments together. +See [self-hosting](docs/SELF_HOSTING.md) for the complete configuration and +operating guidance. -## Documentation +## NetClaw AI Assistant and MCP -See [self-hosting guidance](docs/SELF_HOSTING.md) for configuration, Docker, reverse-proxy, identity, email, AI, MCP, orchestration, telemetry, and troubleshooting guidance. -See [instance branding](docs/branding.md) to customise the customer-facing identity without forking RatelDesk. - -## API, CLI, and MCP +NetClaw is a first-class companion for the ticket AI Assistant. It connects to +RatelDesk in two separate, complementary directions: -The Web-hosted [RatelDesk API reference](/api/docs) groups the public API by product area and sends Try It requests through the established `/api` proxy. Local account login is a browser-cookie flow with CSRF protection; a browser cookie is not a CLI or MCP Bearer credential. - -For automation, sign in normally, complete configured MFA, then create a bounded API integration credential through `POST /api/v1/integration-credentials`. The secret is returned only by the create response. Store it in a protected configuration file or secret mount. Its effective access is always the intersection of the account's current authorization, the credential's selected permissions, and its organization scope; revocation and account disablement take effect on later requests. +```mermaid +flowchart LR + RD[RatelDesk API] -- "paired device token\nSignalR /hub/session" --> NC[NetClaw] + NC -- "scoped HTTP MCP credential\nhttps://rateldesk.example/mcp" --> MCP[RatelDesk HTTP MCP] + MCP --> RD +``` -GitHub Releases contain self-contained `rateldesk` CLI and `rateldesk-mcp` stdio MCP archives for Linux x64/arm64 and Windows x64. The Linux archives target glibc distributions, not Alpine/musl. Both executables support offline `--help` and `--version` before loading credentials. +The first connection lets RatelDesk run a ticket conversation through NetClaw. +The second gives NetClaw carefully scoped RatelDesk tools. They use different +credentials, have different purposes, and must never be substituted for one +another. -HTTP MCP is optional and never joins the base Web/API stack. The source and release overlays are documented in [the HTTP MCP example](docker/examples/mcp-http/README.md). The existing Authentik HTTP MCP mode remains a separately configured external identity integration; it is not a fallback for local credentials. +Read the [NetClaw integration guide](docs/netclaw.md) before enabling either +path. It covers pairing, SignalR recovery, the optional HTTP MCP host, +tenant-per-NetClaw boundaries, least privilege, credential rotation, and a +copy/paste-safe NetClaw CLI onboarding flow. -## Contributing and security +## API, CLI, and MCP -Read [CONTRIBUTING.md](CONTRIBUTING.md) before opening a change. Report vulnerabilities privately according to [SECURITY.md](SECURITY.md). +The web-hosted [RatelDesk API reference](/api/docs) documents the public API. +Browser sign-in uses a CSRF-protected cookie; that cookie is not a CLI or MCP +Bearer credential. + +For automation, create an account-owned integration credential at +`POST /api/v1/integration-credentials` after normal sign-in and configured MFA. +The secret is displayed once. Put it in a protected configuration file or +secret mount. Its access is always the intersection of the account's current +authorization, selected permissions, and organization scope; revocation and +account disablement take effect on later requests. + +GitHub Releases include self-contained `rateldesk` CLI and `rateldesk-mcp` +stdio MCP archives for Linux x64/arm64 and Windows x64. Linux archives require +a glibc distribution, not Alpine/musl. Both support offline `--help` and +`--version` before loading credentials. + +HTTP MCP is optional and separate from the base Web/API stack. Its source and +release overlays are documented in the +[HTTP MCP example](docker/examples/mcp-http/README.md). Authentik HTTP MCP +mode is a separate external-identity integration; it is not a fallback for +local paired credentials. + +## Documentation and contribution + +| Need | Read | +| --- | --- | +| Install, configure, secure, or recover an instance | [Self-hosting](docs/SELF_HOSTING.md) | +| Connect NetClaw AI Assistant and tenant-scoped MCP | [NetClaw integration](docs/netclaw.md) | +| Brand an instance without forking | [Branding](docs/branding.md) | +| Build and publish releases | [Release engineering](docs/releases.md) | + +Read [CONTRIBUTING.md](CONTRIBUTING.md) before opening a change. Report +vulnerabilities privately under [SECURITY.md](SECURITY.md). ## License diff --git a/docs/netclaw.md b/docs/netclaw.md new file mode 100644 index 00000000..2b5e176a --- /dev/null +++ b/docs/netclaw.md @@ -0,0 +1,212 @@ +# NetClaw AI Assistant and tenant-scoped MCP + +NetClaw can work with RatelDesk in two directions. They are complementary, but +they are not the same integration and they do not share credentials. + +```mermaid +flowchart LR + A[RatelDesk API] -- "Dedicated paired-device token\nSignalR /hub/session" --> B[NetClaw daemon] + B -- "MCP-purpose integration credential\nHTTPS /mcp" --> C[RatelDesk HTTP MCP host] + C --> A +``` + +- **RatelDesk to NetClaw** powers the ticket **AI Assistant** conversation. + RatelDesk API, not a browser, holds the paired-device token and opens the + SignalR connection. +- **NetClaw to RatelDesk** gives NetClaw tenant-scoped RatelDesk tools through + the optional HTTP MCP host. + +For production, use one dedicated NetClaw deployment, RatelDesk account, MCP +credential, and organization scope for each tenant. A NetClaw deployment or +credential for one tenant must not be used to reach another tenant. + +## Before you begin + +You need a working RatelDesk instance, a NetClaw daemon, and an operator who +can manage both. Native ticket chat additionally requires PostgreSQL and is +disabled by default. SQLite supports webhook AI assistance and investigation +history, but not native SignalR chat. + +Choose the network shape before creating credentials: + +| Shape | Appropriate use | Boundary to keep | +| --- | --- | --- | +| Private network or local evaluation | Short-lived evaluation where both services are controlled | Do not expose the daemon or MCP port publicly. Private HTTP is a deliberate exception, not a production default. | +| Tailnet | Remote access limited to trusted devices | Keep NetClaw reachable only to the intended tailnet. | +| Reverse proxy with DNS and TLS | A managed public or private service endpoint | Proxy SignalR and HTTP MCP correctly; configure NetClaw trusted proxies. | +| Managed tunnel | A deliberate alternative to a direct public edge | Apply the tunnel provider's access policy and retain NetClaw device authentication. | + +RatelDesk owns ticket authorization, organization scope, and the MCP gateway. +NetClaw owns its daemon, paired devices, model and tool policy. The reverse +proxy terminates TLS and forwards only the routes it is configured to expose. +DNS names identify those public endpoints; they do not grant access. + +NetClaw's [exposure modes](https://netclaw.dev/deployment/exposure-modes/) +and [remote-device pairing guide](https://netclaw.dev/guides/pairing-remote-devices/) +describe the daemon-side choices. Do not copy a private IP address, token, or +internal host name into tracked configuration or support tickets. + +## Connect RatelDesk to NetClaw for ticket chat + +Create a dedicated NetClaw paired device for the RatelDesk API. Give it a +recognizable tenant-specific name, such as `rateldesk-tenant-a-api`. Use +NetClaw's one-time pairing flow from a secure operator environment; on an +existing daemon, that begins with `netclaw daemon pair`. The resulting device +token is a secret for RatelDesk API only. + +Store the token directly in the deployment's secret manager or protected +runtime configuration. Never put it in an appsettings file, Compose file, +browser configuration, shell history, ticket, issue, pull request, or example. +If NetClaw CLI pairing is used, its local secret file is also sensitive; move +the token into the approved RatelDesk secret store without pasting it into a +tracked file. + +Configure the **API service only**. A typical HTTPS deployment has these +settings; replace the example endpoint and inject the token through your secret +mechanism: + +```text +AiAssistantChat__Enabled=true +AiAssistantChat__Instance=dev +AiAssistantChat__Endpoint=https://netclaw.example.com/hub/session +AiAssistantChat__DeviceToken= +AiAssistantChat__AllowPrivateHttp=false +AiAssistantChat__IdleMinutes=15 +AiAssistantChat__ConnectionCapacity=25 +``` + +The endpoint must be an absolute URL with exactly the `/hub/session` path. Use +HTTPS in normal deployments. RatelDesk accepts HTTP only when +`AiAssistantChat__AllowPrivateHttp=true` and the endpoint is a private literal +IPv4 address; that exception is for a trusted private network, not a DNS name +or public service. + +When NetClaw is behind a reverse proxy, forward SignalR/WebSocket upgrades and +long-lived connections to `/hub/session`. Configure the daemon's non-local +exposure mode and trusted proxy addresses as NetClaw requires. For a tailnet or +tunnel, use the endpoint and exposure mode documented by that provider. + +After restarting the API service, open an authorized incident, request, or +change and select **AI Assistant**. Send a harmless test prompt, then refresh +or reconnect the browser and confirm the saved conversation recovers. A failed +or silent transport is not a reason to resend a message: use the ticket UI's +recovery controls so an already admitted turn cannot be duplicated. + +### Rotate or revoke the chat device + +Rotate the paired device token using the current NetClaw device-management +flow. Put the replacement directly into the RatelDesk API secret store, restart +only the API service, and verify one harmless ticket conversation before +retiring the old token. If an API host is lost, an employee leaves, or the +tenant relationship ends, revoke the paired device in NetClaw and remove the +RatelDesk runtime secret. Revocation prevents later connections; it does not +make an already admitted remote action disappear. + +## Connect NetClaw to RatelDesk with HTTP MCP + +HTTP MCP is optional and runs separately from RatelDesk Web/API. Use the +local-account paired gateway mode for this guide. It exchanges the incoming +MCP credential for a short-lived execution credential and does not forward the +long-lived credential to ordinary API operations. + +Follow the [HTTP MCP deployment example](../docker/examples/mcp-http/README.md) +for the source or released-image overlay. It requires a protected gateway +configuration file, an exact RatelDesk API base URL, and these public values: + +- `RATELDESK_MCP_PUBLIC_RESOURCE_URI` is the exact public HTTPS URI ending in + `/mcp`, for example `https://rateldesk.example.com/mcp`. +- `RATELDESK_MCP_ALLOWED_ORIGIN` is the exact browser origin when browser MCP + access is required. + +The MCP container listener does not provide public TLS by itself. Your proxy +must serve the canonical HTTPS `/mcp` route and the protected-resource metadata +route, preserve `Authorization` and MCP protocol headers, and allow streaming +responses without buffering or caching them. This is separate from the SignalR +proxy route above. Do not expose the gateway configuration file, API database, +or data-protection key ring to the MCP container. + +### Create the RatelDesk credential + +Sign in as the account that should own the NetClaw integration, complete any +configured MFA, and open **Account → Integration credentials**. + +1. Create a credential named for this NetClaw tenant and purpose. +2. Select **HTTP MCP** as the purpose. +3. Select exactly one enabled RatelDesk organization. +4. Enter the same canonical public `https://…/mcp` URI configured on the MCP + gateway. It must be HTTPS, end in `/mcp`, and have no query string or + fragment. +5. Select only the permissions this NetClaw role needs, and set a short, + operationally manageable expiry (RatelDesk permits 1–90 days). +6. Save the secret when it is shown. RatelDesk never displays it again. + +Put that secret only in NetClaw's protected configuration. Do not add it to +RatelDesk deployment configuration, a shell profile or history, tickets, +issues, pull requests, screenshots, or documentation examples. + +An API/CLI credential, a stdio-MCP credential, and an HTTP-MCP-purpose +credential are not interchangeable. The effective access of the HTTP MCP +credential is the intersection of the owner's current RatelDesk authorization, +the credential's selected permissions, and its organization scope. Disabling +the owner, removing access, expiring, or revoking the credential takes effect +on later requests. + +### Register the server in NetClaw + +Run this on the NetClaw host or its secure operator environment. It prompts for +the one-time credential instead of placing it in the command line or shell +history. The NetClaw CLI writes header values to its protected secret storage. + +```bash +read -r -s -p "RatelDesk MCP credential: " RATELDESK_MCP_TOKEN +printf '\n' +netclaw mcp add rateldesk-tenant-a https://rateldesk.example.com/mcp \ + --transport http \ + --header "Authorization: Bearer $RATELDESK_MCP_TOKEN" +unset RATELDESK_MCP_TOKEN + +# Restart the NetClaw daemon using its normal service-management method, +# then confirm discovery and explicitly grant the tools that may be used. +netclaw mcp list +netclaw mcp permissions +``` + +Replace the name and URL, but do not change the credential's canonical URI to +make it fit a proxy alias. Review `netclaw mcp permissions` immediately after +registration and choose grants and approval mode for every audience. Do not +assume the defaults are safe for this integration: current NetClaw releases +auto-approve all tools for the Personal audience, while Team and Public start +with no grants. Keep write or destructive tools on approval unless there is a +reviewed reason to automate them. The +[NetClaw MCP CLI reference](https://netclaw.dev/cli/mcp-tools/) documents the +current command behavior and the protected configuration split. + +### Choose least privilege deliberately + +Create separate credentials and NetClaw MCP entries when roles differ: + +| Intended role | Recommended scope | +| --- | --- | +| Incident manager | One tenant; only the incident read and change permissions needed by its runbook. | +| Change manager | One tenant; only the change read, planning, and approved update permissions needed by its change process. | +| Read-only support triage | One tenant; read-only ticket, work-log, and search permissions. | +| Disposable broad test | A separate non-production tenant, account, NetClaw deployment, credential, and short expiry. Never reuse it for production. | + +Do not treat a broad test credential as a shortcut to a second tenant. A +credential scoped to one organization cannot lawfully expand the owner account +or NetClaw deployment into another organization. + +## Troubleshooting and lifecycle + +| Symptom | Check first | +| --- | --- | +| AI Assistant cannot connect or reconnect | Confirm PostgreSQL and `AiAssistantChat__Enabled`; validate the exact `/hub/session` URL, TLS chain, paired-device token, proxy WebSocket forwarding, and NetClaw exposure mode. Run `netclaw doctor` on the daemon host. | +| AI Assistant is unavailable after a restart | Confirm the API has the current injected token and that the token was not placed on the Web service. Use the ticket UI recovery path; do not blindly resend an uncertain turn. | +| HTTP MCP returns `401` | Treat this as a credential, expiry, owner, purpose, resource-URI, permission, or organization-scope problem. Compare the exact configured and credential-bound public `/mcp` URI, then rotate or recreate the credential if necessary. | +| Proxy rejects or cannot reach `/mcp` | Check DNS, TLS, proxy route, forwarded `Authorization` and MCP headers, streaming behavior, and the MCP host health. This is distinct from a RatelDesk authorization failure. | +| NetClaw lists the server but no tools run | Restart or reload the daemon as appropriate, confirm `netclaw mcp list` reports discovery, then review explicit grants and approval policy with `netclaw mcp permissions`. | + +Review every paired device and integration credential when an employee changes +role or leaves, a tenant is removed, or a test deployment is retired. Rotate +credentials before expiry, revoke rather than merely rename compromised or +unused credentials, and keep production and disposable test tenants separate. diff --git a/tools/ci/check-public-disclosure.sh b/tools/ci/check-public-disclosure.sh index 75e4078a..d9df7b4e 100755 --- a/tools/ci/check-public-disclosure.sh +++ b/tools/ci/check-public-disclosure.sh @@ -12,7 +12,7 @@ done repo_root=$(git rev-parse --show-toplevel) cd "$repo_root" -blocked_text='boston|bostec|proxicon|netratel|komodo|openbao|netclaw|spacetimeorchestrator|camelot|konrad|jeremi|hd-dev|@boston\.net\.za' +blocked_text='boston|bostec|proxicon|netratel|komodo|openbao|spacetimeorchestrator|camelot|konrad|jeremi|hd-dev|@boston\.net\.za' blocked_files='(^|/)(\.env|appsettings\.Development\.local\.json)$|\.(pfx|pem|key)$|(^|/)(id_rsa|id_ed25519)$' failed=false