tooling: add new CLI for CVE publication by SRC members

[mtardy]

WIP!

This is in reaction to https://github.com/kubernetes/sig-security/issues/169#issuecomment-3444067871.

[k8s-ci-robot]

Skipping CI for Draft Pull Request. If you want CI signal for your change, please convert it to an actual PR. You can still manually trigger a test run with /test all

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: mtardy

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

The pull request process is described here

Needs approval from an approver in each of these files:

• ~~sig-security-tooling/OWNERS~~ [mtardy]

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

[tabbysable]

Per the tooling meeting conversation, let's try:

• pressing enter mean "edit the current step"
• entering the index for a step imply "edit"
• specify versions like this:

thing: ([introduced] < fixed|"all")

# Please enter the text for your changes. Empty lines and lines
# starting with '#' will be ignored. An empty text aborts the change.
#
# Affected Versions
#
# - $COMPONENT $VERSION_RANGE_1
# - $COMPONENT $VERSION_RANGE_2 ...
# - ...
#
# Example:
# instead of - kube-apiserver: <= v1.31.11
# do this - kube-apiserver: < v1.31.12

[mtardy]

So I couldn't find time to finish this but wanted some people from the SRC to try it.

So I gave a try to AI stuff to generate the missing templates, add the OSV format part in the issue, generate some unit tests and fix a few bugs. The core, which is 90% of this was written manually by me in https://github.com/kubernetes/sig-security/pull/171/changes/7f5e7e62927418290efee27361f86b62e8eee988. I reviewed the patch and they make sense but would need some extra scrutiny. I think it's in a state where it could be tried now so maybe we could merge a v1 of this and see how it goes, if that's useful. To be honest it removes a lot of joy from "writing code" like that but this was stuff I was never going to finish soon enough... It's mostly boilerplate, converting from my API to OSV API, or generating templates, so it should be fine.

[tabbysable]

/hold until it's ready

[tabbysable]

This is looking really good, I've been kicking the tires on it a bit.

Please add a github issue number field to the JSON and populate it into the templates. Please also add a fix lead name into the JSON and populate it into the templates.

Again, thank you!

[tabbysable]

Also, can you make the tool strip off a tailing ".json" from its argument, if present? That would allow an existing CVE to have work continue on it by using tab-completion in the shell. :-D

[tabbysable]

Something about the way the tool sanitizes < in the affected versions field causes it to disappear when pasting the generated issue text into github.

This causes the issue to appear to say the fixed version is the affected version.

[tabbysable]

can we get an "export all" feature?

[mtardy]

This is looking really good, I've been kicking the tires on it a bit.

For reference, this is the first CVE announcements on which it's been used so far:

• https://github.com/kubernetes/kubernetes/issues/136680
• https://github.com/kubernetes/kubernetes/issues/136677
• https://github.com/kubernetes/kubernetes/issues/136678
• https://github.com/kubernetes/kubernetes/issues/136679
• https://github.com/kubernetes/kubernetes/issues/136789

[mtardy]

Please add a github issue number field to the JSON and populate it into the templates. Please also add a fix lead name into the JSON and populate it into the templates.

Hey @tabbysable thanks for the feedback on the srctl thing. So for the issue number I can understand where to put it ~~but for the fix lead it's a bit unclear as I don't see any example of that in https://github.com/kubernetes/kubernetes/issues/136680. Where would you inject that in the templates?~~ (see https://github.com/kubernetes/sig-security/pull/171#issuecomment-3849334203)

[mtardy]

Something about the way the tool sanitizes < in the affected versions field causes it to disappear when pasting the generated issue text into github.

This causes the issue to appear to say the fixed version is the affected version.

So I think I fixed everything you asked except for this, I interpreted the fix lead as the person from the SRC writing the announcements.

[mtardy]

Something about the way the tool sanitizes < in the affected versions field causes it to disappear when pasting the generated issue text into github. This causes the issue to appear to say the fixed version is the affected version.

So I think I fixed everything you asked except for this, I interpreted the fix lead as the person from the SRC writing the announcements.

Ah it was a bug in the template, I fixed it. Would love to merge the first version of this now that we have proved it was usable!

[tabbysable]

This is demonstrably good enough for a first version, given that it was used in practice and found helpful.

Additional improvements can be made in a normal PR process.

Thank you so much, again. This was so helpful.

/lgtm

[PushkarJ]

+1 to @tabbysable

/lgtm

[mtardy]

This is demonstrably good enough for a first version, given that it was used in practice and found helpful.

Additional improvements can be made in a normal PR process.

Yeah we might have more tuning to come but hopefully this can land now!

Thank you so much, again. This was so helpful.

/lgtm

+1 to @tabbysable

/lgtm

Thanks, I'm glad it helped, it was fun to write.

[mtardy]

/unhold