| 1 |
> > <snip> |
| 2 |
> > |
| 3 |
> > While some hash algorithms do take file modification time into |
| 4 |
> > account this is certainly not necessary at all, and in this case a |
| 5 |
> > hash algorithm that does not take file modification time into account |
| 6 |
> > would definitely be used. |
| 7 |
> |
| 8 |
> I was talking about modification times saved in the tarball, not the |
| 9 |
> modification times of the tarball. |
| 10 |
Yes so was I. |
| 11 |
> In that case, you would need to |
| 12 |
> unpack the package and hash all files in it. |
| 13 |
Yes exactly. |
| 14 |
"bzcat kdelibs-4.2.0-r1.tbz2 | md5sum" is a trivial example of this. |
| 15 |
> But to create a general |
| 16 |
> hash algorithm that hashes compressed tar files and does not take into |
| 17 |
> account any times and dates is impractical, if not impossible to do it |
| 18 |
> so that it makes sense. |
| 19 |
It is not even necessary that it runs on the data in its compressed form, it |
| 20 |
can easily decompress files from the archive as it goes and work on the |
| 21 |
uncompressed form, the above trivial sample is already sufficient except for |
| 22 |
the use of md5sum, although there are ways to do this more optimally. |
| 23 |
True this is more expensive then a hash of just the tarball itself would be |
| 24 |
but it only needs to be incurred by those who are contributing a package and |
| 25 |
those who are verifying that a contributed package is valid, it does not have |
| 26 |
to be incurred by those actually installing the package, for that a simple |
| 27 |
tarball hash as with source tarballs is sufficient. |
| 28 |
Also it certainly does not take long enough that it is impractical. |
Archives