[John Thacker <johnthacker@xxxxxxxxx>]

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 <rknall@xxxxxxxxx> 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.broman58@xxxxxxxxx>:

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 <lomato@xxxxxxxxx> 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.broman58@xxxxxxxxx> 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 <rknall@xxxxxxxxx> 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.ws@xxxxxxxxx>:

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.broman58@xxxxxxxxx> 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 <rknall@xxxxxxxxx>:

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 <johnthacker@xxxxxxxxx>:



On Wed, Sep 28, 2022, 10:47 AM Anders Broman <a.broman58@xxxxxxxxx> 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@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
            mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe

--

Naima is online.

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe