action #111314
_SECRET_ variables are exposed in vars.json when the job is not completed.
0%
Description
Some workers contain sensitive information using _SECRET variables. Those variables are hidden in the settings tab and in vars.json, as expected.
However, if you restart or clone a job and cancel it while it's running, those variables are exposed in vars.json
NOTE: I don't want to provide links as I might give too many hints for a public place.
Related issues
History
#1
Updated by cdywan about 1 month ago
Updated by We may want to consider #110518 here and have a hook that verifies that no passwords were stored in production with an according hook on all jobs.
#2
Updated by cdywan about 1 month ago
- Related to action #110518: Call job_done_hooks if requested by test setting (not only openQA config as done so far) size:M added
#3
Updated by okurz about 1 month ago
Updated by - Project changed from openQA Tests to openQA Project
- Category set to Feature requests
- Target version set to future
jlausuch this is not really a problem of tests but os-autoinst so this ticket is better suited in "openQA Project", moving. But, are your plans to look into this yourself? I am putting into "future" because I don't see the feature request currently on our backlog but for now I am keeping "High" prio which means that there must be action on the ticket within the next 30 days. If not likely I will lower prio until then.
#4
Updated by jlausuch about 1 month ago
Updated by okurz wrote:
jlausuch this is not really a problem of tests but os-autoinst so this ticket is better suited in "openQA Project", moving. But, are your plans to look into this yourself? I am putting into "future" because I don't see the feature request currently on our backlog but for now I am keeping "High" prio which means that there must be action on the ticket within the next 30 days. If not likely I will lower prio until then.
No plans to work on this during the next days at least. I consider this as a bug, not as a new feature request.
#5
Updated by okurz about 1 month ago
jlausuch wrote:
No plans to work on this during the next days at least. I consider this as a bug, not as a new feature request.
We don't want to argue what people see as "bug". We only distinguish between "regressions" and "feature requests". "regressions" means we should look into the git history where we broke something and learn how that could have happened. based on what mkittler stated I believe that we never had the wished behaviour in place, hence we see it as a "feature request".
#6
Updated by jlausuch about 1 month ago
okurz wrote:
jlausuch wrote:
No plans to work on this during the next days at least. I consider this as a bug, not as a new feature request.
We don't want to argue what people see as "bug". We only distinguish between "regressions" and "feature requests". "regressions" means we should look into the git history where we broke something and learn how that could have happened. based on what mkittler stated I believe that we never had the wished behaviour in place, hence we see it as a "feature request".
You depict it as A or B, Black or White, but it's not that simple. This is not a regression because it has been probably always like this and I found it by chance. But this doesn't mean it's a feature either. Exposing a secret in the log is a serious product/tool bug, no matter if it's a regression or not.
#7
Updated by okurz about 1 month ago
Jose, seriously, don't waste your effort. If we categorize something as feature request or concrete bug shouldn't really matter that much. If I would select "Concrete Bugs" now then this would just confuse members of the SUSE QE Tools team as they would look for the git commit that broke something which does not exist. And it already happened in the past that comments like these discussing how the ticket should be handled confused people or made them shy away from actually looking into just fixing the issue.
#8
Updated by cdywan about 1 month ago
okurz wrote:
Jose, seriously, don't waste your effort. If we categorize something as feature request or concrete bug shouldn't really matter that much. If I would select "Concrete Bugs" now then this would just confuse members of the SUSE QE Tools team as they would look for the git commit that broke something which does not exist. And it already happened in the past that comments like these discussing how the ticket should be handled confused people or made them shy away from actually looking into just fixing the issue.
I didn't read José as asking about ticket categories. But this was a requirement from the original feature request. This is was always expected to work but never sufficiently tested.
And I agree with that point. It's not a new idea that we only thought of now.