Hi, Antoine Beaupré wrote: > I mean "broken" as in "DVD as are not available as normal ISOs over HTTP > or bittorrent but only jigdo".
Afaik, that's because jigdo uses the package mirror servers as source of the bulk of its downloads. Those servers experience the same as with a generously sized installation of a Debian system. > jigdo is the reason MD5sums are still in the Packages files, according > to ftp-masters. It's not a theory I just came up with just for kicks. I really wonder where this dependency should come from. Is there any public background info to motivate this claim ? ... one only needs to wish: Ansgar <ans...@43-1.org> writes in 942...@bugs.debian.org and on debian...@lists.debian.org: > From looking, I believe it is debian-cd's tools/grab_md5 that is using > the MD5sum from Packages (and Sources) to avoid having to compute all > these checksums itself. So it's about lazyness of debian-cd. That's an implementation detail. One should probably talk to Steve McIntyre directly. > - writing MD5sum in a separate file only used by debian-cd Why that ? debian-cd has copies of the .deb files to pack them up in the ISO. There is no jigdo production without seeing the packages. md5sum is not really slow, nowadays. > - using a (truncated) sha256sum; this requires that the jigdo client > only uses the "md5sum" as an opaque identifier for a file. It is used as opaque identifier, but this identifier is at some occasions also interpreted as MD5 which has to match the package file. Antoine Beaupré wrote: > In my experience, jigdo never worked, I tested the whole procedure shown in https://wiki.debian.org/JigdoOnLive with the non-standard situation to have an old Desktop with the filesystem of an inconscious Debian 6 host of the Debian Live system. Since i assume that you have a Debian system running, be invited to join in at https://wiki.debian.org/JigdoOnLive#If_needed.2C_work_around_a_shortcoming_of_older_jigdo-lite in order to download e.g. https://cdimage.debian.org/cdimage/release/current/amd64/jigdo-dvd/debian-10.1.0-amd64-DVD-4.jigdo https://cdimage.debian.org/cdimage/release/current/amd64/jigdo-dvd/debian-10.1.0-amd64-DVD-4.template Verify them properly and run jigdo-lite with URL https://cdimage.debian.org/cdimage/release/current/amd64/jigdo-dvd/debian-10.1.0-amd64-DVD-4.jigdo Finally verify the emerged debian-10.1.0-amd64-DVD-4.iso by the proposed means. > The CMU Software Engineering Institute considers MD5 essentially > "cryptographically broken and unsuitable for further use" Yes. But jigdo-lite does not use MD5 for cryptographical purposes except for an initial check of .template and a final check of .iso. Both are outdated. But both get re-assured by GPG and SHA512 if you follow the procedure which is outlined above. > The problem is *every* bug report (e.g. #772110) that tries to document > serious issues about jigdo *all* get downgraded to "normal", saying > "this is not a problem". But the diagnosis by Steve McIntyre tells why: > > Sorry, but this bug is hardly grave. Important, maybe... jigdo-lite > > works most of the time for most people. jigdo-lite even noticed the problem before the overall check of the .iso could be run to finally report a damaged ISO, too. Now what would you do if a directly downloaded ISO turns out to be damaged ? I'd advise download from a different source. In case of jigdo this is mainly a different package mirror. Daniel Kahn Gillmor wrote: > I'm unaware of the meaning of "cross-table key matching", You have one table with keys and values and another table with keys and values. Lines in both tables, where the keys are the same, are considered to be in relation. Like in a data base. > but it's known to be relatively easy to find collisions in MD5. It is suspected that it is possible to construct byte strings which produce a desired particular MD5 value. But when matching the lines of two tables by a key you have to consider hash table theory and especially the birthday paradox. A short excursion on wikipedia lets me estimate that the chance for a MD5 collision among 1 billion .deb files is about 1 - e exp -1e-20. Regrettably i found no calculator which would not say 0 as result. > If the adversary can convince any DD to upload an obviously harmless > package of the adversary's choice into the archive, then the adversary > can also craft another package with a matching MD5sum. The cryptographic check is to be done on .jigdo and .template before the run of jigdo-lite, and on .iso afterwards. What is a security risk is that you need much contact with debian-cd and its environment in order to know how to do it. The info is scattered on the Debian web appearance. > You probably don't mean it this way, but this sounds it will make what > should be the software author's problem into the user's problem. > [...] > Thanks for your attention to (and efforts on behalf of) jigdo, Steve. You should now face your critics. I did what i could as lowly user of Debian and disorganized upstream of xorriso. Have a nice day :) Thomas
