From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Griffin Subject: Re: The waf problem (running nondeterministic binary blobs at build) Date: Sat, 30 Apr 2016 18:55:25 -0500 Message-ID: <1462060525.745798.594497289.456F27DF@webmail.messagingengine.com> References: <4a18bcd6782d6dd053be5bc1c732a525@openmailbox.org> <87d1pcvfnb.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:47935) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1awejo-0003cM-KM for guix-devel@gnu.org; Sat, 30 Apr 2016 19:55:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1awejc-0003v8-O3 for guix-devel@gnu.org; Sat, 30 Apr 2016 19:55:47 -0400 Received: from out5-smtp.messagingengine.com ([66.111.4.29]:57257) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aweja-0003pO-7q for guix-devel@gnu.org; Sat, 30 Apr 2016 19:55:40 -0400 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 9241F2086C for ; Sat, 30 Apr 2016 19:55:25 -0400 (EDT) In-Reply-To: <87d1pcvfnb.fsf@gnu.org> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: guix-devel@gnu.org Debian replaces all binary 'waf' files with their own 'waf-uncompressed'. I think our python-waf package should be altered to produce an uncompressed version, then the waf-build-system should automatically use that (look at the python-pycairo package for an example of using the system's waf version instead of the bundled one). --=20 Alex Griffin On Tue, Apr 26, 2016, at 05:16 AM, Ludovic Court=C3=A8s wrote: > Hi! >=20 > rain1@openmailbox.org skribis: >=20 > > 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: > > > > #=3D=3D> > > #BZh91AY&Ha<nl^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^O^GL= ^U... > > #<=3D=3D >=20 > Ouch. >=20 > > 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. >=20 > In a way this is similar to Autoconf-generated =E2=80=98configure=E2=80= =99 scripts, only > more =E2=80=9Cconcealed.=E2=80=9D >=20 > One could argue that this is source, in the form of a self-extracting > archive, but source anyway. >=20 > We could regenerate the =E2=80=98waf=E2=80=99 script of all Waf-using pac= kages instead > of using the provided one. However, we risk encountering > incompatibilities, which is probably one of the reasons why Waf does > this. >=20 > 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 =E2=80=98= make=E2=80=99. >=20 > > 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. >=20 > As for all packages, packagers should check the authenticity of the > tarball that contains the =E2=80=98waf=E2=80=99 script. >=20 > 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 =E2=80=98waf=E2=80=99 into the tarball. But the s= ame could be > said of Autoconf, I suppose. >=20 > Thoughts? >=20 > Ludo=E2=80=99. >=20