| 1 |
> > <snip> |
| 2 |
> I'm not sure if this is doable, but not using hashes would be great. |
| 3 |
The discussion on the bugzilla page is a must read in order to discuss this |
| 4 |
properly, it also explains why using a hash for this is necessary |
| 5 |
https://bugs.gentoo.org/150031 |
| 6 |
> It would be cool to encode as much information as possible so that it |
| 7 |
> can be decoded again. In any case, there should be a database with what |
| 8 |
> the hashes mean, so that users can see "Ok, i use this and that CLFAGS |
| 9 |
> and this and that USE-flags, and if i now change that USE-flag which I |
| 10 |
> don't really care about and add -pipe to my CFLAGS, I can find almost |
| 11 |
> everything I need as binary packages". |
| 12 |
This information is stored inside the xpak tail of package itself and can |
| 13 |
easily be obtained if needed. |
| 14 |
> It would also be cool to work with the stats project here to find out, |
| 15 |
> which CFLAGS and USE-flags are used, which packages are installed. |
| 16 |
This would be interesting long term yes. |
| 17 |
> > The second kind of hash that I am talking about now is a security |
| 18 |
> > hash computed over the final package file. By having multiple users |
| 19 |
> > compile the package and generate a security hash of it one can |
| 20 |
> > ensure(within reasonable doubt) that the package has not been |
| 21 |
> > tampered with by the contributor, by for example adding a rootkit to |
| 22 |
> > the source code. |
| 23 |
> As far as I know, tar is used. If times or anything like that are saved |
| 24 |
> in the tarball, you can forget to reproduce a tarball with the same |
| 25 |
> hash. Also, sometimes the time and date when it was compiled is saved |
| 26 |
> in the binary. So, either I don't understand you, or it just will not |
| 27 |
> work. |
| 28 |
While some hash algorithms do take file modification time into account this is |
| 29 |
certainly not necessary at all, and in this case a hash algorithm that does |
| 30 |
not take file modification time into account would definitely be used. |
| 31 |
|
| 32 |
It is true some programs make use of compile time defines such as __TIME__ and |
| 33 |
__DATE__ these will certainly pose a problem of some degree, however making |
| 34 |
the hash algorithm more advanced to work around these particular cases is |
| 35 |
certainly not impossible. |
| 36 |
|
| 37 |
There might be the odd package which does not work initially but that is okay, |
| 38 |
these can be blacklisted from the system and then investigated and potentially |
| 39 |
fixed at a later time. |
| 40 |
|
| 41 |
Having most things available as binaries certainly beats having none or very |
| 42 |
few. |
Archives