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.

[philipanda]

Where the PC Engines releases with their characteristic versioning scheme would land in this convention?

[pietrushnic]

It really depends on which release, one that the PET Team does:

Dasharo (coreboot+SeaBIOS) Pro LTS Package for PC Engines apu2/3/4/6

[philipanda]

I think we should update the Overview pages then to make sure that every page shows the platform name in a visible place. It's not the case for PC Engines APU https://docs.dasharo.com/variants/pc_engines/overview/

Dasharo/dasharo-issues#1650

[pietrushnic]

I don't get the problem. What is expectation, and how is it related to this discussion?

[philipanda]

• platform: Indicates the target platform for the package. Platform is
  mandatory in public names. Platform name should follow supported hardware
  list.

Oh, it says to look in variants/overview, not the overview of a given platform. The names are there then, so all's good.

[macpijan]

should be resolved?

[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?

[macpijan]

Right now we include Dasharo (framework[+payload]) this part only in SMBIOS, I wonder if we should include more. Possibly related to: #1154 (comment) if we needed to tell which update given platform would need.

[pietrushnic]

SMBIOS has other ways of expressing things. There are also things like compliance profiles in UEFI, as well as OS features in variables, which we do not leverage, and I doubt there is anything like that in coreboot.

• https://uefi.org/sites/default/files/resources/UEFI-Conf_Tables-WP-July-2022v2.pdf
• https://uefi.org/specs/UEFI/2.11/search.html?q=OsIndications&check_keywords=yes&area=default

[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.