DIST portage-2.0.51.22.tar.bz2 257823 RMD160 068a6fbc3e41f7357d1ee4d65894e7903c467cfe SHA1 16459ce2b19592c94ec580bcfade5a89750a62fb SHA256 f0dac4366b5234b084645bbbd6b871a5abe05d501cf868046af2777e02a4100c DIST portage-2.0.54.tar.bz2 234784 RMD160 26c724df242a7d0c44d7fd06067bfcdbc4e3556b SHA1 0559bf8068976c124f0026ab65f3f4a62ae39d83 SHA256 69075ab4599958c4f7c7a932b95dcd77efa1b3c46ac28acb577284bc48a1db06 ^^^ two examples from portages Manifest. Manifest2 was intended to move digest data into manifest; it's exempting md5 however, thus to get all chksums implementations have to access digest also. Goes without saying this is innefficient; related, the N chksums generated in old style manifest format may be droppable considering Manifest2 support (space saving).
To head it off, if the response is that md5 is being dropped from chksums, might want to run it past others also. Yes, can pull off collisions, but we support N chksums (including the simplistic size check) for a reason. If md5 is being punted, should be made clear; glep doesn't specify it, nor has there been any discussion on the ml about actually punting, just usuall "waah, another /. article about decreased strength in a chf" :)
(In reply to comment #0) > ^^^ two examples from portages Manifest. > Manifest2 was intended to move digest data into manifest; it's exempting md5 > however, thus to get all chksums implementations have to access digest also. It's easy to add MD5 to portage_const.MANIFEST2_HASH_FUNCTIONS if people want that. I'm not sure why it hasn't been included. Marius? > Goes without saying this is innefficient; related, the N chksums generated in > old style manifest format may be droppable considering Manifest2 support (space > saving). Do you mean, like these ones? MD5 19f5c196e9fdb3f1a4916a4c9914583c portage-2.0.51.22-r3.ebuild 5746 RMD160 acc2d23c94adbe7823d4193ff3af316be5e173c7 portage-2.0.51.22-r3.ebuild 5746 SHA256 973bf27adcb1ff03fc1d06aa5851c2a1d82df571297064f41e2d0802a8cd3410 portage-2.0.51.22-r3.ebuild 5746 We need at least one of those for backward compatibility, right? The other two can be ommitted in order to save space.
(In reply to comment #2) > (In reply to comment #0) > > ^^^ two examples from portages Manifest. > > Manifest2 was intended to move digest data into manifest; it's exempting md5 > > however, thus to get all chksums implementations have to access digest also. > > It's easy to add MD5 to portage_const.MANIFEST2_HASH_FUNCTIONS if people want > that. I'm not sure why it hasn't been included. Marius? Required for actual transitioning from Manifest1/digest to Manifest2... > > Goes without saying this is innefficient; related, the N chksums generated in > > old style manifest format may be droppable considering Manifest2 support (space > > saving). > > Do you mean, like these ones? > > MD5 19f5c196e9fdb3f1a4916a4c9914583c portage-2.0.51.22-r3.ebuild 5746 > RMD160 acc2d23c94adbe7823d4193ff3af316be5e173c7 portage-2.0.51.22-r3.ebuild > 5746 > SHA256 973bf27adcb1ff03fc1d06aa5851c2a1d82df571297064f41e2d0802a8cd3410 > portage-2.0.51.22-r3.ebuild 5746 > > We need at least one of those for backward compatibility, right? The other two > can be ommitted in order to save space. Need md5 specifically; for the rest, Manifest2 provides it already; for manifest1 only systems, they get md5 only; sucks, but the window for being manifest1 *and* supporting alternative chfs isn't that huge anyways.
Also... digest files aren't listed in the manifest2 entries. Don't particularly see why they aren't classifed offhand; for misc, you basically know the files can be chucked- files/digest-* applies when manifest2 is in affect.
(In reply to comment #2) > (In reply to comment #0) > > ^^^ two examples from portages Manifest. > > Manifest2 was intended to move digest data into manifest; it's exempting md5 > > however, thus to get all chksums implementations have to access digest also. > > It's easy to add MD5 to portage_const.MANIFEST2_HASH_FUNCTIONS if people want > that. I'm not sure why it hasn't been included. Marius? See the glep under "number of hashes", the only guaranteed checksum type in Manifest2 is SHA1. (In reply to comment #4) > Also... digest files aren't listed in the manifest2 entries. > > Don't particularly see why they aren't classifed offhand; for misc, you > basically know the files can be chucked- files/digest-* applies when manifest2 > is in affect. Why should they be listed? They contain redundant information (and they are listed in the compat section). Listing them might cause weird interactions later when manifest1 is going to be phased out (depending on how exactly that is handled). (In reply to comment #3) > (In reply to comment #2) > > It's easy to add MD5 to portage_const.MANIFEST2_HASH_FUNCTIONS if people want > > that. I'm not sure why it hasn't been included. Marius? > Required for actual transitioning from Manifest1/digest to Manifest2... Why?
(In reply to comment #5) > (In reply to comment #2) > > (In reply to comment #0) > > > ^^^ two examples from portages Manifest. > > > Manifest2 was intended to move digest data into manifest; it's exempting md5 > > > however, thus to get all chksums implementations have to access digest also. > > > > It's easy to add MD5 to portage_const.MANIFEST2_HASH_FUNCTIONS if people want > > that. I'm not sure why it hasn't been included. Marius? > > See the glep under "number of hashes", the only guaranteed checksum type in > Manifest2 is SHA1. > > (In reply to comment #4) > > Also... digest files aren't listed in the manifest2 entries. > > > > Don't particularly see why they aren't classifed offhand; for misc, you > > basically know the files can be chucked- files/digest-* applies when manifest2 > > is in affect. > > Why should they be listed? They contain redundant information (and they are > listed in the compat section). Listing them might cause weird interactions > later when manifest1 is going to be phased out (depending on how exactly that > is handled). digests list SHA256 and rmd160; it already has redundant data and can cause weird interactions (thus it's not an arguement against md5 being excluded from manifest2 dist entries). > (In reply to comment #3) > > (In reply to comment #2) > > > It's easy to add MD5 to portage_const.MANIFEST2_HASH_FUNCTIONS if people want > > > that. I'm not sure why it hasn't been included. Marius? > > Required for actual transitioning from Manifest1/digest to Manifest2... > > Why? Shift over for manifest2 is going to require a few steps 1) full manifest2 deployment 2) make portage aware of digest, but ignore non manifest2 data. 3) start pruning 4) reverse the "ignore digest files" and make it a pkg error if digests exist. As such... unless you're planning on trying to shift md5 into manifest2 for #2 (thus invalidating #1 a bit), you need md5 in manifest2 _now_.
(In reply to comment #6) > (In reply to comment #5) > > Why should they be listed? They contain redundant information (and they are > > listed in the compat section). Listing them might cause weird interactions > > later when manifest1 is going to be phased out (depending on how exactly that > > is handled). > digests list SHA256 and rmd160; it already has redundant data and can cause > weird interactions (thus it's not an arguement against md5 being excluded from > manifest2 dist entries). I think we're talking about different things here. I wasn't talking about mismatches between manifest and digest data but existance mismatches later on. Also please stop mixing arguments, digsts in manifest2 have nothing to do with md5 in manifest2. > > > (In reply to comment #3) > > > (In reply to comment #2) > > > > It's easy to add MD5 to portage_const.MANIFEST2_HASH_FUNCTIONS if people want > > > > that. I'm not sure why it hasn't been included. Marius? > > > Required for actual transitioning from Manifest1/digest to Manifest2... > > > > Why? > Shift over for manifest2 is going to require a few steps > 1) full manifest2 deployment > 2) make portage aware of digest, but ignore non manifest2 data. > 3) start pruning > 4) reverse the "ignore digest files" and make it a pkg error if digests exist. > > As such... unless you're planning on trying to shift md5 into manifest2 for #2 > (thus invalidating #1 a bit), you need md5 in manifest2 _now_. Can't follow you: 1) doesn't need MD5 in MF2 2) NFC what you mean with that, digests don't contain Manifest2 data so this statement is a contradiction as far as I can understand it 3) see 1) 4) see 1)
I don't get what this bug is really about. The spec is clear and was approved, and so far I haven't seen any real reason here to keep md5.
