Re: [Groff] Re: PSPIC error - "missing argument"

[Bernd Warken]

On Sun, Jun 16, 2002 at 08:04:06PM +0100, Colin Watson wrote:
> On Sun, Jun 16, 2002 at 12:15:27PM +0100, Ralph Corderoy wrote:
> > That's a shame.  Perhaps next time you make claims such as `groff is
> > full of subtle bugs' and `it is absolutely insecure (buffer-overflows)'
> > you do us the courtesy of backing them up with some facts.  Otherwise,
> > you get a reputation for making unfounded, sensationalist, claims.
> 
> I must say that that sort of claim is rather concerning for those who
> ship groff in an environment where it's sometimes called by setuid
> programs (lpd is an example, IIRC). Am I going to have to backport a lot
> of patches from CVS to 1.18 once Bernd makes his concerns public?
> 
Are you intelligent men or lunatic chickens?  The following assumes
that everyone in the mailing list is able to use her brain, can read,
and is not driven by unconscious fears.  (Otherwise, running `M-x doctor' 
in Emacs might be of help :-)

Don't panic.  The bugs are minor and very old.  It's unlikely that they
will show up in everyday usage - and if so, a user will not notice
in most cases.  Nevertheless, they exist.  I stumbled over some such
bugs when I rewrote the output parser (read the comments in 
libdriver/input.cc before judging).  These libdriver bugs could be
fixed locally within the file without changing the interface.  Other bugs 
will make necessary deeper cuts.  This is not pressing, so just leave it
for groff-2.0.  But be aware that changes are necessary - so please do
not shoot against every little code improvement you do not understand.

As to the security aspects, again do not panic.  Read the 
Secure-Programming-HOWTO before judging about security.  No GNU package
has so far implemented all of the information contained in this document.
But there is a growing awareness of buffer overflows and other insecure
C features.

This HOWTO was validated by industrial programmers in Germany - it was
even enforced by them in a discussion in the press.  So it contains
wisdom; but I am sure that most of you will laugh at it because it
tackles the classical programming style.  You will have to change your
way of thinking - or be eaten by hackers.

Some insecure C features:
- malloc() and friends are insecure.
- printf()/scanf() and friends are insecure.
- '\0'-terminated strings are insecure.
- using `int' for everything is insecure.
etc.

In short, plain C is insecure.  C can be made secure by using very
cryptic constructs, as has been done with the `glib' library (which
we cannot use for groff).  But C++ is generally thought to provide
much more secure features.

Some (hopefully) secure C++ features according to the HOWTO:
- new() for classes.
- single character input/output.
- length controlled, counted string classes.
- strong typing using classes.

Again, you will have to change your way of thinking in order to 
being able to accept this.

The changes will be done in several minimally-invasive steps leading
to temporary code that will be thrown away in later steps.  

As we may not use external libraries I think that a time frame of at 
least two years will be necessary.  So again - relax, but do not oppose
to new things that you are not used to (doing so would be a sign of old 
age).
 
!!!!! Do not answer this letter before you thoroughly have read the
!!!!! Secure-Programming-HOWTO.  I refuse to discuss FBS.

Bernd Warken