On Fri, Jul 14, 2006 at 12:26:12PM +0200, Goswin von Brederlow wrote: > Jakob Bohm <[EMAIL PROTECTED]> 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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]