Wireshark · Wireshark-dev: Re: [Wireshark-dev] Adding libxml2 as optional Wireshark dependency

[Pascal Quantin <pascal.quantin@xxxxxxxxx>]

2017-04-16 16:11 GMT+02:00 Pascal Quantin <pascal.quantin@xxxxxxxxx>:

Hi Graham,

Le 16 avr. 2017 15:35, "Graham Bloice" <graham.bloice@xxxxxxxxxxxxx> a écrit :

Has there been any progress on building and testing libxml2 using OpenSUSE?

No as I was waiting for a confirmation that we would follow this path and decide to add the dependency on the library.

I updated https://code.wireshark.org/review/#/c/20912

Pascal.

On 5 April 2017 at 17:52, Graham Bloice <graham.bloice@xxxxxxxxxxxxx> wrote:

On 5 April 2017 at 14:48, Pascal Quantin <pascal.quantin@xxxxxxxxx> wrote:

Hi Ahmad and Graham,

2017-04-05 15:38 GMT+02:00 Graham Bloice <graham.bloice@xxxxxxxxxxxxx>:

On 5 April 2017 at 14:11, Ahmad Fatoum <ahmad@xxxxxx> wrote:

Hello everyone,

I was advised on Gerrit to post this issue here as to garner wider input.

This concerns proposed Change-Id I13c0a2f408fb5c21bad7ab3d7971e0fa8ed7d783 [1] intending to add libxml2 as optional dependency to Wireshark.

I am currently preparing to submit upstream, changes I did to the EPL v2 dissector (packet-epl.c).

A significant change is the ability to optionally read in user-supplied XML device descriptions and to extract type/description/mapping information for aiding the dissection. See this previous submission of mine to the mailing list: https://www.wireshark.org/lists/wireshark-dev/201701/msg00154.html

Seeing as there also has been interest for libxml2 support in dissectors in the past:

https://www.wireshark.org/lists/wireshark-dev/201005/msg00108.html

https://ask.wireshark.org/questions/36063/using-libxml2-in-my-own-dissector

I think, it would be a good idea to have this as optional dependency as Glib's GMarkup may be inadequate or inconvenient for parsing actual XML.

Looking forward to your feedback.

Best regards,
Ahmad Fatoum

[1] https://code.wireshark.org/review/#/c/20912/

Thanks for the post,

1.  Where will the Windows binaries come from and are these supported long term?  The  libXml2 downloads page indicates another site provides Windows binaries [1].  The binaries at that site in the 64 bit directory seem to be the most recent and are labelled as libXml2-2.9.3 [2].  The current release of libXml2 is 2.9.4 which has a number of security fixes among other bug fixes and enhancements [3] so it would appear that the Windows binaries are not being maintained.

I suggest to use the binaries provided by openSUSE: they provide win32 and win64 variants for libxml2 2.9.0 and we are already using their packages for several third party libraries. If it is really required to take the latest version, I can probbly give it a try (I already did this in the past to package a newer version than the one from openSUSE).

That sounds good, I think for a new package we should use the latest available to ensure we pick up all known security issues. LibXml2 2.9.4 was released in May last year and 2.9.0 in Sep 2012.  I realise I'm attempting to volunteer you for this task Pacal ;-)

2.  According to the diagram at [1], libXml2 depends on iconv and zlib.  We currently build our own zlib, will that be suitable for the libXml2 dependency?  What will be the source of the iconv binary (iconv-1.14 is available in the same download area as libXml2 [2])?

Same thing: we can use the ones provided by openSUSE (we already have those dependencies for other packages).

iconv doesn't seem to be in the latest Wireshark builds (2.3.x). I think iconv was required for GTK, regardless it seems that libXml2 requires it.  We will need to check that the OpenSUSE libXml2 is happy with our built-from-source zlib.

 

3. The readme.txt in the download area ([2]) has some "interesting" text:

These are experimental 64bit binaries. For completeness, 32bit binaries 
built using the same method are also included.

The libraries in these packages are made using GCC (MinGW) toolchain. It is 
presently not possible to use these libraries with any recent version of the 
Microsoft Visual C compiler because of conflicting C-runtimes. To help you 
resist the temptation, the import libraries (.LIB) are not provided at all. 
If you need these libraries in an environment which mandates the use of the 
Microsoft toolchain, you will have to build them from source yourself.

and inspection of the download shows this is true, so it appears that we'll need to rebuild to obtain the import .lib file.

As part of the process of integrating openSUSE libraries, we are generating the .lib file and adding it in the package we upload on our server, so it should be OK.

4. Microsoft have a Visual Studio porting effort underway called vcpkg [4], that does include libXml2, but unfortunately is only for VS2015 or later.  If we move to VS2015 for main releases (post 2.4 release) then this may be a viable source for libXml2 and other packages we use.  It might be possible to use this to build VS2013 libXml2.

5.  Are there any manufacturers or tools that produce XML device description files for the EPL dissector such that choosing XML as the input format is the most sensible choice, or would another format be just as applicable?

I agree XML can be painful, so this is a good question ;)
 

[1]: https://www.zlatkovic.com/libxml.en.html
[2]: ftp://ftp.zlatkovic.com/libxml/64bit/

[3]: http://xmlsoft.org/news.html

[4]: https://github.com/Microsoft/vcpkg

--

Graham Bloice

--

Graham Bloice

--

Graham Bloice

Software Developer

Trihedral UK Limited

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@wireshark.org?subject=unsubscribe