Processed: retitle 654462 to Doesn't contain source for waf binary code ...

[Jonas Smedegaard]

On 12-01-04 at 12:26pm, Barak A. Pearlmutter wrote:
> > How can the Debian project rest assured that that the binary indeed 
> > is (only!) unpacking itself when executed?
> 
> > Also, that it is the case for _every_ new upstream release, not only 
> > once when you cared to investigate closely.
> 
> Although that is a serious issue, *exactly* the same issue is present 
> for *all* upstream sources, not just waf files.  How do we know that 
> some new configure.ac is safe to run autoreconf;./configure on?  How 
> do we know that some new C sources are safe?  How do we know that a 
> TIF file does not contain executable instructions which are cleverly 
> jumped into by a carefully crafted deliberate typo?  As far as I can 
> tell, waf files used in the build process are a bit painful to examine 
> and audit, but then so are .m4 autoconf macros.
> 
> So the true answer is that we do our best, but (at least, without 
> formal methods) we cannot "rest assured" without manual checking, 
> running inside sandboxes, syscall tracing, etc.  And even then, our 
> slumber should be somewhat uneasy.
> 
> In this regard, waf files are no different from any other scripts 
> executed at build time.

Well, the very issue is that the code is binary: After each 
git-import-orig I skim imported changes with "git log -p --color-words".  
Not bullet-proof but better than simply trusting upstream.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20120104/267ee400/attachment.pgp>