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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development