Debian on track to prove binaries' origins

[mardybear]

Debian on track to prove binaries' origins
Reproducible binary project 83% complete

Debian is on its way to becoming what could be the first operating system to prove the origin of its binaries, technologist Micah Lee says.

The feat will allow anyone to independently confirm that Debian binaries were built from a reported source package.

So far a project team devoted to confirming the reproducibility of builds has knocked off 83 percent of source packages within the main archive of the unstable distribution.

Soon @debian could be the first OS that can prove that its binaries were compiled from published source code pic.twitter.com/RjaNYiBkwI
— Micah Lee (@micahflee) February 22, 2015

The effort will not be completed in time for the release of the next major Debian release, codenamed Jessie, but could see reproducible builds a feature for the following stable release dubbed Stretch.

“The team developed the tool debbindiff to provide in-depth detailed diffs of binary packages,” Debian said in a report note.

“Packages are then built twice onjenkins.debian.net, and reproducibility results are reported on the Debian Package Tracker.

The [reproducibility] team is considering submitting a proposal to make reproducible builds a release goal for Stretch, the next stable release after Jessie.”

Reproducibility is important according technologists Mike Perry and Seth Schoen because it can help close transparency gaps that exist in the provenance of binaries. They point to the need for reproducibility in a November talk at Mozilla. That talk included the following statement:

“We often speak as if open source software can't contain backdoors or malware because its source code is 'published', rendering any potentially malicious code visible. But real-world software release processes have major transparency gaps that aren't addressed by most existing open source development practices. The biggest such gap is that compilation and packaging processes aren't reproducible. Trying to recreate these processes typically yields a different result. That means users can't directly verify that the binary releases they download and use were actually created from the purportedly corresponding source trees.

Worse, the Tor and Electronic Frontiers boffins say, those releasing can not assure that a compromise in their infrastructure has not introduced a tiny and all-but undetectable flaw into a binary version.

http://www.theregister.co.uk/2015/02/23/debian_project/
https://jenkins.debian.net/

[geekosupremo]

In light of some of the more insidious malware out there these days this could become a real selling point.

[mardybear]

Agreed, this will be HUGE. The strongest argument for compiling yourself will essentially become a moot point. Like 99% of those compiling from source actually read and understand the code. Certainly not me...so it will definitely be reassuring.

Edit: Don't want to stray too far off topic, but my favourite alternative Linux is Tiny Core. Extensions/packages are compiled and user submitted from the community. Tiny Core v6 might have Firefox 31, for example, but newer Firefox releases will only be available if another community member compiles and submits the newer version. So...you're working with outdated software and don't even know the user who submitted the package. Their last Firefox even had some unknown multimedia plug-in installed by default

[JLloyd13]

Agreed, this will be HUGE. The strongest argument for compiling yourself will essentially become a moot point. Like 99% of those compiling from source actually read and understand the code. Certainly not me...so it will definitely be reassuring.

Edit: Don't want to stray too far off topic, but my favourite alternative Linux is Tiny Core. Extensions/packages are compiled and user submitted from the community. Tiny Core v6 might have Firefox 31, for example, but newer Firefox releases will only be available if another community member compiles and submits the newer version. So...you're working with outdated software and don't even know the user who submitted the package. Their last Firefox even had some unknown multimedia plug-in installed by default

That sounds like a major security problem. I'm not overly paranoid but that seriously sounds risky. Wouldn't it just take one guy to write some malware to threaten the whole community then?

[mardybear]

JLloyd13 wrote:
That sounds like a major security problem. I'm not overly paranoid but that seriously sounds risky. Wouldn't it just take one guy to write some malware to threaten the whole community then?

Yes. Tiny Core's present package system is IMO flawed for anyone who values security. The problem is that there aren't enough active developers to build up a repository even a fraction of the size of Debian's.

A new branch is under active development, called dCore, which will allow users to directly install software from the Debian repository...looking forward to trialing. Still in early stages but looks promising...

The default plugin installed was called OpenH264 Video Codec provided by Cisco Systems, Inc.. Don't think it's suspicious but it's disabled nonetheless.

Minimal security concerns with present use as it's just a hobby system, runs from RAM, read-only file system, no persistence on shutdown, firewalled router, iptables, secure connection, no sensitive data...

[Head_on_a_Stick]

The default plugin installed was called OpenH264 Video Codec provided by Cisco Systems, Inc.. Don't think it's suspicious but it's disabled nonetheless.

I think that's for hardware-accelerated video playback.

TinyCore (64-bit) does have the "firefox-latest" extension which downloads and installs the latest version (36 atm) direct from Mozilla.

Not sure if that's an improvement though...

[mardybear]

Thanks Head_on_a_Stick - will see if there's something similar for 32-bit.

[JLloyd13]

JLloyd13 wrote:
That sounds like a major security problem. I'm not overly paranoid but that seriously sounds risky. Wouldn't it just take one guy to write some malware to threaten the whole community then?

Yes. Tiny Core's present package system is IMO flawed for anyone who values security. The problem is that there aren't enough active developers to build up a repository even a fraction of the size of Debian's.

A new branch is under active development, called dCore, which will allow users to directly install software from the Debian repository...looking forward to trialing. Still in early stages but looks promising...

The default plugin installed was called OpenH264 Video Codec provided by Cisco Systems, Inc.. Don't think it's suspicious but it's disabled nonetheless.

Minimal security concerns with present use as it's just a hobby system, runs from RAM, read-only file system, no persistence on shutdown, firewalled router, iptables, secure connection, no sensitive data...

Interesting.. I'll have to give it a shot, although until they have dCore or whatever I probably wouldn't use it much. I like that they have a 64-bit version.

[tomazzi]

To be honest, I don't get the rationale for this project:
- Source packages are digitally signed,
- Binary packages are digitally signed.
So: the only way to have an "untrusted binary" is to use 3rd party packages or non-official sources.

I understand, that a way to confirm that a signed 3rd party package is compiled from official sources could be useful (nobody should even try unsigned binaries) - but this is not a case in Debian - so what is this all about?

Anyway and definitely, this is bullshit:

The biggest such gap is that compilation and packaging processes aren't reproducible. Trying to recreate these processes typically yields a different result.

As most of source packages are equipped with make/automake/autoconf files, the build process is simply identical on all targets, UNLESS:

Unless, the user decides to drop some features of the program or f.e. the script automatically will select a newer library to link the program or a newer compiler version will be used OR due to parallelism of make a bit different code will be generated.
But this is in fact a *better* situation:
Far worse situation is when all running systems are using exactly the same binaries: this can hugely extend the attack surface f.e. for viruses and other forms of attacks.

IMO this project is at least questionable in a matter of its intensions.
Exactly because Windows is build of identical binaries, it have becomed a perfect target for attacks.

Regards.