[GRASS5] Objections to release 5.0.0stable?

[Glynn Clements]

Eric G. Miller wrote:

> > Don't want to put a dampener on things but I just wanted to point out that
> > I think the definition of a release-critical bug seems very vague:
> > (from http://grass.itc.it/codemanagement.html )
> > 
> > A bug is critical (RT: priority 51..100), when it 
> > 
> > 1) breaks other software on the system (or the whole system), or causes
> > serious data loss, or introduces a security hole on  systems where you
> > install the package. 
> 
> Don't know of any serious breakage problems... But, I personally would
> be very cautious about using GRASS in a setting where security concerns
> are high.  I guarantee some tricky hacker could find a way to create a
> buffer overflow if given a chance...

Well, GRASS doesn't include any setuid programs, it doesn't provide
any network services, and the /tmp/grass-<user> directory which
contains the monitor sockets should be mode 700.

However, I wouldn't recommend running any GRASS module on
untrustworthy data, including accessing a world-writable database
(GISDBASE) directory on a system which has untrusted users.

As for GRASSlinks or similar: I don't know how much of GRASS this
uses, or what validation it does on the data which it passes to GRASS. 
But, if it trusts GRASS at all, you may as well be running a public
"rsh" service.

GRASS isn't secure. Actually, it's the opposite of secure. You
wouldn't need to bother with a buffer overflow; exploiting one of the
many unsafe calls to system() would be easier.

> > 2) bug was not present in previous version (features known to be working in 
> > previous versions are broken now). 
> > 
> > In my opinion, point 2 covers a large number of things that aren't in the
> > bug tracker but I regularly read on the mailing list people complaining
> > about modules that haven't been updated to GRASS 5 and aren't working
> > properly. And a bug I put in the bug tracker about all the
> > snprintf() calls that weren't there before---not a problem for me---I can
> > work around it, but still without extra intervention it causes things to
> > break that worked only 6 or 7 months ago. Also the changes to SG3d I
> > mentioned in an e-mail to this list a while back regarding what I feel is 
> > the wrong capitalisation of the GL includes directory being added in to
> > #include directives in some files only this year. I think I could probably
> > think of more examples of a type 2 release-critical bug if I tried.
> 
> Well, there have been few significant changes in the last couple "pre"
> releases.  Yea, some things probably don't work right.  I don't know
> about changes to SG3d, but the capitalization (or lack thereof) of GL
> seems to be an inconsistency beyond the control of GRASS developers.  It
> has been capitilized on Linux for as long as I can remember (which is
> only a couple years).  But, I know it isn't capitalized on some other
> systems.  Perhaps a job for ./configure?

I was under the impression that this is an IrisGL vs OpenGL issue. The
OpenGL headers are absolutely definitely <GL/gl.h> and <GL/glu.h>. 
But, I think that SG3d is IrisGL.

Paul: is this the change to which you are referring:

--- src.contrib/GMSL/SG3d/externs.h	25 Mar 2002 12:17:20 -0000	1.2
+++ src.contrib/GMSL/SG3d/externs.h	18 Apr 2002 12:46:29 -0000	1.3
@@ -37,7 +37,7 @@
 #undef BLACK
 #endif
 
-#include "gl.h"
+#include <GL/gl.h>
 #include "panel.h"
 #include "gis.h"
 
If so, then it appears to be a mistake in something which I did. Some
files were including OpenGL's <GL/gl.h> as <gl.h>, expecting the
compiler's include path to include the GL directory. I may have
"fixed" one file too many.

-- 
Glynn Clements <glynn.clements at virgin.net>