Bug#841294: Overrule maitainer of "global" to package a new upstream version
Hi all, Please forgive me one more comment. Mon, 24 Oct 2016 19:31:05 +1030, Ron wrote: > ... and it may well be that this has actually happened now with > upstream's decision to drop all support for providing a secure > system CGI of any form that people can use for this. The upstream > code is basically now back to what it was in the 90's, with the only > way to use this being to allow execution of a generated CGI in the > same tree as the html content. Which was already well known to be a > dangerous and ill advised idiom even back then ... Apache + system CGI is somewhat overdone to use htags. GLOBAL is just a source code tagging tool for developers; it is not a system to publish something to the world. My answer is htags-server(1), a private http server for htags. You should invoke this command for each project like this: $ gtags $ htags --suggest2 $ htags-server Please access at http://127.0.0.1:8000 Python2 http/cgi server Serving HTTP on 127.0.0.1 port 8000 ... You can see the output of htags through 'http://127.0.0.1:8000'. It is easy to use, and is safer because it runs with user's privilege without publishing to the network by default. This command was added to GLOBAL-6.3 in 2014. IMO, it is useless to continue supporting system CGI. It is difficult to set up, and never makes something safer. Regards, Shigio -- Shigio YAMAGUCHI <shi...@gnu.org> PGP fingerprint: D1CB 0B89 B346 4AB6 5663 C4B6 3CA5 BBB3 57BE DDA3 I don't like FUD. -- Anonymous
Bug#841294: Overrule maitainer of "global" to package a new upstream version
Hi, 2016-12-09 18:26 GMT+09:00 Philip Hands <p...@hands.com>: > > open(PIPE, "-|") || exec '@globalpath@', '--result=ctags-xid', > > $flags, $pattern; > > Is it not the case that this last line forks and execs global, passing > $pattern as a parameter to global's -e option, and that $pattern is > untrusted input? Yes. $patern is untrusted input. > Looking at global.c it seems that before it is passed on to popen, it is > run through quote_shell() which quotes any single-quotes in the string. > > That seems to deal with Ron's assertion that it's exploitable, although > I have a slight feeling of impending doom about relying upon just this. I agree. I uses popen() in global.c to call idutils(1). I would like to rewrite it in near future. > Would it not be wise to make the network-facing perl code runnable with > strict and taint turned on, if only to stop people reacting with horror > at first glance? > > I presume patches would be welcome? Of course! Thank you. Regargs, Shigio -- Shigio YAMAGUCHI <shi...@gnu.org> PGP fingerprint: D1CB 0B89 B346 4AB6 5663 C4B6 3CA5 BBB3 57BE DDA3
Bug#841294: Overrule maitainer of "global" to package a new upstream version
Hello all,
2016 23:32:44 +1030, Ron wrote:
> open(PIPE, '@globalpath@' . " --result=ctags-xid $flags $pattern |");
>
> Which for those who don't speak it, is perl for "anyone can execute
> arbitrary shell commands by typing them into a web browser", since
> $pattern is an unsanitised, untrusted, input from the query string.
This code is for Windows; it is not used in UNIX.
Ron's quotation seems to be part of the following code:
--
[global.cgi.tmpl.in] (global-6.5.2)
--
if ($^O eq 'MSWin32') {
open(PIPE, '@globalpath@' . " --result=ctags-xid $flags $pattern
|");
} else {
open(PIPE, "-|") || exec '@globalpath@', '--result=ctags-xid',
$flags, $pattern;
if ($?) {
error_and_exit("Cannot execute global.");
}
}
--
Though I don't recognize it is a security hole on Windows, I don't know
whether
it is true in the future. So, it is commented out in the latest release now.
--
[global.cgi.in] (global-6.5.5)
--
if ($^O eq 'MSWin32') {
#
# This code was commented out, because it may have a security hole
in the
# future. To use this code, please uncomment in your own
responsibility.
#
#open(PIPE, "$global_command" . " --result=ctags-xid $flags
\"$pattern\" |");
error_and_exit("Feature not implemented.");
} else {
open(PIPE, "-|") || exec "$global_command", '--result=ctags-xid',
$flags, $pattern;
if ($?) {
error_and_exit("Cannot execute global.");
}
}
--
Please see the following thread, for the details.
[A CGI security hole on Windows?]
http://lists.gnu.org/archive/html/bug-global/2016-03/msg2.html
2016 19:05:55 +, Wookey wrote:
> The .cgi scripts are generated from .in files which are correctly
> parameterised with @PERLPATH@ and @GLOBALPATH@ etc. Upstream
> unhelpfully ships pre-generated versions with the above arbitrary
> local paths, but we kicked the build to force regeneration of these so
> that all the scripts come out with correct debian paths. That was in
> 6.5.5-0.1 and is in 6.5.5-0.2 (with ctags path set correctly
> too). Please file a bug if we missed any.
It's my mistake. I will fix it soon.
It is helpful if these bug reports are sent to bug-glo...@gnu.org.
Thank you in advance.
Regards,
Shigio
--
Shigio YAMAGUCHI <shi...@gnu.org>
PGP fingerprint: D1CB 0B89 B346 4AB6 5663 C4B6 3CA5 BBB3 57BE DDA3
A long mail is hell.
-- An anonymous philosopher in ancient Greece
Bug#574947: Status and progress
2014-04-12 17:34 GMT+09:00 Punit Agrawal punitagra...@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 shi...@gnu.org PGP fingerprint: D1CB 0B89 B346 4AB6 5663 C4B6 3CA5 BBB3 57BE DDA3
Bug#574947: Status and progress
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 shi...@gnu.org
PGP fingerprint: D1CB 0B89 B346 4AB6 5663 C4B6 3CA5 BBB3 57BE DDA3
Bug#574947: Status and progress
2014-04-11 21:55 GMT+09:00 Ron r...@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-glo...@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 shi...@gnu.org PGP fingerprint: D1CB 0B89 B346 4AB6 5663 C4B6 3CA5 BBB3 57BE DDA3
Bug#574947: Status and progress
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 shi...@gnu.org PGP fingerprint: D1CB 0B89 B346 4AB6 5663 C4B6 3CA5 BBB3 57BE DDA3
Bug#574947: Status and progress
Hello, 2014-04-09 22:38 GMT+09:00 Punit Agrawal punitagra...@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 shi...@gnu.org PGP fingerprint: D1CB 0B89 B346 4AB6 5663 C4B6 3CA5 BBB3 57BE DDA3
Bug#574947: global: newer release is available
On Mon, 27 May 2013 04:30:13 +0930 Ron r...@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-glo...@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/msg8.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-glo...@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-glo...@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 shi...@gnu.org PGP fingerprint: D1CB 0B89 B346 4AB6 5663 C4B6 3CA5 BBB3 57BE DDA3 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#574947: global: newer release is available
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-glo...@gnu.org)? Let's argue about it in the public place. Regards, Shigio -- Shigio YAMAGUCHI shi...@gnu.org PGP fingerprint: D1CB 0B89 B346 4AB6 5663 C4B6 3CA5 BBB3 57BE DDA3 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#574947: global: newer release is available
On Sat, 6 Apr 2013 21:26:38 +1030 Ron r...@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 shi...@gnu.org PGP fingerprint: D1CB 0B89 B346 4AB6 5663 C4B6 3CA5 BBB3 57BE DDA3 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#574947: Entrusting the job to younger generations
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 shi...@gnu.org PGP fingerprint: D1CB 0B89 B346 4AB6 5663 C4B6 3CA5 BBB3 57BE DDA3 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704508: closed by Ron r...@debian.org (O: global -- Source code tagging system)
Hello Ron, The current debian package is based on GLOBAL-5.7.1 which was released 5 years ago (April 21 2008). It's too old. Compared with the old version, the latest version (6.2.8), the quality and efficiency has improved by leaps and bounds. However, many debian users are still using the old one in all innocence. Though this is very unfortunate, you are ignoring the bug reports which say 'new release is available' for a long time. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574947 As a result, you are blocking GLOBAL and the users. Since you did not seem to do maintenance jobs, I said you should orphan the package. But you ignored it. Would you please explain about the followings? o Why don't you update the package using newer upstream version? o Why are you ignoring the bug reports which say 'new release is available'? o What do you plan to do after this? You should fulfill the accountability. My wish is that more debian users can use the facilities of newer GLOBAL. Regards, Shigio YAMAGUCHI On Wed, 03 Apr 2013 14:24:12 + ow...@bugs.debian.org (Debian Bug Tracking System) wrote: This is an automatic notification regarding your Bug report which was filed against the wnpp package: #704508: O: global -- Source code tagging system It has been closed by Ron r...@debian.org. Their explanation is attached below along with your original report. If this explanation is unsatisfactory and you have not received a better one in a separate message then please contact Ron r...@debian.org by replying to this email. -- 704508: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704508 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- Shigio YAMAGUCHI shi...@gnu.org PGP fingerprint: D1CB 0B89 B346 4AB6 5663 C4B6 3CA5 BBB3 57BE DDA3 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704508: O: GNU GLOBAL -- Source code tagging system
Package: wnpp Severity: normal The current maintainer of global, Ron Lee r...@debian.org, is apparently not active anymore. Therefore, I orphan this package now. Maintaining a package requires time and skills. Please only adopt this package if you will have enough time and attention to work on it. If you want to be the new maintainer, please see http://www.debian.org/devel/wnpp/index.html#howto-o for detailed instructions how to adopt a package properly. Some information about this package: Package: global GNU GLOBAL is a source code tagging system that works the same way across diverse environments (emacs, vi, less, bash, web browser, etc). You can locate objects in source files and move there easily. It is useful for hacking a large project containing many sub-directories, many #ifdef and many main() functions. It is similar to ctags or etags but is different from them at the point of independence of any editor. It runs on a UNIX(POSIX) compatible operating system like GNU and BSD. GNU GLOBAL has following features: o support C, C++, Yacc, Java, PHP4 and assembly. (definition and reference) o support 41 languages using Exuberant Ctags. (only definition) o work the same way across diverse environments. Currently, the following environments are supported: - Generic shell command line - Bash shell - Vi clone editor (nvi, elvis, vim) - Emacs editor - Less viewer - Web browser (See UNIX kernel source tour! http://www.tamacom.com/tour/kernel/linux/ - Doxygen documentation system o find locations of specified symbol quickly. o locate not only definitions but also references. o locate paths which matches to a specified pattern. o hierarchical search by default. o search not only in a project but also in library projects. o generate completion list for completing input method. o support various output format. o allows customizing of the set of candidate files to be tagged. o understand POSIX 1003.2 regular expressions. o support idutils as an external search engine. o tag files are independent of machine architecture. o incremental updating of tag files. o plug-in parser is available to treat new languages. o support customizing with 'gtags.conf'. o generate a hypertext of source code (XHTML ready). o compact format to save disk space. o customizing using a configuration file (gtags.conf). o support client/server environment (TRAMP ready). o ignore binary files, dot files and specified files. o symbolic link loop detection. o include cscope compatible program (gtags-cscope). o include grep like command (-g command). For the detail, please see http://www.gnu.org/software/global/ -- Shigio YAMAGUCHI shi...@gnu.org PGP fingerprint: D1CB 0B89 B346 4AB6 5663 C4B6 3CA5 BBB3 57BE DDA3 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#574947: Entrusting the job to younger generation
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 shi...@gnu.org PGP fingerprint: D1CB 0B89 B346 4AB6 5663 C4B6 3CA5 BBB3 57BE DDA3 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
