Wookey <wookey@wookware.org> writes: > On 2016-11-30 16:56 +0000, Ian Jackson wrote: > >> On to some questions it raises for me: >> >> > Optionally, "htags" can generate a dynamic index (which reduces disk >> > space usage) but requires an http server setup to be able to serve the >> > pages. In this scenario, you will also need to be able to execute CGI >> > scripts as the symbol lookup is done when serving the http request (as >> > opposed to pre-processed when using static pages). >> > >> > And this last bit (integration with system web server) is the >> > functionality that had security concerns raised by Ron [etc.] >> >> So, to be clear, it is this functionality which is dropped in the >> package that you and Wookey uploaded to experimental/delayed ? > > Said package is available as of today: > https://buildd.debian.org/status/package.php?p=global&suite=experimental > > And that functionality was left in as it was a self-contained patch, > pending determining whether in fact it remained useful/compatible or > not. So you still get htmake and htconfig commands. > > However I have now done some checking, and no it doesn't work any more > because it uses the btreeop command, which has been removed in current > upstream, and the --action option to htags which is also gone. > > We are having a think about whether this code can be hacked about a > bit to remain useful or if its approach is simply no longer relevant, > given upstream changes. And I just said replying to Sam, there is a > lot be said for not diverging significantly from upstream, because > there is significant overhead in doing so. So this patch is currently > likely to get dropped unless someone works out a way to make it > work/be useful. > >> But AIUI this functionality remains: >> >> > In addition to the above mechanisms, upstream also provides "htags" >> > which can be used to generate an HTML version of the index. "htags" >> > uses the index created by "gtags" and the source tree as input and >> > generates html files which allow you to navigate the source code in >> > the browser. By default, htags generates static pages which means you >> > can browse the code in a local browser without requiring a web server. > >> So the impact for a user of the existing functionality the regression >> is not that their entire workflow is disrupted. > >> Rather (unless the software is improved) they have these choices: >> >> - Put up with pregenerated html indices. Is the only downside >> of this that they use additional disk space, and presumably >> cpu time to generate them ? > > Correct. And they can easily be symlinked from say > /var/www/html/global/<package> to make them a) accessible from system > webserver and b) conveniently listed. The static HTML is 7G for a > kernel source tree. The dynamic version is 3.3G. (or 4.8G with the > suggested '--suggest2' options) So there is a x2 space overhead. > >> - Run the htags server on a high-numbered port somehow. (Is there >> some kind of simple scriptery provided, to do this?) > > There is an example in the NEWS file, which should go in the man page. It's trivial: > > cd HTML; python -m CGIHTTPServer > or > cd HTML; python3 -m http.server --cgi > > Then browse to http://localhost:8000/ This functionality is also provided by htags-server(1), which is included in your package: https://www.mankier.com/1/htags-server [BTW htags-server/htags-server.1 should be added to debian/global.manpages] >> - If the machine is not really multi-user, tear down the security >> boundary defending the webserver from their user account, and give >> their user account access to the webserver cgi directory (or plumb >> it in with symlinks). (Are there any instructions or scripts for >> this?) (Also this assumes that the source code is not super >> secret.) > > I've just started playing with this to see what can be done (bearing > in mind the question of how much effort we should put into this sort > of upstream divergence anyway). > > Simply symlinking /var/www/global/sourcetree to <whereever/sourcetree/HTML> from > gives you a convenient list of globalised htags to look through if they are static. > > The issue with dynamic htags (and the search functionality) is that by > default your web server won't run .cgi scripts in arbitrary > directories (for good reasons). I don't know if we can have a central > .cgi that 'sources' the global.cgi or completion.cgi in the htags > sourcetree/HTML dir and uses it, or if that's still not actually a > good idea. > > Possibly something nifty with apache config scripts would work. Suggestions welcome. > >> I don't know much about this, but several of these choices seem likely >> to be plausible choices for many if not most current users of htags. > > Right. I think the functionality upstream provides is fine. It strikes me that users are likely to fall into one of two groups: Local access by users that do not wish to offer remote access and are not offering accounts on the machine to untrusted people -- these users should be well served by htags-server. People offering remote access -- these people can just squander some disk space in order to avoid the questionable CGI setup. I'm failing to be convinced that there is a significant userbase that falls between these two stools. If v6 goes into stretch, there will need to be a NEWS item about htmake and htconfig going away -- that could also mention that, if desperate, one can pin the old version of the package to retain those features. The old package is what they'd be getting otherwise anyway, after all. Anyone that decides that they need to stick with the old version could thus be encouraged to report bugs describing their reasons for doing so, which could then be handled by either making the v6 package satisfy those needs, or by packaging v5 separately, or perhaps ... by doing nothing if such bugs fail to materialise. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/ http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg, GERMANY
Attachment:
signature.asc
Description: PGP signature