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