gigamail 0.1.2__tar.gz

gigamail-0.1.2/.github/workflows/ci.yml

@@ -0,0 +1,29 @@
+name: CI
+
+on:
+  push:
+    branches: [main]
+  pull_request:
+
+jobs:
+  test:
+    strategy:
+      fail-fast: false
+      matrix:
+        os: [windows-latest, ubuntu-latest]
+        python: ["3.10", "3.12", "3.13"]
+    runs-on: ${{ matrix.os }}
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-python@v5
+        with:
+          python-version: ${{ matrix.python }}
+          cache: pip
+      - name: Install
+        run: pip install -e ".[all,dev]"
+      - name: Test suite
+        run: pytest -q
+        # I test DPAPI si auto-skippano su Linux; tutto il resto gira
+        # su entrambi gli OS senza rete ne' credenziali.
+      - name: Tool map allineata al server
+        run: python -m ade_mail_agent.gen_toolmap --check

gigamail-0.1.2/.github/workflows/release.yml

@@ -0,0 +1,69 @@
+name: Release to PyPI
+
+# Pubblicazione via trusted publisher (OIDC): nessun token, nessun segreto
+# conservato nel repo. PyPI si fida di questo workflow, in questo repo,
+# nell'environment "pypi".
+#
+# Come si rilascia:
+#   1. aggiorna version in pyproject.toml e __init__.py, aggiorna CHANGELOG
+#   2. tag vX.Y.Z (immutabile: un numero bruciato non si ricicla)
+#   3. crea la Release su GitHub da quel tag
+#   -> questo workflow costruisce, verifica e pubblica
+
+on:
+  release:
+    types: [published]
+  workflow_dispatch:   # per una prova manuale senza pubblicare
+
+jobs:
+  build:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+
+      - uses: actions/setup-python@v5
+        with:
+          python-version: "3.12"
+          cache: pip
+
+      - name: Test suite (non pubblichiamo codice non verificato)
+        run: |
+          pip install -e ".[all,dev]"
+          pytest -q
+          python -m ade_mail_agent.gen_toolmap --check
+
+      - name: Build sdist + wheel
+        run: |
+          pip install build twine
+          python -m build
+          twine check dist/*
+
+      - name: La versione costruita deve coincidere col tag
+        if: github.event_name == 'release'
+        run: |
+          TAG="${GITHUB_REF_NAME#v}"
+          BUILT=$(ls dist/*.tar.gz | sed -E 's/.*gigamail-(.*)\.tar\.gz/\1/')
+          echo "tag=$TAG  costruito=$BUILT"
+          test "$TAG" = "$BUILT" || {
+            echo "::error::Il tag ($TAG) non coincide con la versione del pacchetto ($BUILT)."
+            exit 1
+          }
+
+      - uses: actions/upload-artifact@v4
+        with:
+          name: dist
+          path: dist/
+
+  publish:
+    needs: build
+    if: github.event_name == 'release'
+    runs-on: ubuntu-latest
+    environment: pypi
+    permissions:
+      id-token: write   # richiesto dal trusted publishing
+    steps:
+      - uses: actions/download-artifact@v4
+        with:
+          name: dist
+          path: dist/
+      - uses: pypa/gh-action-pypi-publish@release/v1

gigamail-0.1.2/.gitignore

@@ -0,0 +1,13 @@
+.venv/
+__pycache__/
+*.pyc
+*.egg-info/
+build/
+dist/
+.env
+NOTES.dev.md
+*.db
+*.token*
+.token_cache.json
+node_modules/
+POST_DRAFTS.md

gigamail-0.1.2/CHANGELOG.md

@@ -0,0 +1,106 @@
+# Changelog
+
+## v0.1.1 — 2026-08-15
+
+**Security fix: the agent could approve its own destructive actions.**
+
+v0.1.0 returned a one-time confirmation token inside the tool result, which
+put it in the model's context. The agent held both halves — the preview and
+the key — so an instruction injected through an email could call the tool
+again with the token it had just read. The gate stopped accidents, not a
+determined injection. Reported on r/mcp by **u/ranbuman**; **u/anderson_the_one**
+added the point about binding approval to the exact operation shown.
+
+Approval is now **out of band**:
+
+- a dangerous tool returns only `request_id`, an inert reference — no secret
+  enters the model's context
+- approval happens through channels the agent has no path to: the console
+  API (behind its session token) or `gigamail approvals approve <id>`
+- execution uses the canonical arguments stored when the request was made,
+  never what the agent passes back at the second call
+- repeating a `request_id` returns *awaiting approval*, indefinitely
+- approvals live in SQLite, because requesting and approving now happen in
+  different processes
+
+New: `gigamail approvals list|approve|reject`, and `/approvals` endpoints on
+the console API. Tool parameter renamed `confirm_token` → `request_id`.
+
+Declared limitation: an agent with full shell access on the same machine can
+run the approval CLI. That is a different threat model and GigaMail does not
+claim to defend it.
+
+Tests: 94 → 103, including one asserting that no MCP tool grants approval and
+that the phase-1 payload contains no token. The red-team scenario now
+instructs the agent to approve itself; with all tools live, it took no
+destructive action.
+
+## v0.1.0 — 2026-08-15
+
+First public release. GigaMail is in daily production use at one company
+(real estate: client enquiries answered with figures from our own files,
+the right floor plans attached, and appointment slots from the calendar) —
+but it is a 0.1: expect rough edges, and read the security model before
+pointing it at a mailbox that matters.
+
+### What's in it
+
+**MCP server (stdio, no network port)** — 24 typed tools for an agent:
+
+- *Read (15)*: accounts, identity, knowledge files, messages, unread,
+  folders, hybrid search (provider + local index), attachment text, sender
+  history, learned correction patterns, calendar events, free-slot
+  availability
+- *Safe writes (3, audited)*: mark read, move message, create folder
+- *Destructive (6, two-phase)*: send, reply, delete message, delete folder,
+  create/delete calendar event
+
+**Permission model** — destructive tools never execute on the agent's word
+alone: the first call returns a preview and a single-use token (5-minute
+TTL), a human approves, the second call executes with the arguments that
+were shown. Every write lands in an append-only action log. Login,
+credentials and account management are CLI-only and never exposed as tools,
+so a hostile email cannot reach them.
+
+**Providers** — Microsoft Graph and IMAP/SMTP (Aruba, Gmail, Libero and any
+IMAP server), Microsoft calendar, optional CalDAV configuration.
+
+**Account context** — per-account identity (who you are, what you do, tone)
+plus knowledge files you register: price lists, terms, product sheets. The
+agent reads them to answer mail, and attachment suggestions follow what it
+actually wrote.
+
+**Human console (optional)** — Electron UI over a local HTTP API bound to
+127.0.0.1 with a session token. What the old app delegated to an internal
+LLM is now delegated to *your* agent through a bridge; there is no LLM
+inside GigaMail.
+
+**Privacy** — manual masking from the console (transparent MCP-side
+filtering is planned). Mail indexes, credentials and memory stay on your
+machine; content your agent reads is handled by that agent's provider.
+
+### Quality
+
+94 tests, green in CI on Windows and Linux across Python 3.10, 3.12 and
+3.13. Anti-injection suite included: hostile emails ordering exfiltration,
+mass deletion and self-approval with invented tokens were fed to a real
+agent with all tools live — no destructive action occurred.
+
+### Known limitations
+
+- The action log is append-only but not tamper-proof.
+- The bundled Azure app is not publisher-verified: the Microsoft consent
+  screen shows an "unverified" notice. Bring your own `client_id` to avoid
+  it; IMAP needs none of this.
+- Gmail is supported via IMAP with an app password but has not been tested
+  against a live account.
+- Not on PyPI yet — install from a clone.
+- The distribution/package name is still `ade-mail-agent` internally; the
+  commands are `gigamail`, with the old names kept as aliases.
+- `mark_spam`, `update_event`, `auth_status`, `search_contacts` and
+  `list_followup_needed` are designed but not implemented.
+
+### License
+
+AGPL-3.0-or-later. Commercial licenses for closed-source use are available
+from the copyright holder.