Hi Dan, Following up on this - let me know if you have any more thoughts/questions on it.
thanks, Robin. On Mon, 2 Mar 2026 at 12:18, Robin Moffatt <[email protected]> wrote: > Hi Dan, > > These are good questions, ones to which I don't necessarily have the > answers :) I'm looking to release managers to guide me here on what would > be good practice really. > > > How do we ensure that this doesn't become a problem for CI (looks like > it's report only right now, so a new CVE doesn't start failing all builds) > and how do we prevent releasing with CVEs that would then block publishing > the artifacts. > > My suggestion would be: > 1. PRs: Don't fail the build. Add a comment to the PR highlighting any > CVEs present. > 2. Push: Fail the build. Trivy supports .trivyignore [1] if we need to > override it for CVEs that do not apply > > > Is this all manual at this point (release manager needs to validate > CVEs)? > > CVEs introduced by dependency changes would get caught at the PR stage. > Newly disclosed CVEs against existing dependencies would show up on push > to main (or via a periodic scan if we add one), and RMs would need to > manually validate during the release process. > > WDYT? > > thanks, Robin. > > [1] https://trivy.dev/docs/latest/configuration/filtering/#trivyignore > > > > On Fri, 27 Feb 2026 at 17:31, Daniel Weeks <[email protected]> wrote: > >> I agree that if the CVE scan is a requirement for publishing, we should >> incorporate it into the CI/release process. >> >> However, I've run into situations in the past where CVE scanners flags >> things that do not apply and create friction during release. >> >> How do we ensure that this doesn't become a problem for CI (looks like >> it's report only right now, so a new CVE doesn't start failing all builds) >> and how do we prevent releasing with CVEs that would then block publishing >> the artifacts. >> >> Is this all manual at this point (release manager needs to validate CVEs)? >> >> I'm just trying to understand what this workflow will look like in >> practice. >> >> -Dan >> >> >> >> On Tue, Feb 24, 2026 at 6:45 AM Robin Moffatt via dev < >> [email protected]> wrote: >> >>> I've raised a second PR [1] that adds a trivy step to the existing Kafka >>> Connect workflow [2]. >>> This would flag CVEs both during PR CI (catching vulnerabilities in >>> current dependencies) and when a release candidate tag is created (catching >>> newly-disclosed CVEs against previously merged code). >>> >>> This PR and the previous one [3] are related but not dependent on each >>> other. >>> >>> thanks, Robin. >>> >>> [1]: https://github.com/apache/iceberg/pull/15430 >>> [2]: >>> https://github.com/apache/iceberg/blob/main/.github/workflows/kafka-connect-ci.yml >>> [3]: https://github.com/apache/iceberg/pull/15212 >>> >>> On Fri, 20 Feb 2026 at 15:02, Kevin Liu <[email protected]> wrote: >>> >>>> Sounds like a good idea to incorporate trivy. There are other apache >>>> projects using trivy as part of their build/publish step for docker >>>> containers. Heres one from apache/superset, >>>> https://github.com/apache/superset/blob/9f8b212ccc75308d019338fab642489bda00af3d/.github/workflows/docker.yml#L104-L119 >>>> >>>> We can emulate that in our pipeline >>>> >>>> On Fri, Feb 20, 2026 at 2:29 AM Robin Moffatt via dev < >>>> [email protected]> wrote: >>>> >>>>> Hi Dan, >>>>> Thanks for the review on the PR. >>>>> >>>>> One thing that's come up internally is that the Confluent team use >>>>> trivy [1] to scan for CVEs as a mandatory step before listing a >>>>> connector. >>>>> This has flagged CVEs previously (e.g. [2]) that needed patching. >>>>> >>>>> Can you suggest what the best way to incorporate this into the release >>>>> workflow might be? >>>>> As it stands, it's only the finalised release that's sent to Confluent >>>>> and then scanned; should the trivy step be further upstream in the release >>>>> process so that CVEs are patched before the final release is made? >>>>> >>>>> thanks, Robin. >>>>> >>>>> [1] https://trivy.dev/ >>>>> [2] https://github.com/apache/iceberg/pull/14985 >>>>> >>>>> On Thu, 19 Feb 2026 at 01:07, Daniel Weeks <[email protected]> wrote: >>>>> >>>>>> I'll take a look tomorrow. This would be great to land and validate >>>>>> with the 1.11 release. >>>>>> >>>>>> -Dan >>>>>> >>>>>> On Mon, Feb 16, 2026, 4:24 AM Robin Moffatt <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Hi Dan, >>>>>>> I've addressed your comments on the PR, could you take another look >>>>>>> please? >>>>>>> >>>>>>> Thanks, Robin >>>>>>> >>>>>>> On Fri, 6 Feb 2026 at 19:29, Daniel Weeks <[email protected]> wrote: >>>>>>> >>>>>>>> Hey Robin, >>>>>>>> >>>>>>>> Sorry for not responding to the last email, but this looks like the >>>>>>>> right approach. A couple small comments on the PR, but other than that >>>>>>>> this looks good. >>>>>>>> >>>>>>>> -Dan >>>>>>>> >>>>>>>> On Mon, Feb 2, 2026 at 9:02 AM Robin Moffatt via dev < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> I've reworked the process based on the feedback into: >>>>>>>>> 1. Add the Kafka Connect artifact to maven as part of gradle >>>>>>>>> release >>>>>>>>> 2. The version from Maven is what gets sent to Confluent Hub >>>>>>>>> >>>>>>>>> Please take a look: https://github.com/apache/iceberg/pull/15212 >>>>>>>>> >>>>>>>>> thanks, Robin. >>>>>>>>> >>>>>>>>> On Fri, 30 Jan 2026 at 06:37, Robin Moffatt <[email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Hi Daniel, >>>>>>>>>> >>>>>>>>>> I appreciate your input and guidance. I'd definitely missed the >>>>>>>>>> released artifacts and provenance angle here. >>>>>>>>>> >>>>>>>>>> So would the right direction here be to include the Kafka Connect >>>>>>>>>> artifact as part of the gradle release command? >>>>>>>>>> Then once the release has passed, the artifact on maven can be >>>>>>>>>> submitted to Confluent Hub directly by the release manager. >>>>>>>>>> >>>>>>>>>> If this sounds right I'm happy to put together a PR for it. >>>>>>>>>> >>>>>>>>>> thanks, Robin >>>>>>>>>> >>>>>>>>>> On Thu, 29 Jan 2026 at 22:23, Daniel Weeks <[email protected]> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> I added some comments to this effect in the PR, but it's >>>>>>>>>>> probably good to highlight this here. >>>>>>>>>>> >>>>>>>>>>> I don't think we should be generating new artifacts to upload to >>>>>>>>>>> connect/hub, but rather referencing the voted and released >>>>>>>>>>> artifacts that >>>>>>>>>>> are part of the release process. >>>>>>>>>>> >>>>>>>>>>> It might be good to include the instructions on how this fits >>>>>>>>>>> into the release process >>>>>>>>>>> <https://iceberg.apache.org/how-to-release/> so we understand >>>>>>>>>>> the full workflow along with the script. >>>>>>>>>>> >>>>>>>>>>> -Dan >>>>>>>>>>> >>>>>>>>>>> On Thu, Jan 29, 2026 at 6:24 AM Robin Moffatt via dev < >>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> Could I ask for input on this please, or a review of the PR[1]? >>>>>>>>>>>> >>>>>>>>>>>> thanks, Robin. >>>>>>>>>>>> >>>>>>>>>>>> [1] https://github.com/apache/iceberg/pull/15113 >>>>>>>>>>>> >>>>>>>>>>>> On Thu, 22 Jan 2026 at 17:20, Robin Moffatt <[email protected]> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> Currently, the version of the Iceberg connector for Kafka >>>>>>>>>>>>> Connect on Confluent Hub is outdated (1.9.2). Confluent staff >>>>>>>>>>>>> manually >>>>>>>>>>>>> uploaded it through an ad-hoc process, which we would like to help >>>>>>>>>>>>> the Apache Iceberg community formalise. >>>>>>>>>>>>> Previously, Tabular owned the connector, and its inclusion >>>>>>>>>>>>> in Confluent Hub was managed through the commercial partnership >>>>>>>>>>>>> between the >>>>>>>>>>>>> two companies. >>>>>>>>>>>>> >>>>>>>>>>>>> I've put together a draft PR [1] with a script that builds and >>>>>>>>>>>>> packages the connector for submission to Confluent Hub [2] (now >>>>>>>>>>>>> called >>>>>>>>>>>>> Confluent Marketplace). >>>>>>>>>>>>> >>>>>>>>>>>>> Please review the PR's proposed process, and let me know what >>>>>>>>>>>>> you think. I'm happy to liaise between the community and the >>>>>>>>>>>>> Confluent team >>>>>>>>>>>>> here to find a process that works for everyone. >>>>>>>>>>>>> >>>>>>>>>>>>> thanks, >>>>>>>>>>>>> Robin >>>>>>>>>>>>> >>>>>>>>>>>>> 1: https://github.com/apache/iceberg/pull/15113 >>>>>>>>>>>>> 2: https://hub.confluent.io >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>> >>>
