Re: bug 887830 and 887831
Hi, i wrote: > > jigdo-lite could now make automatic use of the *SUMS via the according > > *sum programs. Steve McIntyre wrote: > That's a change I don't really want to make - the *SUMS we have are > specific to the Debian layout, and AFAIK we're not the only people > using jigdo. It would immediately create security. Probably more than manual ISO downloading, because people tend to omit verifying. The automatic verifying could be omitted if not gpg and sha512sums are installed and if not SHA512SUMS and SHA512SUMS.sign is found in the .jigdo file's parent directory. But if all this stuff is available, why not use it ? Not to forget, the current version of jigdo-lite can download the .jigdo file and currently does not verify it at all. At least this part should be covered by gpg under control of jigdo-lite. And then why not give .template the same verification treatment as .jigdo ? Of course Debian package jigdo-file should then depend on gpg and sha512sum. > > Or jigdo-lite could expect better .template checksums in the .jigdo file > > and jigdo-file could learn to compute such sums. > > libjte can, so jigdo-file could learn from there. > That makes much more sense, yes. As/when/if I find the time, I'll > fight with the C++ in jigdo-file to look for better checksums. As said, this cannot verify the .jigdo file (unless it gets signed non-detached by gpg). Elsewise: The SHA-512 stuff could be taken from libjte. The .jigdo file already has SHA-512 for the ISO image: # Image Hex SHA512Sum 27e41f13ce0f71e0fc503da41f3afa87285e0fc2e8ffb8d7ff4f572e26451dafd1a6f220c9256731d451400893437b0dfc17534c441f2a29a81130c59f790a50 but not for .template. jigdo-lite would have to hand the SHA-512 of .template to jigdo-file, instead of the MD5 as is done currently. jigdo-file would need a verification command that mimics sha512sum. libjte seems prepared for more .template checksums. Only MD5 is enabled by default. Compare checksum_algo_iso and checksum_algo_tmpl at https://sources.debian.org/src/jigit/1.20-2/libjte/libjte.c/#L100 xorriso calls libjte_set_checksum_template() with the argument of xorrisofs option -checksum_algorithm_template. In debian-9.3.0-i386-netinst.iso/.disk/mkisofs there is -checksum_algorithm_iso md5,sha1,sha256,sha512 but no -checksum_algorithm_template. So, to my untested theory, it should suffice to use in debian-cd -checksum_algorithm_template md5,sha1,sha256,sha512 In live-wrapper it would be -jigdo checksum_template md5,sha1,sha256,sha512 (but debian-live-9.3.0-amd64-xfce.iso/.disk/mkisofs shows no -jigdo commands.) I am a bit brain damaged today and maybe in the next days. When i am in better shape i will modify xorriso's Jigdo production regression test to see whether the production part is really that easy. Have a nice day :) Thomas
Re: bug 887830, was: Joliet name length in amd64 netinst versus DVD-2
On Mon, Feb 12, 2018 at 05:29:45PM +0100, Thomas Schmitt wrote: > >Now the next weakest point in Jigdo download is > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887831 > "jigdo-file: Jigdo .template file and resulting ISO are only verified by MD5" > >jigdo-lite after fix of bug 865864 downloads the .template if it yet >missing in the local directory. Verification is done by line >"Template-MD5Sum" of the .jigdo file, not by *SUMS. > >jigdo-lite could now make automatic use of the *SUMS via the according >*sum programs. That's a change I don't really want to make - the *SUMS we have are specific to the Debian layout, and AFAIK we're not the only people using jigdo. >Or jigdo-lite could expect better .template checksums in the .jigdo file >and jigdo-file could learn to compute such sums. >libjte can, so jigdo-file could learn from there. That makes much more sense, yes. As/when/if I find the time, I'll fight with the C++ in jigdo-file to look for better checksums. -- Steve McIntyre, Cambridge, UK.st...@einval.com Getting a SCSI chain working is perfectly simple if you remember that there must be exactly three terminations: one on one end of the cable, one on the far end, and the goat, terminated over the SCSI chain with a silver-handled knife whilst burning *black* candles. --- Anthony DeBoer
Re: magnet links and pushing them to meta-search engines.
On Mon, Feb 12, 2018 at 08:25:54AM +0530, shirish शिरीष wrote: >On 12/02/2018, Steve McIntyre wrote: >> >> We've had a few "virus" reports about our images over the years, but >> every one I've investigated has clearly been a false positive in the >> virus checker involved. Many of them are proprietary, which of course >> makes it difficult to debug the problem. :-/ > >aha, ok didn't know that. ... >Actually what I had wanted to ask/post the query is that we somehow >miss the bus of getting the releases to meta-search engines such as >torrentz.eu > >See for e.g. https://torrentz2.eu/search?f=%27debian-9.3.0-amd64%27 > >and see the results that have cropped up. I was hoping that it would >show the CD releases as well as the DVD releases and net install. As >can be seen while it shows the DVD image and the netinstall images, >but for unknown reasons officially CD images seems to have gone the >way of dodo > >https://cdimage.debian.org/debian-cd/current/amd64/bt-cd/ > >Maybe because CD-1 has become too big that it can't anymore fit lxde >or something for base-install + desktop environment. I did scour the >archives for last 2-3 months but wasn't able to get anything about why >they were dropped although it probably is due to the space issue I >have mentioned above. > >Are there any hopes of the CD images being revived in the future or >that's sort of gone forever ? We dropped the CD sets a while back, for the reason you've guessed. See the announcement in https://lists.debian.org/debian-devel-announce/2015/09/msg4.html I've since re-added a single-CD option for Xfce, for thoe people who really do want a single CD that will give them a basic desktop, -- Steve McIntyre, Cambridge, UK.st...@einval.com Who needs computer imagery when you've got Brian Blessed?
Bug#767253: Please provide hashes for uncompressed Translation-*
On Fri, Feb 16, 2018 at 04:16:12PM +, Steve McIntyre wrote: >On Sun, Jan 07, 2018 at 07:14:28PM +0100, David Kalnischkies wrote: >>Hi CD Team, >> >>sry for digging out old archived bugs¹, but in this case it seems >>justified to perform the dark art of bugreport necromancy: >> >>Downloading a current netinst iso and looking at the included Release >>file shows that the hashes for uncompressed Translation files aren't >>there which in turn means apt isn't making use of the translations >>shipped in this way. >> >>I haven't tried the attached patch which basically reverts the breaking >>one-line change, so take it with a pinch of salt, but I am hopeful it >>works. > >ACK, thanks for looking at this again. Testing it now. Looks good, so I've backported the fix to older build branches too. -- Steve McIntyre, Cambridge, UK.st...@einval.com "This dress doesn't reverse." -- Alden Spiess
Bug#767253: Please provide hashes for uncompressed Translation-*
On Sun, Jan 07, 2018 at 07:14:28PM +0100, David Kalnischkies wrote: >Hi CD Team, > >sry for digging out old archived bugs¹, but in this case it seems >justified to perform the dark art of bugreport necromancy: > >Downloading a current netinst iso and looking at the included Release >file shows that the hashes for uncompressed Translation files aren't >there which in turn means apt isn't making use of the translations >shipped in this way. > >I haven't tried the attached patch which basically reverts the breaking >one-line change, so take it with a pinch of salt, but I am hopeful it >works. ACK, thanks for looking at this again. Testing it now. -- Steve McIntyre, Cambridge, UK.st...@einval.com "Because heaters aren't purple!" -- Catherine Pitt
