feat: add reusable workflow for autofilling an issue when there's a new TUF version

[rdimitrov]

The following adds a workflow that can be used by projects that want to keep track and be notified when there's a new version of the TUF specification.

In case there's a newer version, it will file an issue against the project with several links, like the currently supported version, and a comparison showing what's changed. Here's an example of the issue it will create -

Title:

TUF specification has a new version - v1.0.30

Body:

Hey, it seems there's a newer version of the TUF specification - v1.0.30

The version which rdimitrov/python-tuf state it supports is - v1.0.29

The following is a comparison of what changed between the two versions - Compare v1.0.29 to v1.0.30

Please review the newer version and address the changes.

Note: A few other PRs will be created and referenced here for https://github.com/theupdateframework/python-tuf and https://github.com/theupdateframework/go-tuf which can serve as examples of how to use this workflow.

Related to - https://github.com/theupdateframework/go-tuf/issues/283

[jku]

I have a question on permissions: can the python-tuf workflow define a permission so that the embedded action can't override that?

I'm asking in context of the @master versioning in the workflow... If python-tuf can't practically limit the permission, then a compromised specification repo would immediately compromise the python-tuf repo as well if we use @master

link: https://github.com/theupdateframework/python-tuf/pull/2001#discussion_r868881109

[rdimitrov]

I have a question on permissions: can the python-tuf workflow define a permission so that the embedded action can't override that?

I'm asking in context of the @master versioning in the workflow... If python-tuf can't practically limit the permission, then a compromised specification repo would immediately compromise the python-tuf repo as well if we use @master

link: theupdateframework/python-tuf#2001 (comment)

Yes, you should be able to either set the permissions for a specific job or for the whole workflow 👍

ref: Github Actions/permissions

[rdimitrov]

Can we add a comment to the top of the reusable workflow which includes a one-line description of what the workflow does and includes an example of how to use it?

It might also be worth mentioning in the README that the reusable workflow exists and implementers can use it to be notified of when new specification versions are released? This could also be a follow-on PR if preferred.

Thanks! I've addressed the suggestions 👍

[joshuagl]

Could we get a second review here from an @theupdateframework/tap-editors ?

[JustinCappos]

This is a great idea! I'd love to see maintainers of other TUF implementations comment as well, but I am very supportive overall.

On Thu, May 19, 2022 at 7:08 PM Joshua Lock @.***> wrote:

Could we get a second review here from an @theupdateframework/tap-editors https://github.com/orgs/theupdateframework/teams/tap-editors ?

— Reply to this email directly, view it on GitHub https://github.com/theupdateframework/specification/pull/224#issuecomment-1131553450, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGRODYQ64J2I4MAEJ6PAITVKYOLHANCNFSM5VOQZHKQ . You are receiving this because you are on a team that was mentioned.Message ID: @.***>

[rdimitrov]

This is really great! And it LGTM, modulo a copy-pasted typo, some trailing whitespace and a line-wrap nit. Feel free to address or ignore. I'll approve as is.

Note, I also diffed the script with python-tuf's specification-version.yml, which we know works and probably served as a base for this workflow(?). It looks like they do the same thing.

Thanks for the review! 👍 I've used it as a base so thus the reason for the PR in python-tuf which discards the old one and switches to the one that will be hosted here - https://github.com/theupdateframework/python-tuf/pull/2001

[lukpueh]

This is really great! And it LGTM, modulo a copy-pasted typo, some trailing whitespace and a line-wrap nit. Feel free to address or ignore. I'll approve as is. Note, I also diffed the script with python-tuf's specification-version.yml, which we know works and probably served as a base for this workflow(?). It looks like they do the same thing.

Thanks for the review! 👍 I've used it as a base so thus the reason for the PR in python-tuf which discards the old one and switches to the one that will be hosted here - theupdateframework/python-tuf#2001

Oh yeah, it was not meant as a criticism, but more as a this has already been reviewed elsewhere, so it should be fine statement. :)