From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1LYpoi-0007bl-9Z for garchives@archives.gentoo.org; Sun, 15 Feb 2009 22:50:28 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 4D8F3E043E; Sun, 15 Feb 2009 22:50:27 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 2CD46E043E for ; Sun, 15 Feb 2009 22:50:27 +0000 (UTC) Received: from [192.168.22.10] (ip68-4-152-120.oc.oc.cox.net [68.4.152.120]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id B8B61B4D47 for ; Sun, 15 Feb 2009 22:50:26 +0000 (UTC) Message-ID: <49989C5E.3020307@gentoo.org> Date: Sun, 15 Feb 2009 14:51:10 -0800 From: Zac Medico User-Agent: Thunderbird 2.0.0.19 (X11/20081209) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [RFC] DIGESTS metadata variable for cache validation References: <498758E6.5080609@gentoo.org> <1234045916.24784.1373.camel@localhost> <498E17E6.8060407@gentoo.org> In-Reply-To: <498E17E6.8060407@gentoo.org> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 7d0273b9-cb7d-4b25-90d7-671411cd3614 X-Archives-Hash: d667a0dd748b2fefa5a5378000104974 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Zac Medico wrote: > Tiziano M=C3=BCller 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. >=20 > 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: >=20 > 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 =3DTxtX -----END PGP SIGNATURE-----