bug-global
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bug#590053: global.cgi fails to work with id-utils extension.


From: Ron
Subject: Re: Bug#590053: global.cgi fails to work with id-utils extension.
Date: Sat, 21 Aug 2010 21:46:42 +0930
User-agent: Mutt/1.5.20 (2009-06-14)

On Sat, Aug 21, 2010 at 12:43:56PM +0900, Shigio YAMAGUCHI wrote:
> Hi,
> > I think if we change from having a generated cgi, to having a static
> > ready to go script, then we can in fact have more than one of these.
> > Almost all of the things that are currently substituted there would
> > be better done with CSS today - which really leaves us only the most
> > fundamental conflict of simplicity (and obvious security) vs greater
> > versatility to deal with.
> 
> Static CGI script is already possible. Since htags generates CSS based
> hypertext by default, you can provide static CGI script (and CSS file
> if needed).

If htags does this by copying that static file from $(datadir)/htags/
then I think we win the real simplification that we are looking for.
It could even have an option to pick from one of several scripts there.

The static scripts are much easier to audit and maintain than if they
are generated from code that is still being modified.  And people can
put their own scripts there and have them work the same way that the
'built in' ones do.  This sounds good to me.

> > We can provide both a very simple script and a more complex one as
> > examples, and the user can select whichever they find more appropriate
> > to their particular needs.  The packages can provide a default config,
> > if they use the complex one, which makes it the equivalent of the simple
> > and safe one in its initially installed form.
> 
> I agree about the point that many CGI scripts should exist.
> However, each script should be released by the author under his 
> responsibility.
> Complex scripts tends to have security holes.

Yes, I completely agree that the people who need and use them should be
the ones to maintain them. I see there being roughly three sets of scripts:

- Default scripts, released with the Global package, and approved by you.

- Contributed scripts, that several people have vouched for and use and
  share the fixes with each other.  I would like to see some sort of
  compilation of these kept under the global GNU project, if not as a
  part of the global package itself.  These I would likely make available
  in packages for users.  The links you suggest would do, but copies of
  them known to work with particular global releases would be even better.

- Random people's scripts.  Things that someone just puts up on their
  blog, with no guarantee they don't make themselves.  If people want
  to use them, they can put these in their $(datadir)/htags/ or so by
  themselves.

We can provide one simple mechanism in global that works for them all,
we just need a '--use-cgi = script_name' option or the like, and some
defined places to look for them.

> > We three cannot guess all the things that people might find useful to
> > add to this.  But we can provide good examples for them to begin their
> > modifications from.  And accept the good ideas to further share.
> 
> I think that the specification of a system is what the author should press
> it against the users. There is no specification that satisfies everyone.
> So, 'good examples' also cannot satisfies everyone.

I think we can find a few common patterns that will cover most people's
needs, and the people who do not find any of them to quite suit what they
need will at least have a starting point in one or the other.

But I agree, if people use this, there _will_ be some things in the third
set from above.  We can ensure there are no known problems with the ones
in the second set though -- and if problems are reported and not fixed,
then we can take them down from there. We just need to provide the sandbox
and then we can pick whatever flowers grow out of it as we please :)

This keeps global very simple, and focussed on being a tag system, and
moves The CGI Problem out to the people who want to spend time on that.
That seems like a step in the right direction to me.

Cheers,
Ron





reply via email to

[Prev in Thread] Current Thread [Next in Thread]