Thanks for the MR Roland.
Best regards
Anders
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.
FWIW, their policy makes a lot of sense to me. As a user of an EL, I want stability first and foremost but I also want security updates (keep in mind that here "stability" doesn't mean "it doesn't crash," it means "it behaves the same"). I can't imagine any Linux vendor could keep up with questions like "what will break (or what behavior will change) if we bump our <package> version from <X> to <Y>?" for every one of the thousands of packages they include. But they can take security patches and apply them to the older package source code. Some won't apply directly which creates more work but the vast majority of the time it's a massive time saver.
At some level we (as individuals) need to trust/offload the security work to the EL (or any other OS) vendor, mainly because we don't have the resources go track all the CVE stuff. Those with more resources (companies) can simply pay for a product that (automatically?) takes in all the CVE inputs and tells you if your OS (EL or otherwise) has any open/unpatched vulnerabilities. Those products know that CVE X is patched in EL8 package P patch level Y.
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