Enable gomod ind. deps for vulnerabilities.

[cevich]

Indirect deps are disabled by default for the gomod manager. Ref:
https://docs.renovatebot.com/modules/manager/gomod/#post-update-options

Indirect deps are also broken for golang updates due to go mod tidy problems. Ref:
https://github.com/renovatebot/renovate/issues/ number 12999

However, for vulnerability related updates, perhaps we want a PR opened anyway. Then at least a developer is able to fixup any go mod tidy related problems.

[github-actions]

Successfully triggered github-actions/success task to indicate successful run of cirrus-ci_retrospective integration and unit testing from this PR's 6f4167ecd35c8ccdfc7a1523a487ac8cc1360a81.

[edsantiago]

I can't pretend to understand renovatebot workflows, but your motivation SGTM. Since I'm not the one who'll be responding to the vendoring PRs, I won't give final approval. Thank you for finding this issue and taking it on.

[cevich]

I can't pretend to understand renovatebot workflows

No worries, I barely understand them myself. It's an incredibly complex tool that sometimes operates in very unexpected ways. OTOH...it does give us a lot more fine-grain DRY controls compared to the (very spammy) Dependabot (with duplicate configs in every repo).

Since I'm not the one who'll be responding to the vendoring PRs, I won't give final approval.

No worries, and TBH I'm not even sure this change will work at all.

[cevich]

@containers/podman-maintainers @containers/buildah-maintainers @containers/image-maintainers @containers/storage-maintainers PTAL. I sent an e-mail about this...but it's really important and potentially time-sensitive (there's at least one vulnerability already reported).

Once merged, this change should (see below) cause any reported vulnerabilities in indirect golang dependencies to have PRs open. Those PRs will very likely fail to compile and/or fail tests. Near as I can tell, this doesn't affect rust or any other languages watched over by Renovate.

There are three alternatives as I see it (but maybe I'm wrong):

1. Don't get any PRs for indirect dependencies at all, potentially not noticing something really important in our software supply-chain 😱
2. Enable Renovate to propose updates for ANY indirect golang dependency (likely resulting in massive update-PR spam) 😖
3. Re-enable Dependabot's ability to open vulnerability update PRs - they are also likely to fail to compile and/or fail tests 🤮

There's some risk

I'm not 100% sure this fix will address the problem. I've submitted a question upstream on the topic (no replies yet). However, once merged, I can easily go spelunking through the Renovate logs to confirm a known indirect dep. w/ vulnerability gets picked up (or not).

[mtrmac]

(I’m not sure how renovatebot/renovate#12999 relates to the topic of this PR but I’m also not sufficiently motivated to try to reproduce that.)

---

For c/image and Skopeo, I’m fine with enabling updates on indirect dependencies, as a general principle (subject to the existing monthly cap on digest updates, if possible). About once a year I manually revisit the indirect dependencies to see if there is something we need, and having that automated wouldn't hurt.

If the worry is that this will file broken PRs, *shrug*, let’s try. We can always revert if it becomes too annoying.

---

BTW https://github.com/containers/podman/security/dependabot/30 is AFAICS not relevant to our code paths. That code is included but not called.

[cevich]

(I’m not sure how renovatebot/renovate#12999 relates to the topic of this PR

My limited (and maybe wrong) understanding is that feature/fix is needed to help renovate open non-broken PRs for indirect dependencies.

I’m fine with enabling updates on indirect dependencies, as a general principle (subject to the existing monthly cap on digest updates

Yeah I think having them limited on a schedule would be important. Then for projects like podman or buildah, I'd be afraid there simply might be "too" many PRs opened up. Unless (as this PR does) it's also limited to only indirect vulnerabilities.

AFAICS not relevant to our code paths. That code is included but not called.

That's good to hear.

Just so it's clear: My motivation to file this PR was: If dependabot hadn't (accidentally) been enabled (for vulnerability PRs) in podman, then NO PR would have been filed at all. Broken or otherwise. According to the Renovate logs, it simply ignored it (since it was indirect).

[mtrmac]

LGTM for the record.

[cevich]

Force-push: Added enabled: true into vulnerabilityAlerts block as per discussion recommendation.

[mtrmac]

Updates only for vulnerable indirect dependencies is even better.

(The test failure is #144 .)

[cevich]

Force-push: rebased to resolve lint problem.

[cevich]

Updates only for vulnerable indirect dependencies is even better.

Yeah, I think this is smarter. A course of resolution for these PRs could be to just wait and bump up the direct dependency if an update is in-progress.

[github-actions]

Successfully triggered github-actions/success task to indicate successful run of cirrus-ci_retrospective integration and unit testing from this PR's c005bb4c471d38b218fe7ecf2ce37b76cec55fa2.