/lgtm

/kind feature

So we're basically reopening #77458 and calling it a security fix now?

@tpepper #77458 is more than a version bump. This simply bumps the image.

/kind bug

/lgtm
/approve

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: anfernee, bowei

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

The pull request process is described here

To update this set of cherry pick PRs (#77834, #77833, and #77832 against 1.12, 1.13, and 1.14 respectively):

As a member of the @kubernetes/patch-release-team, I had previously objected to similar cherry picking (#77572) as it was coupled to a vendor specific feature and did not meet the criteria for cherry pick. ip-masq-agent was bumped for the purpose of enabling a feature and that was rejected.

So in the meantime the submitters seem to have realized there are critical CVEs which should be fixed and that does the bulk of what they'd need coincidentally to add their feature (though that specific feature portion would exist on some branch they control not in the upstream project 1.12/1.13/1.14 release streams). I feel like the system may be being gamed here, I worry about the precedent that would set, and I wonder whether we should reject this set of PRs and ask for just the bug fixes on a 2.0.Z or 2.1.Z release stream.

Despite the poor optics and since the current set of PRs has been decoupled from the feature with the sub-portion of the prior PR attempt now presented as just a bug fix incrementing the minor version of a dependency to bring in CVE fixes that are given lgtm/approve by the appropriate OWNERS that we can approve the cherry pick. It's just unfortunate for this to play out this way and it is something that should be avoided in the future.

So in the meantime the submitters seem to have realized there are critical CVEs which should be fixed and that does the bulk of what they'd need coincidentally to add their feature (though that specific feature portion would exist on some branch they control not in the upstream project 1.12/1.13/1.14 release streams). I feel like the system may be being gamed here, I worry about the precedent that would set, and I wonder whether we should reject this set of PRs and ask for just the bug fixes on a 2.0.Z or 2.1.Z release stream.

Note that if a manifest can be changed to add extra flags, it can also be changed to use a newer image ;)

The version used here is exactly the same one as in the original rejected CP. Since this change doesn't contain extra flag which was required before, it can't enable the feature. It only provides this newer version as default to OSS users (and e2e tests).

If this is about sticking to semantic versioning and maintaining 3 separate tracks for each component, is there a policy about it? Personally, I think it may be an overkill in case of some smaller components (i.e. using most recent minor version everywhere keeps things simple), but if you don't like it, it sounds only fair to have this discussion in context of all components and not just this one.

To update this set of cherry pick PRs (#77834, #77833, and #77832 against 1.12, 1.13, and 1.14 respectively):

As a member of the @kubernetes/patch-release-team, I had previously objected to similar cherry picking (#77572) as it was coupled to a vendor specific feature and did not meet the criteria for cherry pick. ip-masq-agent was bumped for the purpose of enabling a feature and that was rejected.

So in the meantime the submitters seem to have realized there are critical CVEs which should be fixed and that does the bulk of what they'd need coincidentally to add their feature (though that specific feature portion would exist on some branch they control not in the upstream project 1.12/1.13/1.14 release streams). I feel like the system may be being gamed here, I worry about the precedent that would set, and I wonder whether we should reject this set of PRs and ask for just the bug fixes on a 2.0.Z or 2.1.Z release stream.

Despite the poor optics and since the current set of PRs has been decoupled from the feature with the sub-portion of the prior PR attempt now presented as just a bug fix incrementing the minor version of a dependency to bring in CVE fixes that are given lgtm/approve by the appropriate OWNERS that we can approve the cherry pick. It's just unfortunate for this to play out this way and it is something that should be avoided in the future.

Thanks a lot @tpepper
To be clear, nobody is trying to game the system. This has nothing to do with the rejected #77458. This PR is simply bump the OS to include the CVE fixes. The agent behaves exactly the same.