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

[Richard Shann]

On Thu, 2009-12-31 at 12:42 +0100, torbenh wrote:
> 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. 
It is perhaps easier just to fix than to try to figure out consequences:) 
We want to upload to ftp.gnu.org this time, so we will need to fix it
anyway.
Richard