Thanks for the MR Roland. Best regards Anders Den fre 30 sep. 2022 16:41Jeff Morriss <jeff.morriss...@gmail.com> skrev:
> > On Fri, Sep 30, 2022 at 5:50 AM Dario Lombardo <lom...@gmail.com> wrote: > >> 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@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
