initial commit for dasharo naming convention v2

[pietrushnic]

No description provided.

[philipanda]

What if there would be a need to create more than two releases for a single device?

For example, for security reasons, there might be a need to publish a feature-rich version, and a cropped down, but less prone to security exploits one.

I think such scenario, maybe for some other reason, might appear in the future. Will this convention handle such cases? Or will there be no such need?

[pietrushnic]

@philipanda thank you for feedback.

What if there would be a need to create more than two releases for a single device?

For example, for security reasons, there might be a need to publish a feature-rich version, and a cropped down, but less prone to security exploits one.

I think such scenario, maybe for some other reason, might appear in the future. Will this convention handle such cases? Or will there be no such need?

Security fixes most likely have to have their own path. There was hope for the creation of the Dasharo Security Bulletin (DSB) soon. We have to look at Xen and Qubes to see how they do it. Very likely it would be Assured, because we have to have minimal regression (with the assumption that we are fixing LTS) plus test for security fix, which, as defined by Assured, "only tests which validate areas of firmware that experience change".

TL;DR security and hot fixes should go Assured path, but also cover publication of DSB.

I think it will. Let me know if my explanation is sound.

[philipanda]

Security fixes most likely have to have their own path. There was hope for the creation of the Dasharo Security Bulletin (DSB) soon. We have to look at Xen and Qubes to see how they do it. Very likely it would be Assured, because we have to have minimal regression (with the assumption that we are fixing LTS) plus test for security fix, which, as defined by Assured, "only tests which validate areas of firmware that experience change".

TL;DR security and hot fixes should go Assured path, but also cover publication of DSB.

I think it will. Let me know if my explanation is sound.

Thanks for the response. By two releases I meant two separate firmware variants, which would in some way be maintained separately.

For example, because some optional feature, even if implemented with care, could serve as a potential attack vector, someone might prefer to not have it in the firmware at all.

That's just my idea for a scenario where two Independent firmware variants for one device with the same framework and payload could be useful.

[pietrushnic]

Security fixes most likely have to have their own path. There was hope for the creation of the Dasharo Security Bulletin (DSB) soon. We have to look at Xen and Qubes to see how they do it. Very likely it would be Assured, because we have to have minimal regression (with the assumption that we are fixing LTS) plus test for security fix, which, as defined by Assured, "only tests which validate areas of firmware that experience change".
TL;DR security and hot fixes should go Assured path, but also cover publication of DSB.
I think it will. Let me know if my explanation is sound.

Thanks for the response. By two releases I meant two separate firmware variants, which would in some way be maintained separately.

For example, because some optional feature, even if implemented with care, could serve as a potential attack vector, someone might prefer to not have it in the firmware at all.

That's just my idea for a scenario where two Independent firmware variants for one device with the same framework and payload could be useful.

I don't know if such a situation has happened so far. It sounds like preparing for something improbable.

[philipanda]

I don't know if such a situation has happened so far. It sounds like preparing for something improbable.

I can't recall such situation too. I want to base the reworked directory structure on dl.3mdeb.com on the naming convention. I just thought that maybe it might be worth to be prepared should such need arise. Changing the convention and directory structure again would be costly.

If you say its not worth it, then I'm fine with that.

[pietrushnic]

I don't know if such a situation has happened so far. It sounds like preparing for something improbable.

I can't recall such situation too. I want to base the reworked directory structure on dl.3mdeb.com on the naming convention. I just thought that maybe it might be worth to be prepared should such need arise. Changing the convention and directory structure again would be costly.

Agree, that's why we should have some mutual agreement here.

Changing is expensive, but a holistic, infinitely flexible design may be infeasible, so what option do we have?

If you say its not worth it, then I'm fine with that.

If it didn't happen so far, it is unlikely it will happen, so it is not worth adjusting. What is worth is what happens and what we know works in production. We understand that the old scheme was rarely used by users, but caused design and decision issues internally. So we have to change it, especially in light of the need for multi-tier validation schemes.

[macpijan]

@pietrushnic

If it didn't happen so far, it is unlikely it will happen, so it is not worth adjusting. What is worth is what happens and what we know works in production. We understand that the old scheme was rarely used by users, but caused design and decision issues internally. So we have to change it, especially in light of the need for multi-tier validation schemes.

Do you expect a case like this to be realistic:

• we release (coreboot + UEFI) firmware as part of the DCP/DSP,
• we wanted to include extra security features (like intel TXT) in the release, but the owner of this releases is not willing to include it,
• we are releasing another (coreboot + UEFI) firmware, possibly as part of the DPP, with said features enabled
• as a result, we have 2 variants of firmware for the same framework/payload/platform combination - I think @philipanda has meant something like this

We could say that the distinction here is DCP vs DPP and we do not imagine having multiple DPP variants with different tier of features. Or do we imagine it?

[pietrushnic]

We could say that the distinction here is DCP vs DPP and we do not imagine having multiple DPP variants with different tier of features. Or do we imagine it?

We do imagine, although that would be a non-public distribution/special channel, but do we really want to go into a holistic design approach to cover whatever we can imagine? In theory, there may be an infinite number of such versions.

Naming conventions evolve for the following two reasons so far:

1. Marketing (Subscription vs Package) - community feedback
2. Strategy enforcement (Rapid/Assured/LTS) - my way of pushing forward the concept, which is applied too slowly; this requirement is fundamental to increasing the number of releases
3. Partical usage (market segment vs platform name) - nobody used market segment in practice

Can we apply any of the above reasons to features we can imagine, or do we need to add another reason for changing the naming convention? Also, it would be easier to discuss the proposal instead of the theoretical change in naming. The current naming is complex enough to add more to it, before I am forced to do it by reality.

[pietrushnic]

@macpijan @philipanda @Stanislaw-bnk @BeataZdunczyk, dear reviewers, this PR has been here for 1.5 months. We would like to have a clear direction on changes or receive approval.

I would appreciate your clear feedback on what is expected to be changed.

[philipanda]

do we really want to go into a holistic design approach to cover whatever we can imagine? In theory, there may be an infinite number of such versions.

I think that defining a precise naming convention is a holistic approach itself. If it is supposed to cover all current, and as many future releases as possible, then it should either be precise and complex, or relaxed and simple. The suggested convention is precise, which helps with unambiguity, but leaves little space for future changes.

We don't know what the future will bring, so the only reasonable way to mitigate that would be to add some "relaxed and simple" field to the convention, like some generic "variant", but that would make it less precise and more prone to ambiguity.

Assuming that the convention is supposed to be precise, I agree with keeping it as is now. Every other change in this PR is LGTM.

[macpijan]

Do we need to update this section as well? Or do we still use non-LTS naming? https://docs.dasharo.com/osf-trivia-list/dasharo/#what-is-dasharo-non-lts-release

This is also linked in the MSI releases: https://docs.dasharo.com/variants/msi_z690/releases/#v115-2025-09-18 and the z790 equivalent. We might need to change it to rapid in the release notes, and link to naming convention document instead.

[pietrushnic]

Do we need to update this section as well? Or do we still use non-LTS naming? https://docs.dasharo.com/osf-trivia-list/dasharo/#what-is-dasharo-non-lts-release

Yes, based on you comment here #1144 (comment)

This is also linked in the MSI releases: https://docs.dasharo.com/variants/msi_z690/releases/#v115-2025-09-18 and the z790 equivalent. We might need to change it to rapid in the release notes, and link to naming convention document instead.

[pietrushnic]

Fixes: #1177