Adrian Bunk:
> On Thu, Jun 22, 2017 at 08:26:00AM +0000, Ximin Luo wrote:
>> ...
>> One way to give security that is independent of third parties, is to provide
>> some sort of mathematically-verifiable proof. However the world isn't at
>> that stage yet for compiler technology.
>
> What changes in compiler technology are you hoping for?
>
> The main reason for fixing optimizer bugs in the compiler is to get
> different (no longer buggy) output.
>
>> ...
>> For users that can't directly verify everything that they themselves run,
>> one "next best thing" they can do is to check that different parties that
>> they trust - or many parties that they don't trust, that they nevertheless
>> believe are probably not all colluding to attack them - claimed to have
>> performed the build or verified each others' proofs.
>>
>> So, the more buildinfo files we have, from different parties (DDs, the
>> Debian archive, etc) the better this is for users, because they have more
>> sources of claims. How much they "trust" each individual source, is indeed
>> not something that is concretely measurable and no existing security system
>> tries to model this more precisely unfortunately; however I think we can all
>> agree that "more is better" here.
>> ...
>
> I don't see how more random information is helpful for users.
>
> One or more trusted instances verifying that all packages in a release
> were built from their sources is the information that would be useful
> for users.
>
Different users can choose who they want to trust. A DD signing a buildinfo and
uploading this to the archive, is not "random information". Some users would be
happy to trust 1 DD plus the buildd, but not either one individually; other
users would want other third-party builders to re-perform the build and sign
their own buildinfo files.
The point is that making the information available gives more choice for users.
If specific users don't trust a DD, they can ignore this extra information. But
if we don't provide this information, we're preventing people from getting
assurance about the software they're running.
BTW this sort of trust-system I'm suggesting is not like the CA system where 1
trusted party can break your security. Instead, here all/most trusted parties
would have to collude to publish bad buildinfo files, to break your security.
The security dynamics, is closer to bitcoin and other blockchain tech. There
are certain nuances to be made when doing the security logic, for example
someone could sign 100 bad buildinfo files pretending to be from different
people; but I think the success of blockchain tech shows that there is some
demand from users to have these AND-trust systems where many trusted sources,
even from "random strangers", can help make the system stronger, as opposed to
OR-trust systems where 1 CA can go MITM everyone.
> For some users it would also be important to be able to verify this for
> the whole archive themselves.
>
Yeah, we agree on this point. For many other users, who don't have the
resources to rebuild everything, it's equally important to be able to see that
{whatever they choose} other people have claimed to have done it.
X
--
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git
