mailarchive of the ptxdist mailing list
 help / color / mirror / Atom feed
From: Michael Olbrich <m.olbrich@pengutronix.de>
To: Simon Falsig <sfalsig@verity.net>
Cc: "Alexander Dahl" <ada@thorsis.com>,
	"ptxdist@pengutronix.de" <ptxdist@pengutronix.de>,
	"Jiři Vaněk" <jvanek@verity.net>
Subject: Re: [ptxdist] SBOM support
Date: Fri, 8 Sep 2023 20:38:30 +0200	[thread overview]
Message-ID: <ZPtqJgSISLNERZv5@pengutronix.de> (raw)
In-Reply-To: <GV0P278MB0784CE3EC43B779335727332CBEDA@GV0P278MB0784.CHEP278.PROD.OUTLOOK.COM>

Hi,

On Fri, Sep 08, 2023 at 09:05:26AM +0000, Simon Falsig wrote:
> Thanks for your reply! I've never used Buildroot, so really good with some hints as to how
> others solve this.
> 
> >>    My suggestion would be to add a _CPE variable to each package (built from
> >>    whatever other variables make sense, typically _VERSION). I managed to add this
> >>    for the fast report (extracting it to pkg_cpe in rules/post/ptxd_make_world_common.make,
> >>    and adding it to the report in scripts/lib/ptxd_make_world_report.sh), but I
> >>    wouldn't be surprised if there are other places/report that need to track this
> >>    also for consistency?
> >>    Packages that specify _CPE would then have this included in their report, and
> >>    there'd be no change for the packages that don't specify it.
> >
> > As far as I know buildroot [1] already has support for this.  They construct this from
> > defaults and override it with several different variables if defaults are not sufficient
> > for a particular project:
> >
> > <PKG>_CPE_ID_VENDOR
> > <PKG>_CPE_ID_VERSION
> > <PKG>_CPE_ID_UPDATE
> > <PKG>_CPE_ID_PRODUCT
> >
> > And maybe more?  Some quirks handling like this is probably necessary in ptxdist, too?
> >
> > Greets
> > Alex
> 
> I see - Buildroot essentially automatically creates the CPE based on existing data in the
> package, and that can then be overridden if needed. I guess the benefit is that this in
> many cases works directly out of the box without any further configuration - but with the
> risk that a wrong CPE is generated.

What would be a wrong CPE? I know very little about this, but I assume,
that would be something like the wrong string for vendor/product, etc. We
need to use the same as everybody else, so matching is possible, right?

Are there any machine readable list we can use to validate this? That would
help with review and maintenance.

Anyways, the report should not included any automatically created CPE. It
should contain all the data to assemble those anyways, so it could be an
optional part of the SBOM creation.

> (From what I can see, ptxdist doesn't really provide any variable that can be extracted for
> the VENDOR field though?)

For open source projects, a vendor often makes very little sense. What is
used in such cases anyways?

> Explicitly specifying the CPE in each package would lower the risk of getting wrong CPEs, as
> you'd instead just not get a CPE for packages that don't specify it.

As I said, it could be optional. I don't know enough about this to decide
either way.

> Personally, I'd probably lean towards the latter (rather no CVE than a wrong one) for our
> usecase, but would be open to other ways if that can mean getting this upstreamed?

I think an option would be good to start with. That way we can see if
anything useful is created and you can disable it without any patches.

Michael

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |



  reply	other threads:[~2023-09-08 18:38 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-07 15:03 Simon Falsig
2023-09-07 16:24 ` Alexander Dahl
2023-09-08  9:05   ` Simon Falsig
2023-09-08 18:38     ` Michael Olbrich [this message]
2023-09-13 15:42       ` Simon Falsig
2023-09-08 18:22 ` Michael Olbrich
2023-09-11 13:11   ` Gavin Schenk
2023-09-11 17:08     ` Christian Melki
2023-09-13 16:05     ` Simon Falsig
2024-02-19 16:54 ` Simon Falsig
2024-03-01  7:34   ` Simon Falsig
2024-03-04 16:09   ` Michael Olbrich
2024-03-08 16:02     ` Simon Falsig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZPtqJgSISLNERZv5@pengutronix.de \
    --to=m.olbrich@pengutronix.de \
    --cc=ada@thorsis.com \
    --cc=jvanek@verity.net \
    --cc=ptxdist@pengutronix.de \
    --cc=sfalsig@verity.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox