Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add flag for disabling config printing #269

Merged
merged 4 commits into from
Sep 9, 2020

Conversation

unguiculus
Copy link
Member

@unguiculus unguiculus commented Sep 9, 2020

By default, ct prints the config on startup. This can be problematic
because it may contain senstivie data when helm-repo-extra-args contains
passwords. The new flag enables turning off config printing.

Signed-off-by: Reinhard Nägele [email protected]

By default, ct prints the config on startup. This can be problematic
because it may contain senstivie data when helm-repo-extra-args contains
passwords. The new flag enables turning off config printing. In addition
to that, the config is now printed to stderr.

Signed-off-by: Reinhard Nägele <[email protected]>
ct/cmd/root.go Outdated
@@ -94,4 +94,5 @@ func addCommonLintAndInstallFlags(flags *pflag.FlagSet) {
flags.Bool("debug", false, heredoc.Doc(`
Print CLI calls of external tools to stdout (Note: depending on helm-extra-args
passed, this may reveal sensitive data)`))
flags.Bool("print-config", true, "Prints the configuration to stderr")
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This flag seems a bit not intuitive to me. The default is to print the config (this has a true value). So, you don't pass in the flag to skip it. You have to say it's equal to false. Would it be better to make this --skip-print-config with a value of false? Then use the not of this value for the LoadConfiguration function?

Copy link
Member Author

@unguiculus unguiculus Sep 9, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point. Not sure what's better. Ideally, I'd like to change the default to false. I was hesitant to do so. Would that be considered a breaking change?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changing a default value is considered a breaking change. The helm client would only do that on a major version change.

Copy link
Member

@scottrigby scottrigby Sep 9, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is fun, because we already have a printConfig arg in LoadConfiguration(), but had no actual config/flag for it 😄

Given the security implications I think we should change chart-testing to not print the config values by default. Also thinking whatever flag name we decide is most intuitive for end uses should include a hard to miss note in the flag help/description about what you said initially @unguiculus. Something like:

caution: setting this may expose sensitive data when helm-repo-extra-args contains passwords

I'm a bit torn on the semver interpretation here. If it's considered a security bug, then changing output wouldn't require MAJOR. In that case, the additional flag to output it if desired would only require MINOR. Thoughts on this?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with @scottrigby. After all it's only a change in log output, not in functionality.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cool. Whatever we decide with semver, not printing this by default is the right thing to do

Signed-off-by: Reinhard Nägele <[email protected]>
Signed-off-by: Reinhard Nägele <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants