databricks-tellr-app 0.4.3.dev12__tar.gz → 0.4.3.dev13__tar.gz

{databricks_tellr_app-0.4.3.dev12 → databricks_tellr_app-0.4.3.dev13}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: databricks-tellr-app
-Version: 0.4.3.dev12
+Version: 0.4.3.dev13
 Summary: Tellr application package for Databricks Apps
 Requires-Python: >=3.10
 Description-Content-Type: text/markdown

{databricks_tellr_app-0.4.3.dev12 → databricks_tellr_app-0.4.3.dev13}/databricks_tellr_app.egg-info/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: databricks-tellr-app
-Version: 0.4.3.dev12
+Version: 0.4.3.dev13
 Summary: Tellr application package for Databricks Apps
 Requires-Python: >=3.10
 Description-Content-Type: text/markdown

{databricks_tellr_app-0.4.3.dev12 → databricks_tellr_app-0.4.3.dev13}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "setuptools.build_meta"
 
 [project]
 name = "databricks-tellr-app"
-version = "0.4.3.dev12"
+version = "0.4.3.dev13"
 description = "Tellr application package for Databricks Apps"
 readme = "README.md"
 requires-python = ">=3.10"

{databricks_tellr_app-0.4.3.dev12 → databricks_tellr_app-0.4.3.dev13}/src/api/main.py

@@ -489,11 +489,19 @@ logger.info("MCP server mounted at /mcp")
 
 @app.get("/api/health")
 async def health():
-    """Health check endpoint."""
+    """Health check endpoint.
+
+    ``encryption_key_source`` is load-bearing for deployment: ``tellr.update``
+    polls it to confirm a relocated app is reading the secret before it deletes
+    the Lakebase key row. Reports the source only — never the key.
+    """
+    from src.core.encryption import key_source
+
     return {
         "status": "healthy",
         "environment": ENVIRONMENT,
         "version": "0.3.0",
+        "encryption_key_source": key_source(),
     }
 
 

{databricks_tellr_app-0.4.3.dev12 → databricks_tellr_app-0.4.3.dev13}/src/api/routes/chat.py

@@ -543,18 +543,6 @@ async def send_message_streaming(
     )
 
 
-@router.get("/health")
-async def health_check():
-    """Health check endpoint.
-
-    Returns:
-        Status information
-    """
-    return {
-        "status": "healthy",
-        "service": "AI Slide Generator",
-    }
-
 
 @router.post("/chat/async")
 async def submit_chat_async(

{databricks_tellr_app-0.4.3.dev12 → databricks_tellr_app-0.4.3.dev13}/src/core/encryption.py

@@ -1,34 +1,16 @@
 """Fernet symmetric encryption for sensitive data (OAuth credentials, tokens).
 
 Uses AES-128-CBC with HMAC-SHA256 authentication via the ``cryptography``
-library. The master key lives in the ``encryption_keys`` table of the
-application database (SDR-4437 CRITICAL-3): dynamic, persistent across
-restarts/restores, unique per deployment, zero operator setup.
-
-Resolution is SELECT-first, then race-safe INSERT-if-absent:
-
-1. ``SELECT key_value FROM encryption_keys WHERE id = 1`` — read-first is
-   load-bearing: on upgraded installs the table is created by the *deployer*
-   role and the app SP holds an explicit SELECT, INSERT grant; reading first
-   means INSERT privilege is never exercised when the row already exists.
-2. If absent, seed from the ``GOOGLE_OAUTH_ENCRYPTION_KEY`` env var (the
-   UI-button upgrade net — see below), else a legacy ``.encryption_key`` file
-   in the project root (local dev — keeps pre-existing dev ciphertext
-   decryptable), else generate a fresh key. See ``_seed_value``.
-3. ``INSERT ... ON CONFLICT (id) DO NOTHING`` + read-back, so concurrent
-   workers/replicas converge on one key.
-
-The supported upgrade path is ``tellr.update`` / ``deploy_local``, which — run
-as the deploying human — reads the legacy ``GOOGLE_OAUTH_ENCRYPTION_KEY`` from
-the existing app.yaml, seeds it into this table, and writes a keyless app.yaml
-(SDR-4437 remediation, PR-3). As a safety net for a stray Databricks Apps UI
-"Deploy" button upgrade — which bypasses the tool and reuses the old,
-still-key-bearing app.yaml — ``_seed_value`` reads that same
-``GOOGLE_OAUTH_ENCRYPTION_KEY`` env var (Apps injects every app.yaml ``env:``
-entry into the process environment) so the booting app re-seeds the table from
-the injected key instead of fresh-generating one and orphaning existing
-ciphertext. Because resolution is SELECT-first, the env var is consulted only
-while the table is empty; after any successful migration the stored row wins.
+library. The master key comes from one of two places, selected at boot:
+
+1. **Secret-backed (opt-in).** When the deploy tool has attached a Databricks
+   Apps secret resource, the platform injects ``TELLR_ENCRYPTION_KEY`` into the
+   environment and that value is the key. This path never touches the database.
+   See docs/superpowers/specs/2026-08-20-secret-backed-fernet-key-design.md.
+2. **Lakebase-backed (default, unchanged).** The key lives in the
+   ``encryption_keys`` table of the application database (SDR-4437 CRITICAL-3):
+   dynamic, persistent across restarts/restores, unique per deployment, zero
+   operator setup.
 """
 
 import logging
@@ -75,7 +57,7 @@ def _validated(key: bytes) -> bytes:
 def _seed_value() -> bytes:
     """Pick the value to seed an empty encryption_keys table with.
 
-    Priority (SELECT-first in get_encryption_key means this runs only when
+    Priority (SELECT-first in _from_lakebase means this runs only when
     the table is empty):
     1. GOOGLE_OAUTH_ENCRYPTION_KEY env var — the safety net for a stray
        Databricks Apps UI "Deploy" button upgrade of an un-migrated app
@@ -100,12 +82,44 @@ def _seed_value() -> bytes:
     return Fernet.generate_key()
 
 
-@lru_cache(maxsize=1)
-def get_encryption_key() -> bytes:
+_SECRET_ENV_VAR = "TELLR_ENCRYPTION_KEY"
+
+
+def key_source() -> str:
+    """Report where the master key comes from, without reading the key itself.
+
+    Consumed by /api/health so the deploy tool can confirm a relocated app is
+    actually reading the secret before it deletes the Lakebase row.
+    """
+    return "secret" if os.getenv(_SECRET_ENV_VAR, "").strip() else "lakebase"
+
+
+def _from_secret() -> bytes:
+    """Return the Fernet key injected by the Apps secret resource.
+
+    Deliberately touches no database: a secret-mode app's encryption_keys table
+    is empty by construction, and writing to it would defeat the whole point.
+    """
+    raw = os.getenv(_SECRET_ENV_VAR, "").strip()
+    try:
+        Fernet(raw.encode())
+    except (ValueError, TypeError) as exc:
+        raise RuntimeError(
+            f"{_SECRET_ENV_VAR} is not a valid Fernet key — refusing to start. "
+            f"Check the value stored in the secret backing the "
+            f"{_SECRET_ENV_VAR} app resource."
+        ) from exc
+    logger.info("Encryption key loaded from the %s secret resource", _SECRET_ENV_VAR)
+    return raw.encode()
+
+
+def _from_lakebase() -> bytes:
     """Return the Fernet master key from the encryption_keys table (id=1)."""
     from src.core.database import get_db_session
 
-    # 1. Read-first (see module docstring for why this order matters).
+    # 1. Read-first: check for an existing row before seeding so concurrent
+    #    workers never mint two different keys (INSERT … ON CONFLICT DO NOTHING
+    #    is still safe against the race, but this avoids the seed call entirely).
     with get_db_session() as session:
         row = session.execute(_SELECT_KEY).first()
     if row and row[0]:
@@ -125,6 +139,14 @@ def get_encryption_key() -> bytes:
     return _validated(row[0].encode())
 
 
+@lru_cache(maxsize=1)
+def get_encryption_key() -> bytes:
+    """Return the Fernet master key, from the secret resource or Lakebase."""
+    if os.getenv(_SECRET_ENV_VAR, "").strip():
+        return _from_secret()
+    return _from_lakebase()
+
+
 def ensure_encryption_key() -> None:
     """Pre-fork boot hook: load/seed the key before uvicorn workers fork.
 

{databricks_tellr_app-0.4.3.dev12 → databricks_tellr_app-0.4.3.dev13}/src/database/models/encryption_key.py

@@ -4,8 +4,12 @@ Holds the Fernet master key for OAuth credential/token encryption in the
 ACL-governed Lakebase data schema instead of app.yaml. Single-row table
 (id = 1). Deliberately shares the data schema's grants: the key carries
 the same ACLs as the ciphertext it protects — an explicitly accepted risk
-in the SDR-4437 remediation design. Do NOT add key-specific grant
-tightening here.
+in the SDR-4437 remediation. Do NOT add key-specific grant tightening here.
+
+Deployments that need the key out of Lakebase entirely can opt into the
+secret-backed path instead, in which case this table stays empty and the key
+lives in a Databricks secret injected as TELLR_ENCRYPTION_KEY. See
+docs/superpowers/specs/2026-08-20-secret-backed-fernet-key-design.md.
 """
 
 from sqlalchemy import Column, DateTime, Integer, Text