openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <>
Subject RE: [PACKAGING 4.1.2-patch1 Binaries] (was RE: [TESTING] Applying openoffice-4.1.2-patch1 for Windows)
Date Fri, 12 Aug 2016 19:22:12 GMT

> -----Original Message-----
> From: Don Lewis []
> Sent: Thursday, August 11, 2016 14:41
> To:;
> Subject: Re: [PACKAGING 4.1.2-patch1 Binaries] (was RE: [TESTING]
> Applying openoffice-4.1.2-patch1 for Windows)
> On 11 Aug, Kay wrote:
> >
> >
> > On 08/11/2016 12:50 PM, Kay wrote:
> >>
> >>
> >> On 08/09/2016 02:12 PM, Kay Schenk wrote:
> >>> [top posting]
> >>> I'm in the process of trying to "sync" instructions for Linux32,
> >>> Linux64, and MacOSX at the moment. As far as instructions on the
> >>> actual HOTFIX page, we need to have just a "general" instruction for
> >>> ALL zips that simply says -- "Unzip this package to some folder of
> >>> your choosing and read the README that's included." Everything else
> >>> should be in the various READMEs for each platform.
> >>>
> >>> I should be done with all edits by this evening for a final review
> >>> before zipping and signing.
> >>
> >> Ok, I've now moved on to creating zip files, etc for Linux32, Linux64
> >> and Mac.
> >>
> >> My openssl version on does NOT supply digest sha256. Is it OK to use
> >> sha1? MD5 already computed for each of these.
> >
> > sha1 is referenced on the ASF code signing page so I decided it was
> OK. :)
> I'm really surprised that ASF requires MD5 since it was broken long ago.
> Even SHA1 is now regarded as a weak hash.

I think it depends on shrinking the attack surface and also what the MD5 is being used for.
 In the present case, it is extremely difficult to construct a Zip that has different usable
content and the same hash.  It would require adding extra content until the correct hash is
duplicated despite alteration of the key payload, and that should become rather evident. 
I think the main reason for keeping it is that checking the MD5 is still more widely available
to users.  It may not be foolproof but it is better than not.  

And yes, collisions are possible and can be manufactured, but having one that accomplishes
something can be rather tricky.  The proofs-of-concept involve alterations that aren't visible
and won't be noticed.  Somebody will notice and it is not clear that the possible benefit
is worth the effort to pull it off, especially against the risk of discovery.

Hmm, one thing we could do is add the length of the zip in the README.  (It takes a little
work, but can be done, even when the (signed) README is inside the Zip.  That's another nice
reason for having the signed README also available for independent download outside of the
Zip and only downloadable from the ASF archive site, along with the different hashes and the
package's signature.

[Anecdotal Side Note: I just discovered that the MD5 hash for the 4.1.2 Windows .exe fails
to check on my Windows system because of a defect in the .md5 file.  For reasons unknown,
the md5sum tool that I have requires exactly two spaces between the hash value and the name
of the file the hash is for.  Once I fiddled around and added the second space, it all checks.
 What is intriguing to me is that this has not been reported by anyone, which is perhaps of
greater concern than the fact that MD5 is used [;<].
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message