Ethereal-dev: Re: [ethereal-dev] Security race in ethereal leading to root access
> As a solution, maybe we can provide "our own" version of libpcap with
> ethereal, if copyright permits.
Or provide it independently, if somebody's bothered by distributing
BSD-licensed code and GPLed code in the same tarball....
> This has the advantage of being able
> to put the patches that we need (e.g. linux patches, security fixes,
> atm additions etc.) into that version. Of course these patches should
> be sent to the libpcap maintainers for inclusion but this would allow
> us to include all we need and at the speed we want. When the rate of
> change to the lowlevel interface has slowed down sufficiently and the
> required changes are integrated into libpcap we should remove it from
> the distribution again.
Well, I sent them patches to allow "libpcap" to read many different
capture file formats, but
1) they indicated that they might use them instead in a utility
to translate packet files to "libpcap" format rather than
putting them in the library (which I think imposes an
unnecessary inconvenience on users)
and
2) I haven't seen any indication of an alpha release of
"libpcap" 0.4.1 or 0.5 or... yet
so
1) there's no guarantee that they'll accept any patches we
supply
and
2) there's no guarantee that, if they do, a version of "libpcap"
with the patches will appear any time soon
so we may have to keep the patched "libpcap" around for a while....
Long term, I'd like to turn "wiretap" into a complete replacement for
"libpcap", so that
1) we aren't restricted to changes the LBL people approve of
and
2) we can have a somewhat faster development cycle than they
appear to have.
In this particular case, I'd be inclined to switch to using "wiretap" to
write out the capture file, adding the ability to do that to "wiretap",
and have "wiretap"s API include a "wtap_dump_fdopen()" call or something
such as that, which takes a file descriptor rather than a file name.
