Wireshark-dev: Re: [Wireshark-dev] Question about dissector "enhancement" / bug
From: Pascal Quantin <pascal@xxxxxxxxxxxxx>
Date: Fri, 28 Jun 2019 07:49:48 +0200
Hi,

Le ven. 28 juin 2019 à 06:06, Anders Broman <a.broman58@xxxxxxxxx> a écrit :


Den fre 28 juni 2019 00:44Jason Cohen <kryojenik2@xxxxxxxxx> skrev:
The question about about weather or not adding dissection of additional information in a dissector is an enhancement or a bug; I think this is kind of a grey area.  If a dissector doesn't completely dissect a header, would a patch that completes it be considered fixing it?  Does it switch between a fix and enhancement if the reason the field is missing is either a wrong offset, or a missing proto_tree_add_item statement?

How about handling vendor specific decodes?  Particularly where the vendor formerly provided a plugin (under an open source license) and kept it up to date as formats and data changed.  When Wireshark.org opted to pull a version of it into libwireshark (which is a good idea) negatively impacts the release of updates.  Wireshark is not beholden to a vendors release cycle and a vendor isn't beholden to Wiresharks.  But when they do not coincide, functionality that would readily be available is now blocked and delayed.  Furthermore, with the inclusion of the now incomplete dissector it makes it unmanageable to provide the full vendor functionality as a plugin.

I think there should be some level of flexibility to the inclusion of dissector updates under these circumstances.

As a specific example I am referring to:

Jason

It's a slippery slope either way. One can also argue that using the development version is a possibility. At one point Ubuntu was not taking our minor versions but rader did their own with security fixes only. So there's different views on the subject.

 I'm not opposed to make an exception in this case however as the change is small. What does other people think?

Personally I consider adding new fields / new versions of a protocol as being an enhancement (that's what I do for the dissectors I maintain). If we do an exception here, how will we handle the next request and justify if we refuse the backport? We might open a can of worms here.
The development builds are most of the time stable enough for a day to day use.

Just my 2 cents,
Pascal.