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

Jonas Smedegaard dr at jones.dk
Tue Dec 28 18:18:10 UTC 2010


On Tue, Dec 28, 2010 at 06:05:47PM +0100, Rémi Thebault wrote:
>
>
>> >> 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 ?

Ah, you are fast to adopt that new testsanity! :-)

I think maybe it is too strong to unconditionally check.  We should 
permit our users to take off the "safety belt".

Also, I think if we simply do checksum, it is of little help.  What 
indirectly we want to checksum is the _contents_ of that blob.  So 
really if we fail a build as "not properly checked for sanity" then we 
should more clearly indicate what needs sanity checking - which isn't 
looking at a hash, but instead is looking at some code and then 
creating/storing a corresponding hash.

I suggest to create an independent target - not enabled by default until 
fully implemented - which does checksum and unpack blob if failing.

Then when good, this can be included in testsanity - conditional to some 
variable which the user can then set if they find it sane to trust 
upstream without this checksum.

How does that sound?


  - 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: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/build-common-hackers/attachments/20101228/c224b8ce/attachment.pgp>


More information about the Build-common-hackers mailing list