caddyauth: fix unbuffered channel passed to signal.Notify

[cuonglm]

The docs at os/signal.Notify warn about this signal delivery loss bug at
https://golang.org/pkg/os/signal/#Notify, which says:

Package signal will not block sending to c: the caller must ensure
that c has sufficient buffer space to keep up with the expected signal
rate. For a channel used for notification of just one signal value,
a buffer of size 1 is sufficient.

Caught by a static analysis tool from Orijtech, Inc. called "sigchanyzer"

[CLAassistant]

All committers have signed the CLA.

[cuonglm]

Related Go issue: golang/go#9399

[francislavoie]

What issue does this actually solve here? This is just a one-off command used for hashing passwords, and it's just meant to capture ^C to not break terminal state. I've not seen issues with that usecase. 🤔

That said, this looks fine, just trying to understand.

[cuonglm]

What issue does this actually solve here? This is just a one-off command used for hashing passwords, and it's just meant to capture ^C to not break terminal state. I've not seen issues with that usecase.

That said, this looks fine, just trying to understand.

I invite you to read golang/go#9399

Without using buffered channel, there can be a risk that the signal is lost, because it's sent before the channel is ready. Sure it's hard to get in to trouble with this use case, but I think it's better to always use the right (and safe) way that the language offers.

[mholt]

I agree this is probably an insignificant change, but, we do use a buffer size of 1 in sigtrap.go already, so I guess we can be consistent here. Thanks for the PR!