incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [ANNOUNCEMENT] Apache OpenOffice 3.4.1 (incubating) released
Date Fri, 24 Aug 2012 11:23:38 GMT
On 24 August 2012 11:51, Rory O'Farrell <ofarrwrk@iol.ie> wrote:
> On Fri, 24 Aug 2012 11:31:05 +0100
> sebb <sebbaz@gmail.com> wrote:
>
>> On 24 August 2012 09:20, Rory O'Farrell <ofarrwrk@iol.ie> wrote:
>> > On Thu, 23 Aug 2012 18:01:42 -0400
>> > "Maurice Howe" <maurice@stny.rr.com> wrote:
>> >
>> >> Got a warning msg that your product was unsafe, so I deleted the download.
>> >> Here's the msg.
>> > <snip>
>> >
>> > I have this morning scanned my Windows XP computer on which is installed yesterday's
release of AOO 3.4.1 using AVG Free edition 2012.0.2197 (this morning's update) at the most
detailed settings and it has received a clean bill of health.
>> >
>> > The question that might arise in connection with the original post is that of
the filename/download site; if it is from a legitimate (i.e. Apache controlled site) there
should be no worries.
>> >
>> > It was in the past not unusual for new releases of OOo to give false positives
on many virus scanners - the hooks for online updating registered sometimes as poentialy unwanted
programs/possible trojans.
>> >
>> > As another poster (Dan?) pointed out, it is possible to check the Md5Sums of
the downloaded file against the MD5Sum list on the Apache site, to be certain that it is exactly
the file prepared and released by Apache.  If these sums check out then all should be well.
>>
>> AIUI that's not possible to be *certain* that the file is identical [1].
>> Hashes are fine for checking that a download has not been
>> corrupted/truncated in transit, because the chance of a hash collision
>> in such a case is vanishingly small.
>>
>> But they are not generally considered sufficiently robust to *prove*
>> that the download is what it appears to be.
>> It is theoretically possible to create two different downloads with
>> the same hash.
>>
>> Obviously if the hash check fails, then there is a problem, but a
>> successful check does not provide 100% proof.
>>
>> Checking the detached signature for the download is much more secure,
>> but is of course a bit harder to do.
>>
>> [1] http://www.apache.org/dev/release-signing#secure-hash-algorithms
>>
>> > --
>> > Rory O'Farrell <ofarrwrk@iol.ie>
>>
>
> I'm not doubting your remarks above about the possibility of duplicate hashes, but for
most purposes the hash check is probably sufficient.

Yes.

> In any event, the timescale involved of some few hours after release would make the possibility
of a rogue hash matching file quite remote (I hope!).

Actually there will be at least 3-4 days when the files and hashes are
available during release votes.
But more likely the rogue file would be published later when it would
still catch some downloads.

>
> --
> Rory O'Farrell <ofarrwrk@iol.ie>

Mime
View raw message