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

Bug#818604: Relies on MD5SUM and SHA1SUM to download d-i images in a trustful way



Control: tags -1 +help

Le vendredi, 18 mars 2016, 16.25:10 Didier 'OdyX' Raboud a écrit :
> win32-loader (its standalone version, available from debian/tools/ )
> currently relies exclusively on MD5 and SHA1 to trustfully download
> the d-i images.

After some more checking, this doesn't appear to be a quick and easy 
fix, and here's why:

plugins/sha1sum.c is an NSIS plugin file, inheriting from Werner Koch's 
sha1sum.c [0,1], itself inheriting from GnuPG 1.3.92. It has the 
advantage of allowing win32-loader.exe to proceed with the verification 
inline, without any Windows-specific dependency.

Here are the possibilities I see:

A) Package, and then use an NSIS plugin leveraging the Windows CryptoAPI
   [2]:
  - http://nsis.sourceforge.net/Crypto_plug-in
    (doesn't support SHA256, last updated in 2013)
  - http://nsis.sourceforge.net/NsisCrypt_plug-in
    Does support various hashes
    First and only version in 2010
    License quite unclear
    https://sourceforge.net/projects/angabin/files/Version%201.0.0/

B) Write a new standalone sha256sum.c NSIS plugin from one of the
   existing implementations:
  - libgcrypt: cipher/sha256.c (LGPLv2.1+)
  - coreutils: lib/sha256.c (GPLv3+)
  - e2fsprogs: lib/ext2fs/sha256.c (GPLv2)
  - wget: lib/sha256.c (GPLv3+)
  - glibc: crypt/sha256.c (LGPLv2.1+)
  - … plenty of others

Given that win32-loader is GPLv3 +, this excludes e2fsprogs', but others 
should be fine.

C) Get coreutils build a hashsums-win32 package containing cross-
   compiled win32 executables (as we're doing for gpgv-win32 and cpio-
   win32). It could also provide these files through byhand, to allow
   users to check images on Windows platforms themselves too [3].

I don't like the first option, as it relies on outdated glue software; 
the second option probably provides the cleanest solution from the 
win32-loader point of view, at the cost of yet another sha256 
implementation. The third option feels like the correct way to do it, at 
the risk of adding win32 compilers in the bootstrap circle, through 
coreutils.

I'll see whether I can produce a patch to do C), and keep this bug 
posted.

-- 
Cheers,
    OdyX

[0] https://lists.gnupg.org/pipermail/gnupg-announce/2004q4/000184.html
[1] ftp://ftp.gnupg.org/gcrypt/binary/sha1sum.c
[2] https://en.wikipedia.org/wiki/Microsoft_CryptoAPI
[3] https://lists.fedoraproject.org/pipermail/infrastructure/2009-November/008052.html

Attachment: signature.asc
Description: This is a digitally signed message part.


Reply to: