| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
Zac Medico wrote: |
| 5 |
> Tiziano Müller wrote: |
| 6 |
>> I'd recommend to prefix the digest with a "{TYPE}" (like for hashed |
| 7 |
>> passwords) to be able to change the digest algorithm as needed |
| 8 |
>> (especially in regards to the current SHA successor competition). |
| 9 |
>> This allows a future package manager which might use SHA-3 for hashing |
| 10 |
>> (once it's released) to still check old digests. Furthermore it would |
| 11 |
>> allow for easier transition and only needs a definition of allowed |
| 12 |
>> hashes instead of a specific one. |
| 13 |
> |
| 14 |
> I like that idea. That way it's not necessary to bump the EAPI in |
| 15 |
> order to change the hash function. So, a typical DIGESTS value might |
| 16 |
> look like this: |
| 17 |
> |
| 18 |
> SHA1 02021be38b a28b191904 3992945426 6ec21b29a3 |
| 19 |
|
| 20 |
While thinking about the implementation details, I realized that it |
| 21 |
would be very useful to give the DIGESTS data a version identifier |
| 22 |
that is independent of the EAPI. This will allow a package manager |
| 23 |
to validate a cache entry that has been generated for an unsupported |
| 24 |
EAPI, and allows it to trust that there's no point in regenerating |
| 25 |
the cache entry (to see if the EAPI has changed since the last time |
| 26 |
that it was generated). For example, suppose that we introduce EAPI |
| 27 |
3 and a package manager that does not support EAPI 3 encounters a |
| 28 |
cache entry for an EAPI 3 ebuild. If the package manager recognizes |
| 29 |
the DIGESTS data version and it's able to validate the cache entry, |
| 30 |
then it can avoid the cost of regenerating metadata for that ebuild. |
| 31 |
If the user modifies the ebuild locally to change the EAPI to a |
| 32 |
supported EAPI (from 3 to 2, for example), the DIGESTS data will |
| 33 |
allow the package manager to recognize that the cache entry has been |
| 34 |
invalidated and needs to be regenerated (and it will discover that |
| 35 |
the EAPI has changed to a supported value). |
| 36 |
|
| 37 |
So, if a "0" version identifier at the beginning of the DIGESTS |
| 38 |
data, a typical entry could look like this: |
| 39 |
|
| 40 |
0 SHA1 02021be38b a28b191904 3992945426 6ec21b29a3 |
| 41 |
|
| 42 |
Regardless of what the EAPI value happens to be, the package manager |
| 43 |
should be able to trust that the version identifier is a reliable |
| 44 |
indicator of the mechanism which should be used to validate the |
| 45 |
integrity of the cache entry. |
| 46 |
- -- |
| 47 |
Thanks, |
| 48 |
Zac |
| 49 |
-----BEGIN PGP SIGNATURE----- |
| 50 |
Version: GnuPG v2.0.9 (GNU/Linux) |
| 51 |
|
| 52 |
iEYEARECAAYFAkmYnFwACgkQ/ejvha5XGaNTzQCdFyZpEBZhftEISVrBBT+DsOHv |
| 53 |
JXEAn2KtO/g0KjQtQu8fuB8KGF9Krr/d |
| 54 |
=TxtX |
| 55 |
-----END PGP SIGNATURE----- |
Archives