proposal: crypto: add SignContext

[x1ddos]

It is often desirable for a custom crypto.Signer implementation to get a hold of a context.Context during a signing operation, especially so if the signing involves HTTP or RPC roundtrips.

For example, one may want to use Google Cloud KMS to sign digests by implementing the crypto.Signer interface. This could then be fed to x/crypto/acme.Client where each request needs to be signed using crypto.Signer.

We already have precedents:

go1.7.txt:pkg net, method (*Dialer) DialContext(context.Context, string, string) (Conn, error)
go1.7.txt:pkg os/exec, func CommandContext(context.Context, string, ...string) *Cmd
go1.8.txt:pkg database/sql, method (*DB) ExecContext(context.Context, string, ...interface{}) (Result, error)

Please add Go2 label.

[OneOfOne]

@gopherbot please add go2

[bcmills]

Note that you can already use a curried function to achieve a similar effect:

type CtxSigner = func(context.Context) crypto.Signer

func f(ctx context.Context, signCtx CtxSigner, […]) {
	sig, err := signCtx(ctx).Sign(rand, digest, opts)
}

That is, this may be more of an issue with the acme.Client API than with the crypto package itself. (See also #28342 and #20280.)

[ianlancetaylor]

CC @FiloSottile

[rsc]

Added to proposal minutes, but the motivation here is quite old. Is this still an ongoing concern for anyone?
It does seem like having a Signer implementation that has a context inside it (in a closure, for example) would be fine and does not require adding a new interface that the crypto ecosystem has to adopt.

[rsc]

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

[rsc]

Based on the discussion above, this proposal seems like a likely decline.
— rsc for the proposal review group

[rsc]

No change in consensus, so declined.
— rsc for the proposal review group