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

[Arne Babenhauserheide]

Am Montag 30 März 2009 16:37:09 schrieb Philipp Riegger:
> > Or add another group of trusted builders, who sign their packages
> > with GnuPG.
>
> And how will you find and identify trustworthy people?

The same way we find trusted devs, but with laxer coding ability requirements. 

> > 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?

If you managed to get into the trusted group, then you can wreak havoc, sure. 

Others already answered better than me, why this currently isn't an issue. 

> 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.

You could simply check whose packages you trust. 

> > 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",

I would simply use only the active USE flags to get the USE Hash and keep the 
package name and version in the name - and out of the hash (I think something 
got muddled up in discussion here). 

> 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.

The available USE flags are defined in the ebuilds. They can change at any 
moment, but as far as I know you then get a new version of the ebuild (i.e. 
...-r2.ebuild). (If I'm wrong, please write so!)

But though I prefer using a hash for the USE flags, this is really no hard 
blocker - and it's certainly not worth that we squabble over it. 

If you want to implement it as a bitvector and this will have no disadvantages 
over using a hash (no added maintenance cost, no missing possibilities and no 
restrictions on the workflow of ebuild maintainers), then just use a bitvector 
- but make sure it's encoded filename- and url-safe. 

Best wishes, 
Arne
-- 
-- Ein Würfel System: http://1w6.org - einfach saubere (Rollenspiel-) Regeln.
-- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the 
history of free software.
-- My stuff: http://draketo.de - stories, songs, poems, programs and stuff :)

-- PGP/GnuPG: http://draketo.de/inhalt/ich/pubkey.txt