Bug#841294: Overrule maintainer of "global" to package a new upstream version
On Wed, Nov 30, 2016 at 4:56 PM, Ian Jackson
<ijackson@chiark.greenend.org.uk> wrote:
> Punit Agrawal writes ("Bug#841294: Overrule maintainer of "global" to package a new upstream version"):
>> In offline discussions with Wookey, we came to the realisation that
>> reading the various bug reports (including this one) it is not very
>> clear how global (upstream) is structured, the functionality it
>> provides and bits that are holding back the debian update.
>
> Thank you for your clear and excellent explanation.
>
>
> 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 ?
>
The debian packaging added two tools not present in upstream -
htconfig and htmake. These tools and debian patched htags together
make the integration with system web server work to the extent that
Ron was comfortable shipping the package. Both htmake and htconfig are
authored by Ron.
So although the package uploaded by Wookey retain the tools they have
become non-functional due to upstream changes to htags. But as you
point out, you can still achieve a very similar end result using other
mechanisms.
> 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.
That is exactly what I was trying to get across in my previous email.
>
> 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 ?
There
>
> - Run the htags server on a high-numbered port somehow. (Is there
> some kind of simple scriptery provided, to do this?)
It would be a web server - htags isn't a server in itself. Upstream's
suggestion of using
python -m CGIHTTPServer
in the generated HTML folder worked for the package Wookey has
uploaded. This command can be executed with user privileges and runs a
local instance of an http server.
IIUC, running the web server with user privileges, prevents it from
binding to external interfaces/IP addresses.
>
> - 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.)
So I am not very familiar with cgi scripts (having never used it
myself) but I believe what you say is possible - somebody with a
little more knowledge than me should be easily able to come up with
the instructions.
>
> 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.
>
>
> FAOD none of this changes my view about the proper resolution of this
> TC petition. But answers might help clarify the discussion.
>
> Thanks,
> Ian.
>
> --
> Ian Jackson <ijackson@chiark.greenend.org.uk> These opinions are my own.
>
> If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
> a private address which bypasses my fierce spamfilter.
Reply to: