Skip to content

Signing: encrypted PEM option + proper entry point for keygen CLI #191

Description

@bokelley

Follow-up from the expert review of #183.

Two independent keygen CLI improvements, bundled here because they both touch `src/adcp/signing/keygen.py` and `pyproject.toml`:

A. `--encrypt` flag for PEM output

`keygen.py` currently writes PKCS8 with `NoEncryption()`. That's the right default (encrypted keys block automated deployment — a passphrase on every restart is an operational burden). But for dev laptops and CI test keys, an encrypted-PEM option is worth having.

Add:

```
--encrypt Prompt for a passphrase and encrypt the PEM using
BestAvailableEncryption.
```

Implementation sketch:

  • Use `getpass.getpass()` for the prompt so terminal echo is off.
  • Confirm the passphrase (two prompts, must match).
  • Pass `serialization.BestAvailableEncryption(password.encode())` to `private_bytes()`.

When `--encrypt` is set, also skip the chmod-0600 warning dance — the passphrase IS the access control.

B. Entry point via pyproject.toml

Users currently run: `python -m adcp.signing.keygen --alg ed25519`

Better UX: `adcp-keygen --alg ed25519` (after `pip install adcp`).

Add to `pyproject.toml`:
```toml
[project.scripts]
adcp = "adcp.main:main"
adcp-keygen = "adcp.signing.keygen:main"
```

Alternative: a subcommand structure under the existing `adcp` script (`adcp keygen ...`). Better long-term if we add more CLI tools (e.g., a signature debugger that verifies a curl request against an agent's JWKS). If we go subcommand, the existing `adcp` script needs a dispatcher.

Why not in #183

Cosmetic/UX, not correctness or security. The expert review flagged both as 'should' or 'consider' — neither blocks ship.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions