Vastly improve secrets scanning & false-positives

[cevich]

• Fix new-pr secret-scan review URL JQ format
  The before jq filter was using GHA context elements in it's filter
  (.github.event) that don't actually exist in the event JSON. Removing
  them resulted in successful jq before/after commands when run against
  event JSON exported from a new-pr workflow.

• Secret scanning: Move debugging block
  Previously, it was possible for one of several steps to throw an error,
  leaving the operator with no debugging details. Relocate the "important
  details" step earlier in the workflow to mitigate a risk of unavailable
  debugging info.

• Wave secrets protections on select files/scripts
  The baseline gitleaks data is unfortunately commit-locked, meaning small
  changes to files due to (for example) rebases, can render them useless.
  Manually go through all findings and where possible mark lines to be
  ignored directly. In a few cases where secrets are used in tests, mark
  them to be ignored via a new .gitleaksignore file. This will
  hopefully cut way down on the number of false-positive alerts that
  require review.

Note: I intentionally did not wave checks in the .cirrus.yml file as
it's currently going through a large number of changes. I'll leave it
up to a future followup commit to mark known/approved secret references
in this file.

Does this PR introduce a user-facing change?

None

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: cevich
Once this PR has been reviewed and has the lgtm label, please assign flouthoc for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[packit-as-a-service]

Cockpit tests failed for commit ae7a074. @martinpitt, @jelly, @mvollmer please check.

[mheon]

Potential concern: someone could use .gitleaksignore to hide the fact that an actual leak was introduced. Maybe label PRs with changes to that file so they get extra attention?

[cevich]

someone could use .gitleaksignore to hide the fact that an actual leak was introduced.

Yes, I anticipated this. This check runs from the main tree against the subject PR tree, checking specifically for what you describe. In fact, it's why I had to add the BypassLeakNotification label, otherwise this PR would fire off the warning e-mails every time I push.

[cevich]

Case in point: The scanner for this PR will never ever go green. https://github.com/containers/podman/actions/runs/7834697427/job/21378478408?pr=21570#step:12:77

But once merged, if somebody merges into their PR, hopefully it shouldn't fire off so many damn false-positive alerts.

The other idea I had was to whitelist any PR authored by a maintainer.

If none of this works, and the false-positives continue. I'll likely give up and yank the scanner - more trouble than it's maintenance-worth.

[cevich]

Leaving this as a draft until all the activity on main slows down, then I can rebase a final time.

[Luap99]

The other idea I had was to whitelist any PR authored by a maintainer.

Yeah this is not an option IMO, having false positives for any contributor is not acceptable to me. For outside people who do not know the CI setup they get greeted with bogus errors they cannot understand and fix which is a frustrating experience, i.e. #21492

[cevich]

Worse...AFAIK there isn't a good way in github actions to determine if an action is running on a fork or upstream. At least without hard-coding it. Maybe let's just get rid of this damn thing. It's really intended to be run from a pre-commit anyway, so I guess it will be each maintainers responsibility to do that.

[cevich]

Opened #21588