> > <snip>
> I'm not sure if this is doable, but not using hashes would be great.
The discussion on the bugzilla page is a must read in order to discuss this 
properly, it also explains why using a hash for this is necessary 
https://bugs.gentoo.org/150031
> 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".
This information is stored inside the xpak tail of package itself and can 
easily be obtained if needed.
> 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.
This would be interesting long term yes.
> > 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.
While some hash algorithms do take file modification time into account this is 
certainly not necessary at all, and in this case a hash algorithm that does 
not take file modification time into account would definitely be used.

It is true some programs make use of compile time defines such as __TIME__ and 
__DATE__ these will certainly pose a problem of some degree, however making 
the hash algorithm more advanced to work around these particular cases is 
certainly not impossible.

There might be the odd package which does not work initially but that is okay, 
these can be blacklisted from the system and then investigated and potentially 
fixed at a later time.

Having most things available as binaries certainly beats having none or very 
few.