Integration: git credentials

[vimjoyer]

No description provided.

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	secretspec	d0fbaca	Commit Preview URL Branch Preview URL	Aug 13 2026, 12:35 PM

[domenkozar]

This looks great. One UX change I would like before merging: make a small Git-specific secretspec.toml embedded in the binary the default, while keeping --file as an explicit override.

At the moment the helper does:

match &args.file {
    Some(path) => Secrets::load_from(path),
    None => Secrets::load(),
}

I would prefer:

match &args.file {
    Some(path) => Secrets::load_from(path),
    None => Secrets::load_embedded_git_credentials(),
}

In particular, the helper should not walk the current directory when no file was selected. That makes the default deterministic for clone, fetch, push, and use outside a repository.

The embedded manifest would contain declarations, not values—something like an optional USERNAME and required PASSWORD/token—and credential storage should be isolated by the canonical Git credential context (protocol, host, and path when enabled), so different hosts cannot share a value accidentally.

The resulting UX would be:

$ secretspec git configure --url https://github.com --username USER

with no manifest path recorded. Advanced/custom setups would retain the current behavior:

$ secretspec --file company-git.toml git configure \
    --url https://github.com \
    --token-secret GITHUB_TOKEN

Because the helper is intentionally read-only, the embedded default also needs an explicit way to populate and remove its values, e.g. secretspec git login <url> and secretspec git logout <url>. Automatic Git store/erase callbacks can remain ignored so a rejected authentication attempt cannot overwrite or delete a shared-provider value.

I would add coverage for both important cases: no --file uses the embedded manifest even when the CWD contains an unrelated project manifest, and explicit --file takes precedence over the embedded one.

[domenkozar]

One additional integration worth supporting is SMTP credentials for git send-email.

Git already uses the credential-helper protocol when sendemail.smtpUser is set and sendemail.smtpPass is omitted. Its request is effectively:

protocol=smtp
host=smtp.example.com:587
username=user@example.com

See git-send-email.perl and the git send-email documentation.

A minimal implementation could:

• accept smtp://host[:port] as a credential target and match protocol=smtp;
• register the helper under credential.smtp://host[:port].helper;
• keep the existing read-only behavior: answer get, ignore store and erase;
• include the request username as well as protocol, host, and port in the embedded credential's storage identity, so accounts on the same SMTP server cannot share a password accidentally;
• leave transport settings in Git's normal sendemail.* configuration and never write sendemail.smtpPass. The docs should stress that smtp is only Git's credential-context name; encryption is controlled separately by sendemail.smtpEncryption=tls|ssl;
• test exact server/port/username matching and rejection of HTTP(S) or another SMTP account.

For example, the setup could look like:

$ git config --global sendemail.smtpServer smtp.example.com
$ git config --global sendemail.smtpServerPort 587
$ git config --global sendemail.smtpEncryption tls
$ git config --global sendemail.smtpUser user@example.com
$ secretspec git configure --url smtp://smtp.example.com:587 --username user@example.com --global
$ secretspec git login smtp://smtp.example.com:587

The explicit sendemail.smtpUser is important: without it, git send-email does not attempt SMTP authentication or query credential helpers.