From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5BEA4C531DC for ; Fri, 23 Aug 2024 17:18:05 +0000 (UTC) Subject: Re: [master][scarthgap][PATCH] wpa-supplicant: Upgrade 2.10 -> 2.11 To: openembedded-core@lists.openembedded.org From: "Siddharth Doshi" X-Originating-Location: IN (157.32.46.111) X-Originating-Platform: Linux Chrome 126 User-Agent: GROUPS.IO Web Poster MIME-Version: 1.0 Date: Fri, 23 Aug 2024 10:17:59 -0700 References: In-Reply-To: Message-ID: <5008.1724433479274681997@lists.openembedded.org> Content-Type: multipart/alternative; boundary="hbOHMv4wrzc0mJaLH5uI" List-Id: X-Webhook-Received: from li982-79.members.linode.com [45.33.32.79] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Fri, 23 Aug 2024 17:18:05 -0000 X-Groupsio-URL: https://lists.openembedded.org/g/openembedded-core/message/203703 --hbOHMv4wrzc0mJaLH5uI Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Randy and Alex, I appreciate the feedback and your concern regarding upgrades in stable-bra= nches. >=20 > This update make sense for the master brnanch but likely not for scarthga= p > unless you can show that > this is a bug fix only release. >=20 - This release for sure is not a bug fix only release. It does include supp= ort to new feature and can never classify as bug fix only release. >=20 > you'll have to backport any CVE fixes that you're interested in unless > someone explains why this is a sensible update for scarthgap. >=20 >=20 - I do the understand that upgrades are avoided in stable/LTS branches as i= t might break the compatibility and result in various compilation issues. - However, that would only take place if the backward compatibility of the = new upgrade is questionable. - Generally every new releases will have API or ABI-symbols added but if AP= I or ABI symbols are removed from shared libraries or binaries it a matter = of concern as it would be the cause of breakdown. - For this release, there are no ABI-symbols or API removed from the binari= es and shared libraries. you can cross-check it in different ways (there ar= e open-source tools to check or can be checked by manually comparing the he= ader files) - I have my own script to do so and i always check the backward compatibili= ty before submitting any upgrades and since it was all clear for wpa-suppli= cant, i went ahead with the upgrade. However, if still the opinion is that upgrade should be avoided, let me kno= w, i would submit the CVE-patch for the same. Regards, Siddharth --hbOHMv4wrzc0mJaLH5uI Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
Hi Randy and Alex,
 
I appreciate the feedback and your concern regarding upgrades in stabl= e-branches.
 
This update make sense for the master brnanch but likely not f= or scarthgap unless you can show that
this is a bug fix only release. 
- This release for sure is not a bug fix only release. It does include= support to new feature and can never classify as  bug fix only release. 
you'll have to backport any CVE fixes that you're inte= rested in unless
someone explain= s why this is a sensible update for scarthgap.
 
- I do the understand that upgrades are avoided in stable/LTS branches= as it might break the compatibility and result in various compilation issu= es.
- However, that would only take place if the backward compatibility of= the new upgrade is questionable.
- Generally every new releases will have API or ABI-symbols added but = if API or ABI symbols are removed from shared libraries or binaries it a ma= tter of concern as it would be the cause of breakdown.
- For this release, there are no ABI-symbols or API removed from the b= inaries and shared libraries. you can cross-check it in different ways (the= re are open-source tools to check or can be checked by manually comparing t= he header files)
- I have my own script to do so and i always check th= e backward compatibility before submitting any upgrades and since it was al= l clear for wpa-supplicant, i went ahead with the upgrade.

Howev= er, if still the opinion is that upgrade should be avoided, let me know, i = would submit the CVE-patch for the same.

Regards,
Siddharth
--hbOHMv4wrzc0mJaLH5uI--