Re: Adding libdnet and libpcap to nbase

["Luis MartinGarcia." <luis.mgarc () gmail com>]

On 06/11/2010 03:53 AM, Fyodor wrote:
> While I can see how you would need to do that in order to share common
> tcpip code between nping and nmap, I'm a little bit skeptical of this
> idea.  I think of Nbase as a base library for portability stuff and
> core utility functions.  For example, it provides functions like
> getopt_long, inet_pton, inet_ntop, and snprintf for systems which
> don't offer them.  And it has some core utility functions for string
> processing, memory allocation, random number generation, etc.  For the
> random numbers, we pulled in OpenSSL code but didn't add a requirement
> for the OpenSSL library.
>   
Yes, I know making Nbase depend on other libraries doesn't look like the
best option but David and I discussed this and we thought it was the
best choice. All tools in the nmap tarball already depend on Dnet or
Pcap so the impact was not significant.

In my case, the way I saw Nbase was a lib for shared code between nmap
and its companion tools. However, I do see your point on Nbase being a
library focused on portability.

> I worry that making nbase dependent on libdnet and libpcap will not
> only cloud its (admittedly already murky) focus, but also cause
> near-term practical problems.  For example, Ithilgore recently spent
> several days making libpcap removable from Nsock so it could still be
> used in Ncrack.  Ncrack also uses Nbase, so we could run into the same
> issue if we now go and add libpcap to that.
>   

Yes, David pointed this out the other day. We haven't found a solution
yet but we talked about making the inclusion of dnet and pcap optional,
so Ncrack could set the appropriate flags and compile it on its own.



> Maybe it would make more sense to create a new Nmap
> tcpip/networking/packet/internals library (I'm not sure what all you
> have in mind) for this rather than stuffing everything into Nbase?
>
>   

Well, certainly that would be the best option from a theoretical point
of view. However, that would also require major changes in the whole
building structure, and that may lead to some additional problems. I'm
not against any of the two options, keeping the code in nbase or moving
it to a third lib, but this has to be discussed in more detail, as David
will probably have a lot to say about this.


Regards,


Luis MartinGarcia.

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/