incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <robw...@apache.org>
Subject Re: [ANNOUNCEMENT] Apache OpenOffice 3.4.1 (incubating) released
Date Fri, 24 Aug 2012 14:05:06 GMT
On Fri, Aug 24, 2012 at 7:23 AM, sebb <sebbaz@gmail.com> wrote:
> 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.
>


Ideally we'd have a way for the user to verify this themselves,
without getting into command-line tools.  For example, a trusted
website with an applet that would verify hash and signature for a
local file.  Or could this conceivably be doe with Javascript?

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

Mime
View raw message