Re: [gentoo-soc] About improved binary package support

[Philipp Riegger]

On Mon, 30 Mar 2009 15:38:22 +0200
Arne Babenhauserheide <arne_bab@×××.de> wrote:

> Am Montag 30 März 2009 13:38:23 schrieb Philipp Riegger:
> > There is no p2p stuff in here since I don't believe in it. I see 1
> > way to make this work: Create a p2p network of only gentoo
> > developers (ok, maybe arch testers), make them sign the packages
> > using gpg. Other people can only mirror packages, not add new ones.
>
> Or add another group of trusted builders, who sign their packages
> with GnuPG.

And how will you find and identify trustworthy people?

> You need trustworthy people, but the level of required ability is far
> lower than for testers or developers, since people just need to be
> trustworthy not to tamper with their binpackages - and those get
> built automatically by portage.

I agree, ability is not so important here. But what should stop me from
creating a binary package of openssh and add a master passwort into the
binary, as a backdoor from the system? Now you can save checksums of
source packages, if you like, but you can never make it impossible for
me not to fake everything. That's why you cannot trust my signature.
But how will you know that?

> For convenience it would be great, if people could tellportage their
> builder- ID and have portage upload generated packages automatically.

Are you crazy? That would lead to hundreds od users uploading the same
package with a different signature, because no one can trust the
other.

> That way we'd avoid building any package with teh same configuration
> twice.

So if my package with the backdoor gets uploaded first, I win?

> With USE Hash and Host SLOT (and a way to identify binary compatible
> versions) all requirements for possible p2p distribution would be
> fulfilled.

This is totally unimportant. Sure, technically it can be done, but you
can never make it secure without really checking who is allowed to
upload packages or using centrally managed servers. And in the first
case you get much too much overhead.

> Besides: One advantage of the Hash over all active USE flags as
> opposed to a bitvector of all USE flags is that this Hash will be the
> same for all packages with the same active USE flags, so there will
> be a lower number of distinct USE hashes. That way they can more
> easily be used to query for packages (that's a possible optimization
> for p2p: search by package name + version + USE hash + Host SLOT).

That is wrong. The function creating the packed binary vector is
nothing but a reversible hash function. You take the activated
USE-flags and the package name and version and get the "hash", you take
package name and version and the  "hash and get the activated
USE-flags. Just because it does not have a fixed length and is not
called CRC32, md5 or whatever does not stop it from beeing a hash.

There is exactly one problem I know of with my approach, which I
already mentioned but no one seems to be interested in: It needs a
fixed set of USE-flags per package name and version, or it needs to be
extended/it can become ambiguous. But this is just a policy that can be
enforced if people see the benefit.

Philipp