[Development] Qt5 combined source package - Perl dependency

Thiago Macieira thiago.macieira at intel.com
Mon Apr 29 20:25:14 CEST 2013


On segunda-feira, 29 de abril de 2013 19.34.45, Oswald Buddenhagen wrote:
> would it be terribly hard to add a filter step that throws out include/
> (and configure.exe) when zcat-ing the archive?

That's the second choice I listed: do a file-by-file comparison, knowing which 
files are acceptable to be present and which aren't.

Adding a random file somewhere *usually* isn't a problem. It is a problem only 
if the presence of a file changes the output of the build. And that's exactly 
what configure.exe and the include/ dir do: they change the output. It's not 
possible to cryptographically verify them.

An attacker could insert something in one of the forwarding headers and thus 
insert some backdoor into the Qt build.

> on a general note, i don't quite get what the *point* of this exercise
> is. to verify the archieve you actually need the git repo itself.
> signing the archive seems a lot more useful to me ...

Signing with a GPG key, you mean? I'm not excluding that.

But a GPG signature only validates that the file has not been tampered after it 
was signed. It makes no statement about whether the file was tampered with 
*before* the signing. The cryptographic verification of the source tree does 
that.

A determined hacker could infiltrate Digia's network and tamper with perl in 
the build machines. When perl is called to generate the forwarding headers, it 
could then drop the backdoor in. This way, the source packages are infected, 
which means the binaries for all platforms would be infected, as well as for 
people building from sources (including Linux distributions). And no amount of 
signature could lead to the tampering.

If we do close it, we can be sure that the sources aren't infected, even 
though it makes no statement about the binaries. But in that case, security 
conscious or paranoid people could download sources and build them.

You're going to say: why don't security-conscious people download from Git? I 
would say that they should. But some people may not be able to access our Git 
servers from their networks. They may download from Gitorious though:

$ curl -s http://qt.gitorious.org/qt/qtsvg/archive-tarball/v5.1.0-alpha1 | 
zcat | git get-tar-commit-id
9c79ef0046c550614964afb8feb734c96853691c

Is this far-fetched? Maybe, but that's not the point. The point is: why do we 
want to leave an attack vector open, if we can close it?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20130429/bf17e1f5/attachment.sig>


More information about the Development mailing list