bug-standards
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

make dist and GNU coding standards


From: Karl Berry
Subject: make dist and GNU coding standards
Date: Sat, 12 Dec 2009 00:08:39 GMT

For the record, rms wrote me saying that the make dist change made in
the latest automake releases should be "widely announced", which we took
to be tacit approval to change the coding standards.  (We previously
asked him explicitly about it and he did not reply.)

Below is a patch from Ralf, which I am about to apply (with a minor
wording tweak).  Thanks Ralf.


2009-12-11  Ralf Wildenhues  <address@hidden>

        Do not recommend world-writable directories in package tarballs.
        * doc/standards.texi (Releases): Change recommended directory
        mode to 755, include justification and refer to original text;
        following CVE-2009-4029.
        Report by Jim Meyering.

--- standards.texi      20 Nov 2009 17:45:11 -0000      1.189
+++ standards.texi      11 Dec 2009 18:50:52 -0000
@@ -4064,13 +4064,13 @@
 distribution.  So if you do distribute non-source files, always make
 sure they are up to date when you make a new distribution.
 
-Make sure that the directory into which the distribution unpacks (as
-well as any subdirectories) are all world-writable (octal mode 777).
-This is so that old versions of @code{tar} which preserve the
-ownership and permissions of the files from the tar archive will be
-able to extract all the files even if the user is unprivileged.
-
-Make sure that all the files in the distribution are world-readable.
+Make sure that all the files in the distribution are world-readable, and
+that directories are world-readable and world-searchable (octal mode 755).
+We used to recommend that all directories in the distribution be
+world-writable (octal mode 777), because ancient versions of @code{tar}
+would otherwise not cope when extracting the archive as an unprivileged
+user.  That can easily lead to security issues when creating the archive,
+however, so now we recommend against that.
 
 Don't include any symbolic links in the distribution itself.  If the tar
 file contains symbolic links, then people cannot even unpack it on




reply via email to

[Prev in Thread] Current Thread [Next in Thread]