Robin, I think we should probably just go with the non-blocking approach initially and see if there's any real friction. Maybe the 1.11 release would be a good candidate to test this workflow with.
If we complete a release but find a vulnerability before pushing the artifacts, we could follow up quickly with a patch release. -Dan On Mon, Mar 9, 2026 at 2:26 AM Robin Moffatt via dev <[email protected]> wrote: > 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 >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>> >>>> >
