I agree with bumping the version in general, and I can agree that there are cases where increasing the minimum version saves a lot of headaches even if we don't need a new API call.
However, minimum version increases can mean effectively dropping support for a given Linux distribution (at least out of the box, and in a corporate environment changing things from "I need to bring in Wireshark and compile it in a local directory after installing packages from the official repository" to "and I also need to bring in some other libraries, and link against the local version instead of the installed version" can be a non-starter or at least complicated with security policies.) I like to consider exactly which library changes will drop a distribution (see https://gitlab.com/wireshark/wireshark/-/wikis/Development/Support_library_version_tracking ) and in the particular case the gain from c-ares 1.14 vs 1.13 doesn't seem very large compared to dropping a fairly popular family of distributions, especially one that has a lot of use in corporate and server environments where security policies can be strict. Making 3.6 is the last version that officially supports RHEL 8 derived distributions seems hasty to me. John On Fri, Sep 30, 2022, 7:43 AM Roland Knall <rkn...@gmail.com> wrote: > Hi. > > Ok, maybe I have to clarify my thought process here a little bit. The > original version we required as absolute minimum was released nearly 12 > years (!!) ago. I needed a newer API call that would have been sufficiently > supported with 1.11 or 1.12. But there were two considerations: first, we > already used 1.14 on our Windows build server and it is sufficiently > supported on all current and max-3 year old system we support. And second, > 1.13 and 1.14 both had CVE fixes attached. That's why I chose 1.14. > > I am totally fine to backtrack that if it is absolutely necessary, there > was no deeper consideration than to update a mandatory minimum version that > was looong overdue. There was no current security concern, or otherwise I > would have chosen an even higher version. > > As for Qt, glib and others, absolutely, if there is a security issue that > affects our released binaries, we should update our > buildsystems accordingly. I would not necessarily require a newer version > though. > > Btw, for Qt, there is a precondition we cannot control. Every Qt version > seems to require an even higher version of macos as a minimum requirement. > Here we are in need to update to higher versions for the buildsystems or > otherwise would not be able to ship. > > cheers > Roland > > Am Fr., 30. Sept. 2022 um 12:09 Uhr schrieb Anders Broman < > a.broma...@gmail.com>: > >> Hi, >> I just have a problem with our policy here. If we require a certain >> minimum version of a library to keep our code simple and keep up with >> depreciation and API changes that is fine. But if we start to look at >> vulnerabilities where do we draw the line then? Latest qt? Glib? Etc. >> Why make it harder to build the latest ws on rhel8 when in my opinion we >> don't need to and our code does not get cleaner by this decision? >> I'm sure all packages we use have vulnerabilities. >> Best regards >> Anders >> >> Den fre 30 sep. 2022 11:50Dario Lombardo <lom...@gmail.com> skrev: >> >>> Hi Anders, >>> unfortunately this is a hairy issue. Redhat's policy about security is a >>> bit puzzling. They patch (as told before) old versions to make them not >>> vulnerable, maintaining the same version number. This is weird since being >>> vulnerable or not is something everyone in the world points out by looking >>> at the version number. XX is vulnerable, XX+1 is not... but for redhat XX >>> is not vulnerable also. This is something I hit personally (think how many >>> times RH has patched vulnerable kernels), that basically makes vulnerable >>> systems untrackable. I don't know the rationale behind their policy, but >>> for regular people, this is something hard to manage. >>> So I get your point and I would really like another solution, but I >>> agree that we should not solve an issue they created. >>> Since they patched libcares, they keep track of what is vulnerable and >>> what is not: they should patch wireshark accordingly to make it compile >>> with the older one... if they shipped a recent wireshark, and we know they >>> don't. >>> Ciao. >>> Dario. >>> >>> On Thu, Sep 29, 2022 at 10:27 PM Anders Broman <a.broma...@gmail.com> >>> wrote: >>> >>>> Hi, >>>> No problem. Just so we are aware we dropp support for rhel8 and >>>> similiar due to a minor technicality in my opinion. >>>> Best regards >>>> Anders >>>> >>>> >>>> Den tors 29 sep. 2022 16:32Roland Knall <rkn...@gmail.com> skrev: >>>> >>>>> That library was not the only consideration. The main consideration >>>>> was to cut-off at a certain point for 4.0 so that we can avoid having too >>>>> many things to consider going forward. There was a message about this on >>>>> the list a while back as well as a discussion at SF. >>>>> >>>>> Now, I get the argument to have compatibility for self-built versions, >>>>> and I could see a point, where we make a switch for a certain library to >>>>> have a compatibility mode. But I am not sure if this should be the way >>>>> forward in this case. Much rather have the nuisance to compile a more >>>>> recent version together with Wireshark, than have one more thing to >>>>> support >>>>> >>>>> regards >>>>> Roland >>>>> >>>>> Am Do., 29. Sept. 2022 um 15:03 Uhr schrieb Jeff Morriss < >>>>> jeff.morriss...@gmail.com>: >>>>> >>>>>> Also keep in mind that if RHEL decides to fix the CVE(s) in question >>>>>> in version 8 of their OS, they would likely apply the fix for the CVE to >>>>>> the version of CARES that they are already shipping (i.e., they'd create >>>>>> a >>>>>> version like 1.13.0.<whatever> rather than upgrading to 1.14.x). They >>>>>> work >>>>>> hard to avoid changing version numbers for compatibility reasons. >>>>>> >>>>>> On Thu, Sep 29, 2022 at 6:59 AM Anders Broman <a.broma...@gmail.com> >>>>>> wrote: >>>>>> >>>>>>> Hi, >>>>>>> Well a choice to make if we want to support CentOS8/RHEL8 or not. >>>>>>> One could argue that CVE:s in support libraries might not be for us to >>>>>>> decide on but rather the OS maintainers. >>>>>>> Best regards >>>>>>> Anders >>>>>>> >>>>>>> Den tors 29 sep. 2022 kl 08:19 skrev Roland Knall <rkn...@gmail.com >>>>>>> >: >>>>>>> >>>>>>>> The reason for 1.14 was a CVE that was fixed. I would vote strongly >>>>>>>> against reducing the Version just to support an older version. >>>>>>>> >>>>>>>> Regards, Roland >>>>>>>> >>>>>>>> Am 28.09.2022 um 18:48 schrieb John Thacker <johnthac...@gmail.com >>>>>>>> >: >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Sep 28, 2022, 10:47 AM Anders Broman <a.broma...@gmail.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> Is there a workaround for >>>>>>>>> CMake Error at >>>>>>>>> /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:230 >>>>>>>>> (message): >>>>>>>>> Could NOT find CARES: Found unsuitable version "1.13.0", but >>>>>>>>> required is at >>>>>>>>> least "1.14.0" (found /usr/lib64/libcares.so)? >>>>>>>>> I would like to build for CentOS8... >>>>>>>>> >>>>>>>> >>>>>>>> It doesn't actually need anything from 1.14.0, so changing the line >>>>>>>> in CMakeLists.txt that sets the minimum version should be fine. Look >>>>>>>> at the >>>>>>>> commit below and change one line to 1.13.0 >>>>>>>> >>>>>>>> >>>>>>>> https://gitlab.com/wireshark/wireshark/-/commit/5991a75d78a31ba61de6c162c79c2928da19c302 >>>>>>>> >>>>>>>> John >>>>>>>> >>>>>>>>> >>>>>>>> ___________________________________________________________________________ >>>>>>>> Sent via: Wireshark-dev mailing list < >>>>>>>> wireshark-dev@wireshark.org> >>>>>>>> Archives: https://www.wireshark.org/lists/wireshark-dev >>>>>>>> Unsubscribe: >>>>>>>> https://www.wireshark.org/mailman/options/wireshark-dev >>>>>>>> mailto:wireshark-dev-requ...@wireshark.org >>>>>>>> ?subject=unsubscribe >>>>>>>> >>>>>>>> >>>>>>>> ___________________________________________________________________________ >>>>>>>> Sent via: Wireshark-dev mailing list < >>>>>>>> wireshark-dev@wireshark.org> >>>>>>>> Archives: https://www.wireshark.org/lists/wireshark-dev >>>>>>>> Unsubscribe: >>>>>>>> https://www.wireshark.org/mailman/options/wireshark-dev >>>>>>>> mailto:wireshark-dev-requ...@wireshark.org >>>>>>>> ?subject=unsubscribe >>>>>>>> >>>>>>> >>>>>>> ___________________________________________________________________________ >>>>>>> Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org >>>>>>> > >>>>>>> Archives: https://www.wireshark.org/lists/wireshark-dev >>>>>>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev >>>>>>> mailto:wireshark-dev-requ...@wireshark.org >>>>>>> ?subject=unsubscribe >>>>>>> >>>>>> >>>>>> ___________________________________________________________________________ >>>>>> Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> >>>>>> Archives: https://www.wireshark.org/lists/wireshark-dev >>>>>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev >>>>>> mailto:wireshark-dev-requ...@wireshark.org >>>>>> ?subject=unsubscribe >>>>>> >>>>> >>>>> ___________________________________________________________________________ >>>>> Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> >>>>> Archives: https://www.wireshark.org/lists/wireshark-dev >>>>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev >>>>> mailto:wireshark-dev-requ...@wireshark.org >>>>> ?subject=unsubscribe >>>>> >>>> >>>> ___________________________________________________________________________ >>>> Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> >>>> Archives: https://www.wireshark.org/lists/wireshark-dev >>>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev >>>> mailto:wireshark-dev-requ...@wireshark.org >>>> ?subject=unsubscribe >>>> >>> >>> >>> -- >>> >>> Naima is online. >>> >>> >>> ___________________________________________________________________________ >>> Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> >>> Archives: https://www.wireshark.org/lists/wireshark-dev >>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev >>> mailto:wireshark-dev-requ...@wireshark.org >>> ?subject=unsubscribe >>> >> >> ___________________________________________________________________________ >> Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> >> Archives: https://www.wireshark.org/lists/wireshark-dev >> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev >> mailto:wireshark-dev-requ...@wireshark.org >> ?subject=unsubscribe >> > ___________________________________________________________________________ > Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> > Archives: https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org > ?subject=unsubscribe >
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
