[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: gEDA-user: [RFC 1/6] Non-Turing-complete configuration files.
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 <peter@xxxxxxxxxxxxx>:
>
> 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
> geda-user@xxxxxxxxxxxxxx
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
>
_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user