> From: Michael Olbrich
> Sent: Monday, March 4, 2024 17:09
> Hi,
>
> On Mon, Feb 19, 2024 at 04:54:16PM +0000, Simon Falsig wrote:
> > > I'd be happy to get a bit of initial feedback on the approach. I'll
> > > have a look at putting up some initi
> Hi,
>
> > I'd be happy to get a bit of initial feedback on the approach. I'll
> > have a look at putting up some initial patches in the coming days too.
> >
> > Thanks in advance and best regards,
>
> Sorry for the silence around this, but I've been busy with other things in
> the last months.
This provides support for building SBOMs in CycloneDX format.
A target is added alongside the other reports, that (based on the
fast-bsp-report) extracts name, version, cpe and license of each target
package, and puts these into a final sbom-report in CycloneDX/JSON
format.
This requires a
Just to see how this could look for a handful of packages. Note that all
of these have a different way of specifying the vendor ID (one is
$PACKAGE_project, one is just $PACKAGE, one is something completely
different).
---
rules/acl.make| 1 +
rules/busybox.make| 2 ++
If a package specifies a CPE or CPE_VENDOR and CPE_PRODUCT, this is
extracted into the fast report for that package. If no CPE is
specified, or not both of CPE_VENDOR and CPE_PRODUCT, then no value is
added.
By default, the existing VERSION is used, but can be overridden with
CPE_VERSION.
Hi,
> I'd be happy to get a bit of initial feedback on the approach. I'll have a
> look at putting up some initial patches in the coming days too.
>
> Thanks in advance and best regards,
Sorry for the silence around this, but I've been busy with other things in
the last months.
Finally managed
> -Original Message-
> From: Bruno Thomsen
> Sent: Saturday, October 21, 2023 15:52
> Subject: Re: [ptxdist] [PATCH] RFC: sbom_report: Add support
>
> Den man. 18. sep. 2023 kl. 16.34 skrev Simon Falsig :
> >
> > From: Simon Falsig
> >
> >
Hi Michael,
> From: ptxdist On Behalf Of Michael
> Olbrich
> Sent: Friday, September 15, 2023 12:39
>
> On Fri, Sep 15, 2023 at 12:14:30PM +0200, Simon Falsig wrote:
> > From: Simon Falsig
> >
> > If a package specifies a CPE or CPE_VENDOR and CPE_PRODUCT, th
From: Simon Falsig
This provides support for building SBOMs in CycloneDX format.
A target is added alongside the other reports, that (based on the
fast-bsp-report) extracts name, version, cpe and license of each target
package, and puts these into a final sbom-report in CycloneDX/JSON
format
From: Simon Falsig
If a package specifies a CPE or CPE_VENDOR and CPE_PRODUCT, this is
extracted into the fast report for that package. If no CPE is
specified, or not both of CPE_VENDOR and CPE_PRODUCT, then no value is
added.
By default, the existing VERSION is used, but can be overridden
From: Simon Falsig
Just to see how this could look for a handful of packages. Note that all
of these have a different way of specifying the vendor ID (one is
$PACKAGE_project, one is just $PACKAGE, one is something completely
different).
---
rules/acl.make| 1 +
rules/busybox.make
From: Simon Falsig
If a package specifies a CPE or CPE_VENDOR and CPE_PRODUCT, this is
extracted into the fast report for that package. If no CPE is
specified, or not both of CPE_VENDOR and CPE_PRODUCT, then no value is
added.
By default, the existing VERSION is used, but can be overridden
Hi Christian,
> From: Christian Melki
> Sent: Wednesday, September 13, 2023 23:17
>
> On 9/13/23 18:05, Simon Falsig wrote:
> > From: Simon Falsig
> >
> > If a package specifies a CPE, this is extracted into the fast report
> > for that package. If no CPE
From: Simon Falsig
This provides support for building SBOMs in CycloneDX format.
A target is added alongside the other reports, that (based on the
fast-bsp-report) extracts name, version, cpe and license of each target
package, and puts these into a final sbom-report in CycloneDX/JSON
format
From: Simon Falsig
Just to see how this could look for a handful of packages. Note that all
of these have a different way of specifying the vendor ID (one is
$PACKAGE_project, one is just $PACKAGE, one is something completely
different).
---
rules/acl.make| 1 +
rules/busybox.make
From: Simon Falsig
If a package specifies a CPE, this is extracted into the fast report for
that package. If no CPE is specified, then no value is added.
The CPE (Common Platform Enumerator) allows matching CVEs to specific
packages, and see if these apply to a specific deployment.
---
rules
Hi Gavin, Michael,
> From: Gavin Schenk
> Sent: Monday, September 11, 2023 15:11
> Hi,
>
> > On Thu, Sep 07, 2023 at 03:03:47PM +, Simon Falsig wrote:
> >> I saw a post from 2021 to the mailing list on generating SBOMs from
> ptxdist.
> &
Hi Michael,
> From: Michael Olbrich
> Sent: Friday, September 8, 2023 20:39
>
> Hi,
>
> On Fri, Sep 08, 2023 at 09:05:26AM +, Simon Falsig wrote:
> > Thanks for your reply! I've never used Buildroot, so really good with
> > some hints as to how other
Hi Alex,
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
>>
Hi,
I saw a post from 2021 to the mailing list on generating SBOMs from ptxdist.
Has there been any further work on this?
We've been looking at implementing this internally - plan would be to generate
the SBOM in CycloneDX format, and consume it with Dependency-Track
Instead of always building the index with the default md5sum, the index
will now be built with sha256, iff the target opkg package is
configured to support sha256.
Also, the ipkg support in ipkg-push has been removed, and it now always
uses the opkg tools instead. The name is kept, since
>
> Looks good, but something broke all white-spaces, to the patch cannot be
> applied.
>
Hmm - probably Outlook messing up things... I'll try a v2 through git
send-email instead...
___
ptxdist mailing list
ptxdist@pengutronix.de
Instead of always building the index with the default md5sum, the index
will now be built with sha256, iff the target opkg package is
> > +choice
> > + prompt "checksum type"
> > + default IMAGE_IPKG_CHECKSUM_MD5
> > + help
> > + Sets the checksum type to use when generating the index,
> > + both when pushing to a repository and in PKGDIR.
> > + Note that opkg on the target may need to
> > + @$(HOST_ENV) $(PTXDIST_TOPDIR)/scripts/opkg-push \
> > + @$(HOST_ENV) $(PTXDIST_TOPDIR)/scripts/opkg-push \
...I'm off to a good start here...:/ Turns out I messed up the initial commit -
the above lines should of course call ipkg-push instead. Let me know if there's
anything
> --- a/rules/post/image_ipkg.make
> +++ b/rules/post/image_ipkg.make
> @@ -19,13 +19,24 @@ ifdef PTXCONF_IMAGE_IPKG_FORCED_PUSH
> rm -rf "$(IMAGE_REPO_DIST_DIR)"
> endif
> @echo "pushing ipkg packages to ipkg-repository..."
> - @$(HOST_ENV)
> > Judging from the ipkg-push file, it's made to support not just opkg, but
> > also ipkg, which I don't think supports the SHA256 checksum. So just
> > blindly adding the checksum parameter to the commandline would not
> > maintain the generic support. On the other hand, I haven't found any
> >
This allows the checksum type used when creating the pacakge index to
be set in the platformconfig. Currently supported types are md5 (the
default), and sha256.
md5 is kept as default, since the target opkg package needs to be
specifically configured to be built with sha256 support.
Also, the
ipkg-push to
${TYPE}-make-index
- Pull index generation out of ipkg-push, and let it be done by image_ipkg.make
instead (which seems to be the only other place that is currently calling any
of the -make-index functions)
- Something entirely different
Any input is welcome! Thanks in advance!
Si
client)
instead?
Am I overlooking something obvious here, or does this just not make sense?
Thanks and best regards,
Simon Falsig
___
ptxdist mailing list
ptxdist@pengutronix.de
30 matches
Mail list logo
