MD5 considered harmful today, SHA-1 considered harmful tomorrow

[Victor Duchovni]

On Fri, Jan 23, 2009 at 04:01:50PM +1100, Ben Laurie wrote:

> > I really hope to see
> > real OpenSSL patch releases some day with development of new features
> > *strictly* in the development snapshots. Ideally this will start with
> > 0.9.9a, with no new features, just bug-fixes, in [b-z]. ]
> 
> I think that is not likely to happen, because that's not the way it
> works. The promise we try to keep is ABI compatibility between
> releases that have the same numbers. Letters signify new versions
> within that series. We do not have a bugfix-only branch. There doesn't
> seem to be much demand for one.

Don't want to start a long debate here, but I do want to respond to this.

You seem to be out of touch I am afraid. Just look at what many O/S
distributions do. They adopt a new OpenSSL 0.9.Xy release from time to
time (for some initial "y") and back-port security fixes never changing
the letter. One can't actually tell from "openssl version" what version
one is running and which fixes have been applied.

Why am I back-porting patch-sets to 0.9.8i? Is that because there is no
demand for bugfix releases? There is indeed demand for real bugfix
releases, just that people have gotten used to doing it themselves,
but this is not very effective and is difficult to audit.

OpenSSL has not infrequent security advisories, and these are always fixed
in new feature releases not bugfix releases (which are misleadingly called
"patch" releases).

    #define HEADER_OPENSSLV_H

    /* Numeric release version identifier:
     * MNNFFPPS: major minor fix patch status
     * The status nibble has one of the values 0 for development, 1 to e for betas
     * 1 to 14, and f for release.  The patch level is exactly that.
     * For example:
     * 0.9.3-dev      0x00903000
     * 0.9.3-beta1    0x00903001
     * 0.9.3-beta2-dev 0x00903002
     * 0.9.3-beta2    0x00903002 (same as ...beta2-dev)
     * 0.9.3          0x0090300f
     * 0.9.3a         0x0090301f
     * 0.9.4          0x0090400f
     * 1.2.3z         0x102031af
     *
     * For continuity reasons (because 0.9.5 is already out, and is coded
     * 0x00905100), between 0.9.5 and 0.9.6 the coding of the patch level
     * part is slightly different, by setting the highest bit.  This means
     * that 0.9.5a looks like this: 0x0090581f.  At 0.9.6, we can start
     * with 0x0090600S...
     *
     * (Prior to 0.9.3-dev a different scheme was used: 0.9.2b is 0x0922.)
     * (Prior to 0.9.5a beta1, a different scheme was used: MMNNFFRBB for
     *  major minor fix final patch/beta)
     */
    #define OPENSSL_VERSION_NUMBER  0x0090809fL

-- 

 /"\ ASCII RIBBON                  NOTICE: If received in error,
 \ / CAMPAIGN     Victor Duchovni  please destroy and notify
  X AGAINST       IT Security,     sender. Sender does not waive
 / \ HTML MAIL    Morgan Stanley   confidentiality or privilege,
                                   and use is prohibited.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com