## 빠른 시작```bash
cd examples/docker-compose
docker compose up

모든 요청은 구조화된 JSON 감사 항목을 생성합니다:```json
{
  "host": "httpbin.org",
  "method": "GET",
  "path": "/headers",
  "action": "allow",
  "status_code": 200,
  "duration_ms": 142,
  "request_transforms": [
    { "name": "allowlist", "action": "continue" },
    {
      "name": "secrets",
      "action": "continue",
      "annotations": { "swapped": [{ "secret": "OPENAI_API_KEY", "locations": ["header:Authorization"] }] }
    }
  ]
}

### 2. Docker 네트워크 생성

iron-proxy는 컨테이너가 DNS를 지정할 수 있도록 고정 IP가 필요합니다:```bash
docker network create --subnet=172.20.0.0/24 iron-proxy

[No input content provided to translate.]```bash
docker run -d --name iron-proxy \
  --network iron-proxy --ip 172.20.0.2 \
  -v $(pwd)/proxy.yaml:/etc/iron-proxy/proxy.yaml:ro \
  -v $(pwd)/certs/ca.crt:/etc/iron-proxy/ca.crt:ro \
  -v $(pwd)/certs/ca.key:/etc/iron-proxy/ca.key:ro \
  --env-file .env \
  ironsh/iron-proxy:latest -config /etc/iron-proxy/proxy.yaml

더 강력한 강제 적용을 위해, 비프록시 이그레스를 차단하는 nftables 규칙을 계층화하거나,
커널 수준 인터셉션에는 TPROXY를 사용하세요. 각 접근 방식에 대한 자세한 내용은 [프록시로 트래픽
라우팅](#routing-traffic-to-the-proxy)을 참조하세요.

## 왜 iron-proxy인가?

|                          | iron-proxy                     | Squid                       | mitmproxy                 | Envoy                              |
| ------------------------ | ------------------------------ | --------------------------- | ------------------------- | ---------------------------------- |
| 기본 거부 이그레스      | 내장                           | 복잡한 ACL 구성 필요         | 사용자 지정 스크립팅 필요   | RBAC/필터 구성 필요                  |
| 시크릿 주입              | 내장                           | 없음                         | 없음                      | 없음                               |
| 구조화된 감사 로깅      | 내장, 변환별 추적              | 기본 액세스 로그            | 플러그인 기반              | 구성 가능한 액세스 로그            |
| 설정 복잡성              | 단일 바이너리 + YAML           | 방대한 구성 언어            | Python 스크립팅           | 복잡한 YAML 또는 컨트롤 플레인      |

iron-proxy는 단 한 가지 작업을 위해 설계되었습니다: 신뢰할 수 없는 워크로드에서 이그레스를 제어하고 감사하는
것입니다. Squid는 기본 거부를 수행할 수 있지만 상당한 ACL 구성이 필요하며 비밀 값 주입
개념이 없습니다. mitmproxy는 훌륭한 디버깅 도구이지만 프로덕션 강제 적용을 위해 설계되지는 않았습니다.
Envoy는 범용 프록시로, 이 기능의 일부를 수행하도록 구성할 수 있습니다.
하지만 이는 문제가 요구하는 것보다
훨씬 더 복잡합니다.

## 작동 방식

iron-proxy는 DNS 서버와 HTTP/HTTPS 프록시를 실행합니다. 컨테이너의 DNS를
iron-proxy로 지정하면 모든 호스트 이름 조회가 프록시 IP로 확인되어 트래픽이
자동으로 프록시를 통해 라우팅됩니다. 프록시는 TLS를 종료하고(제공한 CA에서
리프 인증서를 즉석에서 생성), 요청을 순서가 있는 변환 파이프라인을 거쳐
업스트림으로 전달한 다음, 응답을 다시 파이프라인을 통과시킵니다.```
Container → DNS lookup → iron-proxy IP → TLS termination → transforms → upstream

### DNS

기본적으로 모든 것은 `proxy_ip`로 해석되며, 이를 통해 트래픽이
프록시를 거쳐 라우팅됩니다. 예외:

- **`passthrough`:** OS 리졸버로 전달되는 glob 패턴 (예:
  `*.internal.corp`). 이러한 호스트로 향하는 트래픽은 프록시를 완전히 우회합니다.
- **`records`:** 정적 A 또는 CNAME 레코드. 가장 높은 우선순위를 가집니다.

### 응답 재시도 핸들러

외부 승인된 응답 재시도를 활성화하려면 `IRON_RESPONSE_RETRY_HANDLER_URL`,
`IRON_RESPONSE_RETRY_COMPLETE_URL`, `IRON_RESPONSE_RETRY_HANDLER_TOKEN`,
`IRON_RESPONSE_RETRY_HANDLER_SANDBOX_ID` 및 쉼표로 구분된
`IRON_RESPONSE_RETRY_STATUSES` 목록을 설정하세요. 권한 부여 핸들러는 정확한 업스트림 스킴, authority, 메서드,
경로/쿼리, 재생 가능성, 응답 상태 및 헤더, 트레이스 컨텍스트 및
샌드박스 ID를 수신합니다. 정확히 한 번의 재생을 위해 요청 헤더와 시도 ID를
반환할 수 있습니다. 그런 다음 완료 핸들러는 `IRON_RESPONSE_RETRY_COMPLETION_HEADERS`에 의해
선택된 재생 상태 및 응답 헤더를 수신하며, 기본값은 `Payment-Receipt`입니다.

응답 본문은 어떤 핸들러에도 전송되지 않으며, 대상(destination)은 변경할 수 없고,
연결/프레이밍 헤더는 거부됩니다. `proxy.max_request_body_bytes`를 초과하는 요청은
정상적으로 진행되지만 재생 불가능으로 표시됩니다. 챌린지가 발생하면 원래 응답이 반환됩니다.
핸들러 오류가 발생해도 원래 응답이 유지됩니다. 핸들러 URL은 루프백이거나
신뢰할 수 있는 내부 네트워크에 대해 `IRON_RESPONSE_RETRY_HANDLER_ALLOW_HTTP=true`가 명시적으로 구성된 경우가 아니면 HTTPS를 사용해야 합니다.
리다이렉트는 거부되며, 응답 재시도 토큰은 컨트롤 플레인 토큰과 독립적으로 구성되어야 합니다. WebSocket,
gRPC 및 길이를 알 수 없는 스트리밍 요청은 응답 재시도 처리를 우회합니다.

신뢰할 수 있는 핸들러가 `proxy.upstream_deny_cidrs` 내부에서 해석되는 경우,
`IRON_RESPONSE_RETRY_HANDLER_ALLOW_CIDRS`를 사용할 수 있는 좁은 사설 CIDR의 쉼표로 구분된 목록으로 설정하세요.
이 예외는 정확히 구성된 authorize 및 complete 엔드포인트에만 적용되며, 일반 프록시 트래픽은
전체 업스트림 거부 목록의 적용을 받습니다. 공용, 루프백, 링크-로컬 및 클라우드
메타데이터 범위는 이 설정을 통해 추가할 수 없습니다.

### 허용 목록

기본적으로 거부(Default-deny)입니다. 요청이 진행되려면 최소한 하나의 도메인 glob 또는 CIDR와 일치해야 합니다.
일치하지 않는 요청은 `403 Forbidden`을 받습니다.

도메인 패턴은 glob 매칭을 사용합니다: `*.example.com`은 모든 하위 도메인과
`example.com` 자체도 일치시킵니다.

**경고 모드:** `warn: true`를 설정하면 허용 목록이 실제로 적용하지 않고
차단할 항목을 확인할 수 있습니다. 거부될 요청은 통과되지만
변환 추적에서 `"action": "warn"`으로 주석 처리됩니다.
이는 새 허용 목록 규칙을 점진적으로 도입하거나 적용 전에 기존 트래픽을
감사할 때 유용합니다.

### 주석

host/method/path 규칙에 따라 HTTP 요청 헤더를 감사 로그 주석으로 캡처합니다.
이는 프록시 코어를 수정하지 않고 요청 ID와 같은 요청별 컨텍스트로 감사 로그를
보강할 때 유용합니다.

각 주석 그룹은 일치시킬 규칙과 캡처할 헤더를 지정합니다. 요청이
그룹의 규칙 중 하나와 일치하면 지정된 헤더 값은 변환 추적 주석에서
`header:<Name>` 항목으로 기록됩니다. 일치하지 않는 요청은 변경 없이 통과됩니다.
이 변환은 요청을 거부하지 않습니다.

> **경고:** 헤더 값은 감사 로그에 일반 텍스트로 출력됩니다. 요청 ID 또는
> 프록시 비밀 토큰을 포함하는 헤더처럼 노출해도 안전한 헤더만 로그로 기록하세요.
> 원본 비밀을 포함하는 헤더는 로그로 기록하지 마세요.```yaml
transforms:
  - name: annotate
    config:
      annotations:
        - rules:
            - host: "api.openai.com"
              methods: ["POST"]
              paths: ["/v1/*"]
          headers: ["x-request-id"]
        - rules:
            - host: "*.anthropic.com"
          headers: ["x-request-id"]

### 본문 캡처

일치하는 요청의 디코딩된 요청 본문을 기록하고, 이를 감사 로그 레코드의 `body_capture` 그룹에 `request_body` 및 `request_body_truncated`로 표시합니다. 프록시를 통과하는 페이로드(예: 샌드박스가 LLM 제공자에게 보내는 프롬프트)를 수정하지 않고 감사하는 데 유용합니다.

호스트, 메서드, 경로는 `allowlist` 및 `secrets`와 동일한 `rules` 구문으로 매칭됩니다. `max_request_body_bytes`는 각 본문에서 캡처되는 양을 제한합니다. 한도를 초과하는 본문은 앞부분으로 잘리며 `request_body_truncated`가 `true`로 설정됩니다. 기본 한도는 16 KiB이며 전역 `proxy.max_request_body_bytes` 제한과 독립적입니다. 이 변환은 관찰 전용입니다. 요청을 거부하지 않으며, 본문 읽기 오류는 요청을 실패시키는 대신 트레이스에 주석으로 기록됩니다.

캡처가 성공하면 `request_transforms`의 변환 항목에 `captured_bytes`와 `truncated`가 주석으로 기록되어, 본문 자체를 중복하지 않으면서 트레이스에 본문이 캡처되었음을 기록합니다.

응답 본문은 캡처되지 않습니다. 스트리밍 응답(SSE)은 전달 전에 종단 간 버퍼링해야 하므로 클라이언트가 지연될 수 있습니다.

> **경고:** 캡처된 본문은 감사 로그에 일반 텍스트로 기록됩니다. `secrets`가 `match_body: true`로 실행될 때, `body_capture`를 `secrets` *앞에* 배치하여 감사 로그가 `secrets`가 본문에 교체하는 실제 자격 증명 대신 샌드박스의 프록시 토큰을 기록하도록 하십시오.```yaml
transforms:
  - name: body_capture
    config:
      max_request_body_bytes: 16384
      rules:
        - host: "api.anthropic.com"
          methods: ["POST"]
          paths: ["/v1/messages"]
        - host: "api.openai.com"
          methods: ["POST"]
          paths: ["/v1/chat/completions"]

불변 조건:

- judge는 거부만 할 수 있다. 정적 허용 목록이 거부했을 요청을 승인하는
  일은 결코 없다. 정적 거부가 항상 우선한다.
- 일치하지 않는 요청은 무시된다: LLM 호출도, 감사 주석도 없다.
- LLM 오류, 시간 초과, 회로 차단기 개방 또는 잘못된 형식의 모델 출력이 발생하면,
  구성된 `fallback`이 적용된다. `deny`는 요청을 차단한다(프로덕션에서 권장되는
  기본값). `skip`은 파이프라인의 나머지 단계로 처리를 넘긴다. iron-proxy는
  기본 거부(default-deny) 방식이므로 일치하지 않는 요청도 여전히 차단된다.

시크릿 변환(secrets transform)과의 파이프라인 순서:

- **권장:** judge를 secrets transform **앞에** 배치한다. LLM
  공급자는 워크로드가 접근할 수 있는 실제 자격 증명이 아닌 프록시 토큰만
  보게 된다.
- 또는 judge를 secrets transform 뒤에 배치하면 실제로 나가는 정확한 와이어
  형식을 평가할 수 있지만, 실제 자격 증명을 LLM 공급자에게 보내는
  대가를 치른다. 위협 모델이 그 트레이드오프를 수용할 때만 이 방식을 선택하라.

지원되는 공급자:

- **`anthropic`** (Messages API). `api_key_env`, `model`, 선택적
  `base_url` 및 `max_tokens`를 사용한다.
- **`openai`** (Chat Completions API). 위와 동일한 필드를 사용한다.
  `type: openai`로 설정하고, `api_key_env`를 OpenAI 키를 보관하는 환경
  변수를 가리키게 한 다음 `gpt-5.4-nano` 같은 모델을 선택한다.

감사 출력: 일치하는 모든 요청은 변환 추적(transform trace) 아래에 구조화된 필드를
추가한다. 여기에는 `judge.instance`, `judge.decision`, `judge.reason`,
`judge.duration_ms`, `judge.input_tokens`, `judge.output_tokens`,
`judge.fallback_applied`(fallback이 실행될 때) 및
`judge.circuit_breaker_tripped`(회로 차단기가 열려 있을 때)가 포함된다.

크레딧: 이 설계에 영감을 준 Brex의 CrabTrap 프로젝트(MIT 라이선스)에
감사드린다.

## MCP 정책

iron-proxy는 [MCP의 Streamable HTTP 전송](https://modelcontextprotocol.io/specification/2025-06-18/basic/transports)을 지원한다. 요청이 구성된 MCP 서버와 일치하면 프록시는 JSON-RPC 본문을 파싱하고, 기본 거부(default-deny) 도구 허용 목록을 적용하며, `tools/list` 응답을 필터링하여 거부된 도구가 에이전트에 도달하지 못하게 한다. SSE 응답은 이벤트별로 필터링되므로 수명이 긴 MCP 스트림도 계속 유지된다.

이는 변환(transform)이 아닌 일급 프록시 기능이다. MCP 응답은 서버가 시작한 임의의 메시지를 담은 개방형 SSE 스트림일 수 있으므로 요청/응답 변환 계약에 맞지 않기 때문이다.```yaml
mcp:
  # JSON-RPC error envelope returned to the agent on policy denial.
  # Defaults: code -32001, message "blocked by iron-proxy policy".
  error:
    code: -32001
    message: "blocked by iron-proxy policy"
  servers:
    - name: github                         # appears in audit as mcp.server
      rules:                               # standard host/method/path rules
        - host: "mcp.github.com"
          paths: ["/mcp", "/mcp/*"]
      tools:
        - name: "search_repositories"      # always allowed
        - name: "create_issue"
          when:                            # all clauses must hold; otherwise deny
            - path: "owner"                # dotted path against arguments
              equals: "ironsh"
            - path: "repo"
              in: ["iron-proxy", "tunis-v2"]
        # Anything not listed is denied (default-deny).

자격 증명은 `secrets` 변환과 동일한 비밀 소스를 사용합니다. 기본적으로 필수입니다. 자격 증명에 `require: false`를 설정하면 사용할 수 없을 때 건너뜁니다. 감사 로그에는 경로, 업스트림 URL, 자격 증명 주입 위치가 기록되지만, 주입된 자격 증명 값은 기록되지 않습니다.

v1의 제한 사항:

- Streamable HTTP 전송만 지원됩니다. 레거시 HTTP+SSE 전송(별도의 `/messages` 및 `/sse` 엔드포인트)은 지원되지 않습니다.
- 거부된 항목이 포함된 JSON-RPC 배치는 전체 배치가 거부됩니다. 부분 배치 전달은 지원되지 않습니다.
- 리소스와 프롬프트는 강제되지 않습니다. 에이전트는 정책 필터링 없이도 `resources/list`, `resources/read` 등을 계속 호출할 수 있습니다.

### 본문 크기 제한

요청/응답 본문을 검사하거나 전달하는 변환(secrets 본문 매칭, gRPC 변환)은 버퍼링된 본문에서 작동합니다. 두 가지 전역 설정이 최대 버퍼 크기를 제어합니다:

- **`max_request_body_bytes`** (기본값: `1048576` / 1 MiB): 변환을 위해 버퍼링되는 요청 본문의 최대량을 제한합니다. 이 한도를 초과하는 데이터는 변환 관점에서 잘리지만 여전히 업스트림으로 전달됩니다.
- **`max_response_body_bytes`** (기본값: `0` / 무제한): 버퍼링되는 응답 본문의 최대량을 제한합니다. `0`으로 설정하면 전체 응답을 버퍼링하며, 이는 대부분의 워크로드(예: npm 패키지, 모델 가중치)에서 올바른 기본값입니다.

본문은 변환이 읽을 때 증분 방식으로 버퍼링되며 파이프라인 단계 사이에서 자동으로 되감깁니다. 변환이 본문을 읽지 않으면 버퍼링이 발생하지 않으며 본문은 변경 없이 스트리밍됩니다.

### 터널 리스너 (HTTP/CONNECT/SOCKS5)

터널 리스너는 전용 포트에서 absolute-form HTTP 프록시 요청, HTTP CONNECT 및 SOCKS5 연결을 수락합니다. 이는 DNS 기반 라우팅에 의존하는 대신 `HTTP_PROXY`/`HTTPS_PROXY`/`ALL_PROXY` 환경 변수 또는 SOCKS5 설정을 통해 프록시 구성을 기본적으로 지원하는 도구에 유용합니다.

이를 활성화하려면 `proxy` 아래에 `tunnel_listen`을 설정하세요:```yaml
proxy:
  tunnel_listen: ":8080"

**일반 HTTP 프록시 예제:**```bash
curl -x http://172.20.0.2:8080 \
  http://httpbin.org/get

표준 환경 변수를 설정하여 모든 도구가 터널을 통해 자동으로 라우팅되도록 할 수도 있습니다:```bash
export HTTP_PROXY=http://172.20.0.2:8080
export HTTPS_PROXY=http://172.20.0.2:8080
export ALL_PROXY=socks5h://172.20.0.2:8080

설정은 쉽지만 우회도 쉽다: 워크로드가 IP를 하드코딩하거나 자체
DNS 리졸버를 사용하여 프록시를 완전히 건너뛸 수 있다.

### DNS + nftables 이그레스 방화벽 (강제 적용)

DNS 라우팅 위에 nftables 방화벽을 계층화한다. DNS는 여전히 트래픽을
프록시로 유도하지만, nftables는 워크로드가 _어떤 다른 것과도_ 통신할 수 없게 하며,
하드코딩된 IP가 있어도 마찬가지다.

[`examples/nftables`](https://github.com/paradigmxyz/iron-proxy/blob/HEAD/examples/nftables/) 디렉토리에는 작동하는 설정이 포함되어 있다.
클라이언트 컨테이너는 시작 시 방화벽 규칙을 로드하여
애플리케이션 트래픽을 실행하기 전에 적용한다:

**nftables.conf**는 프록시로 가는 트래픽을 허용하고 그 외 모든 것을 차단한다:```
table ip iron {
  chain output {
    type filter hook output priority 0; policy drop;

    # allow loopback
    oif lo accept

    # allow traffic to the proxy itself (DNS + HTTP/HTTPS)
    ip daddr 172.20.0.2 tcp dport { 80, 443 } accept
    ip daddr 172.20.0.2 udp dport 53 accept

    # allow established/related (return traffic)
    ct state established,related accept

    # log and drop everything else
    log prefix "iron-proxy-drop: " drop
  }
}

프로덕션 환경에서는 엔트리포인트 래퍼에서 규칙을 로드한 다음
`exec`로 실제 프로세스를 `CAP_NET_ADMIN` 없이 루트가 아닌 사용자로 실행할 것입니다.

### TPROXY (투명 프록시)

워크로드의 DNS를 전혀 제어할 수 없는 환경에서는 nftables
TPROXY가 커널 수준에서 워크로드의 협력 없이도 트래픽을
리다이렉트할 수 있습니다. 이는 PREROUTING 체인의 패킷을 가로채서
iron-proxy로 직접 전달합니다:```
table ip iron {
  chain prerouting {
    type filter hook prerouting priority mangle; policy accept;

    # redirect HTTP/HTTPS to iron-proxy via TPROXY
    tcp dport 80 tproxy to 172.20.0.2:80 meta mark set 1 accept
    tcp dport 443 tproxy to 172.20.0.2:443 meta mark set 1 accept
  }

  chain output {
    type route hook output priority mangle; policy accept;

    # mark locally-originated packets for policy routing
    tcp dport { 80, 443 } meta mark set 1
  }
}

**proxy.yaml**은 `httpbin.org` 및 `icanhazip.com`을 허용 목록에 추가하고, 두 개의 시크릿을 교체합니다:```yaml
transforms:
  - name: allowlist
    config:
      domains:
        - "httpbin.org"
        - "icanhazip.com"
      cidrs:
        - "172.20.0.0/24"

  - name: secrets
    config:
      secrets:
        - source:
            type: env
            var: OPENAI_API_KEY
          replace:
            proxy_value: "proxy-openai-abc123"
            match_headers: ["Authorization"]
            match_query: true # scan the query string
          rules:
            - host: "httpbin.org"

        - source:
            type: env
            var: INTERNAL_TOKEN
          proxy_value: "proxy-internal-tok"
          match_headers: [] # scan all headers
          rules:
            - host: "httpbin.org"

## 감사 로그 형식

모든 프록시 요청은 구조화된 JSON 로그 항목을 생성합니다:```json
{
  "host": "httpbin.org",
  "method": "GET",
  "path": "/headers",
  "action": "allow",
  "status_code": 200,
  "duration_ms": 142,
  "request_transforms": [
    {
      "name": "allowlist",
      "action": "continue"
    },
    {
      "name": "secrets",
      "action": "continue",
      "annotations": {
        "swapped": [{ "secret": "OPENAI_API_KEY", "locations": ["header:Authorization"] }]
      }
    }
  ],
  "response_transforms": []
}

All configuration uses standard OTEL environment variables:

| Variable                       | Description                                             | Default          |
| ------------------------------ | ------------------------------------------------------- | ---------------- |
| `OTEL_EXPORTER_OTLP_ENDPOINT` | OTLP collector URL. OTEL export is disabled when unset. | (비활성화)       |
| `OTEL_EXPORTER_OTLP_PROTOCOL` | `http/protobuf` 또는 `grpc`.                            | `http/protobuf`  |
| `OTEL_EXPORTER_OTLP_HEADERS`  | 인증 헤더용 쉼표로 구분된 `key=value` 쌍.               | (없음)           |
| `OTEL_SERVICE_NAME`            | 모든 로그 레코드에 첨부되는 서비스 이름.                | `iron-proxy`     |
| `OTEL_RESOURCE_ATTRIBUTES`    | 쉼표로 구분된 `key=value` 리소스 속성.                  | (없음)           |

활성화하면 모든 감사 이벤트는 기존 JSON stderr 로그와 함께 OTEL 로그 레코드로 내보내집니다. 로그 레코드는 JSON 감사 항목과 동일한 스키마를 가지며, `host`, `method`, `path`, `action`, `status_code`, `duration_ms`와 주석이 포함된 전체 `request_transforms`/`response_transforms` 배열을 포함합니다.

## 관리 API

iron-proxy는 운영 작업을 위해 선택적으로 인증된 HTTP API를 노출할 수 있습니다. 현재는 단일 엔드포인트인 `POST /v1/reload`를 제공하며, 이 엔드포인트는 디스크에서 YAML 구성을 다시 읽고 새로 빌드된 변환 파이프라인을 원자적으로 교체합니다. 새 구성이 유효하지 않으면 실행 중인 파이프라인이 유지됩니다.

관리 서버는 기본적으로 비활성화되어 있습니다. 활성화하려면 구성에 `management` 블록을 추가하세요:```yaml
management:
  # Bind on loopback unless you front this with a private network or auth proxy:
  # /v1/reload can rebuild the entire transform pipeline.
  listen: "127.0.0.1:9092"
  # Env var that holds the bearer token. Defaults to IRON_MANAGEMENT_API_KEY.
  api_key_env: "IRON_MANAGEMENT_API_KEY"

## iron.sh

Vault/KMS 비밀 백엔드, Kubernetes 연산자(operator), 또는 중앙 집중식 정책
관리가 필요하신가요? [iron.sh](https://iron.sh)는 iron-proxy를 기반으로 엔터프라이즈
기능을 대규모로 실행하는 팀을 위해 제공합니다.

## 릴리스 서명 확인

릴리스 아티팩트에는 서명된 체크섬 매니페스트가 포함됩니다:

- `checksums.txt`
- `checksums.txt.asc` (ASCII-armored detached signature)

포함된 공개 키 [`public-key.asc`](https://github.com/paradigmxyz/iron-proxy/blob/HEAD/public-key.asc)를 사용하여 확인하세요:```bash
# 1) Download release artifacts for a tag
TAG=vX.Y.Z
gh release download "$TAG" --pattern "checksums.txt" --pattern "checksums.txt.asc"

# 2) Import the project signing key
gpg --import public-key.asc

# 3) Verify the signature over checksums.txt
gpg --verify checksums.txt.asc checksums.txt