[10B] Latest SVN files, bootmgr v12

[olkorsha]

Description

Update repo with latest SVN files from the 10B update which have bootmgr v12

Soliciting opinions from consumers of these files:

• Option A: Leave in the outdated KEK2011-signed dbx_SVN_bootmgfw_v11.efiauth2 file and keep adding the new revocation file?
• Option B: Each release, replace the old latest KEK2011-signed dbx_SVN_bootmgfw_v*.efiauth2 file with the new one

[olkorsha]

Pete Batard (@pbatard) would appreciate your input on this

[garlin (garlin-cant-code)]

MS should highlight they've removed the 3 SVN's from October's DBXUpdate2024.bin, which is now SVN-less. Intended changes should be clearly documented, so outsiders can confirm it's by design.

[Pete Batard (pbatard)]

olkorsha, thanks for soliciting input on this.

I guess the first thing I'm going to ask here is to clear some items that are exceedingly confusing to me at this stage:

1. KEK 2011 expired on 2026-06-24, but (officially, per the 2026-08-17 date from https://github.com/microsoft/secureboot_objects/blob/daa32713651f2ffe97b18df5aaf93ffe238aa464/PreSignedObjects/DBX/dbx_info_msft_latest.json) the SVN bump happened after this expiration date.... which logically means that Microsoft is using (and if I understand the above correctly) and still planning to use expired credentials to sign items like PostSignedObjects/SignedByKEK2011/dbx_SVN_Legacy/dbx_SVN_bootmgfw_v##.efiauth2, just like dbx_SVN_bootmgfw_v11.efiauth2 can be seen as having been signed by KEK 2011. Is that a correct assessment?
2. Outside of any KEK 2023/KEK 2011 usage, it's actually super confusing for users to know which of PostSignedObjects/SignedByKEK2011/dbx_SVN_Legacy/dbx_SVN_Legacy.efiauth2, PostSignedObjects/SignedByKEK2011/dbx_SVN_Legacy/dbx_SVN_bootmgfw_v11.efiauth2 and PostSignedObjects/Optional/DBX/DBXUpdateSVN.bin should be used. Now, of course, if one looks at the actual binary (and understand the format), they can find that DBXUpdateSVN.bin has [bootmgfw = 9.0, bootcd = 3.0, bootpxe = 3.0], dbx_SVN_Legacy.efiauth2 (which somehow is not identical to DBXUpdateSVN.bin) has [bootmgfw = 9.0, bootcd = 3.0, bootpxe = 3.0] and dbx_SVN_bootmgfw_v11.efiauth2 has [bootmgfw = 11.0] only. If PostSignedObjects/Optional/DBX/DBXUpdateSVN.bin is to be deprecated, which I believe it is, I would recommend it is being flagged as such, similar to what was done for PostSignedObjects/DBX/ with a README in the directory indicating depreciation. And a README in the PostSignedObjects/SignedByKEK2011/dbx_SVN_Legacy/ indicating why there exists 2 .auth2 along with the usage scenario for each one would be helpful... provided the point I am making next isn't something Microsoft feels like they want to follow.

Now, to indirectly answer the question that I believe is being asked, I would suggest there exists a single authoritative file, with a fixed, immutable name, with all the SVNs, that people can reference, as I currently don't see much point for adding/updating the SVN for bootmgfw alone. Especially because I suspect we will have no choice but to go with a SVN based approach for 3rd party bootloaders in the long term, where Microsoft (or whoever acts as the Secure Boot authority then) assigns a GUID to every independent 3rd party bootloader and mandates the use of some kind of well tested Open Source SVN based revocation early code, for each of bootloaders it signs (which would also alleviate/replace the need for Linux SBAT), so as to drastically reduce the space required in NVRAM for the ever expanding DBX, in which case the DBX can be broken/grouped into hash-based, SVN-based and cert-based entities, and in which case, the SVN DBX is treated like the hash-based DBX, with a single entity encompassing all the current revoked entries.

So, my personal preference is a variation of Option B preferably with only a "single" (insofar as the source and destination of symlinks count as the same) immutable PostSignedObjects/SignedByKEKLatest/dbx_SVN.efiauth2 (since SignedByKEKLatest is a symlink to SignedByKEK2023, which can be updated in 12 years times when KEK 2023 expires), that includes all the SVNs from Microsoft, and (potentially) SVNs from future 3rd parties that may be using their own SVN-like or SVN-mandated code for revocation, as this is what I currently see as the best option to try to future proof a repository that should be designed to be both authoritative and straightforward to reference for the long run.

Besides, with git/GitHub natively providing history for people wanting older versions, it kinda seem redundant to have to want to manually preserve the history of the updates in the repo.

And a note for the depreciation of PostSignedObjects/Optional/DBX/DBXUpdateSVN.bin should be added in that directory.

Now, if KEK 2011 must be used, a single PostSignedObjects/SignedByKEK2011/dbx_SVN.efiauth2 could also be added, but I am quite uncomfortable to have PKI established rules (of not using expired credentials) being treated "more (like) what you'd call guidelines than actual rules"...

Of course, this is only my personal opinion, and, even if I have been directly asked for it, I do not pretend to have more of an insight than anybody else as to what might be the best proposal.