Hi! Sorry if I will be too long, but this is an important question. Short version: Don't Do That! Long version: Once upon a time we did a firewall software development project, which had horribly failed. When we analyzed the causes, we identified numerous management problems, and some technical ones. The most important technical problem was that we have invested disproportional resources into the configuration parser. The project ended, the development team split. And both teams decided that they want to make living from firewall software. Our team restarted the whole project from the ground up. We have decided that python shall be the configuration language (I strongly lobbied for scheme that time, but nowadays I am very grateful that the final decision was python). The software uses python not just for configuration, but the high-level policy decisions and also the glue uses it. And the beast is still fast as hell. Our team is now called Balabit Inc, and we have nearly 70 employees, and doubling in sales every year, the overwhelming majority of it being from Zorp, the most advanced firewall software of the world. The other team continued on the original codebase. They are still exists I think, but nowadays they are actually invisible on the market.
I think the moral of the story is straightforward: mixing a scripting language in is not just saves precious development efforts, but also opens numerous possibilities to get off cheap with in various unforeseen areas. And here I mean not just development time: the overviewable. However it might be worthwile to think about changing to a more widely used and more expressive language like python, ruby, or ada. If you have security concerns, sandboxing the implementation can be a solution, as others have already mentioned it. 2009/1/16 Peter TB Brett <[email protected]>: > > Currently, the gEDA configuration files are executed by a Scheme > interpreter. This has a number of flaws: > > 1. An error in a configuration file will cause it not to be fully > interpreted. This can potentially leave gEDA applications in an > unusable state or even cause it not to start at all. Furthermore, > this can be confusing to a new user, who might not be familiar with > Scheme or the quirks of gEDA configuration and thus more at risk of > making mistakes configuring gEDA. > > 2. Per-project configuration files may legitimately be required. For > instance, they may be used to customize libraries of symbols or > hierarchical schematics. However, they currently pose a security risk > in that downloading and opening a set of schematics from the Internet > can easily result in arbitrary code being executed. > > My proposal is to use a Scheme-like syntax for the configuration files, > but to parse rather than execute them. Naturally, it would be necessary > to design the system carefully to ensure that all configuration > parameters can be specified in the reduced syntax. > > Peter > > -- > Peter Brett > > Electronic Systems Engineer > Integral Informatics Ltd > > > _______________________________________________ > geda-user mailing list > [email protected] > http://www.seul.org/cgi-bin/mailman/listinfo/geda-user > _______________________________________________ geda-user mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
