[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Compromising Debian Repositories



Volker Birk:
> On Sun, Aug 04, 2013 at 03:04:33AM +0000, adrelanos wrote:
>> Volker Birk:> On Sat, Aug 03, 2013 at 10:38:34AM +0000, adrelanos wrote:
>>> There will be the correct checksum, if the maintainer of the package
>>> does it.
>> Why?
> 
> How and by whom are checksums defined?

Please have a look into the BitCoin (official, qt) build process.
Multiple builders build the same binary and when they run a $hashsum
tool on individual resulting binary files, they will always have the
same hash sum. Same goes for the archive files. Those builders publish
their results.

Anyone else can download their source code, read their build
instructions, build from source code and get end up with the same hash
sums. Compare that with what they offer for download. If something
mismatches, there is something wrong.

>>> And if you're taking the build machine, you can inject “correct”
>>> checksums, too.
>> But that will get caught when someone else builds the package and comes
>> up with a different checksum? Or do you talk about hash collisions?
> 
> No, I'm talking about the process by whom and when a checksum is
> defined.

Checksums should be created on the .deb and the individual files. The
advantage of deterministic builds would be, that these checksums would
always be the same, no matter when and by whom the build is made as long
as the source code isn't changed.

> Whoever is able to define checksums is able to circumvent each
> security measure basing on such checksums.

Thats up the community to come up with a general policy on how that
should be done.

> To “define” does not mean she/he has to know a secret to apply the
> checksum.

Yes, no secrets.

> I's enough that she/he is authorized to use the communication
> channel where data is injected, for which then a checksum is computed.

Yes the server could claim a different checksum. But anyone downloading
the source package and building it would get a different checksum.

Sure, deterministic builds are only the first step. Getting up a system
to automatically to track changes in source code and to compare hash
sums would be required as well.

I am afraid if deterministic builds can't solve all problems at once. Do
you see no advantages at all? I am just interested to have in a couple
of years still operating systems without any secretly built-in trojans
because build servers got compromised with zero days.


Reply to: