Contents
While Manifest2 format allows multiple hashes, the question of which checksums should be present, why, and the security implications of such have never been resolved. This GLEP covers all of these issues, and @@ -84,19 +85,19 @@ future.
This GLEP is being written as part of the work on signing the Portage tree, but is only tangentially related to the actual signing of Manifests. Checksums present one possible weak point in the overall security of the tree - and a comprehensive security plan is needed.
This GLEP is not mandatory for the tree-signing specification, but -instead aims to improve the security of the hashes used in Manifest2. -As such, it is also able to stand on it's own.
+instead aims to improve the security of the hashes used in Manifest2 +[GLEP44]. As such, it is also able to stand on it's own.First of all, I'd like to cover the bad news in checksum security. A much discussed point, as been the simple question: What is the security of multiple independent checksums on the same data? @@ -112,7 +113,7 @@ HAVAL-128 and RIPEMD families of hashes.
For a general collision, not a pre-image attack, since the announcement by Wang et al [W04], the time required to break MD5 has been massively reduced. Originally at 1 hour on a near-supercomputer (IBM P690) and @@ -138,7 +139,7 @@ want.
Of the checksums presently used by Manifest2 (SHA1, SHA256, RIPEMD160), one stands close to being completely broken: SHA1; and another is significantly weakened: RIPEMD160. The SHA2 series has suffered some @@ -150,7 +151,7 @@ keep a specific checksum, such as part of a migration plan.
Portage should always try to verify all supported hashes that are available in a Manifest2, starting with the strongest ones as maintained by a preference list. Over time, the weaker checksums should be removed @@ -171,9 +172,9 @@ no supported hashes are available for a given Manifest entry.
A minimum set of depreciated checksums shall be maintained only to support old package manager versions where needed by historically used trees:
@@ -187,7 +188,7 @@For the current Portage, both SHA1 and RIPEMD160 should be immediately removed, as they present no advantages over the already present SHA256. SHA256 cannot be replaced immediately with SHA512, as existing Portage @@ -206,7 +207,7 @@
Old versions of Portage may support and expect only specific checksums. This is accounted for in the checksum depreciation discussion.
For maximum compatiability, we should only have to include each of the @@ -214,7 +215,7 @@ new ones that we prefer.
| [GLEP44] | Mauch, M. (2005) GLEP44 - Manifest2 format. +http://www.gentoo.org/proj/en/glep/glep-0044.html |