Debian Bug report logs - #574947
global: newer release (5.9.2) is available

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Aliaksey Kandratsenka <alk@tut.by>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: global: newer release (3.8.1) is available

Date: Mon, 22 Mar 2010 14:07:43 +0200

Package: global
Version: 5.7.1-1
Severity: wishlist



-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.32.9-alk64 (SMP w/2 CPU cores)
Locale: LANG=be_BY.UTF-8, LC_CTYPE=be_BY.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages global depends on:
ii  libc6                         2.10.2-6   Embedded GNU C Library: Shared lib

global recommends no packages.

Versions of packages global suggests:
ii  apache2-mpm-worker [h 2.2.15-2           Apache HTTP Server - high speed th
ii  doxygen               1.6.3-1            Documentation system for C, C++, J
ii  epiphany-browser [www 2.29.92-1          Intuitive GNOME web browser
ii  fnord [httpd]         1.10-4             yet another small httpd
ii  iceweasel [www-browse 3.5.8-1            Web browser based on Firefox
ii  id-utils              4.2-1              Fast, high-capacity, identifier da
ii  konqueror [www-browse 4:4.3.4-1          KDE 4's advanced file manager, web
ii  lynx                  2.8.8dev.2-1       Text-mode WWW Browser (transitiona
ii  lynx-cur [www-browser 2.8.8dev.2-1       Text-mode WWW Browser with NLS sup
ii  midori [www-browser]  0.2.4-1            fast, lightweight graphical web br
ii  nginx [httpd]         0.7.65-2           small, but very powerful and effic
ii  opera [www-browser]   9.64.2480.gcc4.qt3 The Opera Web Browser
ii  w3m [www-browser]     0.5.2-4            WWW browsable pager with excellent

-- no debconf information

Message #10 received at 574947@bugs.debian.org (full text, mbox, reply):

From: Eric Warmenhoven <warmenhoven@debian.org>

To: 574947@bugs.debian.org

Cc: control@bugs.debian.org

Subject: global: newer release (5.9.2) is available

Date: Thu, 16 Sep 2010 16:28:15 -0700

retitle 574947 global: newer release (5.9.2) is available
thanks

The latest upstream is now 5.9.2. It contains some important bug fixes
for C++ as well as a faster parser.

Message #17 received at 574947@bugs.debian.org (full text, mbox, reply):

From: "R. Andrew Bailey" <bailey@akamai.com>

To: 574947@bugs.debian.org

Subject: global: newer release (5.9.2) is available

Date: Wed, 22 Dec 2010 22:39:05 -0500

[Message part 1 (text/plain, inline)]

Tags: patch

patch for a couple of small changes needed for 5.7.1 -> 5.9.3 update.

htags seems to have changed significantly. I don't use htmake so I haven't
verified that htmake is doing the right thing.

[global-5.9.3.patch (text/plain, attachment)]

Message #22 received at 574947@bugs.debian.org (full text, mbox, reply):

From: "era eriksson" <era@iki.fi>

To: 574947@bugs.debian.org

Cc: control@bugs.debian.org

Subject: Licence changed

Date: Wed, 09 Mar 2011 11:41:07 +0200

tags 574947 +patch
thanks

Also note that debian/copyright should be updated.  Global is now
licensed under GPLv3.

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.

Message #29 received at 574947@bugs.debian.org (full text, mbox, reply):

From: Markus.Grunwald@pruftechnik.com

To: 574947@bugs.debian.org

Subject: Second this

Date: Wed, 29 Jun 2011 13:38:23 +0200

[Message part 1 (text/plain, inline)]

Hello,

I just ran into a problem because of the ancient version of global. 
Fortunately, it was easy to create a 5.9.x debian package with the patch 
from "R. Andrew Bailey".

So please, consider packaging the new version. Thanks!

cu
Markus

[Message part 2 (text/html, inline)]

Message #34 received at 574947@bugs.debian.org (full text, mbox, reply):

From: Thomas Viehweger <patchesThomas.Vie@web.de>

To: 574947@bugs.debian.org

Subject: global: newer release (6.2.4) is available

Date: Sun, 15 Jul 2012 22:19:44 +0200

retitle 574947 global: newer release (6.2.4) is available
severity 574947 important
found 574947 global/5.7.1-2
thanks

Because of the age of the version 5.7.1 the packet becomes more and more 
unusable to browse newer source code.
In my opinion this is the exact description of the severity important.

Regards,
Thomas

Message #39 received at 574947@bugs.debian.org (full text, mbox, reply):

From: Hongzheng Wang <wanghz@gmail.com>

To: 574947@bugs.debian.org

Subject: Any update?

Date: Sun, 17 Feb 2013 11:40:41 -0800

[Message part 1 (text/plain, inline)]

Hi,

The latest version is 6.2.7 which has significant changes from 5.7.1.  Even
global's upstream webpage complains ``Debian's package is too old''.  Hope
the new version can be packaged.

Thank you very much.

Best,
Hongzheng

[Message part 2 (text/html, inline)]

Message #44 received at 574947@bugs.debian.org (full text, mbox, reply):

From: Hongzheng Wang <wanghz@gmail.com>

To: 574947@bugs.debian.org

Subject: Unofficial build

Date: Sun, 17 Feb 2013 20:15:59 -0800

[Message part 1 (text/plain, inline)]

Hi all,

As a temporary solution, I made an unofficial build of version 6.2.7.
The dsc and debian files are attached.

The instruction to build the packages (for users not familiar with
Debian packaging):

step 1:  Install build-essential, devscripts, debhelper,
autotools-dev, libncursesw5-dev, and libncurses5-dev (probably
id-utils and exuberant-ctags as well for their support)
step 2:  Download the original source tarball from
ftp://ftp.gnu.org/pub/gnu/global/global-6.2.7.tar.gz and rename it
into global_6.2.7.orig.tar.gz
step 3:  Download global_6.2.7-1.dsc and global_6.2.7-1.debian.tar.gz
and put them at the same directory as global_6.2.7.orig.tar.gz
step 4:  Run `dpkg-source -x global_6.2.7-1.dsc' to generate directory
global-6.2.7
step 5:  Run `cd global-6.2.7; debuild -us -uc'
If everything goes well, the deb file will be generated at the parent directory.

Best,
Hongzheng

[global_6.2.7-1.dsc (application/octet-stream, attachment)]

[global_6.2.7-1.debian.tar.gz (application/x-gzip, attachment)]

Message #49 received at 574947@bugs.debian.org (full text, mbox, reply):

From: Shigio YAMAGUCHI <shigio@gnu.org>

To: ron@debian.org

Cc: 574947@bugs.debian.org

Subject: Entrusting the job to younger generation

Date: Tue, 26 Mar 2013 08:12:04 +0900

Hello Ron,
 
How about entrusting your job as a maintainer of the GNU GLOBAL package
to younger generation soon? It's easy. You can make the package 'orphaned'.
<http://www.debian.org/devel/wnpp/orphaned>
It is for you and is also for the users in the world.
You don't need to worry about from now on.

Thank you for your big contribution to GNU GLOBAL in your busy schedule.

Regards,
Shigio YAMAGUCHI
-- 
Shigio YAMAGUCHI <shigio@gnu.org>
PGP fingerprint: D1CB 0B89 B346 4AB6 5663  C4B6 3CA5 BBB3 57BE DDA3

Message #54 received at 574947@bugs.debian.org (full text, mbox, reply):

From: Shigio YAMAGUCHI <shigio@gnu.org>

To: 574947@bugs.debian.org

Subject: Re: Entrusting the job to younger generations

Date: Wed, 3 Apr 2013 19:59:59 +0900

Hello all,
I orphaned this package.
Now it is listed in the orphaned package list.
http://www.debian.org/devel/wnpp/orphaned

Regards,
Shigio YAMAGUCHI
-- 
Shigio YAMAGUCHI <shigio@gnu.org>
PGP fingerprint: D1CB 0B89 B346 4AB6 5663  C4B6 3CA5 BBB3 57BE DDA3

Message #59 received at 574947@bugs.debian.org (full text, mbox, reply):

From: Ron <ron@debian.org>

To: Shigio YAMAGUCHI <shigio@gnu.org>, 574947@bugs.debian.org

Subject: Re: Bug#574947: global: newer release is available

Date: Sat, 6 Apr 2013 21:26:38 +1030

Hi Shigio,

Are you aware that Debian is currently frozen for release and has been now
for quite some months?  Now is not the time to be pushing for a major update,
let alone one that changes several options incompatibly with previous releases.

The window for that sort of thing will (hopefully) open again soon, at which
point the major stumbling block becomes something that I know you are aware of,
since we discussed it during the previous merge window ...

I cannot feel comfortable about introducing a new interface for end-users that
requires them to run a freshly generated script, from an unsecured directory,
as root, as part of normal invocation and use, from distro packaged software.

I expressed my concerns about this to you already, and Taisuke Yamada also
proposed some alternatives, all of which you dismissed.

Do you have a new solution for this that might be more acceptable?

If you do I will be glad to consider it for the next release, but so far you
have mentioned nothing further to me about resolving this issue, and you tie
my hands somewhat if you insist this is suitable when it fairly clearly is not.

  Sorry,
  Ron

Message #64 received at 574947@bugs.debian.org (full text, mbox, reply):

From: Shigio YAMAGUCHI <shigio@gnu.org>

To: Ron <ron@debian.org>

Cc: 574947@bugs.debian.org

Subject: Re: Bug#574947: global: newer release is available

Date: Sun, 7 Apr 2013 12:00:27 +0900

On Sat, 6 Apr 2013 21:26:38 +1030
Ron <ron@debian.org> wrote:

Hello Ron,

Thank you for your reply.

> Are you aware that Debian is currently frozen for release and has been now
> for quite some months?  Now is not the time to be pushing for a major update,
> let alone one that changes several options incompatibly with previous releases.

Debian is frozen for five years? It is serious! :-(

> The window for that sort of thing will (hopefully) open again soon, at which
> point the major stumbling block becomes something that I know you are aware of,
> since we discussed it during the previous merge window ...
> 
> I cannot feel comfortable about introducing a new interface for end-users that
> requires them to run a freshly generated script, from an unsecured directory,
> as root, as part of normal invocation and use, from distro packaged software.
> 
> I expressed my concerns about this to you already, and Taisuke Yamada also
> proposed some alternatives, all of which you dismissed.
> 
> Do you have a new solution for this that might be more acceptable?
> 
> If you do I will be glad to consider it for the next release, but so far you
> have mentioned nothing further to me about resolving this issue, and you tie
> my hands somewhat if you insist this is suitable when it fairly clearly is not.

This thread is about 'newer release is available', not one to discuss your proposal.
Sure, I dismissed your proposal. But it is a long time ago. Although I am sorry
about it, both accepting and dismissing are my job. I cannot accept all proposals.
I am also always rejected in other projects. It is an unavoidable thing.

If you believe that your proposal is good, you can orphan this package and make
a fork of GLOBAL in another name, say 'secure-global', to prove your correctness
to the world. In fact, many forks of GLOBAL already exist in Github.

It seems that you make GLOBAL package the hostage to make your proposal accepted.
It is a wrong behavior as a package maintainer. You should not block a way of others
just because it does not become satisfactory. Instead, you can go your own way.
I pray for your success.

Regards,
Shigio YAMAGUCHI
-- 
Shigio YAMAGUCHI <shigio@gnu.org>
PGP fingerprint: D1CB 0B89 B346 4AB6 5663  C4B6 3CA5 BBB3 57BE DDA3

Message #69 received at 574947@bugs.debian.org (full text, mbox, reply):

From: Shigio YAMAGUCHI <shigio@gnu.org>

To: Ron <ron@debian.org>

Cc: 574947@bugs.debian.org

Subject: Re: Bug#574947: global: newer release is available

Date: Mon, 20 May 2013 11:29:54 +0900

Hi Ron,
If you believe there is an serious problem which prevents you
from updating the package, would you please point it out on the
GLOBAL Bug mailing list (bug-global@gnu.org)?
Let's argue about it in the public place.

Regards,
Shigio
-- 
Shigio YAMAGUCHI <shigio@gnu.org>
PGP fingerprint: D1CB 0B89 B346 4AB6 5663  C4B6 3CA5 BBB3 57BE DDA3

Message #74 received at 574947@bugs.debian.org (full text, mbox, reply):

From: Ron <ron@debian.org>

To: Shigio YAMAGUCHI <shigio@gnu.org>

Cc: 574947@bugs.debian.org

Subject: Re: Bug#574947: global: newer release is available

Date: Mon, 27 May 2013 04:30:13 +0930

Hi Shigio,

On Mon, May 20, 2013 at 11:29:54AM +0900, Shigio YAMAGUCHI wrote:
> Hi Ron,
> If you believe there is an serious problem which prevents you
> from updating the package, would you please point it out on the
> GLOBAL Bug mailing list (bug-global@gnu.org)?
> Let's argue about it in the public place.

We already discussed this in detail when you first proposed this
new change and I pointed out why elements of it were showstoppers
for distro deployment.  And we had discussed, and agreed on, the
necessary constraints that any solution needed to satisfy when we
first worked on this problem together many years ago now to make
it suitable for distro users in the first place.

So far as I'm aware nothing has changed about any of that since
our last discussion, so just repeating the same arguments again
isn't likely to be a very productive use of our time.

If you have some new proposal that addresses these concerns though,
then I'll be happy to try and find some time to review and comment
upon that further.

 Ron

Message #79 received at 574947@bugs.debian.org (full text, mbox, reply):

From: Shigio YAMAGUCHI <shigio@gnu.org>

To: Ron <ron@debian.org>

Cc: 574947@bugs.debian.org

Subject: Re: Bug#574947: global: newer release is available

Date: Mon, 27 May 2013 10:45:03 +0900

On Mon, 27 May 2013 04:30:13 +0930
Ron <ron@debian.org> wrote:

> We already discussed this in detail when you first proposed this
> new change and I pointed out why elements of it were showstoppers
> for distro deployment.  And we had discussed, and agreed on, the
> necessary constraints that any solution needed to satisfy when we
> first worked on this problem together many years ago now to make
> it suitable for distro users in the first place.

I have no memory that we reached such an agreement.

The issue you are saying might be about a mechanism about CGI script.
I wrote a RFC (Request for comment) about the issue in the GLOBAL
bug mailing list (bug-global@gnu.org) in 21 Jun 2010.
It is the following:

	Subject:[RFC] Changing the mechanism of the safe CGI script
	Date:	 Mon, 21 Jun 2010 17:14:42 +0900
	<http://lists.gnu.org/archive/html/bug-global/2010-06/msg00008.html>

This was my proposal. You said nothing about it on the mailing list.

I know that you added some modifications to the Debian version of
GLOBAL; It is no problem. However, modifications to the main stream
GLOBAL should be argued in bug-global@gnu.org, that is, a public place
which opened to the world. It is possible even from now.
Of course, you can add the same modifications to new Debian's package.
But you have done the neither at present.

I remember that after the RFC, you told me to adopt your modifications;
I didn't accept it. I'm sorry, if it hurt your heart. But it is an
unavoidable thing. If I accept all the request from everybody, GLOBAL
might become a complicated and mysterious thing.

You have many choices:
o Orphan the package
o Add some modifications and release the package
o Make a fork of GLOBAL
o Make a discussion on bug-global@gnu.org
o ...

I hope you to make a choice soon. I understand that your time is stopped.
But the users is waiting for updating the package for 5 years or more.
Please think of them. A maintainer's position is not the seat of power.

Regards,
Shigio YAMAGUCHI
-- 
Shigio YAMAGUCHI <shigio@gnu.org>
PGP fingerprint: D1CB 0B89 B346 4AB6 5663  C4B6 3CA5 BBB3 57BE DDA3

Message #86 received at 574947@bugs.debian.org (full text, mbox, reply):

From: Vincent Bernat <bernat@debian.org>

To: Ron <ron@debian.org>

Cc: Shigio YAMAGUCHI <shigio@gnu.org>, 574947@bugs.debian.org

Subject: Re: Bug#574947: global: newer release is available

Date: Thu, 14 Nov 2013 09:36:05 +0100

[Message part 1 (text/plain, inline)]

 ❦ 26 mai 2013 21:00 CEST, Ron <ron@debian.org> :

>> Hi Ron,
>> If you believe there is an serious problem which prevents you
>> from updating the package, would you please point it out on the
>> GLOBAL Bug mailing list (bug-global@gnu.org)?
>> Let's argue about it in the public place.
>
> We already discussed this in detail when you first proposed this
> new change and I pointed out why elements of it were showstoppers
> for distro deployment.  And we had discussed, and agreed on, the
> necessary constraints that any solution needed to satisfy when we
> first worked on this problem together many years ago now to make
> it suitable for distro users in the first place.
>
> So far as I'm aware nothing has changed about any of that since
> our last discussion, so just repeating the same arguments again
> isn't likely to be a very productive use of our time.
>
> If you have some new proposal that addresses these concerns though,
> then I'll be happy to try and find some time to review and comment
> upon that further.

Hi Ron!

To my understanding, those discussions were not public. This is rather
difficult to understand why we can't get a newer version of GLOBAL in
Debian. Are the problems limited to the CGI script?
-- 
Replace repetitive expressions by calls to a common function.
            - The Elements of Programming Style (Kernighan & Plauger)

[signature.asc (application/pgp-signature, inline)]

Message #91 received at 574947@bugs.debian.org (full text, mbox, reply):

From: Pranith Kumar <bobby.prani@gmail.com>

To: 574947@bugs.debian.org, ron@debian.org

Subject: Is any update planned for Global?

Date: Thu, 30 Jan 2014 18:26:52 -0500

[Message part 1 (text/plain, inline)]

It's been more than 7 years(?!) since global has been updated on Debian.

Ron, could you please state the reasons why this update is being held back?

Thanks,
-- 
Pranith

[Message part 2 (text/html, inline)]

Message #96 received at 574947@bugs.debian.org (full text, mbox, reply):

From: Punit Agrawal <punitagrawal@gmail.com>

To: 574947@bugs.debian.org

Subject: Working on upgrading to 6.2.11

Date: Tue, 25 Mar 2014 19:16:47 +0000

I have a local version of the package that upgrades to the latest
upstream version - 6.2.11. While installing I seem to be hitting a bug
in emacsen-common (736062). Since this is my first time working on a
debian package any help resolving this issue will be appreciated.

I am hoping I can update the debian package once it's ready. In the
meanwhile if there's interest I could make the package available
somewhere.

Message #101 received at 574947@bugs.debian.org (full text, mbox, reply):

From: Punit Agrawal <punitagrawal@gmail.com>

To: 574947@bugs.debian.org

Cc: Ron <ron@debian.org>, Javi Merino <vicho@debian.org>, Pranith Kumar <bobby.prani@gmail.com>, Vincent Bernat <bernat@debian.org>, Shigio YAMAGUCHI <shigio@gnu.org>

Subject: Status and progress

Date: Wed, 9 Apr 2014 14:38:26 +0100

An update since the last reply.

* I've managed to fix the issue in global related to emacsen-common
while installing the package. Yay! (Note: The emacsen-bug #736062
still needs a fix though).
* The global package development repository has been uploaded to
collab-maint[0] which I'll sync periodically with changes I make
locally.
* The package in the repository has been updated to latest upstream
release - 6.2.12.

Since the package wasn't updated in a long time, I got in touch with
Ron (the package maintainer) to inform him of the above repository and
ask for feedback. I'd also suggested being co-maintainer since I use
global regularly and would like to see it being maintained.

Ron's, rather short, reply pointed out that a distro package requiring
users to run a generated script as root isn't an acceptable interface.
I wasn't quite sure what he was referring to since in all my usage of
global, I've never had to run anything as root.

On digging into the package, I found that one of the binaries in the
package, htags, when run with the '--form' or '--dynamic' and the
'--system-cgi' flag by a user who doesn't have rights to write to
/usr/var/gtags/sitekeys requires them to run a generated script
(bless.sh) as root. In contrast, there are a lot of use cases
(including mine) which don't need any privileged access.

I am not sure how actively this feature is used, but in the interest
of updating the package I proposed to drop generating the script and
print a message for now. I've not received any further reply to my
request for clarification or the proposed changes.

I hope to implement the changes soon after which I'd like to upload the package.

Watch this space for further progress and do let me know if you face
any problems trying to use the package from the linked repository.

[0] http://anonscm.debian.org/gitweb/?p=collab-maint/global.git;a=summary

Message #106 received at 574947@bugs.debian.org (full text, mbox, reply):

From: Shigio YAMAGUCHI <shigio@gnu.org>

To: Punit Agrawal <punitagrawal@gmail.com>

Cc: 574947@bugs.debian.org, Ron <ron@debian.org>, Javi Merino <vicho@debian.org>, Pranith Kumar <bobby.prani@gmail.com>, Vincent Bernat <bernat@debian.org>

Subject: Re: Status and progress

Date: Thu, 10 Apr 2014 09:53:36 +0900

[Message part 1 (text/plain, inline)]

Hello,
2014-04-09 22:38 GMT+09:00 Punit Agrawal <punitagrawal@gmail.com>:
> Ron's, rather short, reply pointed out that a distro package requiring
> users to run a generated script as root isn't an acceptable interface.

It's a misunderstanding. I just offered a means to leave the admin user to
update the system directory (sitekeys directory). It is only a default;
it is not required. You can change it by configure script as follows:

$ ./configure --with-sitekeys-mode=777

This command line executes 'chmod 777 '<localstatedir>/gtags/sitekeys'.

If you have write permission for the directory, you need not invoke
bless.sh after executing htags. Of course, root permission is not required.
Please see 'FILES' section of htags(1).

> I am not sure how actively this feature is used, but in the interest
> of updating the package I proposed to drop generating the script and
> print a message for now. I've not received any further reply to my
> request for clarification or the proposed changes.

Bless.sh script is needed for moving the project directory.
Just making 'sitekeys' directory writable, everything goes well.

#
# Builds a hypertext of a project
#
$ cd /usr/src/project
$ htags -f --system-cgi=key # => CGI works (bless.sh is not needed)

#
# Moves the project to another place
#
$ mv /usr/src/project /home/user # => CGI does not work
$ cd /home/user/project/HTML
$ sh bless.sh # => CGI works (bless.sh is needed)

> Watch this space for further progress and do let me know if you face
> any problems trying to use the package from the linked repository.
>
> [0] http://anonscm.debian.org/gitweb/?p=collab-maint/global.git;a=summary

Great!
I am very glad to hear that new Debian GLOBAL will be released soon.
I appreciate your efforts.

Regards,
Shigio
-- 
Shigio YAMAGUCHI <shigio@gnu.org>
PGP fingerprint: D1CB 0B89 B346 4AB6 5663  C4B6 3CA5 BBB3 57BE DDA3

[Message part 2 (text/html, inline)]

Message #111 received at 574947@bugs.debian.org (full text, mbox, reply):

From: Punit Agrawal <punitagrawal@gmail.com>

To: Shigio YAMAGUCHI <shigio@gnu.org>

Cc: 574947@bugs.debian.org, Ron <ron@debian.org>, Javi Merino <vicho@debian.org>, Pranith Kumar <bobby.prani@gmail.com>, Vincent Bernat <bernat@debian.org>

Subject: Re: Status and progress

Date: Thu, 10 Apr 2014 12:04:22 +0100

Hi Shigio,

Thanks for your reply. Since I don't use the htags functionality I
appreciate your clarifications. I have a

On Thu, Apr 10, 2014 at 1:53 AM, Shigio YAMAGUCHI <shigio@gnu.org> wrote:
> Hello,
> 2014-04-09 22:38 GMT+09:00 Punit Agrawal <punitagrawal@gmail.com>:
>> Ron's, rather short, reply pointed out that a distro package requiring
>> users to run a generated script as root isn't an acceptable interface.
>
> It's a misunderstanding. I just offered a means to leave the admin user to
> update the system directory (sitekeys directory). It is only a default;
> it is not required. You can change it by configure script as follows:
>
> $ ./configure --with-sitekeys-mode=777
>
> This command line executes 'chmod 777 '<localstatedir>/gtags/sitekeys'.
>

I just fixed a bug with packaging which failed to create
'<localstatedir>/gtags/sitekeys'. But...

<localstatedir> resolves to '/usr/var' which throws a lintian warning
as this location doesn't conform to Debian File Hierarchy Standard.
Can you please explain what is the role of this folder and how it is
used? Perhaps there is a more standard debian location where I can
install this to.

> If you have write permission for the directory, you need not invoke
> bless.sh after executing htags. Of course, root permission is not required.
> Please see 'FILES' section of htags(1).
>
>> I am not sure how actively this feature is used, but in the interest
>> of updating the package I proposed to drop generating the script and
>> print a message for now. I've not received any further reply to my
>> request for clarification or the proposed changes.
>
> Bless.sh script is needed for moving the project directory.
> Just making 'sitekeys' directory writable, everything goes well.
>
> #
> # Builds a hypertext of a project
> #
> $ cd /usr/src/project
> $ htags -f --system-cgi=key # => CGI works (bless.sh is not needed)
>
> #
> # Moves the project to another place
> #
> $ mv /usr/src/project /home/user # => CGI does not work
> $ cd /home/user/project/HTML
> $ sh bless.sh # => CGI works (bless.sh is needed)
>

From my understanding, bless.sh writes the location of the current
folder (pwd) into '<localstatedir>/gtags/sitekeys/<key>'. Can you
explain how this information is used then?

>> Watch this space for further progress and do let me know if you face
>> any problems trying to use the package from the linked repository.
>>
>> [0] http://anonscm.debian.org/gitweb/?p=collab-maint/global.git;a=summary
>
> Great!
> I am very glad to hear that new Debian GLOBAL will be released soon.
> I appreciate your efforts.
>

Thanks for your comments. I appreicate your explanation and the
encouragement here.

Punit

> Regards,
> Shigio
> --
> Shigio YAMAGUCHI <shigio@gnu.org>
> PGP fingerprint: D1CB 0B89 B346 4AB6 5663  C4B6 3CA5 BBB3 57BE DDA3

Message #116 received at 574947@bugs.debian.org (full text, mbox, reply):

From: Shigio YAMAGUCHI <shigio@gnu.org>

To: Punit Agrawal <punitagrawal@gmail.com>

Cc: 574947@bugs.debian.org, Ron <ron@debian.org>, Javi Merino <vicho@debian.org>, Pranith Kumar <bobby.prani@gmail.com>, Vincent Bernat <bernat@debian.org>

Subject: Re: Status and progress

Date: Thu, 10 Apr 2014 21:03:55 +0900

[Message part 1 (text/plain, inline)]

Hi Punit,
> <localstatedir> resolves to '/usr/var' which throws a lintian warning
> as this location doesn't conform to Debian File Hierarchy Standard.
> Can you please explain what is the role of this folder and how it is
> used? Perhaps there is a more standard debian location where I can
> install this to.

The role of <localstatedir> is defined in the GNU's standards.
Please see the following site:
http://www.gnu.org/prep/standards/html_node/Directory-Variables.html

Htags uses '<localstatedir>/gtags/sitekeys/' as a database of
project directories.

> From my understanding, bless.sh writes the location of the current
> folder (pwd) into '<localstatedir>/gtags/sitekeys/<key>'. Can you
> explain how this information is used then?

The current folder means 'HTML' directory in the project. Since the
--system-cgi option uses CGI programs in the system area which is
out of the project, the programs need a help for reach there.

Please ask me again, if my explanation is insufficient.
-- 
Shigio YAMAGUCHI <shigio@gnu.org>
PGP fingerprint: D1CB 0B89 B346 4AB6 5663  C4B6 3CA5 BBB3 57BE DDA3

[Message part 2 (text/html, inline)]

Message #121 received at 574947@bugs.debian.org (full text, mbox, reply):

From: Punit Agrawal <punitagrawal@gmail.com>

To: Shigio YAMAGUCHI <shigio@gnu.org>, 574947@bugs.debian.org

Cc: Ron <ron@debian.org>, Javi Merino <vicho@debian.org>, Pranith Kumar <bobby.prani@gmail.com>, Vincent Bernat <bernat@debian.org>

Subject: Re: Bug#574947: Status and progress

Date: Fri, 11 Apr 2014 09:38:54 +0100

Hi Shigio,

Thanks for the explanation.

On Thu, Apr 10, 2014 at 1:03 PM, Shigio YAMAGUCHI <shigio@gnu.org> wrote:
> Hi Punit,
>> <localstatedir> resolves to '/usr/var' which throws a lintian warning
>> as this location doesn't conform to Debian File Hierarchy Standard.
>> Can you please explain what is the role of this folder and how it is
>> used? Perhaps there is a more standard debian location where I can
>> install this to.
>
> The role of <localstatedir> is defined in the GNU's standards.
> Please see the following site:
> http://www.gnu.org/prep/standards/html_node/Directory-Variables.html
>
> Htags uses '<localstatedir>/gtags/sitekeys/' as a database of
> project directories.
>

So the aim is to have a mapping from sitekeys to actual project
directories containing the generated HTML.

>> From my understanding, bless.sh writes the location of the current
>> folder (pwd) into '<localstatedir>/gtags/sitekeys/<key>'. Can you
>> explain how this information is used then?
>
> The current folder means 'HTML' directory in the project. Since the
> --system-cgi option uses CGI programs in the system area which is
> out of the project, the programs need a help for reach there.
>

Ok. Am I correct in understanding that the actual system cgi script is
not provided by global but it is to be created by the user or system
administrator.

I am looking to see if there's an obvious way to package this. I might
resort to turning this feature off in the first update and then add it
to the package as I understand better what is needed on the packaging
side.

> Please ask me again, if my explanation is insufficient.

Thanks for your help. My primary motivation is to update the package
as soon as possible for the majority of the users and then address any
issues incrementally. Your explanation is most helpful.

Punit

> --
> Shigio YAMAGUCHI <shigio@gnu.org>
> PGP fingerprint: D1CB 0B89 B346 4AB6 5663  C4B6 3CA5 BBB3 57BE DDA3

Message #126 received at 574947@bugs.debian.org (full text, mbox, reply):

From: Shigio YAMAGUCHI <shigio@gnu.org>

To: Punit Agrawal <punitagrawal@gmail.com>

Cc: 574947@bugs.debian.org, Ron <ron@debian.org>, Javi Merino <vicho@debian.org>, Pranith Kumar <bobby.prani@gmail.com>, Vincent Bernat <bernat@debian.org>

Subject: Re: Bug#574947: Status and progress

Date: Fri, 11 Apr 2014 19:23:39 +0900

[Message part 1 (text/plain, inline)]

> So the aim is to have a mapping from sitekeys to actual project
> directories containing the generated HTML.

That's right.

> Ok. Am I correct in understanding that the actual system cgi script is
> not provided by global but it is to be created by the user or system
> administrator.

At first, you need to get the CGI scripts by executing htags, and copy
them to the system cgi area. It is required only once.
(The scripts above will become static files in the future.)

$ htags -f ...                                       # in any place
# cp HTML/cgi-bin/*pl /usr/local/apache2/cgi-bin     # required only once

#
# From now on, normal operation
#
$ cd usr/local/src/grep-2.9
$ gtags
$ htags -f --system-cgi=prj1             # 'prj1' is embeded in the form
$ cat /usr/local/var/gtags/sitekeys/prj1
/usr/local/src/grep-2.9/HTML
$ _

[CGI program]
+-----------------------------------------------
|if (key is embeded) {
| Get key => 'prj1'
| Read /usr/local/var/gtags/sitekeys/prj1
| => /usr/local/src/grep-2.9/HTML
| chdir /usr/local/src/grep-2.9/HTML
|}
|Do the job.

> I am looking to see if there's an obvious way to package this. I might
> resort to turning this feature off in the first update and then add it
> to the package as I understand better what is needed on the packaging
> side.

I agree. But I think it is no problem on as is basis, because the use
of this feature is very difficult. I am responsible about it.
It seems that you do not need to take responsibility for it.

Shigio
-- 
Shigio YAMAGUCHI <shigio@gnu.org>
PGP fingerprint: D1CB 0B89 B346 4AB6 5663  C4B6 3CA5 BBB3 57BE DDA3

[Message part 2 (text/html, inline)]

Message #131 received at 574947@bugs.debian.org (full text, mbox, reply):

From: Ron <ron@debian.org>

To: Punit Agrawal <punitagrawal@gmail.com>

Cc: Shigio YAMAGUCHI <shigio@gnu.org>, 574947@bugs.debian.org, Ron <ron@debian.org>, Javi Merino <vicho@debian.org>, Pranith Kumar <bobby.prani@gmail.com>, Vincent Bernat <bernat@debian.org>

Subject: Re: Bug#574947: Status and progress

Date: Fri, 11 Apr 2014 20:01:33 +0930

On Fri, Apr 11, 2014 at 09:38:54AM +0100, Punit Agrawal wrote:
> Hi Shigio,
> 
> Thanks for the explanation.
> 
> On Thu, Apr 10, 2014 at 1:03 PM, Shigio YAMAGUCHI <shigio@gnu.org> wrote:
> > Hi Punit,
> >> <localstatedir> resolves to '/usr/var' which throws a lintian warning
> >> as this location doesn't conform to Debian File Hierarchy Standard.
> >> Can you please explain what is the role of this folder and how it is
> >> used? Perhaps there is a more standard debian location where I can
> >> install this to.
> >
> > The role of <localstatedir> is defined in the GNU's standards.
> > Please see the following site:
> > http://www.gnu.org/prep/standards/html_node/Directory-Variables.html
> >
> > Htags uses '<localstatedir>/gtags/sitekeys/' as a database of
> > project directories.
> >
> 
> So the aim is to have a mapping from sitekeys to actual project
> directories containing the generated HTML.
> 
> >> From my understanding, bless.sh writes the location of the current
> >> folder (pwd) into '<localstatedir>/gtags/sitekeys/<key>'. Can you
> >> explain how this information is used then?
> >
> > The current folder means 'HTML' directory in the project. Since the
> > --system-cgi option uses CGI programs in the system area which is
> > out of the project, the programs need a help for reach there.
> >
> 
> Ok. Am I correct in understanding that the actual system cgi script is
> not provided by global but it is to be created by the user or system
> administrator.

Global creates everything that is needed, but installing it to the system
requires privilege that an ordinary user should not have.  Which means
we need a secure and sensible interface for someone with that privilege
to exercise it, in a way that meets the normal distro expectations and
standards.

A generated script that the user is required to run as root, or making
a privileged system directory 777 writable is not such an interface.

If people want to do that on their own systems that is fine, but the
distro packages should never be recommending or requiring this.

> I am looking to see if there's an obvious way to package this.

There is a mechanism for doing this in the existing package.  If something
equivalent to that was integrated upstream, none of this would be a problem
anymore.


> I might resort to turning this feature off in the first update and then
> add it to the package as I understand better what is needed on the
> packaging side.

NACK.  Saying "I don't need this, so I'm just going to remove it for
everyone else to rush out the bits that _I_ want" is not an acceptable
solution.  If that's all you want then you can make your own local
packages easily enough.


I am very interested in seeing this all fixed, but someone is going to
have to find a middle ground that both meets the minimum sensible
expectations for distro Best Practice for this, and that Shigio is
willing to accept.  Several of us have tried several times, but maybe
you will have more luck with that.

But we need to sort this out.  Sweeping it under the rug is just code
for "This will never happen", so I will strongly object to any upload
that does this.

  Ron

Message #136 received at 574947@bugs.debian.org (full text, mbox, reply):

From: Punit Agrawal <punitagrawal@gmail.com>

To: Ron <ron@debian.org>

Cc: Shigio YAMAGUCHI <shigio@gnu.org>, 574947@bugs.debian.org, Javi Merino <vicho@debian.org>, Pranith Kumar <bobby.prani@gmail.com>, Vincent Bernat <bernat@debian.org>

Subject: Re: Bug#574947: Status and progress

Date: Fri, 11 Apr 2014 12:50:57 +0100

On Fri, Apr 11, 2014 at 11:31 AM, Ron <ron@debian.org> wrote:
> On Fri, Apr 11, 2014 at 09:38:54AM +0100, Punit Agrawal wrote:
>> Hi Shigio,
>>
>> Thanks for the explanation.
>>
>> On Thu, Apr 10, 2014 at 1:03 PM, Shigio YAMAGUCHI <shigio@gnu.org> wrote:
>> > Hi Punit,
>> >> <localstatedir> resolves to '/usr/var' which throws a lintian warning
>> >> as this location doesn't conform to Debian File Hierarchy Standard.
>> >> Can you please explain what is the role of this folder and how it is
>> >> used? Perhaps there is a more standard debian location where I can
>> >> install this to.
>> >
>> > The role of <localstatedir> is defined in the GNU's standards.
>> > Please see the following site:
>> > http://www.gnu.org/prep/standards/html_node/Directory-Variables.html
>> >
>> > Htags uses '<localstatedir>/gtags/sitekeys/' as a database of
>> > project directories.
>> >
>>
>> So the aim is to have a mapping from sitekeys to actual project
>> directories containing the generated HTML.
>>
>> >> From my understanding, bless.sh writes the location of the current
>> >> folder (pwd) into '<localstatedir>/gtags/sitekeys/<key>'. Can you
>> >> explain how this information is used then?
>> >
>> > The current folder means 'HTML' directory in the project. Since the
>> > --system-cgi option uses CGI programs in the system area which is
>> > out of the project, the programs need a help for reach there.
>> >
>>
>> Ok. Am I correct in understanding that the actual system cgi script is
>> not provided by global but it is to be created by the user or system
>> administrator.
>
> Global creates everything that is needed, but installing it to the system
> requires privilege that an ordinary user should not have.  Which means
> we need a secure and sensible interface for someone with that privilege
> to exercise it, in a way that meets the normal distro expectations and
> standards.
>
> A generated script that the user is required to run as root, or making
> a privileged system directory 777 writable is not such an interface.
>
> If people want to do that on their own systems that is fine, but the
> distro packages should never be recommending or requiring this.
>
>> I am looking to see if there's an obvious way to package this.
>
> There is a mechanism for doing this in the existing package.  If something
> equivalent to that was integrated upstream, none of this would be a problem
> anymore.
>

The parameters that htconfig/htmake rely on are not part of upstream
htags. So they are broken with recent releases.

>
>> I might resort to turning this feature off in the first update and then
>> add it to the package as I understand better what is needed on the
>> packaging side.
>
> NACK.  Saying "I don't need this, so I'm just going to remove it for
> everyone else to rush out the bits that _I_ want" is not an acceptable
> solution.  If that's all you want then you can make your own local
> packages easily enough.
>

Turning off a feature is not my preferred option either. I am the one
who's initiated this discussion with the intent of trying to
understand the functionality and how to package it.

>
> I am very interested in seeing this all fixed, but someone is going to
> have to find a middle ground that both meets the minimum sensible
> expectations for distro Best Practice for this, and that Shigio is
> willing to accept.  Several of us have tried several times, but maybe
> you will have more luck with that.
>

The problem arises due to the expectation that the user needs to write
to a priviledged system wide location. Instead, is it not preferable
that the user generated content (the HTML folder and cgi scripts
therein) be placed in the users web area (e.g., ~public_html) and it
is served from there like any other user generated content. No
priviledged access is required. Does that make sense?

> But we need to sort this out.  Sweeping it under the rug is just code
> for "This will never happen", so I will strongly object to any upload
> that does this.
>

Sweeping it under the run isn't my intention. I agree we need to
resolve the issue. I'd appreciate your input on how it can be fixed
properly.

Punit

>   Ron
>
>

Message #141 received at 574947@bugs.debian.org (full text, mbox, reply):

From: Ron <ron@debian.org>

To: Punit Agrawal <punitagrawal@gmail.com>, 574947@bugs.debian.org

Cc: Ron <ron@debian.org>, Shigio YAMAGUCHI <shigio@gnu.org>, Javi Merino <vicho@debian.org>, Pranith Kumar <bobby.prani@gmail.com>, Vincent Bernat <bernat@debian.org>

Subject: Re: Bug#574947: Status and progress

Date: Fri, 11 Apr 2014 22:25:29 +0930

On Fri, Apr 11, 2014 at 12:50:57PM +0100, Punit Agrawal wrote:
> On Fri, Apr 11, 2014 at 11:31 AM, Ron <ron@debian.org> wrote:
> > On Fri, Apr 11, 2014 at 09:38:54AM +0100, Punit Agrawal wrote:
> >> Ok. Am I correct in understanding that the actual system cgi script is
> >> not provided by global but it is to be created by the user or system
> >> administrator.
> >
> > Global creates everything that is needed, but installing it to the system
> > requires privilege that an ordinary user should not have.  Which means
> > we need a secure and sensible interface for someone with that privilege
> > to exercise it, in a way that meets the normal distro expectations and
> > standards.
> >
> > A generated script that the user is required to run as root, or making
> > a privileged system directory 777 writable is not such an interface.
> >
> > If people want to do that on their own systems that is fine, but the
> > distro packages should never be recommending or requiring this.
> >
> >> I am looking to see if there's an obvious way to package this.
> >
> > There is a mechanism for doing this in the existing package.  If something
> > equivalent to that was integrated upstream, none of this would be a problem
> > anymore.
> 
> The parameters that htconfig/htmake rely on are not part of upstream
> htags. So they are broken with recent releases.

Which is why I say "something equivalent".  This was the best that Shigio
and I could come up with together 15 years ago, to meet the needs of doing
this in a way that was suitable for the distro.  I'd like to think that if
anything there would be Better ways to do this today, given the number of
web-appy type things that also exist.


> >> I might resort to turning this feature off in the first update and then
> >> add it to the package as I understand better what is needed on the
> >> packaging side.
> >
> > NACK.  Saying "I don't need this, so I'm just going to remove it for
> > everyone else to rush out the bits that _I_ want" is not an acceptable
> > solution.  If that's all you want then you can make your own local
> > packages easily enough.
> 
> Turning off a feature is not my preferred option either. I am the one
> who's initiated this discussion with the intent of trying to
> understand the functionality and how to package it.

Well, your first reply to my query was "I don't use this, so I could
just turn it off".  And you were still suggesting that as an option.

The equation is pretty simple really - either we solve the problem(s)
that makes this unsuitable for release with the distro, or it remains
unsuitable for release with the distro.


> > I am very interested in seeing this all fixed, but someone is going to
> > have to find a middle ground that both meets the minimum sensible
> > expectations for distro Best Practice for this, and that Shigio is
> > willing to accept.  Several of us have tried several times, but maybe
> > you will have more luck with that.
> 
> The problem arises due to the expectation that the user needs to write
> to a priviledged system wide location. Instead, is it not preferable
> that the user generated content (the HTML folder and cgi scripts
> therein) be placed in the users web area (e.g., ~public_html) and it
> is served from there like any other user generated content. No
> priviledged access is required. Does that make sense?

Well ...  no.  That doesn't make any sense at all.

The cgi scripts run with the privilege of the web server.  Which means
an audited copy of that needs to be installed and enabled by someone
with the privilege to decide whether or not that is acceptable.

And someone with similar privilege needs to decide what files it will
be allowed to access.

Which means all of this needs to:

 a) Not be generated on the fly, so that the sysadmin can actually
    audit it, and know that what they audited is what is running.

 b) Not be world writable.  Which is effectively what you'd be doing
    if you let 'non-static' content run executables from ~pub_html
    with elevated privilege.


None of this is rocket science to do.  It just requires some acceptance
that sane security practices are actually important, and need to be
designed in from the beginning, not handwaved away as "too hard".


> > But we need to sort this out.  Sweeping it under the rug is just code
> > for "This will never happen", so I will strongly object to any upload
> > that does this.
> 
> Sweeping it under the run isn't my intention. I agree we need to
> resolve the issue. I'd appreciate your input on how it can be fixed
> properly.

If it isn't your intention, that's great, but that wasn't what your words
kept saying :)

I, and others, have said many times what is needed to do this sanely,
and the constraints above should not be that hard to satisfy.  What has
so far proved impossible has been convincing Shigio that chmod 777 is
not an acceptable substitute for this.  And I don't really know what else
I can say anymore that might change that.

Shigio, please reconsider.  We have people prepared to spend time on this.
Let's use that to do this properly once and for all.  Let's find an answer
that satisfies both basic security practices, and whatever it is that does
concern you about methods that would do that.  bless.sh and chmod 777 do
not do that, so if you want to progress with this, we need to meet in the
middle somewhere with a modern design using current best practice.

  Ron

Message #146 received at 574947@bugs.debian.org (full text, mbox, reply):

From: Shigio YAMAGUCHI <shigio@gnu.org>

To: Ron <ron@debian.org>

Cc: Punit Agrawal <punitagrawal@gmail.com>, 574947@bugs.debian.org, Javi Merino <vicho@debian.org>, Pranith Kumar <bobby.prani@gmail.com>, Vincent Bernat <bernat@debian.org>

Subject: Re: Bug#574947: Status and progress

Date: Sat, 12 Apr 2014 07:13:48 +0900

[Message part 1 (text/plain, inline)]

2014-04-11 21:55 GMT+09:00 Ron <ron@debian.org>:
> Shigio, please reconsider.  We have people prepared to spend time on this.
> Let's use that to do this properly once and for all.  Let's find an answer
> that satisfies both basic security practices, and whatever it is that does
> concern you about methods that would do that.  bless.sh and chmod 777 do
> not do that, so if you want to progress with this, we need to meet in the
> middle somewhere with a modern design using current best practice.

I don't remember about 15 years before. If you have a proposal about GLOBAL
then you should come to the public place for it, that is, bug-global@gnu.org
,
and explain it so that the members can understand. About the debian's
policy,
I can say nothing other than "Debian's issue should be solved in Debian."

Incidentally, removing the --system-cgi option is a wise judgment, because
it is not so important any longer. It is hardly used. Those who want to use
it will install GLOBAL from the tar archive.

-- 
Shigio YAMAGUCHI <shigio@gnu.org>
PGP fingerprint: D1CB 0B89 B346 4AB6 5663  C4B6 3CA5 BBB3 57BE DDA3

[Message part 2 (text/html, inline)]

Message #151 received at 574947@bugs.debian.org (full text, mbox, reply):

From: Punit Agrawal <punitagrawal@gmail.com>

To: Ron <ron@debian.org>

Cc: 574947@bugs.debian.org, Shigio YAMAGUCHI <shigio@gnu.org>, Javi Merino <vicho@debian.org>, Pranith Kumar <bobby.prani@gmail.com>, Vincent Bernat <bernat@debian.org>

Subject: Re: Bug#574947: Status and progress

Date: Sat, 12 Apr 2014 09:34:10 +0100

On Fri, Apr 11, 2014 at 1:55 PM, Ron <ron@debian.org> wrote:
> On Fri, Apr 11, 2014 at 12:50:57PM +0100, Punit Agrawal wrote:
>> On Fri, Apr 11, 2014 at 11:31 AM, Ron <ron@debian.org> wrote:
>> > On Fri, Apr 11, 2014 at 09:38:54AM +0100, Punit Agrawal wrote:
>> >> Ok. Am I correct in understanding that the actual system cgi script is
>> >> not provided by global but it is to be created by the user or system
>> >> administrator.
>> >
>> > Global creates everything that is needed, but installing it to the system
>> > requires privilege that an ordinary user should not have.  Which means
>> > we need a secure and sensible interface for someone with that privilege
>> > to exercise it, in a way that meets the normal distro expectations and
>> > standards.
>> >
>> > A generated script that the user is required to run as root, or making
>> > a privileged system directory 777 writable is not such an interface.
>> >
>> > If people want to do that on their own systems that is fine, but the
>> > distro packages should never be recommending or requiring this.
>> >
>> >> I am looking to see if there's an obvious way to package this.
>> >
>> > There is a mechanism for doing this in the existing package.  If something
>> > equivalent to that was integrated upstream, none of this would be a problem
>> > anymore.
>>
>> The parameters that htconfig/htmake rely on are not part of upstream
>> htags. So they are broken with recent releases.
>
> Which is why I say "something equivalent".  This was the best that Shigio
> and I could come up with together 15 years ago, to meet the needs of doing
> this in a way that was suitable for the distro.  I'd like to think that if
> anything there would be Better ways to do this today, given the number of
> web-appy type things that also exist.
>
>
>> >> I might resort to turning this feature off in the first update and then
>> >> add it to the package as I understand better what is needed on the
>> >> packaging side.
>> >
>> > NACK.  Saying "I don't need this, so I'm just going to remove it for
>> > everyone else to rush out the bits that _I_ want" is not an acceptable
>> > solution.  If that's all you want then you can make your own local
>> > packages easily enough.
>>
>> Turning off a feature is not my preferred option either. I am the one
>> who's initiated this discussion with the intent of trying to
>> understand the functionality and how to package it.
>
> Well, your first reply to my query was "I don't use this, so I could
> just turn it off".  And you were still suggesting that as an option.
>

I've been using global for over a year now. And in all that usage I've
never had to run anything as root. When you off-handedly mentioned a
generated script being required to be run as root I didn't even know
what you were talking about. Neither did you reply to my query asking
for further clarification.

When faced with this situation and not knowing how to move things
forward I'd suggested turning it off. And Shigio in his reply agrees
that this isn't a bad option as it isn't even used that widely.

> The equation is pretty simple really - either we solve the problem(s)
> that makes this unsuitable for release with the distro, or it remains
> unsuitable for release with the distro.
>

The current package in debian is broken - even the tags functionality
is broken. The problem doesn't exist in upstream release.

I am in favour of solving the problem you point out, but at the same
time I don't agree with holding back a package update which fixes a
problem for users, especially when there isn't a resolution in >3.5
years.

>
>> > I am very interested in seeing this all fixed, but someone is going to
>> > have to find a middle ground that both meets the minimum sensible
>> > expectations for distro Best Practice for this, and that Shigio is
>> > willing to accept.  Several of us have tried several times, but maybe
>> > you will have more luck with that.
>>
>> The problem arises due to the expectation that the user needs to write
>> to a priviledged system wide location. Instead, is it not preferable
>> that the user generated content (the HTML folder and cgi scripts
>> therein) be placed in the users web area (e.g., ~public_html) and it
>> is served from there like any other user generated content. No
>> priviledged access is required. Does that make sense?
>
> Well ...  no.  That doesn't make any sense at all.
>
> The cgi scripts run with the privilege of the web server.  Which means
> an audited copy of that needs to be installed and enabled by someone
> with the privilege to decide whether or not that is acceptable.
>
> And someone with similar privilege needs to decide what files it will
> be allowed to access.
>
> Which means all of this needs to:
>
>  a) Not be generated on the fly, so that the sysadmin can actually
>     audit it, and know that what they audited is what is running.
>
>  b) Not be world writable.  Which is effectively what you'd be doing
>     if you let 'non-static' content run executables from ~pub_html
>     with elevated privilege.
>
>
> None of this is rocket science to do.  It just requires some acceptance
> that sane security practices are actually important, and need to be
> designed in from the beginning, not handwaved away as "too hard".
>
>
>> > But we need to sort this out.  Sweeping it under the rug is just code
>> > for "This will never happen", so I will strongly object to any upload
>> > that does this.
>>
>> Sweeping it under the run isn't my intention. I agree we need to
>> resolve the issue. I'd appreciate your input on how it can be fixed
>> properly.
>
> If it isn't your intention, that's great, but that wasn't what your words
> kept saying :)
>

Only because there doesn't seem to be a resolution in the 3.5 years
that have passed. I'd like to hope that things can move forward from
here.

Punit

Message #156 received at 574947@bugs.debian.org (full text, mbox, reply):

From: Shigio YAMAGUCHI <shigio@gnu.org>

To: Punit Agrawal <punitagrawal@gmail.com>

Cc: Ron <ron@debian.org>, 574947@bugs.debian.org, Javi Merino <vicho@debian.org>, Pranith Kumar <bobby.prani@gmail.com>, Vincent Bernat <bernat@debian.org>

Subject: Re: Bug#574947: Status and progress

Date: Wed, 16 Apr 2014 06:15:37 +0900

[Message part 1 (text/plain, inline)]

2014-04-12 17:34 GMT+09:00 Punit Agrawal <punitagrawal@gmail.com>:
>
> I've been using global for over a year now. And in all that usage I've
> never had to run anything as root. When you off-handedly mentioned a
> generated script being required to be run as root I didn't even know
> what you were talking about. Neither did you reply to my query asking
> for further clarification.
>

There will be no response, even if you are waiting. Instead, how about
making a new package named 'global6'? Such cases are often seen.
e.g.
Python: python, python3
gnupg:  gnupg, gnupg2

Since the present package includes Ron's fine htmake, it should be
considered a special one. So, the new package may co-exist with it.
There is no fear of collisions, because Ron's package is 'global5'
forever. :)
-- 
Shigio YAMAGUCHI <shigio@gnu.org>
PGP fingerprint: D1CB 0B89 B346 4AB6 5663  C4B6 3CA5 BBB3 57BE DDA3

[Message part 2 (text/html, inline)]

Message #161 received at 574947@bugs.debian.org (full text, mbox, reply):

From: Vincent Bernat <bernat@debian.org>

To: Shigio YAMAGUCHI <shigio@gnu.org>

Cc: Punit Agrawal <punitagrawal@gmail.com>, 574947@bugs.debian.org, Ron <ron@debian.org>, Javi Merino <vicho@debian.org>, Pranith Kumar <bobby.prani@gmail.com>

Subject: Re: Bug#574947: Status and progress

Date: Sun, 08 Jun 2014 08:02:56 +0200

 ❦ 16 avril 2014 06:15 +0900, Shigio YAMAGUCHI <shigio@gnu.org> :

> There will be no response, even if you are waiting. Instead, how about
> making a new package named 'global6'? Such cases are often seen.
> e.g.
> Python: python, python3
> gnupg: gnupg, gnupg2
>
> Since the present package includes Ron's fine htmake, it should be
> considered a special one. So, the new package may co-exist with it.
> There is no fear of collisions, because Ron's package is 'global5'
> forever. :)

Unfortunately, because of the conflicting names, it would be
problematic. Ron, will you agree if someone packaged global6 without the
CGI stuff and use of the alternative system to let people choose between
global and global6 for gtags and other commands?

I am using gg-tags in Emacs and the current version of global in Debian
just doesn't work with this mode.
-- 
panic("CPU too expensive - making holiday in the ANDES!");
	2.2.16 /usr/src/linux/arch/mips/kernel/traps.c

Message #166 received at 574947@bugs.debian.org (full text, mbox, reply):

From: Ron <ron@debian.org>

To: Vincent Bernat <bernat@debian.org>, 574947@bugs.debian.org

Cc: Shigio YAMAGUCHI <shigio@gnu.org>, Punit Agrawal <punitagrawal@gmail.com>, Javi Merino <vicho@debian.org>, Pranith Kumar <bobby.prani@gmail.com>

Subject: Re: Bug#574947: Status and progress

Date: Mon, 9 Jun 2014 01:27:10 +0930

Hi Vincent,

On Sun, Jun 08, 2014 at 08:02:56AM +0200, Vincent Bernat wrote:
>  ❦ 16 avril 2014 06:15 +0900, Shigio YAMAGUCHI <shigio@gnu.org> :
> 
> > There will be no response, even if you are waiting. Instead, how about
> > making a new package named 'global6'? Such cases are often seen.
> > e.g.
> > Python: python, python3
> > gnupg: gnupg, gnupg2
> >
> > Since the present package includes Ron's fine htmake, it should be
> > considered a special one. So, the new package may co-exist with it.
> > There is no fear of collisions, because Ron's package is 'global5'
> > forever. :)
> 
> Unfortunately, because of the conflicting names, it would be
> problematic. Ron, will you agree if someone packaged global6 without the
> CGI stuff and use of the alternative system to let people choose between
> global and global6 for gtags and other commands?

That sounds a lot like taking a horrible mess, and making it even more
horrible and messy to me ...

which seems like quite step in the wrong direction.

> I am using gg-tags in Emacs and the current version of global in Debian
> just doesn't work with this mode.

What changed incompatibly to make it not work?  And what would need
patching to fix that?

I'd really much rather see problems get fixed than layered under even
more problems.  If someone familiar with Emacs has some details of what
doesn't work, and what needs to be done so that it will, that sounds
like a separate bug to be addressed to me.

  Cheers,
  Ron

Message #171 received at 574947@bugs.debian.org (full text, mbox, reply):

From: Vincent Bernat <bernat@debian.org>

To: Ron <ron@debian.org>

Cc: 574947@bugs.debian.org, Shigio YAMAGUCHI <shigio@gnu.org>, Punit Agrawal <punitagrawal@gmail.com>, Javi Merino <vicho@debian.org>, Pranith Kumar <bobby.prani@gmail.com>

Subject: Re: Bug#574947: Status and progress

Date: Sun, 08 Jun 2014 18:53:16 +0200

[Message part 1 (text/plain, inline)]

 ❦  9 juin 2014 01:27 +0930, Ron <ron@debian.org> :

>> I am using gg-tags in Emacs and the current version of global in Debian
>> just doesn't work with this mode.
>
> What changed incompatibly to make it not work?  And what would need
> patching to fix that?
>
> I'd really much rather see problems get fixed than layered under even
> more problems.  If someone familiar with Emacs has some details of what
> doesn't work, and what needs to be done so that it will, that sounds
> like a separate bug to be addressed to me.

Some arguments seem to not exist in previous versions. I did not
investigate more as it seems quite sensible for a program to get more
functionalities.

With a recent version:

Usage: global [-adGilnqrstTvx][-e] pattern
       global -c[diIoOPrsT] prefix
       global -f[adlnqrstvx][-L file-list] files
       global -g[aGilnoOqtvVx][-L file-list][-e] pattern [files]
       global -I[ailnqtvx][-e] pattern
       global -P[aGilnoOqtvVx][-e] pattern
       global -p[qrv]
       global -u[qv]

With the version currently in Debian:

Usage: global [-aGilnqrstTvx][-e] pattern
       global -c[qrsv] prefix
       global -f[anqrstvx] files
       global -g[aGilnoOqtvx][-e] pattern
       global -I[ailnqtvx][-e] pattern
       global -P[aGilnoOqtvx][-e] pattern
       global -p[qrv]
       global -u[qv]
-- 
Let the data structure the program.
            - The Elements of Programming Style (Kernighan & Plauger)

[signature.asc (application/pgp-signature, inline)]

Message #176 received at 574947@bugs.debian.org (full text, mbox, reply):

From: Punit Agrawal <punitagrawal@gmail.com>

To: Vincent Bernat <bernat@debian.org>

Cc: Ron <ron@debian.org>, 574947@bugs.debian.org, Shigio YAMAGUCHI <shigio@gnu.org>, Javi Merino <vicho@debian.org>, Pranith Kumar <bobby.prani@gmail.com>

Subject: Re: Bug#574947: Status and progress

Date: Sun, 15 Jun 2014 11:33:15 +0100

Re-iterating what's been said earlier...

On Sun, Jun 8, 2014 at 5:53 PM, Vincent Bernat <bernat@debian.org> wrote:
>  ❦  9 juin 2014 01:27 +0930, Ron <ron@debian.org> :
>
>>> I am using gg-tags in Emacs and the current version of global in Debian
>>> just doesn't work with this mode.

I am using global with the linux kernel source code and the version in
Debian hasn't worked for me since about a year. The binary silently
fails to build the tags. The issue does not exist with upstream
releases.

>>
>> What changed incompatibly to make it not work?  And what would need
>> patching to fix that?
>>
>> I'd really much rather see problems get fixed than layered under even
>> more problems.  If someone familiar with Emacs has some details of what
>> doesn't work, and what needs to be done so that it will, that sounds
>> like a separate bug to be addressed to me.
>
> Some arguments seem to not exist in previous versions. I did not
> investigate more as it seems quite sensible for a program to get more
> functionalities.
>

Indeed! :)

While there doesn't seem to be any motivation to resolve the issues
blocking the package upgrade, I'd like to point you to a package
repository containing an upgrade to recent upstream release (6.2.12) -

http://anonscm.debian.org/gitweb/?p=collab-maint/global.git.

The package is also updated to follow more recent packaging standards.

It would be ideal if the official package got upgraded (or maybe
replaced by another package), but in the meanwhile I'd like to keep
the above repo in-sync with upstream releases. Please let me know if
you face any issues using that version.

Message #185 received at 574947@bugs.debian.org (full text, mbox, reply):

From: Volker Mische <volker.mische@gmail.com>

To: 574947@bugs.debian.org

Subject: Re: Bug#574947: GLOBAL 6.4 release

Date: Sat, 18 Apr 2015 17:20:44 +0200

Hi Ron,

I've read this bug report several times and it took my a while to 
understand what the actual problem is. Do I summarize correctly that the 
problem is a system wide installed CGI script that can serve up the 
gtags information for several independent source code basis and that 
this script needs privileges a normal user shouldn't have?

Given that with the GLOBAL 6.4 release the `--system-cgi` option is 
gone, it's not longer possible to run it system wide. Does it mean that 
the original issue isn't one anymore?

Cheers,
  Volker

Message #190 received at 574947@bugs.debian.org (full text, mbox, reply):

From: Johannes Stezenbach <js@sig21.net>

To: Volker Mische <volker.mische@gmail.com>

Cc: 574947@bugs.debian.org, Ron <ron@debian.org>, Shigio YAMAGUCHI <shigio@gnu.org>

Subject: Re: Bug#574947: GLOBAL 6.4 release

Date: Mon, 29 Jun 2015 12:42:23 +0200

Hi,

On Sat, Apr 18, 2015 at 05:20:44PM +0200, Volker Mische wrote:
> Hi Ron,
> 
> I've read this bug report several times and it took my a while to understand
> what the actual problem is. Do I summarize correctly that the problem is a
> system wide installed CGI script that can serve up the gtags information for
> several independent source code basis and that this script needs privileges
> a normal user shouldn't have?
> 
> Given that with the GLOBAL 6.4 release the `--system-cgi` option is gone,
> it's not longer possible to run it system wide. Does it mean that the
> original issue isn't one anymore?

I've been using the Debian version for a while but now found
that it randomly drops symbols from the tags database when
indexing a large code base like parts of Android AOSP.
(The symbols are there when indexing a smaller part, so
it's not a parser issue.)  This makes the Debian version
unusable.  The current upstream version 6.5 works fine.

However, wrt to the issue blocking Debian from accepting the
update, my understanding is that it is still not fixed,
htags still dynamically generates CGI scripts.

What it should do instead is to have static CGI scripts
which read a generated data file.  So that the CGI scripts
can be reviewed for security and can be installed in a place
where they are protected from modification.
The language here is quite explicit:
http://httpd.apache.org/docs/2.2/misc/security_tips.html#cgi

Personally I don't care about htags so I would be delighted
to see an updated Debian global package which just drops htags.


Johannes

Message #195 received at 574947-done@bugs.debian.org (full text, mbox, reply):

From: Wookey <wookey@wookware.org>

To: 574947-done@bugs.debian.org, 816924-done@bugs.debian.org

Subject: re: global: newer release is available

Date: Thu, 15 Dec 2016 23:29:18 +0000

[Message part 1 (text/plain, inline)]

Global has new maintainers and 6.5.5 has now been uploaded to
unstable. It will hopefully migrate to testing in a week or so.

Please try it out and report bugs.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/

[signature.asc (application/pgp-signature, inline)]

Send a report that this bug log contains spam.