Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
Received-SPF: pass (google.com: domain of robweir@apache.org designates
 10.52.35.12 as permitted sender) client-ip=10.52.35.12;
MIME-Version: 1.0
In-Reply-To: <FC637421-86AC-41B0-B9C6-6D1E9CE0C788@comcast.net>
References: 
 <CAP-ksohkJPZkPx4rvsvkeKa_RzaXVW9b3bE7ySi=wnX=r5rQhQ@mail.gmail.com>
	<FC637421-86AC-41B0-B9C6-6D1E9CE0C788@comcast.net>
Date: Fri, 2 Mar 2012 12:52:23 -0500
Message-ID: 
 <CAP-ksojJ8nkCMgsT_1U7m3J4L1YCiDU6tzjbOQddr1JSWzaMJg@mail.gmail.com>
Subject: Re: Symantec WS.Reputation.1 Errors: What we can do
From: Rob Weir <robweir@apache.org>
To: ooo-dev@incubator.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Mar 2, 2012 at 12:25 PM, Dave Fisher <dave2wave@comcast.net> wrote:
>
> On Mar 2, 2012, at 7:00 AM, Rob Weir wrote:
>
>> Several testers have mentioned this anti-virus error when installing
>> the AOO 3.4 dev snapshot build. =C2=A0 This is not a virus.
>> "WS.Reputation" errors come from Symantec Antivirus based on their
>> "reputation-based" threat assessments. =C2=A0Essentially, they evaluate
>> software that you are about to install according to a range of
>> factors, including how new the file is, how many other people have
>> installed it, whether the installer is digitally signed, etc. =C2=A0It i=
s
>> not just one factor, but a proprietary mix of weighted factors.
>>
>> We're probably getting penalized based on several of these factors.
>> Note that with the final AOO 3.4 release we'll be in the same
>> position, since that installer will also be new,etc.
>>
>> A few things we should consider doing:
>>
>> 1) Make sure the readme file and install instructions cover this case
>> and explain what the user should do, e.g. "Run anyways"
>>
>> 2) We can make a request to Symantec to "whitelist" our installer.
>> This takes a couple of weeks for them to process. =C2=A0And we can';t st=
art
>> this work in advance since they need the SHA-256 hash of our
>> installer:
>>
>> https://submit.symantec.com/whitelist/isv/
>>
>> 3) We could digitally sign our Windows installers. =C2=A0 Apache already
>> requires a detached signature. =C2=A0But Symantec has no idea about thes=
e.
>> We need traditional Windows exe code signing. =C2=A0This will help us wi=
th
>> Windows 8 as well. =C2=A0So it is something we probably want to look int=
o
>> at some point.
>
> This is likely to be a release requirement. Remember all artifacts in an =
Apache Release must be signed and installers are artifacts. (This touches =
=C2=A0your discussion on the other thread about what is AOO, what is powere=
d by, and what is "White Label")
>

Right.  But all that is required are *detached* signatures.  These are
fine for human verification, but they don't help in this case.

> I believe that signing process is being worked on elsewhere in the founda=
tion in a way that can make this an easy part of the release process. I've =
a little experience with signing installers a few years ago, but I won't ha=
ve many cycles for it for a few weeks. I'll look in my ML archives and ask =
the question on the appropriate Incubator ML about our participation in the=
se tests.
>

With current approach, it is based on "web of trust". So Release
Manager, and other PMC members verify and sign.   But normal code
signing on Windows is more hierarchical, and based on a trusted root
CA, etc.  Is the plan to have each PMC have its own signing cert?  In
this case the IPMC?

-Rob

> Regards,
> Dave
>
>>
>> My recommendation:
>>
>> Plan on doing 1. =C2=A0Do 2. as soon as we have a release. =C2=A0Look in=
to 3. for AOO 4.0.
>>
>> Regards,
>>
>> -Rob
>