[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ftp.debian.org: please drop MD5sum lines from Packages



Hi,

Ansgar wrote:
> > > 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.

Steve McIntyre wrote:
> > Well, not just that. It grabs them for use in the jigdo file. The
> > jigdo backend in xorriso (libjte) also checks them as it creates the
> > ISO, for sanity checking on archive/mirror consistency right there.

The aspect of "archive/mirror consistency" is not what i perceive as
the main purpose of the MD5s. I'd rather characterize them as relation
keys and as transport checksums.
Not as security precaution.


> > I've started a local branch to update jigdo and jigit/libjte to use
> > sha256 some time ago, but -ENOTIME.

If you had asked me, i would have tried to talk you out of this.

The MD5s are sufficient for their purposes. Nothing essential is gained
by using SHA256 instead (and why not SHA512 if security matters ?).
An estimation of birthday paradox probability with a billion .deb packages
yields as upper limit for collision probability: 1 - e exp -1e-20
The negative e potency nearest to 0 which powl(3) can compute as non-0
is e exp -1e-18 (and the result printfed by %Ld looks questionable:
0.999999999999999999).

The security weakness of jigdo-lite download is in the fact that the
input file .info is not verified at all, .template is verified by an MD5
(not one of the package MD5s), and the result .iso is verified by MD5.

The user has means to do better. But they are neither mandatory nor
described in a way that a novice could apply them.
So the verification steps need to be augmented to match the security of
user applicable SHA512SUMS.sign and SHA512SUMS.

I propose to directly use this stronger authentication at the start
and end of jigdo-lite, and to leave the jigdo entrails as they are.


> >  As mentioned in IRC yesterday, we
> > will also need some time to update clients in the field to be able to
> > upgrade safely.

My proposal would make this update of clients much smoother, because the
old not-so-safe clients would continue to work with new jigdo files.

I wonder whether it is really that hard for debian-cd to compute the MD5s
on its own, before it runs xorriso.


> That includes Windows binaries (yay!)...

Who will maintain them ?

If there is expertise about MS-Windows and MacOS available, i would ask
for help with the open questions in

  https://wiki.debian.org/JigdoOnLive

which are:

- How to get firmware and network helper software when Debian Live is up ?

- How to get write access to the usual OS' filesystem in order to download
  .jigdo and .template, and in order to create the .iso file ?

(Both are questions which Debian Live should be able to answer anyways,
 if shall not only be a demo but also a rescue system.)


Daniel Kahn Gillmor wrote:
> Perhaps we should officially EOL jigdo now, if no one has time to work
> on it.

But how will Debian then distribute its full DVD sets and the BD-sized
ISOs ?


Have a nice day :)

Thomas


Reply to: