On Tue, 24 Mar 2009 09:45:30 +0200
mmacleod@... wrote:

> > Then have a hash generate set up where it would take
> > the name, version, and use flags, cflags and hash just that
> > information.
> We are talking about two different types of hashes.
> There would be a hash in the package names in order to tell the
> difference between package foo compiled with use flag "bar" and
> package foo compiled without useflag "baa"(It would also have to take
> into account cflags and dependency versions), this is part of the
> "improved binary support idea".

I'm not sure if this is doable, but not using hashes would be great.
It would be cool to encode as much information as possible so that it
can be decoded again. In any case, there should be a database with what
the hashes mean, so that users can see "Ok, i use this and that CLFAGS
and this and that USE-flags, and if i now change that USE-flag which I
don't really care about and add -pipe to my CFLAGS, I can find almost
everything I need as binary packages".

It would also be cool to work with the stats project here to find out,
which CFLAGS and USE-flags are used, which packages are installed.

> The second kind of hash that I am talking about now is a security
> hash computed over the final package file. By having multiple users
> compile the package and generate a security hash of it one can
> ensure(within reasonable doubt) that the package has not been
> tampered with by the contributor, by for example adding a rootkit to
> the source code.

As far as I know, tar is used. If times or anything like that are saved
in the tarball, you can forget to reproduce a tarball with the same
hash. Also, sometimes the time and date when it was compiled is saved
in the binary. So, either I don't understand you, or it just will not
work.

Philipp