Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SBAT.md recommends resetting vendor generation numbers after global generation number went up #634

Open
kukrimate opened this issue Feb 2, 2024 · 1 comment

Comments

@kukrimate
Copy link

For example:

However, once the global number is bumped for the next upstream CVE fix there will be no further need to carry that product-specific generation number. Satisfying the check of the global number will also exclude any of the older product-specific binaries.

If this same Vendor C has a similar event after the global number is incremented, they would again set their product-specific or version-specific number to 1. If they have a second event on the same component, they would set their product-specific or version-specific number to 2.

The current consensus seems to be for both generation numbers to only ever go up, so we should stop recommending people do this.

@aronowski
Copy link
Contributor

Related explanation regarding such consensus in historical context, as well as the SbatLevel variable: rhboot/shim-review#355 (comment)

I'd highly recommend writing an introductory document akin to what @nicholasbishop provided here, but covering all the common scenarios, so people are immediately getting the knowledge of how the appropriate numbering system.

I can write a draft and suggest it, but first I need to make sure that I know, what is actually happening and that I was consulted on this before writing things that may be incorrect.

aronowski added a commit to aronowski/rhboot-shim that referenced this issue Jul 23, 2024
As per rhboot#634, the current consensus
seems to be for generation numbers to only ever go up and not get reset.
This has been clarified and an example related to this behavior has been
described.

Signed-off-by: Kamil Aronowski <[email protected]>
aronowski added a commit to aronowski/rhboot-shim that referenced this issue Jul 23, 2024
As per rhboot#634, the current consensus
seems to be for generation numbers to only ever go up and not get reset.
This has been clarified and an example related to this behavior has been
described.

Signed-off-by: Kamil Aronowski <[email protected]>
steve-mcintyre pushed a commit that referenced this issue Aug 20, 2024
As per #634, the current consensus
seems to be for generation numbers to only ever go up and not get reset.
This has been clarified and an example related to this behavior has been
described.

Signed-off-by: Kamil Aronowski <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants