Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse.org-architecture-council] Adding SBOM Generation to Builds
Thanks for your thoughtful response, Krum. My apologies for the delay in responding.

The short version is that I'm actually looking to the Architecture Council for help on some of these issues. So I will answer many of your questions with questions of my own.

My comments are in-line...

On Thu, Oct 26, 2023 at 11:36 AM Tsvetkov, Krum via eclipse.org-architecture-council <eclipse.org-architecture-council@xxxxxxxxxxx> wrote:

Hi Wayne,

 

I spent some time to follow the recommendations and provide SBOM for Memory Analyzer. I tried to summarize my questions / feedback below.

I wasn’t sure if replying to the AC list is the appropriate way to give feedback – if you think this is spamming the list, let’s move this to an issue on the sbom project and continue the discussion there.

 

  • I’ve seen the announcement about a zoom session on the SBOM topic on 12 October, but couldn’t join. I cannot find the recording for it – sorry if I am asking questions which were already covered there

 
  • Somewhat unclear relation between dash-license and other SBOM generators – the handbook mentions dash-license both as a replacement for the IP logs, but also that the output of dash could be used as SBOM (for the moment?). I was unsure and added both to the build. Assuming at some moment sboms with cyclonedx or others would be required, will the dash-license tool integration still be needed (it does answer the question if a particular dependency is permitted for use within Eclipse, rather than simply listing the dependency)? I suppose it might be too early to answer this, but later we should try to be clearer.

I considered the output of the Eclipse Dash License Tool a stopgap between IP Logs and proper SBOMs. My thinking is that when we have good quality SBOMs, we don't need the DEPENDENCIES file.
 

  • Taking dash-license as an example, it was really straightforward to use both dash-license and cyclonedx and produce _some_ output – I don’t recall how I ended up looking into dash-license, but it is very helpful to point in the documentation to a specific project

I don't understand what you're asking. Do you mean that we should provide examples?
 
  • About the output – this is where I am still most uncertain.
    • I’ll need to give a short overview of what we are building, I hope this would make to following questions then clearer:
      • MAT is built with Tycho and what is produced by the project itself is a set of eclipse-plugins
      • We have an update site in the MAT downloads space – it includes only MAT’s plugins + a selection of BIRT plugins. We do aggregate all dependencies we need in our update site. These plugins are also contributed to the Simrel repo, but this is I guess a separate topic
      • We also build and provide for download a standalone RCP application
    • What should be the content of the sbom and how many sboms we need for the concrete MAT case?
      • The aggregated sbom of the tycho build seems to be the most useful one – although I think (still have to check in all-details) it contains a few dependencies more than what we actually package in the standalone product

Agreed
 
      • Should we try to produce a separate sbom for the update site? The aggregated one contains way more than what is provided on the update site. All dependencies would be resolved upon installation. I read https://gitlab.eclipse.org/eclipsefdn/emo-team/sbom/-/issues/3 as “we don’t need an sbom for the update-site”, but still wanted to double-check

Probably not. SBOMs for individual plug-ins don't actually make sense, IMHO. It's only after everything gets resolved that we actually know enough about versions of dependencies to generate any kind of meaningful SBOM. This is why I've been focussing on getting projects to provide complete (and correct) metadata. It's from this metadata that adopters will build SBOMs.

Let's move further discussion on this to the issue, please.
 
      • Should the sbom contain strictly only the pieces which are provided for download? MAT has a “works-with” dependency on IBM’s DTFJ libraries. We don’t package them within the standalone application and they are not provided on MAT’s download site. Should they be part of the SBOM (currently they are listed in it)

I think so.
 
      • Somewhat related to the previous point – the documentation (https://gitlab.eclipse.org/eclipsefdn/emo-team/sbom/-/blob/main/docs/sbom.adoc) states what maven scopes are selected by default and how they might be changed. I would rather expect a recommendation for Eclipse projects what should be selected (probably a few different examples if there are different use-cases). I was for example wondering if “includeCompileScope” should be selected or not for MAT

My thinking is that the compile scope should be included. This seems obvious to me, but I'm likely missing something important. If this warrants further discussion, please open an issue.
 
    • It would be helpful to have a few Eclipse specific recommendations/examples how to select the “projectType”, e.g. should we set it to application for our standalone MAT application (or for the EPP packages)? And if so, if a separate sbom is needed for the update-site, we’d need a different type there…

Agreed. Please open an issue. I think that most of our content is either "library" or "application" (maybe "framework").  This is an area where we'll need help from the AC.
 
    • Where should we put the output (sbom.json)? For now, it is just saved as build results and available from the Jenkins server (looked at dash)

For now, that you're generating them and making them available at all is great news. The Eclipse Dash License Tool also propagates them to repo.eclipse.org as an artifact (we got this for free). My expectation is that projects that push content to Maven Central will also push the SBOMs.

We're working on some solutions to centralise storage of SBOMs. We'll put this on the agenda for our next meeting and maybe open a separate thread.
 
  • It would be helpful to have a Tycho build example – so far, I haven’t done any config different than Dash (which is “plain” maven). But if we figure out that in order to get precise results with Tycho some specifics are needed, it would be helpful to have some tycho specific examples (or to point to a concrete project as an example)

This is where I reveal that I know nothing about Eclipse Tycho and need your help. We've been working with a couple of folks to come up with some meaningful ways of generating an SBOM for a product based on the Eclipse Platform; I'll see if we can line some of them up to present their findings.
 
  • About metadata
    • Currently the doc states something like “Specify all of the metadata” and some examples. Are all of these equally important, or are there pieces which are mandatory and some which are nice to have?

I'd love to hear what you and the rest of the AC think. https://gitlab.eclipse.org/eclipsefdn/emo-team/sbom/-/issues/8
 
    • I think it would be helpful to have some specific examples in the context of Eclipse

I believe that the advice that we've been giving is to use the project's formal name.
 
      • Issues – an example for Bugzilla (as long as sboms requirements are rolled out before the deprecation)

 
    • I didn’t understand if license information in the MANIFEST.MF files is mandatory (it was missing in our pom.xml files, and I’ll add it there, and we have it in about files)

My thinking is that we should be putting all required metadata in the OSGi MANIFEST. In the context of an OSGi bundle, the pom.xml file is a build artifact, right?

https://gitlab.eclipse.org/eclipsefdn/emo-team/sbom/-/issues/10
 

 

These are the things I thought abouts so far. Hope this sbom-newbie view helps :-)


It helps. Thanks again.
 

 

Krum

 

From: Wayne Beaton
Date: Thursday, 5. October 2023 at 14:09
To: eclipse.org-architecture-council <eclipse.org-architecture-council@xxxxxxxxxxx>
Subject: Re: [eclipse.org-architecture-council] Adding SBOM Generation to Builds

My apologies.

 

Here's the link:

 

 

I also attempted to include a link to one specific issue: SBOMs don't make sense for individual Eclipse Platform Plug-ins.

 

I swear that I'm getting worse at this.

 

/shakes head

 

Wayne

 

On Thu, Oct 5, 2023 at 3:36 AM Tsvetkov, Krum via eclipse.org-architecture-council <eclipse.org-architecture-council@xxxxxxxxxxx> wrote:

Hi Wayne,

 

could you share a link to the assembled documentation? Sorry if I missed when it was shared, but I can’t anything besides the short info in the handbook.

 

> For those of you who have familiarity with the space...

I have no deep understanding in the topic, but I could at least give some feedback as “the unexperienced user of the docs”.  Last week I tried to get the Memory Analyzer build to produce an SBOM [1] (by copying what was done in the Dash project). It was straightforward to get “something” generated, but that also raised a few questions, so I could see if I get answers to some of these in the documentation you mentioned.

 

Regards

Krum

 

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=582480

 

From: eclipse.org-architecture-council <eclipse.org-architecture-council-bounces@xxxxxxxxxxx> on behalf of Wayne Beaton via eclipse.org-architecture-council <eclipse.org-architecture-council@xxxxxxxxxxx>
Date: Thursday, 5. October 2023 at 04:19
To: eclipse.org-architecture-council <eclipse.org-architecture-council@xxxxxxxxxxx>
Subject: [eclipse.org-architecture-council] Adding SBOM Generation to Builds

Hey Architecture Council.

We need your help.

We've discussed options for automating the construction of SBOMs, but our efforts in this regard have not delivered as we had hoped. At this point, we've come to the conclusion that we need to have some help from our project teams to generate them.

At this point, our main focus is to just generate the SBOMs. How and where we make them available to others is also a requirement, but we'll need to defer that for now. This means that anything that we decide now may need to be revised. This is likely going to be an incremental effort.

We've assembled some documentation to describe how to create SBOMs and need your help to make sure that it is correct and complete. We have what I believe is pretty comprehensive documentation to create SBOMs for Maven-based builds of Java libraries and for NPM components, leveraging existing tools.

For those of you who have familiarity with the space... our focus has been on generating CycloneDX SBOMs. We're equally interested in SPDX SBOMs and invite your assistance if you have a particular affinity for SPDX.

Since the tools that we're using generate SBOMs based on metadata, an important first step is that effort be undertaken to ensure that the metadata is complete. This means that things that are not consistently specified in pom.xml files like licenses, need to be specified. We've provided specific advice in the documentation.

We haven't done a lot of work with Eclipse Platform/OSGi content yet; any help that you can provide would be... well... helpful.

So, here's the request... Can you have a look at the content that we've produced, try to apply it to some subset of the projects that you work with, and report back any interesting discoveries, concerns, or issues that you encounter as issues here. If this request sounds a little open-ended or half-baked, that’s because it is. We need your help to move this to a point where we can start working with the general committer community to make this happen.

We've been tinkering with a few repositories, so you might also get copied on a pull request here or there.

Let's also add this as an agenda topic on our next couple of meetings/calls.

 

Wayne and Mikael


--

Wayne Beaton

Director of Open Source Projects | Eclipse Foundation

 

My working day may not be your working day! Please don’t feel obliged to read or reply to this e-mail outside of your normal working hours.

_______________________________________________
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/eclipse.org-architecture-council



--

Wayne Beaton

Director of Open Source Projects | Eclipse Foundation



My working day may not be your working day! Please don’t feel obliged to read or reply to this e-mail outside of your normal working hours.

_______________________________________________
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/eclipse.org-architecture-council


--

Wayne Beaton

Director of Open Source Projects | Eclipse Foundation


My working day may not be your working day! Please don’t feel obliged to read or reply to this e-mail outside of your normal working hours.

Back to the top