[Findutils-patches] [PATCH] Addd a maintenance manual

[James Youngman]

---
 ChangeLog           |    5 +
 NEWS                |    3 +
 doc/Makefile.am     |    5 +-
 doc/find-maint.texi |  880 +++++++++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 891 insertions(+), 2 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 4579e9a..3bba3cb 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,10 @@
 2007-06-26  James Youngman  <address@hidden>
 
+       Added a maintenance manual.
+       * doc/find-maint.texi: New file.
+       * doc/Makefile.am (info_TEXINFOS): Added doc/find-main.texi.
+       * doc/find.texi (Introduction): Fixed typo.
+
        * build-aux/src-sniff.py: Detect uses of struct stat where the
        header file was not included.
        * find/find.c: Fix this, and uses of assert without a following
diff --git a/NEWS b/NEWS
index 4ae957b..d4c213e 100644
--- a/NEWS
+++ b/NEWS
@@ -17,6 +17,9 @@ several fields.
 Also explain that when reporting a bug, you should check the most
 recent findutils release first.
 
+Introduced doc/find-maint.texi, a maintenance manual for findutils.
+
+
 * Major changes in release 4.3.8
 
 ** Bug Fixes
diff --git a/doc/Makefile.am b/doc/Makefile.am
index ec70e4f..55b5724 100644
--- a/doc/Makefile.am
+++ b/doc/Makefile.am
@@ -1,5 +1,6 @@
-info_TEXINFOS = find.texi
-find_TEXINFOS = perm.texi getdate.texi regexprops.texi
+info_TEXINFOS = find.texi find-maint.texi
+find_TEXINFOS = perm.texi getdate.texi regexprops.texi 
+find_maint_TEXINFOS = 
 MOSTLYCLEANFILES = find.cps 
 CLEANFILES = find.txt find_mono.html findutils.texi_html_node.tar.gz
 
diff --git a/doc/find-maint.texi b/doc/find-maint.texi
new file mode 100644
index 0000000..a438620
--- /dev/null
+++ b/doc/find-maint.texi
@@ -0,0 +1,880 @@
+\input texinfo @c -*-texinfo-*-
address@hidden %**start of header
address@hidden find-maint.info
address@hidden Maintaining Findutils
address@hidden For double-sided printing, uncomment:
address@hidden @setchapternewpage odd
address@hidden %**end of header
+
address@hidden versionmaint.texi
+
address@hidden
address@hidden
address@hidden iftex
+
address@hidden GNU organization
address@hidden
+* Maintaining Findutils: (find-maint).        Maintaining GNU findutils
address@hidden direntry
+
address@hidden
+This manual explains how GNU findutils is maintained, how changes should
+be made and tested, and what resources exist to help developers.
+
+This is edition @value{EDITION}, for findutils version @value{VERSION}.
+
+Copyright @copyright{} 2007 Free Software Foundation, Inc.
+
+Permission is granted to copy, distribute and/or modify this document
+under the terms of the GNU Free Documentation License, Version 1.2
+or any later version published by the Free Software Foundation;
+with no Invariant Sections, with no
+Front-Cover Texts, and with no Back-Cover Texts.
+A copy of the license is included in the section entitled ``GNU
+Free Documentation License''.
address@hidden copying
+
address@hidden
address@hidden Maintaining Findutils
address@hidden Edition @value{EDITION}, for GNU findutils version 
@value{VERSION}
address@hidden @value{UPDATED}
address@hidden by James Youngman
+
address@hidden
address@hidden 0pt plus 1filll
address@hidden
address@hidden titlepage
+
address@hidden
+
address@hidden
address@hidden Top, Introduction, (dir), (dir)
address@hidden Maintaining GNU Findutils
+
address@hidden
address@hidden ifnottex
+
address@hidden
+* Introduction::
+* Maintaining GNU Programs::
+* General Considerations::
+* Tools::
+* Using the GNU Portability Library::
+* Documentation::
+* Testing::
+* Bugs::
+* Distributions::
+* Internationalisation::
+* Security::
+* Making Releases::
address@hidden menu
+
+
+
+
+
address@hidden Introduction
address@hidden Introduction
+
+This document explains how to contribute to and maintain GNU
+Findutils.  It concentrates on developer-specific issues.  For
+information about how to use the software please refer to
address@hidden, ,Introduction,find,The Findutils manual}.
+
+This manual aims to be useful without necessarily being verbose.  It's
+also a recent document, so there will be a many areas in which
+improvements can be made.  If you find that the document misses out
+important information ot any part of the document is be so terse as to
+be unuseful, please ask for help on the @email{bug-findutils@@gnu.org}
+mailing list.  We'll try to improve this document too.
+
+
address@hidden Maintaining GNU Programs
address@hidden Maintaining GNU Programs
+
+GNU Findutils is part of the GNU Project and so there are a number of
+documents which set out standards for the maintenance of GNU
+software.  
+
address@hidden @file
address@hidden standards.texi
+GNU Project Coding Standards.  All changes to findutils should comply
+with these standards.  In some areas we go somewhat beyond the
+requirements of the standards, but these cases are explained in this
+manual.
address@hidden maintain.texi
+Information for Maintainers of GNU Software.  This document provides
+guidance for GNU maintainers.  Everybody with commit access should
+read this document.   Everybody else is welcome to do so too, of
+course.
address@hidden table
+
+
+
address@hidden General Considerations
address@hidden General Considerations
+
+The findutils package is installed on many many systems, usually as a
+fundamental component.  The programs in the package are often used in
+order to successfully boot or fix the system.
+
+This fact means that for findutils we bear in mind considerations that
+may not apply so much as for other packages.  For example, the fact
+that findutils is often a base component motivates us to
address@hidden
address@hidden Limit dependencies on libraries
address@hidden Avoid dependencies on other large packages (for example, 
interpreters)
address@hidden Be conservative when making changes to the 'stable' release 
branch
address@hidden itemize
+
+All those considerations come before functionality.  Functional
+enhancements are still made to findutils, but these are almost
+exclusively introduced in the 'development' release branch, to allow
+extensive testing and proving.
+
+Sometimes it is useful to have a priority list to provide guidance
+when making design trade-offs.   For findutils, that priority list is:
+
address@hidden
address@hidden Correctness
address@hidden Standards compliance
address@hidden Security
address@hidden Backward compatibility
address@hidden Performance
address@hidden Functionality
address@hidden enumerate
+
+For example, we support the @code{-exec} action because POSIX
+compliance requires this, even though there are security problems with
+it and we would otherwise prefer people to use @code{-execdir}.  There
+are also cases where some performance is sacrificed in the name of
+security.  For example, the sanity checks that @code{find} performs
+while traversing a directory tree may slow it down.   We adopt
+functional changes, and functional changes are allowed to make
address@hidden slower, but only if there is no detectable impact on users
+who don't use the feature.  
+
+Backward-incompatible changes do get made in order to comply with
+standards (for example the behaviour of @code{-perm -...} changed in
+order to comply with POSIX).  However, they don't get made in order to
+provide better ease of use; for example the semantics of @code{-size
+-2G} are almost always unexpected by users, but we retain the current
+behaviour because of backward compatibility and for its similarity to
+the block-rounding behaviour of @code{-size -30}.  We might introduce
+a change which does not have the unfortunate rounding behaviour, but
+we would choose another syntax (for example @code{-size '<2G'}) for
+this.
+
+
+
address@hidden Installed on many systems
address@hidden Often part of base
address@hidden Needs to work on broken systems (e.g. unresponsive NFS servers,
address@hidden mode-0 files)
+
address@hidden Tools
address@hidden Tools
+Most of the tools required to build findutils are mentioned in the
+file @file{README-CVS}.  We also use some other tools:
+
address@hidden
address@hidden System call traces
+Much of the execution time of find is spent waiting for filesystem
+operations.  A system call trace (for example, that provided by
address@hidden) shows what system calls are being made.   Using this
+information we can work to remove unnecessary file system operations.
+
address@hidden Valgrind
+Valgrind is a tool which dynamically verifies the memory accesses a
+program makes to ensure that they are valid (for example, that the
+behaviour of the program does not in any way depend on the contents of
+uninitialised memory).  
+
address@hidden DejaGnu
+DejaGnu is the test framework used to run the findutils test suite
+(the @code{runtest} program is part of DejaGnu).  It would be ideal if
+everybody building @code{findutils} also ran the test suite, but many
+people don't have DejaGnu installed.  When changes are made to
+findutils, DejaGnu is invoked a lot. @xref{Testing}, for more
+information. 
address@hidden itemize
+
address@hidden Using the GNU Portability Library
address@hidden Using the GNU Portability Library
+The Gnulib library (@url{http://www.gnu.org/software/gnulib/}) makes a
+variety of systems look more like a GNU/Linux system and also applies
+a bunch of qutomatic bug fixes and workarounds.  Some of these also
+apply to GNU/Linux systems too.  For example, the Gnulib regex
+implementation is used when we determine that we are building on a
+GNU libc system with a bug in the regex implementation.
+
+
address@hidden How and Why we Import the Gnulib Code
+Gnnulib does not have a release process which results in a source
+tarball you can download.  Instead, the code is simply made available
+by CVS.  
+
+GNU projects vary in how they interact with Gnulib.  Many import a
+selection of code from Gnulib into the working directory and then
+check the updated files into the CVS repository for their project.
+The coreutils project does this, for example.
+
+At the last maintainer changeover for findutils (2003) it turned out
+that there was a lot of material in findutils in common with gnulib,
+but it had not been updated in a long time.  It was difficult to
+figure out which source files were intended to track external sources
+and which were intended to contain incompatible changes, or diverge
+for other reasons.
+
+To reduce this uncertainty, I decided to treat Gnulib much like
+Automake.  Files supplied by Automake are simply absent from the
+findutils source tree.  When Automake is run with @code{automake
+--add-missing --copy}, it adds in all the files it thinks should be
+there which aren't there already.
+
+An analogous approach is taken with Gnulib.  The Gnulib code is
+imported from the CVS repository for Gnulib with a findutils helper
+script, @code{import-gnulib.sh}.  That script fetches a copy of the
+Gnulib code into the subdirectory @file{gnulib-cvs} and then runs
address@hidden  The @code{gnulib-tool} program copies the
+required parts of Gnulib into the findutils source tree in the
+subdirectory @file{gnulib}.  This process gives us the property that
+the code in @file{gnulib} and @code{gnulib-cvs} is not included in the
+findutils CVS tree.   Both directories are listed in @file{.cvsignore}
+and so CVS ignores them.
+
+Findutils does not use all the Gnulib code.  The modules we need are
+listed in the file @file{import-gnulib.config}.  The same file also
+indicates the version of Gnulib that we want to use.  Since Gnulib has
+no actual release process, we just use a date.  Both
address@hidden and @file{import-gnulib.config} are in the
+findutils CVS repository.
+
+The upshot of all this is that we can use the findutils CVS repository
+to track which version of Gnulib every findutils release uses.  That
+information is also provided when the user invokes a findutils program
+with the @samp{--version} option.  It also means that if a file exists
+in the Findutils CVS repository, you can be certain that the file
+exists in the CVS repository and is different from a similar file
+elsewhere, it's for a reason.
+
+There are a small number of exceptions to this; the standard
+boiler-plate GNU files such as @file{ABOUT-NLS}, @file{INSTALL} and
address@hidden
+
+
address@hidden How We Fix Gnulib Bugs
+If we always directly import the Gnulib code directly from the CVS
+repository in this way, it is impossible to maintain a locally
+different copy of Gnulib.  This is often a benefit in that accidental
+version skew is prevented.
+
+However, sometimes we want deliberate version skew in order to use a
+findutils-specific patched version of a Gnulib file, for example
+because we fixed a bug.  
+
+Gnulib is used by quite a number of GNU projects, and this means that
+it gets plenty of testing.  Therefore there are relatively few bugs in
+the Gnulib code, but it does happen from time to time.
+
+However, since there is no waiting around for a Gnulib source release
+tarball, Gnulib bugs are generally fixed quickly.  Here is an outline
+of the way we would contribute a fix to Gnulib (assuming you know it
+is not already fixed in current Gnulib CVS):
+
address@hidden @asis
address@hidden Check you already completed a copyright assignment for Gnulib
address@hidden Begin with a vanilla CVS tree
+Download the Findutils source code from CVS (or use the tree you have
+already)
address@hidden Check out a copy of the Gnulib source
+An easy way to do this is to simply use @code{cp -ar} on the
address@hidden directory.   Have the Gnulib code checked out
+somewhere @emph{outside} your working CVS tree for findutils.
address@hidden Import Gnulib from your local copy
+The @code{import-gnulib.sh} tool has a @samp{-d} option which you can
+use to import the code from a local copy of Gnulib.
address@hidden Build findutils
+Build findutils and run the test suite, which should pass.  In our
+example we assume you have just noticed a bug in gnulib, not that
+recent gnulib changes broke the findutils regression tests.  
address@hidden Write a test case
+If in fact gnulib did break the findutils regression tests, you can probably
+skip this step, since you already have a test case demonstrating the problem.
+Otherwise, write a findutils test case for the bug and/or a Gnulib test case.
address@hidden Fix the Gnulib bug
+Make sure your editor follows symbolic links so that your changes to
address@hidden/...} actually affect the files in the CVS working
+directory you checked out earlier.   Observe that your test now passes.
address@hidden Prepare a Gnulib patch
+Use @code{cvs -z3 diff -upN} to prepare the patch.  Write a ChangeLog
+entry and prepend this to the patch.  Check that the patch conforms
+with the GNU coding standards, and email it to the Gnulib mailing
+list.  
address@hidden Wait for the patch to be applied
+Once your bugfix has been applied, you can update your local directory
+from CVS, re-import the code into Findutils (still using the @code{-d}
+option), and re-run the tests.  This verifies that the fix the Gnulib
+team made actually fixes your problem.  
address@hidden Reimport the Gnulib code
+Update the findutils file @file{import-gnulib.config} to specify a
+date which is after the point at which the bugfix was comitted to
+Gnulib.  Finally, re-import the Gnulib code directly from CVS and run
+the tests again.  This verifies that there was no remaining local
+change that we were relying on to fix the bug.
address@hidden table
+
address@hidden Documentation
address@hidden Documentation
+
+The findutils CVS tree includes several different types of
+documentation.
+
address@hidden User Documentation
+User-oriented documentation such as
address@hidden,,Introduction,find,The Findutils manual} and the
+manual pages for the various findutils programs are the primary
+documentation.  
+
+Please make sure both sets of documentation are updated if you make a
+change to the code.  The GNU coding standards do not normally call for
+mantaining manual pages on the grounds of effort duplication.
+However, the manual page format is more convenient for quick
+reference, and so it's worth maintaining both types of documentation.
+However, the manual pages are normally rather more terse than the
+Texinfo documentation.
+
+
address@hidden Build Guidance
+
address@hidden @file
address@hidden ABOUT-NLS
+Describes the Free Translation Project, the translation status of
+various GNU projects, and how to participate by translating an
+application.  
address@hidden AUTHORS
+Lists the authors of findutils.
address@hidden COPYING
+The copyright license covering findutils; currently, the GNU GPL,
+version 2.
address@hidden INSTALL
+Generic installation instructions for installing GNU programs.
address@hidden README
+Information about how to compile findutils in particular
address@hidden README-alpha
+A README file which is included with testing releases of findutils.
address@hidden README-CVS
+Describes how to build findutils from the code in CVS.
address@hidden THANKS
+Thanks for people who contributed to findutils.  Generally, if
+someone's contribution was significant enough to need a copyright
+assignment, their name should go in here.
address@hidden TODO
+Mainly obsolete.
address@hidden table
+
+
address@hidden Release Information
address@hidden @file
address@hidden NEWS
+Enumerates the user-visible change in each release.  Typical changes
+are fixed bugs, functionality changes and documentation changes.
address@hidden ChangeLog
+This file enumerates all changes to the findutils source code (with
+the possible exception of @file{.cvsignore} and @code{.gitignore}
+changes).  
address@hidden table
+
address@hidden Testing
address@hidden Testing
+This chapter will explain the general procedures for adding tests to
+the test suite, and the functions defined in the findutils-specific
+DejaGnu configuration.  Where appropriate references will be made to
+the DejaGnu documentation.
+
address@hidden Bugs
address@hidden Bugs
+
+Bugs are logged in the Savannah bug tracker
address@hidden://savannah.gnu.org/bugs/?group=findutils}.  The tracker
+offers several fields but their use is largely obvious.  The
+life-cycle of a bug is like this:
+
+
address@hidden @asis
address@hidden Open
+Someone, usually a maintainer, a distribution maintainer or a user,
+creates a bug by filling in the form.   They fill in field values as
+they see fit.  This will generate an email to
address@hidden@@gnu.org}.  
+
address@hidden Triage
+The bug hangs around with @samp{Status=None} until someone begins to
+work on it.  At that point they set the ``Assigned To'' field and will
+sometimes set the status to @samp{In Progress}, especially if the bug
+will take a while to fix.
+
address@hidden Non-bugs
+Quite a lot of reports are not actually bugs; for these the usual
+procedure is to explain why the problem is not a bug, set the status
+to @samp{Invalid} and close the bug.   Make sure you set the
address@hidden to} field to yourself before closing the bug.
+
address@hidden Fixing
+When you commit a bugfix into CVS (or in the case of a contributed
+patch, commit the change), mark the bug as @samp{Fixed}.  Make sure
+you include a new test case where this is relevant.  If you can figure
+out which releases are affected, please also set the @samp{Release}
+field to the earliest release which is affected by the bug.
+Indicate which source branch the fix is included in (for example,
+4.2.x or 4.3.x).  Don't close the bug yet.
+
address@hidden Release
+When a release is made which includes the bug fix, make sure the bug
+is listed in the NEWS file.  Once the release is made, fill in the
address@hidden Release} field and close the bug.
address@hidden table
+
+
address@hidden Distributions
address@hidden Distributions
+Almost all GNU/Linux distributions include findutils, but only some of
+them have a package maintainer who is a member of the mailing list.
+Distributions don't often feed back patches to the
address@hidden@@gnu.org} list, but on the other hand many of
+their patches relate only to standards for file locations and so
+forth, and are therefore distirbution specific.  On an irregular basis
+I check the current patches being used by one or two distributions,
+but the total number of GNU/Linux distributions is large enough that
+we could not hope to cover them all.
+
+Often, bugs are raised against a distribution's bug tracker instead of
+GNU's.    Periodically (about every six months) I take a look at some
+of the more accessible bug trackers to indicate which bugs have been
+fixed upstream.  
+
+Many distributions include both findutils and the slocate package,
+which provides a replacement @code{locate}.  
+
+
address@hidden Internationalisation
address@hidden Internationalisation
+Translation is essentially automated from the maintainer's point of
+view.  The TP mails the maintainer when a new PO file is available,
+and we just download it and check it in.  We copy the @file{.po} files
+into the CVS repository.  For more information, please see
address@hidden://www.iro.umontreal.ca/translation/HTML/domain-findutils.html}.
+
+
address@hidden Security
address@hidden Security
+
+See @ref{Security Considerations, ,Security Considerations,find,The
+Findutils manual}, for a full description of the findutils approach to
+security considerations and discussion of particular tools.
+
+If someone reports a security bug publicly, we should fix this as
+rapidly as possible.  If necessary, this can mean issuing a fixed
+release containing just the one bugfix.  We try to avoid issuing
+releases which include both significant security fixes and functional
+changes.  
+
+Where someone reports a security problem privately, we generally try
+to construct and test a patch without checking the intermediate code
+in.  Once everything has been tested, this allows us to commit a patch
+and immediately make a release.   The advantage of doing things this
+way is that we avoid situations where people watching for CVS commits
+can figure out and exploit a security problem before a fixed release
+is available. 
+
+If the security problem is serious, send an alert to
address@hidden@@lst.de}.  The members of the list include most
+GNU/Linux distributions.  The point of doing this is to allow them to
+prepare to release your security fix to their customers, once the fix
+becomes available.    Here is an example alert:-
+
address@hidden
+-----BEGIN PGP SIGNED MESSAGE-----
+Hash: SHA1
+
+GNU findutils heap buffer overrun (potential privilege escalation)
+
+$Revision: 1.5 $; $Date: 2007/05/28 21:15:25 $
+
+
+I. BACKGROUND
+=============
+
+GNU findutils is a set of programs which search for files on Unix-like
+systems.  It is maintained by the GNU Project of the Free Software
+Foundation.  For more information, see
+http://www.gnu.org/software/findutils.
+
+
+II. DESCRIPTION
+===============
+
+When GNU locate reads filenames from an old-format locate database,
+they are read into a fixed-length buffer allocated on the heap.
+Filenames longer than the 1026-byte buffer can cause a buffer overrun.
+The overrunning data can be chosen by any person able to control the
+names of filenames created on the local system.  This will normally
+include all local users, but in many cases also remote users (for
+example in the case of FTP servers allowing uploads).
+
+III. ANALYSIS
+=============
+
+Findutils supports three different formats of locate database, its
+native format "LOCATE02", the slocate variant of LOCATE02, and a
+traditional ("old") format that locate uses on other Unix systems.
+
+When locate reads filenames from a LOCATE02 database (the default
+format), the buffer into which data is read is automatically extended
+to accomodate the length of the filenames.
+
+This automatic buffer extension does not happen for old-format
+databases.  Instead a 1026-byte buffer is used.  When a longer
+pathname appears in the locate database, the end of this buffer is
+overrun.  The buffer is allocated on the heap (not the stack).
+
+If the locate database is in the default LOCATE02 format, the locate
+program does perform automatic buffer extension, and the program is
+not vulnerable to this problem.  The software used to build the
+old-format locate database is not itself vulnerable to the same
+attack.
+
+Most installations of GNU findutils do not use the old database
+format, and so will not be vulnerable.
+
+
+IV. DETECTION
+=============
+
+Software
+- --------
+All existing releases of findutils are affected.
+
+
+Installations
+- -------------
+
+To discover the ongest path name on a given system, you can use the
+following command (requires GNU findutils and GNU coreutils):
+
+find / -print0 | tr -c '\0' 'x' | tr '\0' '\n' | wc -L
+
+
+V. EXAMPLE
+==========
+
+This section includes a shell script which determines which of a list
+of locate binaries is vulnerable to the problem.  The shell script has
+been tested only on glibc based systems having a mktemp binary.
+
+NOTE: This script deliberately overruns the buffer in order to
+determine if a binary is affected.  Therefore running it on your
+system may have undesirable effects.  We recommend that you read the
+script before running it.
+
+#! /bin/sh
+set +m
+if vanilla_db="$(mktemp nicedb.XXXXXX)" ; then
+    if updatedb --prunepaths="" --old-format --localpaths="/tmp" \
+       --output="address@hidden@}" ; then
+       true
+    else
+       rm -f "address@hidden@}"
+       vanilla_db=""
+       echo "Failed to create old-format locate database; skipping the sanity 
checks" >&2
+    fi
+fi
+
+make_overrun_db() @{
+    # Start with a valid database
+    cat "address@hidden@}"
+    # Make the final entry really long
+    dd if=/dev/zero  bs=1 count=1500 2>/dev/null | tr '\000' 'x'
address@hidden
+
+
+
+ulimit -c 0
+
+usage() @{ echo "usage: $0 binary [binary...]" >&2; exit $1; @}
+[ $# -eq 0 ] && usage 1
+
+bad=""
+good=""
+ugly=""
+if dbfile="$(mktemp nasty.XXXXXX)"
+then
+    make_overrun_db > "$dbfile"
+    for locate ; do
+      ver="$locate = $("$locate"  --version | head -1)"
+      if [ -z "$vanilla_db" ] || "$locate" -d "$vanilla_db" "" >/dev/null ; 
then
+         "$locate" -d "$dbfile" "" >/dev/null
+         if [ $? -gt 128 ] ; then
+             bad="$bad
+vulnerable: $ver"
+         else
+             good="$good
+good: $ver"
+         fi
+       else
+         # the regular locate failed
+         ugly="$ugly 
+buggy, may or may not be vulnerable: $ver"
+       fi
+    done
+    rm -f "address@hidden@}" "address@hidden@}"
+    # good: unaffected.  bad: affected (vulnerable).  
+    # ugly: doesn't even work for a normal old-format database.
+    echo "$good"
+    echo "$bad"
+    echo "$ugly"
+else
+  exit 1
+fi
+
+
+
+
+
+VI. VENDOR RESPONSE
+===================
+
+The GNU project discovered the problem while 'locate' was being worked
+on; this is the first public announcement of the problem.
+
+The GNU findutils mantainer has issued a patch as p[art of this
+announcement.  The patch appears below.
+
+A source release of findutils-4.2.31 will be issued on 2007-05-30.
+That release will of course include the patch.  The patch will be
+committed to the public CVS repository at the same time.  Public
+announcements of the release, including a description of the bug, will
+be made at the same time as the release.
+
+A release of findutils-4.3.x will follow and will also include the
+patch.
+
+
+VII. PATCH
+==========
+
+This patch should apply to findutils-4.2.23 and later.
+Findutils-4.2.23 was released almost two years ago.
+
+Index: locate/locate.c
+===================================================================
+RCS file: /cvsroot/findutils/findutils/locate/locate.c,v
+retrieving revision 1.58.2.2
+diff -u -p -r1.58.2.2 locate.c
+- --- locate/locate.c  22 Apr 2007 16:57:42 -0000      1.58.2.2
++++ locate/locate.c    28 May 2007 10:18:16 -0000
+@@@@ -124,9 +124,9 @@@@ extern int errno;
+ 
+ #include "locatedb.h"
+ #include <getline.h>
+- -#include "../gnulib/lib/xalloc.h"
+- -#include "../gnulib/lib/error.h"
+- -#include "../gnulib/lib/human.h"
++#include "xalloc.h"
++#include "error.h"
++#include "human.h"
+ #include "dirname.h"
+ #include "closeout.h"
+ #include "nextelem.h"
+@@@@ -468,10 +468,36 @@@@ visit_justprint_unquoted(struct process_
+   return VISIT_CONTINUE;
+ @}
+ 
++static void
++toolong (struct process_data *procdata)
address@hidden
++  error (1, 0,
++       _("locate database %s contains a "
++         "filename longer than locate can handle"),
++       procdata->dbfile);
address@hidden
++
++static void
++extend (struct process_data *procdata, size_t siz1, size_t siz2)
address@hidden
++  /* Figure out if the addition operation is safe before performing it. */
++  if (SIZE_MAX - siz1 < siz2)
++    @{
++      toolong (procdata);
++    @}
++  else if (procdata->pathsize < (siz1+siz2))
++    @{
++      procdata->pathsize = siz1+siz2;
++      procdata->original_filename = x2nrealloc (procdata->original_filename,
++                                              &procdata->pathsize,
++                                              1);
++    @}
address@hidden
++
+ static int
+ visit_old_format(struct process_data *procdata, void *context)
+ @{
+- -  register char *s;
++  register size_t i;
+   (void) context;
+ 
+   /* Get the offset in the path where this path info starts.  */
+@@@@ -479,20 +505,35 @@@@ visit_old_format(struct process_data *pr
+     procdata->count += getw (procdata->fp) - LOCATEDB_OLD_OFFSET;
+   else
+     procdata->count += procdata->c - LOCATEDB_OLD_OFFSET;
++  assert(procdata->count > 0);
+ 
+- -  /* Overlay the old path with the remainder of the new.  */
+- -  for (s = procdata->original_filename + procdata->count;
++  /* Overlay the old path with the remainder of the new.  Read 
++   * more data until we get to the next filename.
++   */
++  for (i=procdata->count;
+        (procdata->c = getc (procdata->fp)) > LOCATEDB_OLD_ESCAPE;)
+- -    if (procdata->c < 0200)
+- -      *s++ = procdata->c;           /* An ordinary character.  */
+- -    else
+- -      @{
+- -    /* Bigram markers have the high bit set. */
+- -    procdata->c &= 0177;
+- -    *s++ = procdata->bigram1[procdata->c];
+- -    *s++ = procdata->bigram2[procdata->c];
+- -      @}
+- -  *s-- = '\0';
++    @{
++      if (procdata->c < 0200)
++      @{
++        /* An ordinary character. */    
++        extend (procdata, i, 1u);
++        procdata->original_filename[i++] = procdata->c;
++      @}
++      else
++      @{
++        /* Bigram markers have the high bit set. */
++        extend (procdata, i, 2u);
++        procdata->c &= 0177;
++        procdata->original_filename[i++] = procdata->bigram1[procdata->c];
++        procdata->original_filename[i++] = procdata->bigram2[procdata->c];
++      @}
++    @}
++
++  /* Consider the case where we executed the loop body zero times; we
++   * still need space for the terminating null byte. 
++   */
++  extend (procdata, i, 1u);
++  procdata->original_filename[i] = 0;
+ 
+   procdata->munged_filename = procdata->original_filename;
+   
+
+
+
+VIII. THANKS
+============
+
+Thanks to Rob Holland <rob@@inversepath.com> and Tavis Ormandy.
+
+
+VIII. CVE INFORMATION
+=====================
+
+No CVE candidate number has yet been assigned for this vulnerability.
+If someone provides one, I will include it in the public announcement
+and change logs.
+-----BEGIN PGP SIGNATURE-----
+Version: GnuPG v1.4.6 (GNU/Linux)
+
+iD8DBQFGW0sucqCfqxMUHDYRAntVAKCIt54u8If+gpRtdwf+OHH5F+UUbACeNFWV
+KQ8qLDri26ScoEXXXQn08QA=
+=olFi
+-----END PGP SIGNATURE-----
address@hidden example
+
+
+Once a fixed release is available, announce the new release using the
+normal channels.  Any CVE number assigned for the problem should be
+included in the @file{ChangeLog} and @file{NEWS} entries. See
address@hidden://cve.mitre.org/} for an explanation of CVE numbers.
+
+
+
address@hidden Making Releases
address@hidden Making Releases
+This section will explain how to make a findutils release.   For the
+time being here is a terse description of the main steps:
+
address@hidden
address@hidden Commit changes; make sure your working directory has no
+uncomitted changes.
address@hidden Test; make sure that all changes ou have made have tests, and
+that the tests pass.  Verify this with @code{make distcheck}.
address@hidden Bugs; make sure all Savannah bug entries fixed in this release
+are fixed.
address@hidden NEWS; make sure that the NEWS and configure.in file are updated
+with the new release number (and checked in).
address@hidden Build the release tarball; do this with @code{make distcheck}.
+Copy the tarball somewhere safe.
address@hidden Tag the release; findutils releases are tagged in CVS as
+FINDUTILS_x_y_z-1.  For example, the tag for findutils release 4.3.8
+is FINDUTILS_4_3_8-1.
address@hidden Prepare the upload and upload it; see the
address@hidden FTP Uploads, ,Automated FTP
+Uploads, maintain, Information for Maintainers of GNU Software}
+for detailed upload instructions.
address@hidden Make a release announcement; include an extract from the NEWS
+file which explains what's changed.  Announcements for test releases
+should just go to @email{bug-findutils@@gnu.org}.  Announcements for
+stable releases should go to @email{info-gnu@@gnu.org} as well.
address@hidden Bump the release numbers in CVS; edit the @file{configure.in}
+and @file{NEWS} files to advance the release numbers.   For example,
+if you have just released @samp{4.6.2}, bump the release number to
address@hidden  The point of the @samp{-CVS} suffix here is that a
+findutils binary built from CVS will bear a release number indicating
+it's not built from the the ``official'' source release.
address@hidden Close bugs; any bugs recorded on Savannah which were fixed in 
this
+release should now be marked as closed.   Update the @samp{Fixed
+Release} field of these bugs appropriately and make sure the
address@hidden to} field is populated.
address@hidden enumerate
+
+
address@hidden
+
address@hidden texi related words used by Emacs' spell checker ispell.el
+
address@hidden LocalWords: texinfo setfilename settitle setchapternewpage
address@hidden LocalWords: iftex finalout ifinfo DIR titlepage vskip pt
address@hidden LocalWords: filll dir samp dfn noindent xref pxref
address@hidden LocalWords: var deffn texi deffnx itemx emph asis
address@hidden LocalWords: findex smallexample subsubsection cindex
address@hidden LocalWords: dircategory direntry itemize
+
address@hidden other words used by Emacs' spell checker ispell.el
address@hidden LocalWords: README fred updatedb xargs Plett Rendell akefile
address@hidden LocalWords: args grep Filesystems fo foo fOo wildcards iname
address@hidden LocalWords: ipath regex iregex expr fubar regexps
address@hidden LocalWords: metacharacters macs sr sc inode lname ilname
address@hidden LocalWords: sysdep noleaf ls inum xdev filesystems usr atime
address@hidden LocalWords: ctime mtime amin cmin mmin al daystart Sladkey rm
address@hidden LocalWords: anewer cnewer bckw rf xtype uname gname uid gid
address@hidden LocalWords: nouser nogroup chown chgrp perm ch maxdepth
address@hidden LocalWords: mindepth cpio src CD AFS statted stat fstype ufs
address@hidden LocalWords: nfs tmp mfs printf fprint dils rw djm Nov lwall
address@hidden LocalWords: POSIXLY fls fprintf strftime locale's EDT GMT AP
address@hidden LocalWords: EST diff perl backquotes sprintf Falstad Oct cron
address@hidden LocalWords: eg vmunix mkdir afs allexec allwrite ARG bigram
address@hidden LocalWords: bigrams cd chmod comp crc CVS dbfile dum eof
address@hidden LocalWords: fileserver filesystem fn frcode Ghazi Hnewc iXX
address@hidden LocalWords: joeuser Kaveh localpaths localuser LOGNAME
address@hidden LocalWords: Meyering mv netpaths netuser nonblank nonblanks
address@hidden LocalWords: ois ok Pinard printindex proc procs prunefs
address@hidden LocalWords: prunepaths pwd RFS rmadillo rmdir rsh sbins str
address@hidden LocalWords: su Timar ubins ug unstripped vf VM Weitzel
address@hidden LocalWords: wildcard zlogout basename execdir wholename 
iwholename
address@hidden LocalWords: timestamp timestamps Solaris FreeBSD OpenBSD POSIX
-- 
1.5.2.1