[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