Re: The waf problem (running nondeterministic binary blobs at build)

[Ludovic Courtès]

Hi!

address@hidden skribis:

> I think there is a danger in packaging programs that use the 'waf'
> build system. That may pass a regular source code audit.
>
> If you look at the last line of a waf file you may see strange text
> like this:
>
> #==>
> #BZh91AY&Ha<F0><<F7><FB>n<F6>address@hidden@address@hidden@address@hidden@address@hidden@address@hidden@address@hidden@address@hidden@address@hidden@address@hidden@^O^GL^U...
> #<==

Ouch.

> Now waf is not malicious, it is actually an encoded bzip file
> containing the waf build system python scripts, the waf script reads
> its own source code and unpacks that before loading and running it.

In a way this is similar to Autoconf-generated ‘configure’ scripts, only
more “concealed.”

One could argue that this is source, in the form of a self-extracting
archive, but source anyway.

We could regenerate the ‘waf’ script of all Waf-using packages instead
of using the provided one.  However, we risk encountering
incompatibilities, which is probably one of the reasons why Waf does
this.

But we would need to apply the same reasoning to
Autoconf/Automake-generated files; this is what Debian does, but it
would defeat the whole purpose of these tools, which is to facilitate
bootstrapping by requiring nothing more than a Bourne shell and ‘make’.

> but I don't think the authenticity of these scripts is being verified,
> since they are not being looked at and are obfuscated they are the
> perfect vector to hide a malicious code/backdoor.

As for all packages, packagers should check the authenticity of the
tarball that contains the ‘waf’ script.

There is still the possibility, though, that the developer who produced
the tarball was themself a victim of a targeted attack that led them to
introduce a backdoored ‘waf’ into the tarball.  But the same could be
said of Autoconf, I suppose.

Thoughts?

Ludo’.