Re: [Denemo-devel] A problem for the release?

[torbenh]

On Thu, Dec 31, 2009 at 10:52:37AM +0000, Richard Shann wrote:
> This is relevant to us
> > There was a nasty flaw in _every_ automake-generated Makefile.in
> > until recently[*].  When making releases, most of us who maintain
> > automake-using packages run "make dist" or "make distcheck".
> > Even if you don't, your users may.  The flaw put all of us at risk.
> > 
> > With a Makefile.in generated by unpatched automake,
> > if you run "make dist" in a potentially hostile environment,
> > you risk including arbitrary code in a tarball that you may
> > then sign, thinking it's a faithful copy of your working sources.
> > Worse, if you run "make distcheck" you risk immediate arbitrary
> > code execution.
> > 
> > Even if you are confident you never run those commands
> > in a vulnerable environment, you have to consider that
> > someone who downloads your release tarball may run them.
> > 
> > I mention this because some recently released packages
> > included Makefile.in files generated by unpatched automake.
> > To check, simply run this against the top-level Makefile.in:
> > 
> >     grep 'perm -777' Makefile.in
> > 
> > If there's a match, you should get a fixed version of automake
> > and use it to regenerate that file.
> 
> we cannot make the release without sorting this out. The email (on
> gnu-prog-discuss) refers us to 
>      http://thread.gmane.org/gmane.comp.sysutils.autotools.announce/131
> for details. I am guessing it is genuine.
> Richard

well... it talks about a timewindow where a hostile person can modify
the directory ending up in the tarball.

that requires that another (hostile) person has access to the computer
while you run make dist.

i dont see why any otherone than the release manager should run make
dist. 


-- 
torben Hohn