Comment 11 for bug 1397091

Revision history for this message
Thomas Ward (teward) wrote : Re: [Security] Update Wireshark in Precise, Trusty, and Utopic to 1.12.1+g01b65bf-2 (from Vivid)

Attaching the full content of the email from Evan to me, in response to my asking for details as to the main reason 1.8.x was suggested in Precise instead:

The main reason is that wireshark is not just a userspace application
- it is also an API. A substantial number of companies have private
internal protocol plugins based on our API - changing major versions
at *all* will break that API and cause serious regressions for those
companies.

For this reason, keeping Precise on the 1.6 branch would be the ideal
solution; unfortunately 1.6 has been unsupported by upstream for
nearly two years, so staying on the 1.6 branch securely would involve
jumping to the 1.6.16 upstream release, then manually backporting a
ton of CVE fixes. Moving to a secure 1.8-based branch is the next-best
thing. If I recall correctly the API changes between 1.6 and 1.8 are
very minor, and most plugins should work after simply being
recompiled.

For trusty (currently with version 1.10.6-1) I would actually
recommend moving to the upstream 1.10.11, which pulls in the latest
CVE fixes without breaking the API. Upstream 1.10 will be supported
until mid-2015 so pulling in upstream micro-releases will be
sufficient until then; after that point the choice will be between
doing additional work backporting CVE fixes or breaking the API by
moving to a still-supported release like 1.12.

For utopic (already on 1.12), moving to the latest upstream 1.12
release is the unambiguous choice.

This is the general shape of the problem: Ubuntu LTS releases are
supported for much longer (5 years) than Wireshark upstream supports
their releases (2 years). If Ubuntu wants to keep their Wireshark
package up-to-date with CVEs, they can either:
 - bump major versions and break the API
 - do the work of backporting CVE fixes themselves
 - ensure that Wireshark packages in LTS releases are based on
debian-stable versions since Balint (the Debian maintainer) already
does the work to pull in CVE fixes for those versions even when
they're unsupported

Hope this clarifies, please let me know if you have any other questions.
Evan