End Of Life Tag in spdx #spdx
|
Patil, Sandeep
Hi All,
We have requirement to specify End Of Life as part of package information in SBoM , Is there way current SPDX format support this ? Regards Sandeep |
|
|
|
|
|
Kate Stewart
Hi Sandeep, There is a pull request expected shortly from the Usage profile team, to add this specific field to 2.3. When it comes in, please feel free to review and make sure it's going to suffice for your needs. For now, with 2.2 documents, suggest you use the Package Comment field (https://spdx.github.io/spdx-spec/package-information/#720-package-comment-field) and standardize on a tag (like EndOfSupport: ) and the date. Will that work for now? Thanks, Kate On Fri, May 6, 2022 at 2:27 PM Patil, Sandeep via lists.spdx.org <sandeep.patil=philips.com@...> wrote: Hi All, |
|
|
|
|
|
Kate and Sandeep,
Our customers are also interested in this information. There are two concepts to consider: Commercial Status: <enumeration value="Available"></enumeration> <enumeration value="Retired"></enumeration> <enumeration value="EOL"></enumeration> <enumeration value="BetaTest"></enumeration> <enumeration value="Pilot"></enumeration> <enumeration value="Abandoned"></enumeration>
Support Status: <enumeration value="Supported"></enumeration> <enumeration value="Unsupported"></enumeration> <enumeration value="Community"></enumeration>
Both are described in the open-source Vendor Response File (VRF) XML schema available here: https://raw.githubusercontent.com/rjb4standards/REA-Products/master/SAGVendorSchema.xsd
Thanks,
Dick Brooks
Active Member of the CISA Critical Manufacturing Sector, Sector Coordinating Council – A Public-Private Partnership
Never trust software, always verify and report! ™ http://www.reliableenergyanalytics.com Email: dick@... Tel: +1 978-696-1788
From: spdx@... <spdx@...> On Behalf Of Kate Stewart
Sent: Friday, May 6, 2022 3:34 PM To: SPDX-general <spdx@...> Subject: Re: [spdx] End Of Life Tag in spdx #spdx
Hi Sandeep,
There is a pull request expected shortly from the Usage profile team, to add this specific field to 2.3. When it comes in, please feel free to review and make sure it's going to suffice for your needs.
For now, with 2.2 documents, suggest you use the Package Comment field (https://spdx.github.io/spdx-spec/package-information/#720-package-comment-field) and standardize on a tag (like EndOfSupport: ) and the date.
Will that work for now?
Thanks,
On Fri, May 6, 2022 at 2:27 PM Patil, Sandeep via lists.spdx.org <sandeep.patil=philips.com@...> wrote:
|
|
|
|
|
|
Armijn Hemel - Tjaldur Software Governance Solutions
hello,
I would suggest to keep this
information "out of band" and not inside SPDX documents. Current
information inside SPDX documents is largely static: package,
license, checksum, and so on. Of course there could have been
errors that need to be fixed, but overall these fields are static.
EOL information, commercial status and
support status on the other hand are much more dynamic. Sometimes
packages are supported for only a few hours, sometimes for
decades. Very often it is also not clear when a package is EOL or
supported as many authors/maintainers do not announce it. The
support is sometimes also not done by the author/maintainers, but
by an external entity (for example: enterprise grade Linux
distributions). Does this mean it is supported, or only supported
for people willing to pay for it, or .... ? It is simply not clear
and it adds a lot of fuzziness.
This would make SPDX a lot more
cumbersome, as not only do the documents need to be generated, but
they also need to be updated all the time to avoid falling out of
sync. It also mixes syntax and semantics, which is never a good
idea.
armijn
-- Armijn Hemel, MSc Tjaldur Software Governance Solutions |
|
|
|
|
|
I agree: “I would suggest to keep this information "out of band" and not inside SPDX documents”
Thanks,
Dick Brooks
Active Member of the CISA Critical Manufacturing Sector, Sector Coordinating Council – A Public-Private Partnership
Never trust software, always verify and report! ™ http://www.reliableenergyanalytics.com Email: dick@... Tel: +1 978-696-1788
From: spdx@... <spdx@...> On Behalf Of Armijn Hemel - Tjaldur Software Governance Solutions
Sent: Thursday, May 19, 2022 6:21 AM To: spdx@... Subject: Re: [spdx] End Of Life Tag in spdx #spdx
hello,
I would suggest to keep this information "out of band" and not inside SPDX documents. Current information inside SPDX documents is largely static: package, license, checksum, and so on. Of course there could have been errors that need to be fixed, but overall these fields are static.
EOL information, commercial status and support status on the other hand are much more dynamic. Sometimes packages are supported for only a few hours, sometimes for decades. Very often it is also not clear when a package is EOL or supported as many authors/maintainers do not announce it. The support is sometimes also not done by the author/maintainers, but by an external entity (for example: enterprise grade Linux distributions). Does this mean it is supported, or only supported for people willing to pay for it, or .... ? It is simply not clear and it adds a lot of fuzziness.
This would make SPDX a lot more cumbersome, as not only do the documents need to be generated, but they also need to be updated all the time to avoid falling out of sync. It also mixes syntax and semantics, which is never a good idea.
armijn
-- Armijn Hemel, MSc Tjaldur Software Governance Solutions |
|
|
|
|
|
Armijn said: > Current information inside SPDX documents is largely static […] > This would make SPDX a lot more cumbersome, as not only do the documents need to be generated, but they also need to be updated all the time to avoid falling out of sync
I have no opinion on end-of-life either way, but wouldn’t the same argument apply to security vulnerabilities?
steve
From: spdx@... <spdx@...>
On Behalf Of Armijn Hemel - Tjaldur Software Governance Solutions
Sent: 19 May 2022 11:21 To: spdx@... Subject: Re: [spdx] End Of Life Tag in spdx #spdx
hello,
I would suggest to keep this information "out of band" and not inside SPDX documents. Current information inside SPDX documents is largely static: package, license, checksum, and so on. Of course there could have been errors that need to be fixed, but overall these fields are static.
EOL information, commercial status and support status on the other hand are much more dynamic. Sometimes packages are supported for only a few hours, sometimes for decades. Very often it is also not clear when a package is EOL or supported as many authors/maintainers do not announce it. The support is sometimes also not done by the author/maintainers, but by an external entity (for example: enterprise grade Linux distributions). Does this mean it is supported, or only supported for people willing to pay for it, or .... ? It is simply not clear and it adds a lot of fuzziness.
This would make SPDX a lot more cumbersome, as not only do the documents need to be generated, but they also need to be updated all the time to avoid falling out of sync. It also mixes syntax and semantics, which is never a good idea.
armijn
-- Armijn Hemel, MSc Tjaldur Software Governance Solutions |
|
|
|
|
|
Steve,
Regarding: “I have no opinion on end-of-life either way, but wouldn’t the same argument apply to security vulnerabilities?”
Yes, if a software vendor chooses to list each known vulnerability with a separate V 2.3 “SECURITY advisory object “affecting a software product on day one, when the SBOM is finalized.
However, that is not the case if a vendor chooses to link to a single, dynamically generated Vulnerability Disclosure Report (VDR) using a V 2.3 “SECUIRTY advisory object”, where the link is static, but the contents delivered by the link are dynamic, which enables a software consumer to answer this question about a software product: “What is the vulnerability status NOW at the SBOM component level?”
The 5/5 NIST guidance for Executive order 14028 supports this dynamic VDR concept, which appears in SPDX V 2.3, Appendix G 1.3.1 and G 1.9:
“Maintain vendor vulnerability disclosure reports at the SBOM component level.”
Thanks,
Dick Brooks
Active Member of the CISA Critical Manufacturing Sector, Sector Coordinating Council – A Public-Private Partnership
Never trust software, always verify and report! ™ http://www.reliableenergyanalytics.com Email: dick@... Tel: +1 978-696-1788
From: spdx@... <spdx@...> On Behalf Of Steve Kilbane
Sent: Friday, May 20, 2022 3:33 AM To: spdx@... Subject: Re: [spdx] End Of Life Tag in spdx #spdx
Armijn said: > Current information inside SPDX documents is largely static […] > This would make SPDX a lot more cumbersome, as not only do the documents need to be generated, but they also need to be updated all the time to avoid falling out of sync
I have no opinion on end-of-life either way, but wouldn’t the same argument apply to security vulnerabilities?
steve
hello,
I would suggest to keep this information "out of band" and not inside SPDX documents. Current information inside SPDX documents is largely static: package, license, checksum, and so on. Of course there could have been errors that need to be fixed, but overall these fields are static.
EOL information, commercial status and support status on the other hand are much more dynamic. Sometimes packages are supported for only a few hours, sometimes for decades. Very often it is also not clear when a package is EOL or supported as many authors/maintainers do not announce it. The support is sometimes also not done by the author/maintainers, but by an external entity (for example: enterprise grade Linux distributions). Does this mean it is supported, or only supported for people willing to pay for it, or .... ? It is simply not clear and it adds a lot of fuzziness.
This would make SPDX a lot more cumbersome, as not only do the documents need to be generated, but they also need to be updated all the time to avoid falling out of sync. It also mixes syntax and semantics, which is never a good idea.
armijn
-- Armijn Hemel, MScTjaldur Software Governance Solutions |
|
|
|
|
|
Kate Stewart
On Fri, May 20, 2022 at 2:32 AM Steve Kilbane <stephen.kilbane@...> wrote:
Sort of. Security information is even more likely to change after release, EOL for open source components supported by the community may, but much less frequently. Thinking so far, is that this would start out as an optional field, so that those who do know the information when assembling an SBOM can include it. Example: you are using a product that contains the linux 4.9 kernel. You know from the community (https://kernel.org/category/releases.html) that it will go out of support Jan 2023 (as of today, but this may evolve), so including this information, which could then be queried by a script around then, and then determine next steps, is going to be much more efficient then expecting all consumers of your product to add it manually. Similarly certain distros have expectations of EOL for support from the community (https://wiki.debian.org/LTS). To your point, there may well be a contract with a supplier, with a date that extends this, and in that case there are likely processes already in place to track/monitor/etc. in an organization. However those consuming open source based products are not necessarily tracking the upstream components EOL, and probably should be. Adding this field, as optional, enables more efficiency. Thanks, Kate |
|
|
|
|
|
Gary O'Neall
Armijn raises a valid concern. We’ve avoided dynamic information in the past, but even with version 1.0 you could argue the “Concluded License” could change over time if new information is available after publication of the SPDX document. We’ve certainly seen project home page links change over time as well.
Since having the end of life information available is useful for a few use cases and the frequency of change should be relatively low, I’m of the opinion we could include this as an optional field.
One suggestion is to define the field as the valid information at the time the SPDX document is created. That way, even if one of these fields changes later, the SPDX document still records valid facts.
Regards, Gary
From: spdx@... <spdx@...> On Behalf Of Kate Stewart
Sent: Friday, May 20, 2022 5:41 AM To: SPDX-general <spdx@...> Subject: Re: [spdx] End Of Life Tag in spdx #spdx
On Fri, May 20, 2022 at 2:32 AM Steve Kilbane <stephen.kilbane@...> wrote:
Sort of. Security information is even more likely to change after release, EOL for open source components supported by the community may, but much less frequently.
Thinking so far, is that this would start out as an optional field, so that those who do know the information when assembling an SBOM can include it.
Example: you are using a product that contains the linux 4.9 kernel. You know from the community (https://kernel.org/category/releases.html) that it will go out of support Jan 2023 (as of today, but this may evolve), so including this information, which could then be queried by a script around then, and then determine next steps, is going to be much more efficient then expecting all consumers of your product to add it manually. Similarly certain distros have expectations of EOL for support from the community (https://wiki.debian.org/LTS).
To your point, there may well be a contract with a supplier, with a date that extends this, and in that case there are likely processes already in place to track/monitor/etc. in an organization. However those consuming open source based products are not necessarily tracking the upstream components EOL, and probably should be. Adding this field, as optional, enables more efficiency.
Thanks, |
|
|
|
