Dear Maintainer,

as described in
https://lists.debian.org/debian-cd/2018/01/msg00021.html
jigdo-file verifies the .template file and the resulting ISO image only
by MD5 checksums which stem from the .jigdo or from the .template file.
The .jigdo file is not verified at all.

Both issues have own bug reports (#887831 and #887830). This one proposes
a preliminary fix by simply telling the user that it's not safe yet.

The final message after the MD5 check of the finished ISO image is
overly affirmative:
  "OK: Checksums match, image is good!"
It stems from jigdo-file and it might be used by automated callers of
jigdo-lite as indication of successful download.

But after this message, jigdo-lite could point to the advised verification
by GPG and a more secure checksum type like SHA512.


Have a nice day :)

Thomas

Please let's not ask the user to do something that the software can do
automatically for them.  If the user used jigdo, and the author(s) of
jigdo know how to do the appropriate checks, then jigdo should just do
the checks and report the result, not tell users how to do the checks
and expect them to actually follow through.  We know in practice that
won't happen.

Let's make our tools usable.

[ Sent to multiple people and Debian bugs - please respect the
  reply-to and follow up on the debian-cd list if you have
  replies/comments. ]

Hi folks!

For a while we've been working to move away from using MD5 in various
parts of Debian, and jigdo is one of the last few things that's still
using it now. We've had a few bugs raised about this (#887837 and
#887831) and quite some discussion recently. I've been hacking on
jigdo and jigit to add support for a new v2 jigdo format which
switches from using md5 for internal checksumming to using sha256
instead, and I'm just about done now. I have a few remaining things to
do next, that I'd like to ask for some help with (please!) - see
further down. Prompt responses would be appreciated if possible.

jigdo
=====

I've extended jigdo to support both formats (old and new). Building a
new jigdo/template pair requires the user to specify which format they
want, while creating/verifying an image will auto-detect the format
automatically from the input data. I think that is clearly the best
design here.

I'm *most* worried about updating the various clients that people may
have in the field, using jigdo-lite/jigdo-mirror to make ISO images
from the jigdo data that we release with Debian, so that was my first
priority. I'm *not* aware of anybody actually using jigdo-file itself
to create new jigdo/template pairs these days, but I've done the right
thing anyway and added support for sha256 here too.

I've forked from Richard's last 0.7.3 release, and put it into my own git
server at

https://git.einval.com/cgi-bin/gitweb.cgi?p=jigdo.git;a=shortlog;h=refs/heads/upstream

along with the various fixes that we already had in Debian since that
release.

I've built and tested binaries locally with both jigdo formats,
including on Windows. All looks good here. \o/

jigit/libjte
============

I've also updated and extended my own jigit/libjte code to work with
both formats, and I'm about to release those. The changes are not too
big, and the external API for libjte is *very* close to what we had
before. I've already updated a local copy of xorriso to use it, and
the changes are tiny! \o/

genisoimage
===========

I am *not* planning to update my code in genisoimage to use the new
jigdo v2 format. We don't use genisoimage at all in the Debian images
team any more, having moved to xorriso instead. The only reason to
even think about updating genisoimage would be for powerpc
images. While the debian-ports people are still supporting powerpc and
periodically releasing new unofficial CD/DVD images for it, I don't
think jigdo is needed here. *If you think differently*, let me know...

Publishing the new format
=========================

debian-cd and some of our backend setup on our cdimage sites will need
some minor updates to support the new sha256 format as well, but
that's not urgent yet. We must *not* switch to publishing the new v2
jigdo format for a while (I'm thinking maybe 12 months?), to give
people the chance to update their clients. I also don't want to leave
this *too* long, as the Debian ftpmaster team and others would like to
ditch md5 soon.

We'll need to make noise about this, and update web pages etc. to
mention the change. New links to new tools, etc.

Richard
=======

With your blessing, I'd like to release my new code as jigdo version
0.8.0. If you're ok with that, could you please update your jigdo web
pages to mention this? I'll add a page at

https://www.einval.com/~steve/software/jigdo/

that you can link to. I'll add some docs, and links back to you (of
course!) and download links for Windows binaries etc. So far I've left
the creator information in newer jigdo files pointing at your site as
you're the inventor, but I'm also happy to change that if you'd like
and reduce your web traffic - just let me know please! :-)

Mattias
=======

You're the person normally working with people using jigdo tools to
mirror Debian's CD/DVD releases. We'll need to ask people to update
all their tools to enable using the new v2 format. What systems are
they normally using? I'm guessing a mix of Debian systems of various
versions, plus maybe a few other OSes? I'm happy to do Debian
backports builds of the new tool versions to help support people, but
I don't know:

 (a) what else might need to be supported
 (b) what timescale these people would be happy with or updates

Obviously, we don't want to be pushing new format versions until the
mirror network is ready to take them. But we want that to be as soon
as practically possible.

Thomas
======

You've done an awesome job with xorriso and the libjte integration!
It's been really easy to drop in my new libjte code and have xorriso
generate the new format. I've got a simple diff right now that I'm
just cleaning up and will send you shortly.