Re: [rtcweb] Cisco to open source its H.264 implementation and absorb MPEG-LA licensing fees

Ron <ron@debian.org> Fri, 13 December 2013 04:03 UTC

Return-Path: <ron@debian.org>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2968F1AE62C for <rtcweb@ietfa.amsl.com>; Thu, 12 Dec 2013 20:03:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eA26QBjBE9Wh for <rtcweb@ietfa.amsl.com>; Thu, 12 Dec 2013 20:03:26 -0800 (PST)
Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by ietfa.amsl.com (Postfix) with ESMTP id 8361F1AE61B for <rtcweb@ietf.org>; Thu, 12 Dec 2013 20:03:26 -0800 (PST)
Received: from ppp14-2-56-86.lns21.adl2.internode.on.net (HELO audi.shelbyville.oz) ([14.2.56.86]) by ipmail05.adl6.internode.on.net with ESMTP; 13 Dec 2013 14:33:19 +1030
Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id 320F34F8F3; Fri, 13 Dec 2013 14:33:18 +1030 (CST)
X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz
Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id cyFfE9BF2Q5e; Fri, 13 Dec 2013 14:33:16 +1030 (CST)
Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 89FE04F902; Fri, 13 Dec 2013 14:33:16 +1030 (CST)
Date: Fri, 13 Dec 2013 14:33:16 +1030
From: Ron <ron@debian.org>
To: rtcweb@ietf.org
Message-ID: <20131213040316.GX3245@audi.shelbyville.oz>
References: <186CE8D65BA3A741A81A543F936DD0D10A5803D8@xmb-rcd-x07.cisco.com> <A672E2AB-827D-46E8-9EB1-D7ED82B10B94@cisco.com> <20131211193239.GK3245@audi.shelbyville.oz> <558F8D49-4024-4DF1-9A9E-AF422F1292C2@iii.ca> <20131212011550.GM3245@audi.shelbyville.oz> <E8882BCE-4795-4CF5-B785-18C2141A5DE2@iii.ca> <20131212183852.GN3245@audi.shelbyville.oz> <9B19C671-4356-4918-B271-D95B7AA84BBA@iii.ca> <20131212213234.GQ3245@audi.shelbyville.oz> <CECFDD00.20577%mzanaty@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CECFDD00.20577%mzanaty@cisco.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
Subject: Re: [rtcweb] Cisco to open source its H.264 implementation and absorb MPEG-LA licensing fees
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Dec 2013 04:03:29 -0000

On Fri, Dec 13, 2013 at 03:33:00AM +0000, Mo Zanaty (mzanaty) wrote:
> Yes, Cisco and Mozilla plan on solving fully reproducible binaries for all
> targets officially supported in the openh264 project. Nothing less would
> be acceptable to the community, especially given the recent security
> incidents.

If nothing else but this comes out of this initiative, then I would have
to say it still would be a great success :)  I'm very glad to hear this.

It's not a case of "I don't trust Cisco" so much "I shouldn't have to".

If this raises the bar for others distributing pre-compiled binaries,
that would be an awesome outcome all on its own.


> We welcome contributions from anyone who has struggled with this in the
> past, and is aware of specific problems or solutions beyond the obvious
> ones below.
> 
> 1. Identical source trees (git hash)
> 2. Identical project configuration (make targets that include all
> configuration options)
> 3. Identical tool chains on similar build machines (same arch at least,
> probably x86-64)
> 4. Deterministic tool chains (avoid tool options that lack determinism)
> 5. Deterministically identical tool chain output must be hashed separately
> from uniquely generated data (build info, etc.)

The tor people would definitely be worth talking to here for first hand
information on what's solved and what still needs serious work.  They
have people working on this full time at present.

The link I posted in the other mail has some details, but I'm sure they'll
have plenty more to say if asked :)

> Some feel that tool chains can also be subverted and therefore should also
> be built from source, using some root golden tool chain. We are not that
> paranoid yet. Should we be?

Ken Thompson thought we should in 1995!

There is work being done on that too though, which not so much is about
providing a "golden tool chain" as a method of confirming that the one
you have is not corrupted.

But that's probably more of a job for the OS Vendors to do (and for the
real paranoids to confirm that they've done).  There's some information
on that here:

http://www.dwheeler.com/trusting-trust/
https://www.schneier.com/blog/archives/2006/01/countering_trus.html


Getting the openh264 builds reproducible to begin with is probably the
best initial investment, since that will identify the compiler(s) used,
and people can use the above technique to confirm that compiler is clean.

At least for the compilers that you can build yourself from source.

  Ron