Re: gEDA-user: Fixing the attribute censorship bug

[John Doty <jpd@xxxxxxxxx>]

On Jun 3, 2011, at 2:09 AM, Peter Brett wrote:

> 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.

It's not missing any more. We fixed that, remember? With (gnetlist:get-all-package-attributes) you *can* distinguish.

>  Backends can substitute
> magic strings (e.g. "unknown") if they want to; the core should behave
> sanely.

It's useful to have a common convention, so that the user can easily understand that "unknown" in a BOM corresponds to "unknown" in a netlist, regardless of the back end chosen. Back ends or plugins can substitute other behavior if needed.

> 
>> [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.

From where I sit, the more serious problem is that the config files execute Scheme functions, including functions in the core code. This is a serious barrier to tools that aren't written in Scheme.

> 
>> [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.

In Scheme, order matters.

> 
>> 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>

In Scheme, order matters.

> 
> 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.

*Which* basic initialization?

>  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.

"Hooks" impose the developers' necessarily limited vision on users. Better to have well-factored, well-layered code than "hooks". Thus, (gnetlist:get-package-attribute) is built upon (gnetlist:get-all-package-attributes) which *should* be built on something accessible that makes a list of symbol instances, which should be built on ...

Then, user code would have access to the data at the level of digestion needed by the problem at hand (which neither you nor I can anticipate), and can access data of control behavior by redefinition as needed. It seems to me that "hooks" are a hack to get around bad factoring.

> 
> 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).

Sure, that was what I had in mind. Have functions (in the current approach) that build lists of plugins (probably one early and one late set), and have them actually loaded by code in gnetlist.scm and gnetlist-post.scm.

> 
> 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.

The principal difference between your vision and mine is that mine can be entirely implemented outside the C core, while yours requires additions to the C core (or a thorough refactoring). But I think the C core is the main barrier to progress: it needs to go away. So, whose approach is a "hack"?

John Doty              Noqsi Aerospace, Ltd.
http://www.noqsi.com/
jpd@xxxxxxxxx




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