Remove superfluous warning: X "may be a potentially sensitive environment variable."

1 
WARN KEY may be a potentially sensitive environment variable. Consider setting it as a secret, and removing it from the [env] section: https://fly.io/docs/reference/secrets/
 KEY
WARN KEY may be a potentially sensitive environment variable. Consider setting it as a secret, and removing it from the [env] section: https://fly.io/docs/reference/secrets/
 KEY
WARN KEY may be a potentially sensitive environment variable. Consider setting it as a secret, and removing it from the [env] section: https://fly.io/docs/reference/secrets/
 KEY
WARN PRIVATE may be a potentially sensitive environment variable. Consider setting it as a secret, and removing it from the [env] section: https://fly.io/docs/reference/secrets/
 PRIVATE

This is a weird warning for a couple reasons:

  1. I don’t have a variable named KEY or PRIVATE. I have one named AC_APP_KEY and one named PRIVATE_IMAGE_BUCKET.
  2. Neither of those variables is secret.

Is there a way to silence the warning for these variables that I know are safe?
Is there a way to fail my deploy instead of showing a warning if a new potentially sensitive variable is added?

The warning as it stands is noisy FUD, but if it’s given some bite (and actually fails the deploy) and I can explicitly override it when I know it’s safe, then I guess it could be a helpful point of reflection to leave it in. Otherwise, I’d like to just blanketly disable it.

2 Likes
2

Hi Adam2,
This looks like a bug in the secret detection code of flyctl. This was fixed and should be available in the next release of flyctl (v0.1.66 when it’s actually released).

As of now, there isn’t a way to disable it, but that does seem like a good idea. We should probably implement a work around, something like a --ignore-potential-secrets flag (but named better).

As for why it’s a warning rather than a hard failure, this has false positives as you can see, and introducing a change that can fail CI deployments over a false positive would make some people upset.

3

Thanks billy. --not-secrets=AC_APP_KEY,PRIVATE_IMAGE_BUCKET --on-potential-secrets=fail is a pair of flags I’d use if they were available. That would make the fail opt-in so no one gets upset.

1 Like
4

Just noticed the fix for the variable names came through to my Github Actions. Thanks!

2 Likes
5

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.