[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