[ Thanks Glenn for rerouting the bug report! ] Hi Behdad,
> From: Behdad Esfahbod > Subject: On the fix for CVE-2009-4029 Automake security fix for 'make dist*' > Date: Thu, 11 Nov 2010 16:17:22 -0500 > I recently read about the fix for the chmod 777 issue. Just wanted to note > that it may be preferred if you continue with chmod 777 and instead fix the > problem by moving the dist dir inside another direction that is 700. > > The reason a 777 mod in the tarball may be preferred (or 775 for that matter, > but not 755) is for systems that users of a group are using sticky-bit on the > group to share writable files with eachother. By letting the umask decide > what bits should not be set you you enable such settings, whereas using 755, > the user expanding the tarball has to reset it to 775 or the rest of the group > cannot write to it. Thanks for the bug report. At the time we fixed this, we considered going this other option. It was a fairly close call. The downside of the solution you suggest was that it would complicate 'make dist' a little, and maybe break a few packages that rely on the exact subdir structure of $(distdir) being one directory below the toplevel build directory. Such reliance is probably bad style anyway, but we didn't know of many uses that would benefit from more relaxed permission inside the tarball. How useful is that for you, how come you don't use a version control repository rather than an extracted tarball for collaborative work (honest question)? You are the first person to report this in the 12 months since we released fixed versions of Automake. I don't have other data to go on but it thus doesn't seem to be a very wide spread issue to me, and there's the obvious workaround of a chmod -R after extraction, no? I'm open to arguments here, but so far I'm slightly leaning toward keeping the current behavior. Thanks, Ralf