Re: gEDA-user: Fixing the attribute censorship bug

[Peter Brett <peter@xxxxxxxxxxxxx>]

John Doty <jpd@xxxxxxxxx> writes:

> On Jun 1, 2011, at 7:58 PM, Peter Brett wrote:
>
>> John Doty <jpd@xxxxxxxxx> writes:
>> 
>>>   On May 31, 2011, at 11:02 PM, Peter Brett wrote:
>> 
>>>> This script deliberately poisons the netlist.
>>> 
>>> Exactly. This is consistent with other gnetlist behavior. If no
>>> attribute is found, the resulting value is "unknown". So, I think
>> 
>> Yes, and that behaviour is broken too.  If no attribute is found, no
>> value should be returned.
>
> I think that would be a severe burden on projects using heavy
> symbols. One often needs attributes that apply to only a subset of
> components, or are to be chosen downstream. "unknown" is a fine
> indicator.

Being totally unable to distinguish between "there is no such attribute"
and "the attribute has its value set to 'unknown'" *even if you need to*
is obvious missing functionality in gnetlist.  Backends can substitute
magic strings (e.g. "unknown") if they want to; the core should behave
sanely.

> [snip]
>
>> 
>> Let's not overload the config files with even more attack vectors for
>> malicious designs.  Some sort of plugin system?
>
> I have no idea what you mean.

As you point out, per-project config files can contain executable code.
And this is a *security* bug and is *broken* by design, and that
facility is going away as soon as practically possible.

> [snip]
>
> In particular, we have -l and -m because the order in which things are
> defined matters.

Which is stupid, and shouldn't be necessary.

> I thought you were asking for the possibility to load this kind of
> plugin from a config file.  This would require additional support, to
> allow a config file to specify a list of expressions to be evaluated
> later. It would be almost trivial to add such support to
> gnetlist-post.scm, if that was desired.

I am asking for the ability to load plugins in the same way as backends.

  gnetlist -p <plugin> -g <backend>

Or to specify *plugin names* to load in the config file

  (gnetlist-plugin <plugin 1>)
  (gnetlist-plugin <plugin 2>)

Plugins should be loaded after gnetlist's basic initialisation is
complete.  It shouldn't be too challenging an exercise to define a set
of hooks etc. that allow plugins to modify most aspects of gnetlist's
behaviour.

This approach has several benefits:

1. The config file doesn't run the plugin directly, so security checks
   can be carried out before loading the plugin (at a minimum, forcing
   the plugin to be loaded from a defined plugin search path).

2. It enables command-line options like:

     gnetlist --list-plugins

3. It permits the removal and/or serious rethinking of the -l, -m and -c
   arguments (-c in particular is hilarously broken).

This is more complicated to implement than your proposed hack, but has
the advantages of security, usability, discoverability, and elegance.

                           Peter

-- 
Peter Brett <peter@xxxxxxxxxxxxx>
Remote Sensing Research Group
Surrey Space Centre



_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user