[Build-common-hackers] a WAF class for CDBS

Rémi Thebault remi.thebault at gmail.com
Tue Dec 28 17:05:47 UTC 2010



> >> As a sidenote, I really dislike the fundamental design of waf: 
> >> Shipping a self-extracting scripting environment, obfuscated by an 
> >> odd format, and telling users to execute that code blindly.  It is a 
> >> security risk!
> >>
> >> We really should extend the initial check to e.g. keep a checksum
> >
> >Do you mean keeping track of a checksum in cdbs source code ?
> >If yes, it means we must keep an eye on every waf new release. I don't 
> >think it could work on long term.
> 
> I mean storing a checksum in e.g. debian/waf.sha1sum inside each source 
> package.
> 
> It might require updating each time there is a new upstream release, 
> yes.  And not us, but the package maintainer need to keep an eye on it - 
> which is needed in any case due to the insecure design of waf.  What we 
> offer is a mechanism to ensure it is not forgotten: I suggest that we 
> make the build routine FAIL if checksum does not match, which means the 
> package maintainer must do the needed security scrutiny each time the 
> waf blob changes, or explicitly do the foolish act of suppressing our 
> safety mechanism.


I added 2 checks in testsanity target :
1. check that debian/waf.sha1sum contains the word "waf"
2. sha1sum --check debian/waf.sha1sum

but the packager still can do something like "sha1sum ./waf >
debian/waf.sha1sum" on a malicious waf file.
The security is still not as strong as we would like, is it ?
Could we check the debian/waf.sha1sum is signed by the packager or
something ?


regards
Rémi




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/build-common-hackers/attachments/20101228/d432d04c/attachment.htm>


More information about the Build-common-hackers mailing list