Wireshark · Wireshark-dev: Re: [Wireshark-dev] Meeting minutes from (pre)FOSDEM meeting

[Jaap Keuter <jaap.keuter@xxxxxxxxx>]

Hi all down there in Belgium,

I see I missed a lot already :/ Good to see so many things discussed. 
Well done documenting this Jörg.

Without starting a complete discussion I would like to put in my 2 
cents.

On backporting, I did a lot of that stuff for 1.4.11. From my 
experience, when the patch is clean the backport is easy.
Trouble is is that the patch comes from another trunk, which may have 
other changes (like ENCodings) which make patches incompatible.
A little (or a lot of) tweaking of the patch makes them apply, but this 
cannot be automated. So thinking about automation is a step too far.
Another way of tagging/marking revisions would 1. require a script to 
extract the tags/marks, and 2. commit messages cannot be corrected once 
a mistake is made.
As flawed as it is, the Wiki is the best we got so far. Other tools 
(who uses Trac, or that other one I can't remember right now) may 
provide this.

On building Linux packages, the Debian builder (Ubuntu) could work use 
`make debian-package` maybe? Although some control file manipulation for 
version numbers would be required.

On documentation: Another, more accessible source format would be 
appreciated. Still we must consider merging effort, which is easier with 
plain text based source. AsciiDoc anyone?

Git would open up for shared development work on features. I would love 
to see the way-of-working for this (git newby here).

Generic dissection engine is hard to do because the correctness of the 
configuration file cannot be relied upon.
If this causes a crash these are though bugs to fix. There has already 
been a set of bugreports on 'crooked' config files causing crashes.

Ok, now I need a beer. ;)

Thanks guys, keep up the good work,
Jaap





On 2012-02-03 16:51, Joerg Mayer wrote:
> As some people met in Brussels on the eve of FOSDEM and talked about
> Wireshark,
> here are some notes on what was talked about. We just don't want to
> leave anyone
> out on what was talked about.
>
> As usual: These are personal opinions etc, nothing is set in 
> stone....
>
>  ciao
>      Jörg
>
> Next release:
>
> - we have interesting new features
>   + multi interface capture:
>     o how will people feel about the additional click required to get
> to capture filter
>     o how well is it documented
>   + default of pcap-ng
>     o new install: pcap-ng default
>     o update: keep
>     o put it prominently into the release notes
>     o unexpected behaviour, like mergecap - better error messages
>   + Gerald may do some blog posts to introduce the new things to
>     warn users about the upcoming changes
>   + gtk3 as default build
>     o proto_help
>     o audiograph problems
>     o tcp-graph: crosshairs not right
>     o menus lack frames
>     o gtk2 support on windows has problems as well (no current gtk
> 2.24 on win64)
>     o It's too early for making it default for 1.8
>   + building Linux packages:
>     o Jörg will try to get a repo on obs for wireshark to provide 
> packages
>       for many Linux distros (and offer an alternative with gtk2 and 
> gtk3)
>   + Must perform as well or better than the GTK2 version
> - release timing
>   + well before sharkfest, so people have used it
>   + perhaps shortly after easter
>   + April / May looks realistic
> - we do too few *development* releases
>   + do them more regularly (monthly/bi-monthly)
>   + do feature releases
> - backporting:
>   + right now: using the wiki
>     o it's a lot of work
>   + to make it easier: use a magic word in the commit message
>     Mesa uses: "    NOTE: This is a candidate for the 7.11 branch."
>     and keep the wiki in case the note was forgotten (or enforce 
> every
>     commit message to HEAD to have a #Backport: 0/1# part
>   + can svn hooks help here?
>   + Alternatively: give a level of importance for a backport instead 
> of
>     just yes/no
>
> Bugfixing:
> - How do we handle all the old bugs?
> - Maybe a top 5 bugs of the week
> - Maybe a top 5 bugfixers of the week
> - Maybe a testing/bugfixing weekend like Fedora/Ubuntu do
> - Maybe Riverbed could hire someone to work on this
> - Chris and Jeff seem to do quite a lot of triaging on the bugzilla
> - can/should we make use of the voting mechanism in bugzilla?
>
> Annotations:
> - Martin has submitted a patch and wants to know whether he is on the
>   right track
> - Is annotating packet #3 in a 4 GB file a problem?
>
> Anonymizing:
> - Two use cases:
>   + Address anonymization
>     o replace everything of FT_IPv4 in memory
>       x more general: transformation function
>     o ftp, where ip-addresses are embedded in ascii-form
>       x needs special handling inside the dissector.
>       x for this particular problem: Maybe add an Encoding
>         type for it
>     o Print a csv file for the mapping
>     o maybe keep the last n bits as an option
>   + Content anonymization
>     o Zero out elements that contain sensitive information, e.g.
>       credit card information, rtp: audio part
>     o Have an FT-type that declares that data is available to
>       anonymization
> - Have a white list, zero out all protocol data that's not
>   on the whitelist
> - Order of steps
>   + First solve the prolbem of writing the changed data back to file
>     (take a look at the packeteditor feature)
>   + Then discuss the rest.
>
> How do display filters work:
> - Nobody present here really understands how display filters work
>
> qtshark:
> - maybe we can attract a seasoned qt-developer to help us getting 
> started
>   with the qtshark design stuff
>
> cmake:
> - on windows
>   + cmake for VisualStudio would be welcome
>   + Find out which features (scripts) are needed on windows
>   + Graham is working on getting rid of the cygwin toolchain by 
> writing
>     powershell replacements. If they are cross platform scripts, they
>     will be in python. The setup still requires the normal Windows
>     perl and python packages.
>   + cmake would allow out-of-tree builds on Windows
>   + starting with a cygwin/nmake alternative would be an idea as 
> there is
>     no native windows / VisualStudio setup available right now.
>
> iOS version:
> - Probably not: Apple does not allow GPLed Software in the 
> applestore:
>   http://michelf.com/weblog/2011/gpl-ios-app-store/
>
> packet-x11.c:
> - Copy the required includes into wireshark sources dissectors/x11/
>
> git:
> - Gerald will make the git repo official once he finds the time for 
> it
> - Moving to git will probably annoy lots of Windows users (tortoise 
> git
>   is not comparable to tortoise svn).
> - Are there tools to mirror out from git to svn?
> - Create use cases for core and non-core developer use of git and 
> svn,
>   then check whether these use cases can be fulfilled by running svn 
> and
>   git-svn.
> - If not, ask the core developers how they think about git - they are 
> the
>   only ones that would be forced to interact with git, the rest could 
> use a
>   svn mirror.
> - non-core developers could benefit a lot from git, read-only access
>   is enough.
>
> docbook:
> - can we create one paper type that is compatible with both us and 
> a4, so
>   we only have to build the pdfs once.
> - the windows help files are deprecated by microsoft but the 
> replacement
>   is not supported on xp
> - we don't have oneline help on Unix/Linux/...
> - Using a unified help format for all platforms? pdf with links?
> - Is docbook really the right format or should the documentation be
>   moved to odf?
>   + Svn has tools to unpack odf files so the diffs are still
>     visible on checkin.
>   + Moving to odf would lower the barrier for most people who might
>     want to do documentation
>   + Ask the people who contributed to the documentation what they 
> think
>     about such a change.
> - Jörg will add install targets and bug package maintainers to add ug 
> and dg
>   to the packages.
>
> wiretap plugins:
> - plugins for reading proprietary packet formats are a good idea
> - put an example and explanation into wiretap/README.plugin
> - How to handle writing the (read-only) captures into a standard
>   format? Don't know.
> - is there a 1:1 mapping between DLTs and WTAP_ENCAP_... ?
>
> i10n:
> - for the GUI OK
> - for the dissectors not OK
> - if someone wants to do it: don't stop him or her