Bug#378183: apt: All SHA256 hashes generated/used by APT are wrong

[Jakob Bohm <jbj@image.dk>]

On Fri, Jul 14, 2006 at 12:26:12PM +0200, Goswin von Brederlow wrote:
> Jakob Bohm <jbj@image.dk> writes:
> 
> > To work around the "breaks whole system" issue, the following
> > transition plan is proposed:
> >
> >  1. Before uploading the fixed apt, temporarily reconfigure
> >   darcs etc. to NOT include SHA256 values in Packages files at
> >   all (apt-ftparchive has an option to do that).
> >
> >  2. Upload the fixed apt as a minimal change from the apt
> >    version in testing, and coordinate with ftpadmin to push it
> >    quickly through to testing.  Yes, this means holding back
> >    other bug fixes until the change has propagated.
> >
> >  3. Allow 1-3 weeks for users to upgrade to the fixed apt.  Use
> >    the various announce mailing lists to alert users to the
> >    urgency of getting rid of apt versions 0.6.44 to 0.6.44.?
> >    inclusive before the grace period ends!
> >
> >  4. Turn SHA256 back on in darcs etc. this makes the SHA256
> >    security available for real.  But it also means that the
> >    archive can no longer be used by the broken 0.6.44 versions
> >    of apt.  So leave behind (on the ftp server, www server etc.)
> >    a message explaining how users can manually upgrade to a new
> >    apt version by downloading a .tar file and a detached .gpg
> >    signature from ftp.debian.org/debian/tools/something .  (This
> >    would be a hand-built tar file containing replacement .so
> >    files for each of the bad 0.6.44 apt versions and platforms).
> >
> > For the security breakage, patching apt is the obvious fix.
> 
> One could rename the SHA256 field to SHA256v2 (or something) instead
> alowing for both new and old apt to work with both new and old
> Packages files.
> 
> Breaking the format even with a 4 week grace period will result in
> users having broken systems. We had such a transition for the
> debian-amd64 project (with libc6/base-files depends) and even 6 month
> after the transition period user still appeared on the ML unable to
> upgrade from before the transition to current. There will always be
> stragglers.

On second thought, renaming the field (even though the old field use
is not really useful) may be the better option.  The biggest unknown
factor (to me), is if the SHA256 field is already being used by one
or more Debian derived distributions, and if so, if those derived
distributins use the correct or broken value for the field.

But if no deployed software is currently using the field with its
correct contents, renaming it (and reserving the old name
indefinitely) would indeed be the smoothest overall solution.  As the
field name will appear repeatedly in Packages, Sources, Release and
other key archive index files, the new name should be chosen to match
the following criteria already satisfied by the old name:

  - Short, apt and dpkg store the uncompressed indices on the users
   disk.
  
  - Meaning obvious to the casual observer
  
  - Unlikely to clash with future updates to FIPS180, for instance if
   NIST/NSA release an updated 256 bit algorithm, such an updated
   algorithm is likely to be named SHA256v2 or SHA256v1, just as the
   second edition of 160 bit SHA (FIPS180) was named SHA-1
   (FIPS180-1).

  - A valid identifier in most programming languages, including
   shell, C++ etc.

Since SHA256 is one of the 4 new and similar hash formulas defined in
FIPS180-2, those 4 algorithms are often referred to collectively as
SHA2, with the 4 individual functions distinguished by their size in
bits.  Since none of the other SHA2 algorithms have yet to appear in
the Packages file format, and since the mental ambiguity with SHA224,
SHA384 and SHA512 is trivially dispelled by the size of the value
(256 bits == 64 hex chars), I propose simply calling the field "SHA2"
. If it is later decided to add one of the other bit lengths, that
bit length can use the SHA224/SHA384/SHA512 names that have not been
subjected to a failed implementation.

Cheers

Jakob

-- 
This message is hastily written, please ignore any unpleasant wordings,
do not consider it a binding commitment, even if its phrasing may
indicate so. Its contents may be deliberately or accidentally untrue.
Trademarks and other things belong to their owners, if any.