Re: [gentoo-dev] [RFC] DIGESTS metadata variable for cache validation

[Zac Medico <zmedico@gentoo.org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Zac Medico wrote:
> Tiziano Müller wrote:
>> I'd recommend to prefix the digest with a "{TYPE}" (like for hashed
>> passwords) to be able to change the digest algorithm as needed
>> (especially in regards to the current SHA successor competition).
>> This allows a future package manager which might use SHA-3 for hashing
>> (once it's released) to still check old digests. Furthermore it would
>> allow for easier transition and only needs a definition of allowed
>> hashes instead of a specific one.
> 
> I like that idea. That way it's not necessary to bump the EAPI in
> order to change the hash function. So, a typical DIGESTS value might
> look like this:
> 
> SHA1 02021be38b a28b191904 3992945426 6ec21b29a3

While thinking about the implementation details, I realized that it
would be very useful to give the DIGESTS data a version identifier
that is independent of the EAPI. This will allow a package manager
to validate a cache entry that has been generated for an unsupported
EAPI, and allows it to trust that there's no point in regenerating
the cache entry (to see if the EAPI has changed since the last time
that it was generated). For example, suppose that we introduce EAPI
3 and a package manager that does not support EAPI 3 encounters a
cache entry for an EAPI 3 ebuild. If the package manager recognizes
the DIGESTS data version and it's able to validate the cache entry,
then it can avoid the cost of regenerating metadata for that ebuild.
If the user modifies the ebuild locally to change the EAPI to a
supported EAPI (from 3 to 2, for example), the DIGESTS data will
allow the package manager to recognize that the cache entry has been
invalidated and needs to be regenerated (and it will discover that
the EAPI has changed to a supported value).

So, if a "0" version identifier at the beginning of the DIGESTS
data, a typical entry could look like this:

0 SHA1 02021be38b a28b191904 3992945426 6ec21b29a3

Regardless of what the EAPI value happens to be, the package manager
should be able to trust that the version identifier is a reliable
indicator of the mechanism which should be used to validate the
integrity of the cache entry.
- --
Thanks,
Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkmYnFwACgkQ/ejvha5XGaNTzQCdFyZpEBZhftEISVrBBT+DsOHv
JXEAn2KtO/g0KjQtQu8fuB8KGF9Krr/d
=TxtX
-----END PGP SIGNATURE-----