+1 On Sun, Nov 8, 2026 at 2:19 PM Wenchen Fan <[email protected]> wrote:
> +1 > > On Sat, Nov 7, 2026 at 6:13 PM Jungtaek Lim <[email protected]> > wrote: > >> Bumping this, since I just figured out we do not do this today while we >> look to be in a sort of reaching consensus. >> >> Should we update AGENT.md to check the release date for the dependency >> upgrade and block it? Hand-written code change can bypass it, but AI review >> would point it out again. If some area is unclear from the discussion e.g. >> transitive dependencies being pulled from Apache project, that could be >> left as it is, say, agent to only concern about direct dependency the code >> change is about to change (and Apache projects to be excluded, though I >> don't know whether this is really necessary.) >> >> >> On Thu, Apr 23, 2026 at 10:18 PM Wenchen Fan <[email protected]> wrote: >> >>> > we may want to extend our exceptions to include all ASF project >>> releases >>> >>> I think it's a good idea to avoid cascading the delay, but for now we >>> are still discussing this delay for Spark, so there is no real cascading >>> today. We can revisit this if many Apache projects start to delay >>> dependency upgrades as well. >>> >>> On Thu, Apr 23, 2026 at 9:13 PM Steve Loughran <[email protected]> >>> wrote: >>> >>>> >>>> The "malicious release manager" is an interesting attack, one that the >>>> ASF "we trust the community" doesn't defend against. The risk here is that >>>> someone generates a set of malicious artifacts (maybe just publishes them >>>> to maven), while the source code is safe. >>>> >>>> To help defend against this, here's some code which will do a >>>> bytecode-level diff between JARs, ignoring debugging stuff, generated >>>> metadata etc. Enjoy >>>> >>>> https://github.com/steveloughran/auditor >>>> >>>> This wouldn't defend against someone adding a malicious dependency to >>>> the artifacts they publish on maven, so really the tool should audit that >>>> too. But you can at least check out a spark branch, build the binaries and >>>> then audit the RC's artifacts against them to look for tangible variations. >>>> >>>> On Wed, 22 Apr 2026 at 23:53, Tian Gao via dev <[email protected]> >>>> wrote: >>>> >>>>> So are you suggesting that we don't enforce this 1-week buffer for all >>>>> Apache projects? I agree that a legitimate Apache project release is >>>>> well-vetted and generally safe, but there could be situations where a >>>>> release is maliciously executed by stealing identities of people who have >>>>> access to make releases - that's where many supply chain attacks occur. >>>>> Moreover, it would be more difficult to enforce this (whether for LLM or >>>>> for human) to treat Apache projects differently. Also I think a 7-day >>>>> delay >>>>> to accept an Apache project release is not a big deal for us. >>>>> >>>>> Regarding the Spark-related projects, we don't need to enforce the >>>>> policy for them. >>>>> >>>>> I think for supply chain attacks, we are defending ourselves not only >>>>> against package developers, but more importantly, we are defending >>>>> ourselves against potential loopholes in the release process. We must >>>>> assume that there could be something wrong during the release process of >>>>> any project. >>>>> >>>>> Tian >>>>> >>>>> On Wed, Apr 22, 2026 at 3:32 PM Dongjoon Hyun <[email protected]> >>>>> wrote: >>>>> >>>>>> To be clear, this discussion should be applied to Apache Spark main >>>>>> repository only. >>>>>> >>>>>> https://github.com/apache/spark >>>>>> >>>>>> It's because subprojects need to consume Apache Spark releases ASAP. >>>>>> For example, Apache Spark K8s Operator will upgrade its dependency on the >>>>>> same day of Apache Spark release because we trust our release process >>>>>> (including vote). >>>>>> >>>>>> In addition, probably, we may want to extend our exceptions to >>>>>> include all ASF project releases (Apache Hadoop, Avro, Parquet, ORC, >>>>>> Kafka, >>>>>> ...) which have established community vote process. >>>>>> >>>>>> Dongjoon. >>>>>> >>>>>> On 2026/04/22 22:21:41 Dongjoon Hyun wrote: >>>>>> > Thank you for the suggestion. >>>>>> > >>>>>> > +1 for the general predefined (1-week) grace-period policy sounds >>>>>> good to me. >>>>>> > >>>>>> > For the exception cases, I believe we can let the PMC members make >>>>>> the final decision on merge timing like the PMC members decides the >>>>>> `Blocker` level priority of JIRA issues already. >>>>>> > >>>>>> > If we have a voted policy, it would be great if we can add the >>>>>> policy to AGENTS.md explicitly to apply the policy from the PR steps. >>>>>> > >>>>>> > Best, >>>>>> > Dongjoon. >>>>>> > >>>>>> > On 2026/04/22 20:47:24 Steve Loughran wrote: >>>>>> > > 7 days is long enough to catch most (all?) malicious attacks. >>>>>> > > >>>>>> > > Regarding developers, there's a strong case to be made for only >>>>>> doing >>>>>> > > builds and especially tests in isolated containers, even though >>>>>> artifacts >>>>>> > > will leak across shared containers through a shared maven repo. >>>>>> It still >>>>>> > > limits the damage malicious binaries can do. >>>>>> > > >>>>>> > > On Tue, 21 Apr 2026 at 23:58, Jungtaek Lim < >>>>>> [email protected]> >>>>>> > > wrote: >>>>>> > > >>>>>> > > > +1 >>>>>> > > > >>>>>> > > > We tend to consider that merging to master branch gives some >>>>>> time to bake >>>>>> > > > before releasing. But we (Spark devs) are people who build >>>>>> Spark and >>>>>> > > > run some tests against the master branch almost day to day. For >>>>>> us, there >>>>>> > > > is literally no time for these library upgrades to be baked - >>>>>> we are >>>>>> > > > exposed to any kind of potential CVE from these library >>>>>> upgrades. >>>>>> > > > >>>>>> > > > It's arguable whether we should stay up to date with the recent >>>>>> release >>>>>> > > > version for dependencies, but that'd probably be uneasy to make >>>>>> consensus; >>>>>> > > > there is a clear trade-off. The current proposal sounds to me >>>>>> as a good >>>>>> > > > compromise - IMHO delaying by 2 weeks (14 days) seems >>>>>> reasonable, but >>>>>> > > > strict 1 week (7 days) is better than nothing if anyone is >>>>>> concerned 2 >>>>>> > > > weeks is too long. >>>>>> > > > >>>>>> > > > On Tue, Apr 21, 2026 at 9:45 PM Szehon Ho < >>>>>> [email protected]> wrote: >>>>>> > > > >>>>>> > > >> +1 make sense to me as well. We should of course be fast for >>>>>> security >>>>>> > > >> upgrades, but make sense to avoid such eager upgrades for the >>>>>> rest of >>>>>> > > >> the hundreds of Spark dependencies, due to the increased >>>>>> supply chain >>>>>> > > >> attack risks in the ecosystem. >>>>>> > > >> >>>>>> > > >> Thanks >>>>>> > > >> Szehon >>>>>> > > >> >>>>>> > > >> On Tue, Apr 21, 2026 at 3:32 AM Wenchen Fan < >>>>>> [email protected]> wrote: >>>>>> > > >> >>>>>> > > >>> Thanks for starting this discussion! I did a data analysis a >>>>>> while ago >>>>>> > > >>> but didn't have time to act on it. The analysis shows: >>>>>> > > >>> >>>>>> > > >>> *58* maven dep upgrades in the last 3 months. >>>>>> > > >>> *46%* (27/58) within 7 days of release >>>>>> > > >>> ≤7d : 27 / 58 (47%) >>>>>> > > >>> 8d–30d : 12 / 58 (21%) >>>>>> > > >>> >30d : 19 / 58 (32%) >>>>>> > > >>> >>>>>> > > >>> You can find the raw data in the attached file. This does >>>>>> look a bit >>>>>> > > >>> aggressive. I build Spark locally everyday, and I believe I'm >>>>>> not the only >>>>>> > > >>> one. Having a couple of weeks as the buffer time is a good >>>>>> idea to protect >>>>>> > > >>> developers like me from potential supply chain attacks. >>>>>> > > >>> >>>>>> > > >>> On Tue, Apr 21, 2026 at 6:24 AM Hyukjin Kwon < >>>>>> [email protected]> >>>>>> > > >>> wrote: >>>>>> > > >>> >>>>>> > > >>>> SGTM I think it's good practice to give a couple of weeks >>>>>> before the >>>>>> > > >>>> upgrade >>>>>> > > >>>> >>>>>> > > >>>> On Tue, 21 Apr 2026 at 07:13, Tian Gao via dev < >>>>>> [email protected]> >>>>>> > > >>>> wrote: >>>>>> > > >>>> >>>>>> > > >>>>> Hi, I want to start a discussion about our dependency >>>>>> upgrade policy >>>>>> > > >>>>> for active development. >>>>>> > > >>>>> >>>>>> > > >>>>> Our current dependency upgrade (mostly for Java, but Python >>>>>> should be >>>>>> > > >>>>> included too) is a bit spontaneous. People find that a >>>>>> dependency has a new >>>>>> > > >>>>> version available and we just do the upgrade. >>>>>> > > >>>>> >>>>>> > > >>>>> This raises concerns about potential supply chain attacks. >>>>>> We already >>>>>> > > >>>>> established a few sets of rules (including pinning the >>>>>> github action >>>>>> > > >>>>> versions) to avoid the supply chain attack, but manually >>>>>> upgrading the >>>>>> > > >>>>> dependency version too eagerly could also be risky. >>>>>> > > >>>>> >>>>>> > > >>>>> It normally takes time for a bad release to be recognized, >>>>>> so I think >>>>>> > > >>>>> we should set a buffer time before upgrading to the latest >>>>>> version. For >>>>>> > > >>>>> example, we can wait a week or two after the latest release >>>>>> before we set >>>>>> > > >>>>> our development dependency to it. This could reduce the >>>>>> possibility of >>>>>> > > >>>>> being impacted by malicious releases, or just give them >>>>>> enough time to fix >>>>>> > > >>>>> their own severe bugs. >>>>>> > > >>>>> >>>>>> > > >>>>> The cost for this policy is very low - it barely impacts us >>>>>> if we >>>>>> > > >>>>> can’t use the “latest” version of dependencies. >>>>>> > > >>>>> >>>>>> > > >>>>> Of course, there should be exceptions when dependency >>>>>> upgrades include >>>>>> > > >>>>> security fixes for known vulnerabilities; we should upgrade >>>>>> as fast as >>>>>> > > >>>>> possible. >>>>>> > > >>>>> >>>>>> > > >>>>> Tian >>>>>> > > >>>>> >>>>>> > > >>>> >>>>>> > > >>> >>>>>> --------------------------------------------------------------------- >>>>>> > > >>> To unsubscribe e-mail: [email protected] >>>>>> > > >> >>>>>> > > >> >>>>>> > > >>>>>> > >>>>>> > >>>>>> --------------------------------------------------------------------- >>>>>> > To unsubscribe e-mail: [email protected] >>>>>> > >>>>>> > >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe e-mail: [email protected] >>>>>> >>>>>>
