# spdx-sbom-generator Community Meeting Minutes

Times: Every Wednesday 9:30am-10:30am Pacific, 12:00pm-1:00pm EDT, 5:00pm-6:00pm UTC
Online meeting: https://meet.jit.si/SBOM-tools

***Template***

## Enter Date Here

### Attendees
- _attendees list_

### Notetaker
- _notetaker_ 🥇
- _backup notetaker_ 🥈

Agenda
- _enter agenda before meeting_

Notes

-------------------
## Backlog
- https://github.com/opensbom-generator/spdx-sbom-generator/issues/306
- Deprecate SPDX 2.2 support

-------------------
## 09/20/2023

### Attendees
- Rahul Tiwari

Agenda
- Plugin Interface Design

Notes
- Browse through the existing implementation to find scope of refactoring so that the new plugin interface fits in better.

-------------------
## 09/20/2023

### Attendees
- Nisha Kumar

Agenda
- Plugin Interface Design

Notes
- Most straightforward implementation is 1 method to return an SPDX document. This should work for SPDX2.x
- In the current refactor we have a document handler which is called by the generator implementation

type GeneratorImplementation interface {
	GetDocumentFormatHandler(*options.Options) (DocumentFormatHandler, error)
	GetCodeParsers(*options.Options) ([]plugin.Plugin, error)
	RunParser(*options.Options, plugin.Plugin) ([]meta.Package, error)
}

The `GetDocumentFormatHandler` handles different spdx specification versions

// GetDocumentFormatHandler gets a document handler according to the spdx schema version
func (di *defaultGeneratorImplementation) GetDocumentFormatHandler(opts *options.Options) (DocumentFormatHandler, error) {
	switch opts.SchemaVersion {
	case "2.3":
		return &v23.Handler{}, nil
	case "2.2":
		return &v22.Handler{}, nil
	default:
		return nil, errors.New("no document format handler defined")
	}
}

// a mapping between each plugin 


var plugins := make(map[string]DocumentFormatHandler)

type DocumentHandler interface {
	GetDocumentFormatHandler(*options.Options) (DocumentFormatHandler, error)
}

type Plugin interface {
    GetDocument(opts *options.Options)
}

func GetPluginHander(pluginName string) DocumentFormatHandler{
    return plugins[pluginName]
} 

package main

import "plugin"
import _ "plugins/python"

func main() {
    dfh := GetPluginHander("python")
    dfh.CreateDocument()
}

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

## 09/13/2023

### Attendees
- Nisha Kumar
- Rahul Tiwari

### Notetaker
- Rahul Tiwari

Agenda
- Proposal to update plugin architecture

Notes
- Proposed architecture diagram: https://drive.google.com/file/d/1lw1Iitv6PEbRnV5gpbkXyXcZl2WIione/view?usp=sharing
- Next steps: create issue with proposed architecture (Done: https://github.com/opensbom-generator/spdx-sbom-generator/issues/306)

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

## 08/23/2023

### Attendees
- Rahul Tiwari
- Maximilian Huber

### Notetaker
- Rahul Tiwari

Notes
- Glanced through the pnpm parser [PR](https://github.com/opensbom-generator/parsers/pull/75/files)
-------------------

## 08/09/2023

### Attendees
- Rahul Tiwari
- Nisha Kumar

### Notetaker
- Rahul Tiwari

Agenda
- Reviewing the refactor [PR](https://github.com/opensbom-generator/spdx-sbom-generator/pull/295) of the SBOM generator.
- Discussing separating plugins out of the parsers project and its feasibility.

Notes
- GSoC work
- Fix the build job in the GitHub actions.

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

## 07/26/2023

### Attendees
- Rahul Tiwari
- Nisha Kumar

### Notetaker
- Rahul Tiwari

Agenda
- Discussing Nisha's [PR](https://github.com/opensbom-generator/parsers/pull/35) supporting various lockfile versions for npm. The PR seems stale and needs to be revisited.

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

## 06/28/2023

### Attendees
- Rahul Tiwari
- Nisha Kumar
- Adolfo García Veytia

### Notetaker
- Rahul Tiwari

Agenda
- GSoC work:
- Start with integrating the parsers with spdx-sbom-generator as a new command maintaining backward compatibility.
- Generate SBOMS from requirements.txt , packages.json

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

## 06/21/2023

### Attendees
- Rahul Tiwari
- Nisha Kumar
- Maximilian Huber

### Notetaker
- Rahul Tiwari

Agenda
- GSoC work:
- Continue adding more unit tests for poetry
- Discussion about integrating the parsers with the spdx-sbom-generator

Notes
- Continue on unit tests.

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

## 06/14/2023

### Attendees
- Rahul Tiwari

### Notetaker
- Rahul Tiwari

Agenda
- GSoC work:
- Setup unit testing for poetry

Notes
- Continue on unit tests.

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

## 06/07/2023

### Attendees
- Rahul Tiwari
- Nisha Kumar
- Adolfo García Veytia

### Notetaker
- Rahul Tiwari

Agenda
- GSoC work:
- Finalize the approach for unit tests for the poetry package manager.

Notes
- Rahul to rethink and go bottom up for writing unit tests for poetry.

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

## 05/24/2023

### Attendees
- Rahul
- Nisha

Agenda
- GSoC work:
- https://github.com/opensbom-generator/parsers/issues/57

Notes
- Rahul to work on issue 57
- Nisha to find out more about the cargo mocks

-------------------
## 03/08/2023

### Attendees
- Adolfo García Veytia
- Nisha Kumar
- Ivana Atanasova
- Rahul Tiwari

### Notetaker
- Nisha 🥇

Notes:
- Kubeflow is having trouble with using spdx-sbom-generators with python
- Nisha: need to know what python package manager they are using; some of the parsers are broken
- Project Layout:
- parsers will contain just parsers of files that exist on the filesystem.
- We don't know if any of the ecosystems require network calls to fetch package information. - Needs to be investigated.
- It was decided that functionality where we shell out to package managers or external tools exists in another project.
- Conformance tests: we need specific test data to test expectations.
- Nisha: testdata layout in [npm PR](https://github.com/opensbom-generator/parsers/pull/35) works reasonably well.
- Submission of [sbom-composer](https://github.com/vmware-samples/sbom-composer) to opensbom-generator org
- Ivana will let others know when it's ready to be moved.
- Welcome Rahul!

No attendees :white_frowning_face:

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

## 11/23/2022

### Attendees
- Adolfo García Veytia

### Notetaker
- _notetaker_ 🥇
- _backup notetaker_ 🥈

Agenda
- Parsers Package and Plugin Model

Notes

No attendees :white_frowning_face:

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

## 11/09/2022

### Attendees
- Adolfo
- Nisha Kumar

### Notetaker
- Nisha 🥇
- _backup notetaker_ 🥈

Agenda
- Parsers Package and Plugin Model

Notes
- Decision:
- Make parser functionality testable
- Continue to use the current plugin and meta package

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

## 10/12/2022

### Attendees
- Adolfo
- Nisha Kumar

### Notetaker
- Nisha 🥇
- _backup notetaker_ 🥈

Agenda
- Manifest Parsers

Notes
- Manifest parsers
- Action: Nisha to make Adolfo maintainer of org and repo
- Action: Adolfo creates "parser" repo
- Before that, create a document on how this is structured.
- Perhaps keep all parsers in this repo?
- Ask Gary in the ACT call

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

## 09/28/2022

### Attendees
- _attendees list_

### Notetaker
- _notetaker_ 🥇
- _backup notetaker_ 🥈

### Agenda
-

### Notes
- So many tools!
- Adolfo's ideas:
- Pluggable model in bom: go package with some options and it will produce an SPDX object
- SPDX generator: could reuse the language analyzers
- We want to link this to some best practices
- Universal lock file?
- SBOM Guidance (going to be presented in OpenSSF Securing repos wg) In order to produce an SBOM you need a lock file. For example, go.mod/go.sum,
- Use top level project metadata then add build metadata when invoking a build
- Maybe also adding in-toto
- Adolfo: most valuable use case is to generate a good quality SPDX SBOM
- Example of `bom`'s upcoming plugin model. As simple as:

        type PackageGenerator interface {
            Generate(interface{}) (*spdx.Package, error)
        }

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