[wildfly-dev] Re: Importing 3rd Party Boms?

Let me ask the future looking question of what should be the policy when we have to start generating SBOMs? Perhaps Stuart can chime in how HACBS is experiencing this issue. On Nov 11, 2022 at 10:00:20 AM, Brian Stansberry < brian.stansberry(a)redhat.com&gt; wrote: > I don't think we have a formal policy re this, although it's possible we > do and it's just been followed so long that in my mind 'policy' and > 'current practice' have blended into one in my head. ;) > > Let's think about it in terms of what our requirements should be, and > then the technical solution needs to follow that agreed upon requirements. > Some thoughts I have: > > 1) The process we use for defining dependencies needs to be solid and > unambiguous. If someone understands how we do it they should be able to > work out what versions are used by the server. Without having to use > mvn dependency:tree mvn help:effective-pom etc. Using those might be the > fast way to check what we use, but someone who understands what we do > should be able to figure it out from looking at poms. > > 2) A nice-to-have is making things relatively simple, i.e. 'someone who > understands what we do' shouldn't be limited to a handful of gurus. At > least any lead for a WFLY / WFCORE JIRA component should understand. > > 3) We import a bom from WildFly Core and what we import should take > precedence over anything else, except for an explicit declaration of a > specific GAV in wildfly's boms. IOW if Core says foo:bar:1.2.3 and an otel > bom said foo.bar:1.2.4, then core wins, and use of 1.2.4 requires an > explicit entry for that GAV. > > 4) If we change the WildFly component set we should have a JIRA that > describes what actual components changed, not just that there was a bom > update. (If project X produces 5 components as part of the same release we > don't need to list them all, but if an imported bom updates X and also its > dependency Y, we need the JIRA to note X and Y, not just 'X bom update'. > > 5) The PR for the update should also be explicit about what artifacts are > upgraded, beyond the obvious one (i.e. X in my example in #4.) This makes > it efficient to ask component leads for other uses of the affected libs > (i.e. Y) if the update is ok. > > 6) We should continue to add the RN or git diff into to the JIRAs, the > way we have over the last couple years. I find that very useful, but won't > blab on about why. ;) > > 7) We need to be able to exclude transitive dependencies to avoid > ambiguity in what we support, to avoid things creeping into end user > boms or getting irrelevant CVE scanner hits for things we don't even use. > > HTH, > > Brian > > On Fri, Nov 11, 2022 at 9:18 AM Jason Lee <jasondlee(a)redhat.com&gt; wrote: > >> Do we have a policy on importing third party boms (in >> boms/common-ee/pom.xml, for example)? The OpenTelemetry project provides a >> BOM to help synchronize artifact versions. I'm currently declaring >> dependency with explicit versions (controlled by a Maven property, of >> course) for each dependency. Things get tricky for otel as some artifacts >> are $VERSION and some are ${VERSION}-alpha. Using a BOM would make that >> transparent (as well as making the eventual transition from -alpha to ga >> transparent). >> >> I don't see any BOMs being imported, so I thought I'd ask before I tried >> to be first. :) >> >> Jason Lee >> >> Principal Software Engineer >> >> Red Hat JBoss EAP >> >> _______________________________________________ >> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org >> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org >> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s > > > > _______________________________________________ > wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org > To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s >