Hi Raphael, 2015-04-10 23:59 GMT+02:00 Raphael Hertzog <hert...@debian.org>: > Hello Balint, > > I would like to clarify the situation of wireshark in squeeze. > In https://bugs.debian.org/774312 you requested to mark the > package as "not-supported" and this has now been done. > > So in theory I should tag all CVE as "end-of-life" and they > will be hidden from our main view (and I will never again add "wireshark" > to dla-needed.txt): > https://security-tracker.debian.org/tracker/status/release/oldstable > > But at the same time you said that you would continue to backport > the relevant fixes and you are still listed in dla-needed.txt as preparing > an update fixing the CVE currently open in Squeeze (all of which are fixed > in Wheezy): > https://security-tracker.debian.org/tracker/source-package/wireshark > > So what's the correct status that I should put on all those CVE? > And should we keep or drop the entry in dla-needed.txt? > > Maybe the package should have been added to the "limited support" list > instead of the "not-supported" one? In which case, CVE are handled like > usual, trying to take into account the restrictions defined by the "limited > support". Let me copy the content of #/774312 here before my answer: > As the maintainer of wireshark I still plan continuing back-porting > security fixes for Squeeze's wireshark package, but I can't honestly > say that it is safe to run even the fixed versions. Squeeze had been > released with Wireshark 1.2.11 but upstream stopped providing official > security updates for that branch years ago. > > Currently security fixes are provided for 1.10.x and 1.12.x versions > which I back-port to Wheezy and Squeeze when their version is > affected, but there can be many hidden issues, especially in Squeeze. > > I will still fix all issues in dumpcap from the wireshark-common > package, thus Debian LTS users can still capture traffic safely, but > analysis should be performed using a later Wireshark version. Probably I should have asked for limited support instead of endings support, but at that time I was not aware of the distinction but let me extend my explanation.
I could keep up with back-porting security fixes to stable's 1.8.x from 1.10.x releases, but back-porting to oldstable's 1.2.x needs more work and while preparing back-ports for Squeeze I found several issues which would still be open even after back-porting related CVE fixes. Those issues are fixed in commits not related to the CVE-s, but for example in general code quality improvements like more rigorous error condition checking. Back-porting all those fixes would not make a lot of senss but not backporting them would leave vulnerabilities open which are easy to discover and which are not tracked publicly. This is why I think people should not run Wireshark 1.2.x for analyzing potentially harmful files, but should use newer versions instead. I have several back-ported patches here prepared for a new upload but I could not find time to prepare the rest of the fixes: https://code.wireshark.org/review/gitweb?p=wireshark.git;a=shortlog;h=refs/heads/lts-1.2.11 I can upload them, but I need more time to work on the rest and I'm not sure if it would worth it due to the other issues which would still stay unpatched. I assume this situation is not unique to Wireshark. What do you think, what would be the best for the LTS project in Wireshark's case and what is the general LTS strategy in similar cases? Cheers, Balint > > Cheers, > -- > Raphaël Hertzog ◈ Debian Developer > > Support Debian LTS: http://www.freexian.com/services/debian-lts.html > Learn to master Debian: http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-lts-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAK0OdpxFv+4dX4eC1ZrBQnVr+nwpBjsXFUTreTp+HZBvC+OK=q...@mail.gmail.com
