Jan-Oliver Wagner wrote: > Hello, > > I'd like to discuss a long-standing open question about about using > external, widely-used libraries in favour of self-maintained copies or > self-brewn implementations. > > I am aware that there is no simple answer. > > Among others, the discussion was avout the glib librarary of > the GNOME project. It offers several utility functions e.g. for > hashed data storages or command line parsing to name only two > of them. The code base of OpenVAS could be reduced by using > the functions of glib. Of course, adding further libraries > adds potential security problems. On the other hand, code review is > shared with a much larger developer/user group for widely used external > libraries. > > I'd like to hear some opinions about this question. > > What strategy should OpenVAS follow?
when I've found myself complaining about some open source project's use (or mis-use, or unfortunately non-portable use) of things like glib, I think these are the issues one might consider: -- what distro's should it run on easily? -- should it run easily on live cd's? -- how much work do we want it to end up being to do "apt-cache search openvas" In other words, I would like to see it be at least a tolerable process to run on: - fedora 8 - ubuntu 7 - debian 4 - backtrack/wolvix/etc. live cd's - slackware 8 Note: I don't claim my list is anything but a sample data point ;-) > Are there already noteworthy articles about this question (as it > is absolutely not OpenVAS-specific)? I agree it is not OpenVAS specific. However, "what effort does the team want to put into making it easy to deploy OpenVAS" is a question the group might want to consider. _______________________________________________ Openvas-discuss mailing list Openvas-discuss@wald.intevation.org http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss
