>Message: 3
>Date: Wed, 10 Dec 2014 11:08:25 -0700
>From: Stephen Fisher <sfisher@xxxxxxx>
>To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
>Subject: Re: [Wireshark-dev] What Wireshark base version to use for
> customization
>Message-ID: <20141210180825.GA29277@xxxxxxx>
>Content-Type: text/plain; charset=us-ascii
>
>On Wed, Dec 10, 2014 at 12:51:23PM -0500, John Dill wrote:
>
>> So what restrictions are there when you have a Wireshark plugin that
>> contains proprietary information (which can be of the do not export
>> variety) from the govt or customer and they do *not* want that
>> information released to the public, since Wireshark can be used as a
>> tool to visualize and analyze these private kinds of protocols? If
>> some of that implementation leaks into the Wireshark application (like
>> hiding all of the unnecessary protocol cruft to make it simpler for
>> user to use), what are the implications?
>
>Is the proprietary information short, such as encryption keys? A
>preference can be used for things like that and then only if the
>user's preferences file is shared will it get out. If that's a
>high-risk, you could even have the dissector/plug-in do something
>non-stndard like reading a file for the information (but we probably
>wouldn't want that kind of dissector in the base source).
The entire packet stream generated is a proprietary system on top of
TCP and UDP that consists of avionics data, all of which is considered
proprietary. There are several hundred different packet messages that
contain one to several hundred data elements.
I was curious how the license Wireshark uses applies to this scenario,
since I've created a DLL to process data that is also distributed to a
govt entity, but I'm using an open source project with a GPL license
to translate this data, but the source code that translates the content
they want to keep private.
Regardless, there's no way I would be allowed to submit this plugin to
the public Wireshark repository (not without serious legal/employment
consequences), so maybe its a moot point to discuss.
Best regards,
John D.
<<winmail.dat>>
