Re: [Patch] Update libpcap to 1.5.3; Also discussion on whether we should really bundle 3rd party libraries or not

[Daniel Miller <bonsaiviking () gmail com>]

Jay,

We need to do better checking on whether these issues have been addressed
upstream. Patch 0004-Include-netpacket-packet.h-before-pcap-bpf.h.patch for
instance was addressed in libpcap 1.4.1, as evidenced by this issue on
GitHub (https://github.com/the-tcpdump-group/libpcap/issues/306) and our
own CHANGELOG, which notes the upstream fix which was not in a release in
2008.

Patch 0003 was actually in response to a Valgrind bug, which has been fixed
in Valgrind upstream (
https://github.com/the-tcpdump-group/libpcap/issues/147 and
https://bugs.kde.org/show_bug.cgi?id=318203)

I've opened a pull request (
https://github.com/the-tcpdump-group/libpcap/pull/358) with upstream for
the --disable-packet-ring one, though I don't see how it affects Nmap
unless it's used for building the RPM binary packages for releases.

I also opened a pull request (
https://github.com/the-tcpdump-group/libpcap/pull/359) with upstream for
the pre-configure.patch issue on AIX. We'll see what they say.

Patch 0001 is simply to keep our SVN history clean, since folks with
different bison/flex versions could conceivably generate different files,
which would lead to unnecessary check-ins of "changes" to those files. When
you do rebuild those files with the new version of libpcap, please use
bison 2.5 or newer, since that is the version that was used with the
previous generation.

That said, I think that you can go ahead and commit the upgrade. You should
have pre-configure.patch, 0001-*.patch, and 0002-*.patch applied. If you
would like review on the modifications to those patches, please ask. Thanks
for your work!

Dan




On Thu, May 22, 2014 at 10:24 AM, Jay Bosamiya <jaybosamiya () gmail com>
wrote:

> Hi all!
>
> I wrote a patch in March that updates libpcap but it turned out to be too
> large and so couldn't be reviewed and thus couldn't be committed.
> Most of its size came from the updates in libpcap itself and I personally
> had nothing to do in it.
>
> In order to make it quite easy to review and for simplicity sake, I wrote
> the patch as a small script that is bundled with the actual changes I made.
> (script.sh and nmap_modifications.patch respectively).
> I have attached the same as a compressed tar.gz.
>
> To use the script, please extract the file to an empty directory and run
> script.sh using bash. The script allows you to check out nmap, download
> libpcap 1.5.3, runs the necessary changes (see nmap_modifications.patch)
> and then generates a final patch file which can then be used on the latest
> svn repo to update libpcap.
>
> Note: You can test the downloaded libpcap file's signature here:
> http://www.tcpdump.org/#latest-release to make sure that the download was
> successful.
>
> In order to review the patch, only reading the two files is needed and
> testing can be done after running script.sh.
>
> FYI, any tests that I ran after updating libpcap worked just fine. I was
> testing on Ubuntu 14.04 (64 bit).
>
>
>
> BTW, Looking at all the trouble that it takes to update a third party
> library, both Gisle and Daniel have pointed out that we should actually be
> having no need to bundle libpcap or any other 3rd party library for that
> matter with Nmap.
> Quoting Dan, "The basic question is, should we bundle readily-available
> third-party libraries with Nmap? Sometimes we need to make modifications;
> sometimes (like liblinear) the libraries are not readily available; but we
> don't want to get into this problem of needing to keep them updated all the
> time!"
>
> What I suggest is that we should probably discuss this here and decide
> whether we want to continue with these party libraries (and commit in this
> update) or whether we should get rid of them (thus, not only reducing bloat
> but also removing this trouble of updating).
>
> I personally say that we should remove these libraries, even though I just
> helped in updating one.
>
> Hopefully we'll come to some sort of resolution on this soon. :)
>
> Cheers,
> Jay
>
> _______________________________________________
> Sent through the dev mailing list
> http://nmap.org/mailman/listinfo/dev
> Archived at http://seclists.org/nmap-dev/
_______________________________________________
Sent through the dev mailing list
http://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/