mailarchive of the ptxdist mailing list
 help / color / mirror / Atom feed
From: Simon Falsig <sfalsig@verity.net>
To: "ptxdist@pengutronix.de" <ptxdist@pengutronix.de>
Subject: Re: [ptxdist] [PATCH] RFC: ptxd_make_world: Extract CPE for packages
Date: Mon, 18 Sep 2023 14:37:48 +0000	[thread overview]
Message-ID: <GV0P278MB0784D42CBEB10B4C3C7148E2CBFBA@GV0P278MB0784.CHEP278.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <ZQQ0Tj+oIFGMPsh3@pengutronix.de>

Hi Michael,

> From: ptxdist <ptxdist-bounces@pengutronix.de> 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 <sfalsig@verity.ch>
> >
> > 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.
> >
> > Constructed CPEs are validated against the official CPE regex.
> >
> > The CPE (Common Platform Enumerator) allows matching CVEs to specific
> > packages, and see if these apply to a specific deployment.
> > ---
> >  rules/post/ptxd_make_world_common.make |  4 ++++
> > scripts/lib/ptxd_make_world_report.sh  | 29 ++++++++++++++++++++++++++
> >  2 files changed, 33 insertions(+)
> >
> > diff --git a/rules/post/ptxd_make_world_common.make
> > b/rules/post/ptxd_make_world_common.make
> > index 08120607a..0804f0b81 100644
> > --- a/rules/post/ptxd_make_world_common.make
> > +++ b/rules/post/ptxd_make_world_common.make
> > @@ -78,6 +78,10 @@ world/env/impl = \
> >     pkg_PKG="$(call ptx/escape,$(1))"                                       \
> >     pkg_pkg="$(call ptx/escape,$($(1)))"                                    \
> >     pkg_version="$(call ptx/escape,$($(1)_VERSION))"                        \
> > +   pkg_cpe_vendor="$(call ptx/escape,$($(1)_CPE_VENDOR))"
>       \
> > +   pkg_cpe_product="$(call ptx/escape,$($(1)_CPE_PRODUCT))"                \
> > +   pkg_cpe_version="$(call ptx/escape,$($(1)_CPE_VERSION))"                \
> > +   pkg_cpe="$(call ptx/escape,$($(1)_CPE))"                                \
> >     pkg_config="$(call ptx/escape,$($(1)_CONFIG))"                          \
> >     pkg_ref_config="$(call ptx/escape,$($(1)_REF_CONFIG))"
>       \
> >     pkg_path="$(call ptx/escape,$($(1)_PATH))"                              \
> > diff --git a/scripts/lib/ptxd_make_world_report.sh
> > b/scripts/lib/ptxd_make_world_report.sh
> > index dbdae5736..11f17b405 100644
> > --- a/scripts/lib/ptxd_make_world_report.sh
> > +++ b/scripts/lib/ptxd_make_world_report.sh
> > @@ -31,6 +31,30 @@ ptxd_make_world_report_yaml() {
> >         awk "BEGIN { RS=\" \" } { if (\$1) print \"- '\" \$1 \"'\" }"
> <<<"${2}"
> >     fi
> >      }
> > +    do_build_cpe() {
> > +        prefix="${1}"
> > +        cpe="${2}"
> > +        vendor="${3}"
> > +        product="${4}"
> > +        version="${5}"
> > +        if [ -n "${cpe}" ]; then
> > +            # If a cpe is fully specified, then use that
> > +            :
> > +        elif [ -n "${vendor}" -a -n "${product}" -a -n "${version}" ];
> then
> > +            # Otherwise, if we have vendor, product and version, then
> build a CPE2.3 string from it
> > +
> cpe="cpe:2.3:a:${vendor}:${product}:${version}:*:*:*:*:*:*:*"
> > +        fi
>
> Hmmm, I think we should preserve the original data in the report. Building
> the cpe string should happen in the SBOM script. So:
>
>   cpe: ....
>
> or:
>
>   cpe-vendor: ...
>   cpe-product: ...
>
> and maybe:
>
>   cpe-version: ...
>

Makes sense - changed.

> > +        if [ -n "$cpe" ]; then
> > +            # Validate the resulting CPE string
> > +            # Regex taken from:
> https://csrc.nis/
> t.gov%2Fschema%2Fcpe%2F2.3%2Fcpe-
> naming_2.3.xsd&data=05%7C01%7Csfalsig%40verity.net%7Cc9dea8f344e64c0f2a570
> 8dbb5daf98c%7C06487c727d884632bf56071603defa0a%7C1%7C0%7C63830372431499528
> 3%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1h
> aWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RQxWOHS3iGwu%2BUXaR%2Bc1FZRzo4rHk
> XX8U4fjSmWtalQ%3D&reserved=0
> > +            if echo "$cpe" | grep -Eq 'cpe:2\.3:[aho\*\-
> ](:(((\?*|\*?)([a-zA-Z0-9\-
> \._]|(\\[\\\*\?!"#$$%&'\''\(\)\+,/:;<=>@\[\]\^`\{\|}~]))+(\?*|\*?))|[\*\-
> ])){5}(:(([a-zA-Z]{2,3}(-([a-zA-Z]{2}|[0-9]{3}))?)|[\*\-
> ]))(:(((\?*|\*?)([a-zA-Z0-9\-
> \._]|(\\[\\\*\?!"#$$%&''\''\(\)\+,/:;<=>@\[\]\^`\{\|}~]))+(\?*|\*?))|[\*\-
> ])){4}'; then
> > +                echo "${prefix} ${cpe}"
> > +            else
> > +                >&2 echo "Error! $cpe is not valid CPE format string"
> > +                return 1
> > +            fi
>
> Hmmm, I'm not sure where the validation should take place. Here or the
> SBOM script. I don't mind either way.
>

I've switched to do the validation in the SBOM script. Matches better with
having the original cpe_... values in the individual reports, then building
and validating the complete CPE when doing the full report.

> FYI, your indention is wrong. Please check the rest of the script. I know
> the style is a bit strange, but lets keep things consistent.

Argh, sorry. I've tried fixing things up now - hope it's good!

>
> Michael

Thanks for the input!
 - Simon




      parent reply	other threads:[~2023-09-18 14:37 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-13 16:05 [ptxdist] [PATCH 1/3] " Simon Falsig
2023-09-13 16:05 ` [ptxdist] [PATCH 2/3] RFC: Add CPE for a few packages Simon Falsig
2023-09-15 10:15   ` [ptxdist] [PATCH] " Simon Falsig
2023-09-13 16:05 ` [ptxdist] [PATCH 3/3] RFC: sbom_report: Add support Simon Falsig
2023-09-18 14:33   ` [ptxdist] [PATCH] " Simon Falsig
2023-10-21 13:52     ` Bruno Thomsen
2023-11-03  7:34       ` Simon Falsig
2023-09-13 21:16 ` [ptxdist] [PATCH 1/3] RFC: ptxd_make_world: Extract CPE for packages Christian Melki
2023-09-14  6:46   ` Simon Falsig
2023-09-15 10:14   ` [ptxdist] [PATCH] " Simon Falsig
2023-09-15 10:39     ` Michael Olbrich
2023-09-18 14:29       ` Simon Falsig
2023-09-18 14:37       ` Simon Falsig [this message]

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=GV0P278MB0784D42CBEB10B4C3C7148E2CBFBA@GV0P278MB0784.CHEP278.PROD.OUTLOOK.COM \
    --to=sfalsig@verity.net \
    --cc=ptxdist@pengutronix.de \
    /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