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@redhat.com> 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,BrianOn Fri, Nov 11, 2022 at 9:18 AM Jason Lee <jasondlee@redhat.com> 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@lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s_______________________________________________
wildfly-dev mailing list -- wildfly-dev@lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s