Bug#841294: Overrule maintainer of "global" to package a new upstream version
On Mon, Oct 24, 2016 at 12:48:10PM -0500, Don Armstrong wrote:
> On Sun, 23 Oct 2016, Tollef Fog Heen wrote:
> > Maybe the question we should ask is less «who/how many people use
> > htags?» and more «what value does htags provide?». I'm no big fan of
> > arbitrarily breaking people's workflows, which we might be the result
> > if we remove htags.
>
> It sure looks like upstream has removed the CGI generation option from
> ctags itself, and no longer supports the --system-cgi option. Htags
> appear to now just be generated statically, with the possibility of a
> generated CGI as well [which seems to just set appropriate paths.]
>
> It's quite possible that I've totally missed something (the upstream
> manual is a bit impenetrable), but maybe this will obviate the need to
> answer this question?
Only half-missed :) That removes any trace of the ability to generate
a _static_ CGI that can be audited and installed to a system path.
Which basically takes us back to the original situation from the 90's
again, where the CGI is generated dynamically for each source repo,
and is expected to be allowed to execute from the same tree as the
static html content.
It is possible to generate html that doesn't use a CGI at all, but
that completely removes the ability to search the gtags database
(which is what the CGI is needed to do) - which makes htags fairly
useless, since the whole point of global is the tag search function,
and you really would be far better off using something like doxygen
instead which provides client side search functionality.
The evolution was basically:
- 1999 I added the ability to generate static CGI and use it securely.
It was then suitable for use as a distro package, and uploaded to
Debian.
Upstream was sensitive about accepting major contributions that
might mean he couldn't relicence it without permission from other
authors, so he wanted the major parts of that kept separate, and
we added only the hooks needed to support it to the main body of
his code. (at some point after that he did change the licence
from BSD to GPL).
- 2010 Upstream proposed replacing that with a mechanism that was
part of the 'upstream' code, and approached me privately to
review his proposed changes. This was the "run a generated script
as root and/or chmod 777 the privileged directory" option.
He then wasn't interested in anything but a rubberstamp acceptance
of that, and I couldn't convince him why that would be Troublesome.
At that point he also deliberately removed the old interfaces that
were necessary to support what we had, and the stalemate began.
- At some point more recently, he broke that mechanism too, then
dropped it completely (which is the change you were looking at).
So now we're back to the pre-1999 option of only having it generated
dynamically, hardcoded to be in the same tree as the static html.
Which was already a fairly strongly condemned practice in the 90's.
So basically, you've now got a choice of "Something worse than doxygen
with no search functionality", or something that's a PITA to make work
at best (you need to let your web server execute CGIs from arbitrary
paths), and a security hole waiting for people to walk through at worst,
and potentially still worse than what you'd get from doxygen anyway.
I haven't audited the most recent code in detail yet, but the older
code and docs used to be full of warnings along the lines of "if you
put this on the public internet, you lose. Don't do that.".
Which doesn't seem like something we really want in a distro package.
That's basically why "just nuke htags now" is starting to look like
a viable, and even sensible, option. But it's tricky to know who
might be upset by that - and we don't have a clear idea of exactly
what we'd really gain elsewhere from that tradeoff, since most of
the people saying "I need a new upstream" haven't actually been
telling us what the real problem is which that fixes, even when I
asked.
It's quite possible that some of those would just need a trivial
patch to what we currently have - but with these latest changes to
htags, I am feeling more and more like the writing is on the wall
for its ultimate demise now - even if upstream isn't accepting
that yet.
But I haven't forgotten the hatemail I got for finally killing off
svgatextmode, a whole decade after its upstream declared it an
obsolete solution, when kms finally made it impossible to keep it
working - so I don't underestimate what some people might cling to.
Cheers,
Ron
Reply to: