Date   

OCI and ORAS Support for SBOM

William Bartholomew (CELA)
 

OCI and ORAS have added support for attaching SBOMs (or other related artifacts) to container images in a registry:

https://oras.land/blog/oras-0.14-and-future/

 

Their example uses Microsoft’s SBOM Tool to generate an SPDX SBOM and then the ORAS client to attach it to a container image in the registry.

 

William


Re: Element marbles

David Kemp
 

In preparation for the Examples discussion, proponents of nested serializations should provide two example Payloads:

1) a transfer unit that carries two SBOMs  urn:spdx.dev:null-sbom-a and  urn:spdx.dev:null-sbom-b.
2) a transfer unit that carries two SBOMs  urn:spdx.dev:null-sbom-a and  urn:spdx.dev:null-sbom-b where SBOM B is included in SBOM A, e.g.:

{
  "type": "SBOM",
  "id": "urn:spdx.dev:null-sbom-a",
   <... 5 creation properties ...>,
  "elements": [
    "urn:spdx.dev:iamwillbar",
    "urn:spdx.dev:spdx-tools-3.0.1",
    "urn:spdx.dev:null-sbom-b"
   ]
}

The nested serialized data examples must illustrate how these cases are handled when, for example, both SBOM A and SBOM B contain some of the same elements, e.g. the Person and/or Package elements from the current SBOM example.  

Regards,
David

On Wed, Sep 21, 2022 at 2:29 PM David Kemp via lists.spdx.org <dk190a=gmail.com@...> wrote:
We have already agreed that some use cases, including streaming, involve sending individual Elements.  The logical model currently includes example values, but none of them include individual elements.  The "Minimal Example Element (JSON)" data is not an Element - it has a type of Person but it does not include any Person values.  This illustrates that examples are necessary to refine the model - it currently has ExternalIdentifier and ExternalReference structs that are supposedly used in Actor and/or Identity, but the examples don't use them.  (IMO, Actor should have a required "identifier" property with the value "urn:spdx:dev:iamwillbar" but no locator as included in ExternalIdentifier.)

A Minimal SBOM example is also needed that shows the value of a single SBOM Element without the values of any other elements; e.g.

{
  "type": "SBOM",
  "id": "urn:spdx.dev:null-sbom",
   <... 5 creation properties ...>,
  "elements": [
    "urn:spdx.dev:iamwillbar",
    "urn:spdx.dev:spdx-tools-3.0.1"
   ]
}

This single SBOM element has only the values of the SBOM element, not the values of other elements that it references.  It doesn't make sense to include a hash verifiedUsing because a consumer computes and verifies a hash of the element against the value included in a reference to the element.  It could include a creator signature verifiedUsing, but a minimal example probably wouldn't use per-element signatures.  There are no rootElements or externalMap properties in a single element; those are properties of the SpdxDocument element.

The Person element could replace the existing Minimal Single Element since it does include externalIdentifiers, but it demonstrates that the model is missing both ExternalIdentifierType and an "authority" property as shown in the example, and the property name is "externalIdentifierType" or should be changed to just "type" to match the example.  ExternalIdentifierType would be capitalized and include at least the values "EMAIL_ADDRESS" and "ACCOUNT".

The Package example needs serious rework - "externalIdentifiers" would have either a "type" or "externalIdentifierType", and ExternalIdentifierType would need EXTERNAL_REFERENCE value, and in general the structure of an ExternalIdentifier that contains an ExternalReference must be clarified.

The verifiedUsing property makes sense for Package because the package artifact (a sequence of bytes) can be hashed.  This points out the need to reconcile the meaning of the verifiedUsing property, it is the hash or signature of artifact bytes, not a signature of serialized element bytes.

In short, the Examples must include the values of three individual elements, a Person, a Package, and an SBOM, serialized in at least JSON, but it would be useful to have serialized values of the identical three elements in other formats as well (in accompanying files, not on the model diagram).

Regards,
David

On Sat, Sep 17, 2022 at 12:37 PM David Kemp via lists.spdx.org <dk190a=gmail.com@...> wrote:
One thing that still needs to be decided is whether or in how much detail the logical model goes to define the Payload.  This requires agreeing on the answers to two questions:

1 - True or False:  Elements stand alone, with a unique SPDXID and a value that doesn't depend on any other element.
Elements can be visualized as marbles, where each marble has its own SPDXID, and 0..* IRIs that are the SPDXIDs of other marbles.

2 - True or False: The logical value of an element is not affected by serialization.
In an element store (logical graph), an element 0 with 1..* IRIs of other elements always works correctly without regard to how or if elements 0 and 1..* may have been serialized.

If these are true, then elements are marbles, marbles can be placed in a cup, and a cup is not a marble.  The cup is a Payload, and like a cup of marbles or a tarfile of serialized elements, the Payload can contain any combination of elements without regard to their types or any edges between them.

The SpdxDocument element describes a Payload. Because a marble is not a cup, an SpdxDocument element is not a Payload.  The Payload is a sequence of bytes that carry any combination of 1..* elements without regard to serialization format and without any alteration of their logical values.  The marbles in the picture can pulled apart, put into any combination of one or more Payloads with the same or different serialization formats, then unambiguously deserialized and reassembled into the identical logical graph as before.

If we want to define Payload in the logical model, then it is a datatype that goes with other datatypes on the right side of the diagram, and it is modeled as an OWL/RDF collection - a first/next/nil structure, not what SPDX calls a "collection" which is an OWL/RDF container.

Regards,
David


Re: Element marbles

David Kemp
 

We have already agreed that some use cases, including streaming, involve sending individual Elements.  The logical model currently includes example values, but none of them include individual elements.  The "Minimal Example Element (JSON)" data is not an Element - it has a type of Person but it does not include any Person values.  This illustrates that examples are necessary to refine the model - it currently has ExternalIdentifier and ExternalReference structs that are supposedly used in Actor and/or Identity, but the examples don't use them.  (IMO, Actor should have a required "identifier" property with the value "urn:spdx:dev:iamwillbar" but no locator as included in ExternalIdentifier.)

A Minimal SBOM example is also needed that shows the value of a single SBOM Element without the values of any other elements; e.g.

{
  "type": "SBOM",
  "id": "urn:spdx.dev:null-sbom",
   <... 5 creation properties ...>,
  "elements": [
    "urn:spdx.dev:iamwillbar",
    "urn:spdx.dev:spdx-tools-3.0.1"
   ]
}

This single SBOM element has only the values of the SBOM element, not the values of other elements that it references.  It doesn't make sense to include a hash verifiedUsing because a consumer computes and verifies a hash of the element against the value included in a reference to the element.  It could include a creator signature verifiedUsing, but a minimal example probably wouldn't use per-element signatures.  There are no rootElements or externalMap properties in a single element; those are properties of the SpdxDocument element.

The Person element could replace the existing Minimal Single Element since it does include externalIdentifiers, but it demonstrates that the model is missing both ExternalIdentifierType and an "authority" property as shown in the example, and the property name is "externalIdentifierType" or should be changed to just "type" to match the example.  ExternalIdentifierType would be capitalized and include at least the values "EMAIL_ADDRESS" and "ACCOUNT".

The Package example needs serious rework - "externalIdentifiers" would have either a "type" or "externalIdentifierType", and ExternalIdentifierType would need EXTERNAL_REFERENCE value, and in general the structure of an ExternalIdentifier that contains an ExternalReference must be clarified.

The verifiedUsing property makes sense for Package because the package artifact (a sequence of bytes) can be hashed.  This points out the need to reconcile the meaning of the verifiedUsing property, it is the hash or signature of artifact bytes, not a signature of serialized element bytes.

In short, the Examples must include the values of three individual elements, a Person, a Package, and an SBOM, serialized in at least JSON, but it would be useful to have serialized values of the identical three elements in other formats as well (in accompanying files, not on the model diagram).

Regards,
David

On Sat, Sep 17, 2022 at 12:37 PM David Kemp via lists.spdx.org <dk190a=gmail.com@...> wrote:
One thing that still needs to be decided is whether or in how much detail the logical model goes to define the Payload.  This requires agreeing on the answers to two questions:

1 - True or False:  Elements stand alone, with a unique SPDXID and a value that doesn't depend on any other element.
Elements can be visualized as marbles, where each marble has its own SPDXID, and 0..* IRIs that are the SPDXIDs of other marbles.

2 - True or False: The logical value of an element is not affected by serialization.
In an element store (logical graph), an element 0 with 1..* IRIs of other elements always works correctly without regard to how or if elements 0 and 1..* may have been serialized.

If these are true, then elements are marbles, marbles can be placed in a cup, and a cup is not a marble.  The cup is a Payload, and like a cup of marbles or a tarfile of serialized elements, the Payload can contain any combination of elements without regard to their types or any edges between them.

The SpdxDocument element describes a Payload. Because a marble is not a cup, an SpdxDocument element is not a Payload.  The Payload is a sequence of bytes that carry any combination of 1..* elements without regard to serialization format and without any alteration of their logical values.  The marbles in the picture can pulled apart, put into any combination of one or more Payloads with the same or different serialization formats, then unambiguously deserialized and reassembled into the identical logical graph as before.

If we want to define Payload in the logical model, then it is a datatype that goes with other datatypes on the right side of the diagram, and it is modeled as an OWL/RDF collection - a first/next/nil structure, not what SPDX calls a "collection" which is an OWL/RDF container.

Regards,
David


Event: SPDX tech team meeting - 09/20/2022 #cal-reminder

Group Notification <noreply@...>
 

Reminder: SPDX tech team meeting

When:
09/20/2022
11:00am to 12:30pm
(UTC-05:00) America/Chicago

Where:
https://zoom.us/j/663426859

Organizer: Kate Stewart kstewart@...

View Event

Description:
https://zoom.us/j/663426859
Meeting ID: 663 426 859

Tuesdays at 17:00 UTC (and best guess for local time - 10:00AM PDT, 11:00 MDT, 12:00PM CDT, 1:00PM EDT, 18:00 WAT, 19:00 CEST).
Australia +61 2 8015 2088
Canada +1 647 558 0588
Germany +49 30 3080 6188
Japan +81 3 4578 1488
US Toll-free 877 369 0926
Find your local number: https://zoom.us/u/ac9KKJWzJT

-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-
Please do not edit this section of the description.

View your event at https://www.google.com/calendar/event?action=VIEW&eid=MjhvMjJvOGd2cXAxNjk3bzA4bDYzYTk2cjQgc3BkeC10ZWNoQGxpc3RzLnNwZHgub3Jn&tok=Mjgja3N0ZXdhcnRAbGludXhmb3VuZGF0aW9uLm9yZzZmNjFiY2RkMThiNDZlMzg1ZjY5OTFhMjM3NGJhMGFiNjg4ZDdlMjU&ctz=America%2FChicago&hl=en&es=1.
-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-


Re: Where did Table 1 go?

Martin, Robert A
 

Hi Sebastian,

Doing a little looking around it appears there were no tables in the SPDX specifications versions 1.0, 2.0, and 2.1.

In 2.2 tables appear and there is no table 1 but I believe the table in section 4.4 - a table with formats and extensions - should have been labeled as table 1.

Bob's 2cents

Robert (Bob) Martin
Sr. Software and Supply Chain Assurance Principal Eng.
Cross Cutting Solutions and Innovation Dept
Cyber Solutions Innovation Center
MITRE Labs
MITRE Corporation
781-271-3001o
781-424-4095c
On 9/19/22 5:42 PM, Sebastian Crane wrote:

Dear all,

In continuing my efforts to convert the SPDX 2.3 specification to
LaTeX in order to generate a PDF edition, I'm now up against the
curious case of the missing table...

Clause 6 opens with 'Table 2 - Metadata for the SPDX version field' -
but it's the first numbered table in the specification! The only other
table is the unnumbered table in-line with the bullet points in Clause
4. All of the above is true for SPDX 2.2.2 as well.

If anyone remembers when table 1 was deleted (if it even existed at
all), please let me know!

Best wishes,

Sebastian





Where did Table 1 go?

Sebastian Crane
 

Dear all,

In continuing my efforts to convert the SPDX 2.3 specification to
LaTeX in order to generate a PDF edition, I'm now up against the
curious case of the missing table...

Clause 6 opens with 'Table 2 - Metadata for the SPDX version field' -
but it's the first numbered table in the specification! The only other
table is the unnumbered table in-line with the bullet points in Clause
4. All of the above is true for SPDX 2.2.2 as well.

If anyone remembers when table 1 was deleted (if it even existed at
all), please let me know!

Best wishes,

Sebastian


Re: Build Profile meeting 19 Sep

Joshua Watt
 

FYI, attendance was really low, so we just cancelled this week. See
you all next week

On Thu, Sep 15, 2022 at 3:22 PM Joshua Watt <jpewhacker@...> wrote:

I can lead it

On Thu, Sep 15, 2022 at 3:06 PM Brandon Lum via lists.spdx.org
<lumb=google.com@...> wrote:

Hi All,

I will be attending the NIST NCCOE DevSecOps workshop - would someone be able to lead the meeting next week? If not we can skip this week.

Cheers
Brandon


FYI: An article about the OMB memo for the energy industry

Dick Brooks
 

Just an FYI, in case anyone is interested:

https://energycentral.com/c/pip/omb-memo-identifies-best-practices-software-supply-chain-protections

 

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

 


Re: [SCITT] Just want to raise your awareness to some FUD from BSA and ITI making the rounds

Dick Brooks
 

Excellent point, Charlie. This is what happens when Joanne has a golf tournament and I’m not included.

 

Totally agree NDAA != 14028, but there is considerable overlap in the requirements.

 

FYI: I’ve had conversations with BSA and ITI this week to show them what’s possible today with SBOM and vulnerability monitoring by consumers.

 

Software consumers bear all the risk of cyber-attacks and software vendors could show more empathy for the plight of these consumers by giving them an SBOM so they can monitor for risk in installed components, when new vulnerabilities are reported. The optics of resistance to this one small, but meaningful gesture, are putting software vendors in a position of appearing like they don’t care about what happens to their customers – and that would not be good. The new OMB directives will help consumers get the visibility they deserve and need, IMO.

 

I continue to reach out to our BSA and ITI colleagues and others in the SBOM community to collaborate on the implementation of NIST EO 14028 recommendations in the OMB memo.

 

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: Hart, Charlie <charlie.hart@...>
Sent: Saturday, September 17, 2022 1:15 PM
To: scitt@...; 'SPDX Technical Mailing List' <spdx-tech@...>; dick@...
Cc: 'scrm-nist' <scrm-nist@...>; 'swsupplychain-eo' <swsupplychain-eo@...>
Subject: Re: [EXT][SCITT] Just want to raise your awareness to some FUD from BSA and ITI making the rounds

 

Both Dick and I need hobbies for sure.

 

That letter is commenting on the NDAA, which is separate from 14028. I don't know much about it. I think BSA and ITI were taken by surprise at the groundswell for SBOMs and are now scrambling to get some order in the household.

 

One thing that might account for the late push:14028 can be waived by the EOP any time for procurement of something problematic, NDAA if passed will be somewhat unavaoidable.

 

The threat of USG not getting access to top software immediately made me think: Palantir wrote this.

 

Charlie

 


From: SCITT <scitt-bounces@...> on behalf of Dick Brooks <dick@...>
Sent: Saturday, September 17, 2022 1:04 PM
To: scitt@... <scitt@...>; 'SPDX Technical Mailing List' <spdx-tech@...>
Cc: 'scrm-nist' <scrm-nist@...>; 'swsupplychain-eo' <swsupplychain-eo@...>
Subject: [EXT][SCITT] Just want to raise your awareness to some FUD from BSA and ITI making the rounds

 

FYI:

 

https://www.linkedin.com/posts/richard-dick-brooks-8078241_iti-and-bsa-letter-opposing-sbom-and-nist-activity-6976931523883065344-0J8-/?utm_source=share&utm_medium=member_desktop

 

Good to know the SCITT use case for SBOM that we’ve been discussing aligns more closely with NIST and White House views, and OMB directives, on software supply chain practices:

 

https://www.linkedin.com/posts/richard-dick-brooks-8078241_omb-memo-outlining-secure-software-supply-ugcPost-6976939817175523328-DtfI?utm_source=share&utm_medium=member_desktop

 

 

Link to the SCITT SBOM Use Case and presentation are here:

https://hackmd.io/QuqKhy_bQ1qG9yyyBuEABg?view

 

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

 


Just want to raise your awareness to some FUD from BSA and ITI making the rounds

Dick Brooks
 

FYI:

 

https://www.linkedin.com/posts/richard-dick-brooks-8078241_iti-and-bsa-letter-opposing-sbom-and-nist-activity-6976931523883065344-0J8-/?utm_source=share&utm_medium=member_desktop

 

Good to know the SCITT use case for SBOM that we’ve been discussing aligns more closely with NIST and White House views, and OMB directives, on software supply chain practices:

 

https://www.linkedin.com/posts/richard-dick-brooks-8078241_omb-memo-outlining-secure-software-supply-ugcPost-6976939817175523328-DtfI?utm_source=share&utm_medium=member_desktop

 

 

Link to the SCITT SBOM Use Case and presentation are here:

https://hackmd.io/QuqKhy_bQ1qG9yyyBuEABg?view

 

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

 


Element marbles

David Kemp
 

One thing that still needs to be decided is whether or in how much detail the logical model goes to define the Payload.  This requires agreeing on the answers to two questions:

1 - True or False:  Elements stand alone, with a unique SPDXID and a value that doesn't depend on any other element.
Elements can be visualized as marbles, where each marble has its own SPDXID, and 0..* IRIs that are the SPDXIDs of other marbles.

2 - True or False: The logical value of an element is not affected by serialization.
In an element store (logical graph), an element 0 with 1..* IRIs of other elements always works correctly without regard to how or if elements 0 and 1..* may have been serialized.

If these are true, then elements are marbles, marbles can be placed in a cup, and a cup is not a marble.  The cup is a Payload, and like a cup of marbles or a tarfile of serialized elements, the Payload can contain any combination of elements without regard to their types or any edges between them.

The SpdxDocument element describes a Payload. Because a marble is not a cup, an SpdxDocument element is not a Payload.  The Payload is a sequence of bytes that carry any combination of 1..* elements without regard to serialization format and without any alteration of their logical values.  The marbles in the picture can pulled apart, put into any combination of one or more Payloads with the same or different serialization formats, then unambiguously deserialized and reassembled into the identical logical graph as before.

If we want to define Payload in the logical model, then it is a datatype that goes with other datatypes on the right side of the diagram, and it is modeled as an OWL/RDF collection - a first/next/nil structure, not what SPDX calls a "collection" which is an OWL/RDF container.

Regards,
David


Re: Build Profile meeting 19 Sep

Joshua Watt
 

I can lead it

On Thu, Sep 15, 2022 at 3:06 PM Brandon Lum via lists.spdx.org
<lumb=google.com@...> wrote:

Hi All,

I will be attending the NIST NCCOE DevSecOps workshop - would someone be able to lead the meeting next week? If not we can skip this week.

Cheers
Brandon


Build Profile meeting 19 Sep

Brandon Lum
 

Hi All,

I will be attending the NIST NCCOE DevSecOps workshop - would someone be able to lead the meeting next week? If not we can skip this week.

Cheers
Brandon


FYI: New White House Memo issued today outlining SBOM implementation guidance for Executive Order 14028

Dick Brooks
 

Parties interested in actual SBOM implementation guidance should refer to this White House Memo, issued September 14, 2022:

https://www.whitehouse.gov/wp-content/uploads/2022/09/M-22-18.pdf

 

 

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

 


Event: SPDX tech team meeting - 09/13/2022 #cal-reminder

Group Notification <noreply@...>
 

Reminder: SPDX tech team meeting

When:
09/13/2022
11:00am to 12:30pm
(UTC-05:00) America/Chicago

Where:
https://zoom.us/j/663426859

Organizer: Kate Stewart kstewart@...

View Event

Description:
https://zoom.us/j/663426859
Meeting ID: 663 426 859

Tuesdays at 17:00 UTC (and best guess for local time - 10:00AM PDT, 11:00 MDT, 12:00PM CDT, 1:00PM EDT, 18:00 WAT, 19:00 CEST).
Australia +61 2 8015 2088
Canada +1 647 558 0588
Germany +49 30 3080 6188
Japan +81 3 4578 1488
US Toll-free 877 369 0926
Find your local number: https://zoom.us/u/ac9KKJWzJT

-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-
Please do not edit this section of the description.

View your event at https://www.google.com/calendar/event?action=VIEW&eid=MjhvMjJvOGd2cXAxNjk3bzA4bDYzYTk2cjQgc3BkeC10ZWNoQGxpc3RzLnNwZHgub3Jn&tok=Mjgja3N0ZXdhcnRAbGludXhmb3VuZGF0aW9uLm9yZzZmNjFiY2RkMThiNDZlMzg1ZjY5OTFhMjM3NGJhMGFiNjg4ZDdlMjU&ctz=America%2FChicago&hl=en&es=1.
-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-


Extensions (was Re: [spdx-tech] PR created for tech minutes)

David Kemp
 

Minutes Line 62:
 * Proposal: Extensions field will be encapsulated in Profile and removed from Core Model type.

Discussion: The goal of extensions is to easily identify non-standardized content by inspection.  The current "extensions Map(URI, any)" clearly labels extensions but has the flavor of serialization rather than logical model (minutes line 59).  It also follows the (undesirable IMO) practice of shoving everything up into Element rather than down into the types where they apply.

New Proposal
* remove "extension" property from Element
* define "Extension" abstract class in Core with an "extensionId URI" property.
* non-standard profiles extend only the Extension class

This segregates extension types from standard types like Gary's hack of extending Annotation to support CycloneDX information.


Re: PR created for tech minutes

William Bartholomew (CELA)
 

Thanks for leading the call today Gary, I will be around next week so happy to lead. We can try and close out some of these questions if there is quorum.

 

William (currently in JFK airport enroute to Brussels)

 

From: Spdx-tech@... <Spdx-tech@...> On Behalf Of Gary O'Neall via lists.spdx.org
Sent: Tuesday, September 6, 2022 1:47 PM
To: 'SPDX Technical Mailing List' <spdx-tech@...>
Subject: [EXTERNAL] [spdx-tech] PR created for tech minutes

 

I created a pull request for the minutes from today’s tech call including an update to the decisions document: https://github.com/spdx/meetings/pull/222/files

 

William will follow-up if there is will be a call next week.

 

Best regards,

Gary

 

-------------------------------------------------

Gary O'Neall

Principal Consultant

Source Auditor Inc.

Mobile: 408.805.0586

Email: gary@...

CONFIDENTIALITY NOTE: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material. Any review, re-transmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and destroy any copies of this information.

 


PR created for tech minutes

Gary O'Neall
 

I created a pull request for the minutes from today’s tech call including an update to the decisions document: https://github.com/spdx/meetings/pull/222/files

 

William will follow-up if there is will be a call next week.

 

Best regards,

Gary

 

-------------------------------------------------

Gary O'Neall

Principal Consultant

Source Auditor Inc.

Mobile: 408.805.0586

Email: gary@...

CONFIDENTIALITY NOTE: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material. Any review, re-transmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and destroy any copies of this information.

 


Event: SPDX tech team meeting - 09/06/2022 #cal-reminder

Group Notification <noreply@...>
 

Reminder: SPDX tech team meeting

When:
09/06/2022
11:00am to 12:30pm
(UTC-05:00) America/Chicago

Where:
https://zoom.us/j/663426859

Organizer: Kate Stewart kstewart@...

View Event

Description:
https://zoom.us/j/663426859
Meeting ID: 663 426 859

Tuesdays at 17:00 UTC (and best guess for local time - 10:00AM PDT, 11:00 MDT, 12:00PM CDT, 1:00PM EDT, 18:00 WAT, 19:00 CEST).
Australia +61 2 8015 2088
Canada +1 647 558 0588
Germany +49 30 3080 6188
Japan +81 3 4578 1488
US Toll-free 877 369 0926
Find your local number: https://zoom.us/u/ac9KKJWzJT

-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-
Please do not edit this section of the description.

View your event at https://www.google.com/calendar/event?action=VIEW&eid=MjhvMjJvOGd2cXAxNjk3bzA4bDYzYTk2cjQgc3BkeC10ZWNoQGxpc3RzLnNwZHgub3Jn&tok=Mjgja3N0ZXdhcnRAbGludXhmb3VuZGF0aW9uLm9yZzZmNjFiY2RkMThiNDZlMzg1ZjY5OTFhMjM3NGJhMGFiNjg4ZDdlMjU&ctz=America%2FChicago&hl=en&es=1.
-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-


Re: stable spec URLs

J Lovejoy
 

Hi again,

Now that 2.3 is out, this question is more pertinent:

Note, if I want to link to a specific part of the SPDX spec, I can find it via the HTML format, for example:

if I wanted to see this same section in v2.2.2, the link is:

but if I simply removed the version number in the URL - https://spdx.github.io/spdx-spec/license-matching-guidelines-and-templates/
it ends up going to v2.2.2

That doesn’t seem right - should it default to the most current version?

Thanks,
Jilayne

On Jul 25, 2022, at 10:00 PM, J Lovejoy <opensource@...> wrote:

(cross-posting to tech and legal team, as I suspect others may be interested)

Hi SPDX-tech team,

I just wanted to confirm my understanding of the various formats we now have for the SPDX specification and linking to specific sections.

If I wanted to link to, for example, Annex D, in a way that would remain stable with subsequent versions of the spec, then I could use the HTML format, and then the link https://spdx.github.io/spdx-spec/SPDX-license-expressions/ - and this would still point to the Annex D on SPDX license expressions even for version 2.3 of the spec - is that right? (assuming of course that Annex D doesn't change name such that the link also changes)

Thanks!
Jilayne


1 - 20 of 4791