[Dario Lombardo <lomato@xxxxxxxxx>]

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.