QA (public) » openQA Project (public)

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.

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.

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".

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.

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.

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.

I'm having now the same issue with some exposed secrets from the Active Directory domain. A solution would be highly appreciated - the ticket is already rather old.