You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Rob Weir <ro...@apache.org> on 2012/03/02 16:00:14 UTC

Symantec WS.Reputation.1 Errors: What we can do

Several testers have mentioned this anti-virus error when installing
the AOO 3.4 dev snapshot build.   This is not a virus.
"WS.Reputation" errors come from Symantec Antivirus based on their
"reputation-based" threat assessments.  Essentially, 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.  It is
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.  And we can';t start
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.   Apache already
requires a detached signature.  But Symantec has no idea about these.
We need traditional Windows exe code signing.  This will help us with
Windows 8 as well.  So it is something we probably want to look into
at some point.

My recommendation:

Plan on doing 1.  Do 2. as soon as we have a release.  Look into 3. for AOO 4.0.

Regards,

-Rob

[RELEASE] Signing Artifacts [Was Re: Symantec WS.Reputation.1 Errors: What we can do]

Posted by Dave Fisher <da...@comcast.net>.
Hi Dennis,

I am changing the subject to give this discussion the visibility it should have.

I think it would be highly desirable to digitally sign AOO 3.4 artifacts.

On Mar 2, 2012, at 1:15 PM, Dennis E. Hamilton wrote:

> Out of curiosity I just did another download of the OOo-dev 3.4 Windows "MSI" r1293550 to see if the popularity contest had been won yet.  
> 
> Not yet.
> 
>  The Internet Explorer 9 download warning is "OOo-Dev-OOO340m1_Win_x86_install_en-US.exe is not commonly downloaded and could harm your computer."  The file is already downloaded at that point, however.  The options are Delete, Actions, and View downloads (opening a separate tool that shows downloads and status).  The Actions option includes "Don't run this program (recommended)", "Delete", and "Run Anyway."  
> 
>  A "Run Anyway" or a later execution of the downloaded .exe will provoke an User Account Control message (on default configurations, even for administrator accounts) that warns that the file is from an unknown source (that is, the .EXE is not signed) and that it was downloaded from the Internet. 
> 
> I also did a custom scan of the single download file using Microsoft Security Essentials.  The scan (which is programmed to dig into these files) identified 51916 individual items and no threats.
> 
> All of this is tolerable and arguably appropriate for developer snapshots.  Users who use these builds need to rely on their own judgment about the trustworthiness of the origin and the content of those files.  
> 
> Note that it is the .exe that needs to be signed.  This should not be confused with a .msi file, although I assume those can be signed also.  Apache OpenOffice does not use .msi as the packaged binary that is downloaded.  (It appears that LibreOffice has changed that.)  It strikes me that using external digest values (md5 and sh1 digests) on the download requires a super-user skill set and should not be the only thing relied upon for project binary releases.

(Side note about Releases) All PPMC members who vote for a release will be expected to understand how to use md5/sha1 digest values and to have checked the signatures of ALL artifacts. It is a release blocker to have missing or incorrect signatures.

Soon, all will understand that this is NOT something to ask Grandma or Joe Bob to do.

So, signatures from a trusted entity like the ASF will go along way towards gaining trust. The gist of the signing service discussion was when to apply digital signatures to Development, Test and Production Artifacts. It was mentioned that Dev and Test Artifacts could have expiring certificates.

So, I will explore this and if viable return with documentation for the Release Manager.

Regards,
Dave

> 
> -----Original Message-----
> From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org] 
> Sent: Friday, March 02, 2012 11:19
> To: ooo-dev@incubator.apache.org
> Subject: RE: Symantec WS.Reputation.1 Errors: What we can do
> 
> The web-based downloader in Internet Explorer 9 also warns about the .exe files (not the tar.gz or Zip ones).  The message is clearly a no-reputation-yet warning.  
> 
> This is an on-line check.  When the file is known to be regularly downloaded, the report will change automatically.  
> 
> I have seen no AV warnings about the downloaded files themselves, although there is a standard OS warning on use of such files when they were downloaded from the internet and/or are not signed.  (In Windows 8 Consumer Preview, it is necessary to click "details" to see that there is a "Run anyhow" selection.)  
> 
> I saw no AV warnings after the installation on any systems having Microsoft Malware detection and regularly-updated Windows Security Essentials.
> 
> - Dennis
> 
> -----Original Message-----
> From: Rob Weir [mailto:robweir@apache.org] 
> Sent: Friday, March 02, 2012 07:00
> To: ooo-dev@incubator.apache.org
> Subject: Symantec WS.Reputation.1 Errors: What we can do
> 
> Several testers have mentioned this anti-virus error when installing
> the AOO 3.4 dev snapshot build.   This is not a virus.
> "WS.Reputation" errors come from Symantec Antivirus based on their
> "reputation-based" threat assessments.  Essentially, 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.  It is
> 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.  And we can';t start
> 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.   Apache already
> requires a detached signature.  But Symantec has no idea about these.
> We need traditional Windows exe code signing.  This will help us with
> Windows 8 as well.  So it is something we probably want to look into
> at some point.
> 
> My recommendation:
> 
> Plan on doing 1.  Do 2. as soon as we have a release.  Look into 3. for AOO 4.0.
> 
> Regards,
> 
> -Rob
> 


Re: Symantec WS.Reputation.1 Errors: What we can do

Posted by drew jensen <dr...@gmail.com>.
Just to add my observations.

Installed on Vista and Win7
- both machines running Avast vs Symantec.
- both cases Avast also notes to the user the exe and msi are unsigned
and offers to run them in a sandbox. 
- After install as each of the modules is run for the fist time (swriter
vs soffice) then Avast again pops up and again suggests this first time
arrival be run in a sanbox. (note after saying no once it is no longer
prompted)

Anyway - just how a different anti-virus package deals with it.

//drew

On Fri, 2012-03-02 at 16:39 -0500, Rob Weir wrote:
> On Fri, Mar 2, 2012 at 4:15 PM, Dennis E. Hamilton
> <de...@acm.org> wrote:
> > Out of curiosity I just did another download of the OOo-dev 3.4 Windows "MSI" r1293550 to see if the popularity contest had been won yet.
> >
> > Not yet.
> >
> >  The Internet Explorer 9 download warning is "OOo-Dev-OOO340m1_Win_x86_install_en-US.exe is not commonly downloaded and could harm your computer."  The file is already downloaded at that point, however.  The options are Delete, Actions, and View downloads (opening a separate tool that shows downloads and status).  The Actions option includes "Don't run this program (recommended)", "Delete", and "Run Anyway."
> >
> >  A "Run Anyway" or a later execution of the downloaded .exe will provoke an User Account Control message (on default configurations, even for administrator accounts) that warns that the file is from an unknown source (that is, the .EXE is not signed) and that it was downloaded from the Internet.
> >
> > I also did a custom scan of the single download file using Microsoft Security Essentials.  The scan (which is programmed to dig into these files) identified 51916 individual items and no threats.
> >
> > All of this is tolerable and arguably appropriate for developer snapshots.  Users who use these builds need to rely on their own judgment about the trustworthiness of the origin and the content of those files.
> >
> > Note that it is the .exe that needs to be signed.  This should not be confused with a .msi file, although I assume those can be signed also.  Apache OpenOffice does not use .msi as the packaged binary that is downloaded.  (It appears that LibreOffice has changed that.)  It strikes me that using external digest values (md5 and sh1 digests) on the download requires a super-user skill set and should not be the only thing relied upon for project binary releases.
> >
> 
> Yes,MSI's can be installed and are required to be signed for some
> distribution paths.  Generally you want to sign what you distribute.
> Don't expect the I.E. or your anti-virus is going to deflate a 200 MB
> archive to see if some EXE inside is signed.  (And then what about the
> DLL's?)  We should be signing the whole enchilada.
> 
> -Rob
> 
> > -----Original Message-----
> > From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org]
> > Sent: Friday, March 02, 2012 11:19
> > To: ooo-dev@incubator.apache.org
> > Subject: RE: Symantec WS.Reputation.1 Errors: What we can do
> >
> > The web-based downloader in Internet Explorer 9 also warns about the .exe files (not the tar.gz or Zip ones).  The message is clearly a no-reputation-yet warning.
> >
> > This is an on-line check.  When the file is known to be regularly downloaded, the report will change automatically.
> >
> > I have seen no AV warnings about the downloaded files themselves, although there is a standard OS warning on use of such files when they were downloaded from the internet and/or are not signed.  (In Windows 8 Consumer Preview, it is necessary to click "details" to see that there is a "Run anyhow" selection.)
> >
> > I saw no AV warnings after the installation on any systems having Microsoft Malware detection and regularly-updated Windows Security Essentials.
> >
> >  - Dennis
> >
> > -----Original Message-----
> > From: Rob Weir [mailto:robweir@apache.org]
> > Sent: Friday, March 02, 2012 07:00
> > To: ooo-dev@incubator.apache.org
> > Subject: Symantec WS.Reputation.1 Errors: What we can do
> >
> > Several testers have mentioned this anti-virus error when installing
> > the AOO 3.4 dev snapshot build.   This is not a virus.
> > "WS.Reputation" errors come from Symantec Antivirus based on their
> > "reputation-based" threat assessments.  Essentially, 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.  It is
> > 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.  And we can';t start
> > 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.   Apache already
> > requires a detached signature.  But Symantec has no idea about these.
> > We need traditional Windows exe code signing.  This will help us with
> > Windows 8 as well.  So it is something we probably want to look into
> > at some point.
> >
> > My recommendation:
> >
> > Plan on doing 1.  Do 2. as soon as we have a release.  Look into 3. for AOO 4.0.
> >
> > Regards,
> >
> > -Rob
> >



Re: Symantec WS.Reputation.1 Errors: What we can do

Posted by Rob Weir <ro...@apache.org>.
On Fri, Mar 2, 2012 at 4:15 PM, Dennis E. Hamilton
<de...@acm.org> wrote:
> Out of curiosity I just did another download of the OOo-dev 3.4 Windows "MSI" r1293550 to see if the popularity contest had been won yet.
>
> Not yet.
>
>  The Internet Explorer 9 download warning is "OOo-Dev-OOO340m1_Win_x86_install_en-US.exe is not commonly downloaded and could harm your computer."  The file is already downloaded at that point, however.  The options are Delete, Actions, and View downloads (opening a separate tool that shows downloads and status).  The Actions option includes "Don't run this program (recommended)", "Delete", and "Run Anyway."
>
>  A "Run Anyway" or a later execution of the downloaded .exe will provoke an User Account Control message (on default configurations, even for administrator accounts) that warns that the file is from an unknown source (that is, the .EXE is not signed) and that it was downloaded from the Internet.
>
> I also did a custom scan of the single download file using Microsoft Security Essentials.  The scan (which is programmed to dig into these files) identified 51916 individual items and no threats.
>
> All of this is tolerable and arguably appropriate for developer snapshots.  Users who use these builds need to rely on their own judgment about the trustworthiness of the origin and the content of those files.
>
> Note that it is the .exe that needs to be signed.  This should not be confused with a .msi file, although I assume those can be signed also.  Apache OpenOffice does not use .msi as the packaged binary that is downloaded.  (It appears that LibreOffice has changed that.)  It strikes me that using external digest values (md5 and sh1 digests) on the download requires a super-user skill set and should not be the only thing relied upon for project binary releases.
>

Yes,MSI's can be installed and are required to be signed for some
distribution paths.  Generally you want to sign what you distribute.
Don't expect the I.E. or your anti-virus is going to deflate a 200 MB
archive to see if some EXE inside is signed.  (And then what about the
DLL's?)  We should be signing the whole enchilada.

-Rob

> -----Original Message-----
> From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org]
> Sent: Friday, March 02, 2012 11:19
> To: ooo-dev@incubator.apache.org
> Subject: RE: Symantec WS.Reputation.1 Errors: What we can do
>
> The web-based downloader in Internet Explorer 9 also warns about the .exe files (not the tar.gz or Zip ones).  The message is clearly a no-reputation-yet warning.
>
> This is an on-line check.  When the file is known to be regularly downloaded, the report will change automatically.
>
> I have seen no AV warnings about the downloaded files themselves, although there is a standard OS warning on use of such files when they were downloaded from the internet and/or are not signed.  (In Windows 8 Consumer Preview, it is necessary to click "details" to see that there is a "Run anyhow" selection.)
>
> I saw no AV warnings after the installation on any systems having Microsoft Malware detection and regularly-updated Windows Security Essentials.
>
>  - Dennis
>
> -----Original Message-----
> From: Rob Weir [mailto:robweir@apache.org]
> Sent: Friday, March 02, 2012 07:00
> To: ooo-dev@incubator.apache.org
> Subject: Symantec WS.Reputation.1 Errors: What we can do
>
> Several testers have mentioned this anti-virus error when installing
> the AOO 3.4 dev snapshot build.   This is not a virus.
> "WS.Reputation" errors come from Symantec Antivirus based on their
> "reputation-based" threat assessments.  Essentially, 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.  It is
> 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.  And we can';t start
> 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.   Apache already
> requires a detached signature.  But Symantec has no idea about these.
> We need traditional Windows exe code signing.  This will help us with
> Windows 8 as well.  So it is something we probably want to look into
> at some point.
>
> My recommendation:
>
> Plan on doing 1.  Do 2. as soon as we have a release.  Look into 3. for AOO 4.0.
>
> Regards,
>
> -Rob
>

RE: Symantec WS.Reputation.1 Errors: What we can do

Posted by "Dennis E. Hamilton" <de...@acm.org>.
Out of curiosity I just did another download of the OOo-dev 3.4 Windows "MSI" r1293550 to see if the popularity contest had been won yet.  

Not yet.

  The Internet Explorer 9 download warning is "OOo-Dev-OOO340m1_Win_x86_install_en-US.exe is not commonly downloaded and could harm your computer."  The file is already downloaded at that point, however.  The options are Delete, Actions, and View downloads (opening a separate tool that shows downloads and status).  The Actions option includes "Don't run this program (recommended)", "Delete", and "Run Anyway."  

  A "Run Anyway" or a later execution of the downloaded .exe will provoke an User Account Control message (on default configurations, even for administrator accounts) that warns that the file is from an unknown source (that is, the .EXE is not signed) and that it was downloaded from the Internet. 

I also did a custom scan of the single download file using Microsoft Security Essentials.  The scan (which is programmed to dig into these files) identified 51916 individual items and no threats.

All of this is tolerable and arguably appropriate for developer snapshots.  Users who use these builds need to rely on their own judgment about the trustworthiness of the origin and the content of those files.  

Note that it is the .exe that needs to be signed.  This should not be confused with a .msi file, although I assume those can be signed also.  Apache OpenOffice does not use .msi as the packaged binary that is downloaded.  (It appears that LibreOffice has changed that.)  It strikes me that using external digest values (md5 and sh1 digests) on the download requires a super-user skill set and should not be the only thing relied upon for project binary releases.

-----Original Message-----
From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org] 
Sent: Friday, March 02, 2012 11:19
To: ooo-dev@incubator.apache.org
Subject: RE: Symantec WS.Reputation.1 Errors: What we can do

The web-based downloader in Internet Explorer 9 also warns about the .exe files (not the tar.gz or Zip ones).  The message is clearly a no-reputation-yet warning.  

This is an on-line check.  When the file is known to be regularly downloaded, the report will change automatically.  

I have seen no AV warnings about the downloaded files themselves, although there is a standard OS warning on use of such files when they were downloaded from the internet and/or are not signed.  (In Windows 8 Consumer Preview, it is necessary to click "details" to see that there is a "Run anyhow" selection.)  

I saw no AV warnings after the installation on any systems having Microsoft Malware detection and regularly-updated Windows Security Essentials.

 - Dennis

-----Original Message-----
From: Rob Weir [mailto:robweir@apache.org] 
Sent: Friday, March 02, 2012 07:00
To: ooo-dev@incubator.apache.org
Subject: Symantec WS.Reputation.1 Errors: What we can do

Several testers have mentioned this anti-virus error when installing
the AOO 3.4 dev snapshot build.   This is not a virus.
"WS.Reputation" errors come from Symantec Antivirus based on their
"reputation-based" threat assessments.  Essentially, 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.  It is
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.  And we can';t start
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.   Apache already
requires a detached signature.  But Symantec has no idea about these.
We need traditional Windows exe code signing.  This will help us with
Windows 8 as well.  So it is something we probably want to look into
at some point.

My recommendation:

Plan on doing 1.  Do 2. as soon as we have a release.  Look into 3. for AOO 4.0.

Regards,

-Rob


RE: Symantec WS.Reputation.1 Errors: What we can do

Posted by "Dennis E. Hamilton" <de...@acm.org>.
The web-based downloader in Internet Explorer 9 also warns about the .exe files (not the tar.gz or Zip ones).  The message is clearly a no-reputation-yet warning.  

This is an on-line check.  When the file is known to be regularly downloaded, the report will change automatically.  

I have seen no AV warnings about the downloaded files themselves, although there is a standard OS warning on use of such files when they were downloaded from the internet and/or are not signed.  (In Windows 8 Consumer Preview, it is necessary to click "details" to see that there is a "Run anyhow" selection.)  

I saw no AV warnings after the installation on any systems having Microsoft Malware detection and regularly-updated Windows Security Essentials.

 - Dennis

-----Original Message-----
From: Rob Weir [mailto:robweir@apache.org] 
Sent: Friday, March 02, 2012 07:00
To: ooo-dev@incubator.apache.org
Subject: Symantec WS.Reputation.1 Errors: What we can do

Several testers have mentioned this anti-virus error when installing
the AOO 3.4 dev snapshot build.   This is not a virus.
"WS.Reputation" errors come from Symantec Antivirus based on their
"reputation-based" threat assessments.  Essentially, 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.  It is
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.  And we can';t start
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.   Apache already
requires a detached signature.  But Symantec has no idea about these.
We need traditional Windows exe code signing.  This will help us with
Windows 8 as well.  So it is something we probably want to look into
at some point.

My recommendation:

Plan on doing 1.  Do 2. as soon as we have a release.  Look into 3. for AOO 4.0.

Regards,

-Rob


Re: Symantec WS.Reputation.1 Errors: What we can do

Posted by Dave Fisher <da...@comcast.net>.
On Mar 2, 2012, at 9:52 AM, Rob Weir wrote:

> On Fri, Mar 2, 2012 at 12:25 PM, Dave Fisher <da...@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.   This is not a virus.
>>> "WS.Reputation" errors come from Symantec Antivirus based on their
>>> "reputation-based" threat assessments.  Essentially, 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.  It is
>>> 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.  And we can';t start
>>> 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.   Apache already
>>> requires a detached signature.  But Symantec has no idea about these.
>>> We need traditional Windows exe code signing.  This will help us with
>>> Windows 8 as well.  So it is something we probably want to look into
>>> 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  your discussion on the other thread about what is AOO, what is powered 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 foundation 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 have 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 these 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?

I'll need to confirm the status with Infrastructure, but I think that an ASF wide certificate was being considered. There was a lot of debate and it is hard to know without followup what happened. I'll ask now.

Regards,
Dave


> 
> -Rob
> 
>> Regards,
>> Dave
>> 
>>> 
>>> My recommendation:
>>> 
>>> Plan on doing 1.  Do 2. as soon as we have a release.  Look into 3. for AOO 4.0.
>>> 
>>> Regards,
>>> 
>>> -Rob
>> 


Re: Symantec WS.Reputation.1 Errors: What we can do

Posted by Rob Weir <ro...@apache.org>.
On Fri, Mar 2, 2012 at 12:25 PM, Dave Fisher <da...@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.   This is not a virus.
>> "WS.Reputation" errors come from Symantec Antivirus based on their
>> "reputation-based" threat assessments.  Essentially, 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.  It is
>> 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.  And we can';t start
>> 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.   Apache already
>> requires a detached signature.  But Symantec has no idea about these.
>> We need traditional Windows exe code signing.  This will help us with
>> Windows 8 as well.  So it is something we probably want to look into
>> 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  your discussion on the other thread about what is AOO, what is powered 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 foundation 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 have 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 these 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.  Do 2. as soon as we have a release.  Look into 3. for AOO 4.0.
>>
>> Regards,
>>
>> -Rob
>

Re: Symantec WS.Reputation.1 Errors: What we can do

Posted by Dave Fisher <da...@comcast.net>.
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.   This is not a virus.
> "WS.Reputation" errors come from Symantec Antivirus based on their
> "reputation-based" threat assessments.  Essentially, 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.  It is
> 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.  And we can';t start
> 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.   Apache already
> requires a detached signature.  But Symantec has no idea about these.
> We need traditional Windows exe code signing.  This will help us with
> Windows 8 as well.  So it is something we probably want to look into
> 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  your discussion on the other thread about what is AOO, what is powered by, and what is "White Label")

I believe that signing process is being worked on elsewhere in the foundation 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 have 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 these tests.

Regards,
Dave

> 
> My recommendation:
> 
> Plan on doing 1.  Do 2. as soon as we have a release.  Look into 3. for AOO 4.0.
> 
> Regards,
> 
> -Rob


Re: Symantec WS.Reputation.1 Errors: What we can do

Posted by Greg Roberts <lo...@yahoo.com>.
Rob,
 
I agree with this plan with some additional detail into action point 1. The user can't just "run anyways" as the virus software will quarantine and remove the software until you get the reputation promoted. The user must manually go into the error log and override then restore the threat manually. I think this is a little to much to ask of a normal user of applications designed to be used by grandma Jones in Kansas. They just don't have the technical aptitude to perform this kind of operation. But for the folks that are testing and developing this plan would work prior to release.
 
Greg


________________________________
From: Rob Weir <ro...@apache.org>
To: ooo-dev@incubator.apache.org 
Sent: Friday, March 2, 2012 7:00 AM
Subject: Symantec WS.Reputation.1 Errors: What we can do

Several testers have mentioned this anti-virus error when installing
the AOO 3.4 dev snapshot build.  This is not a virus.
"WS.Reputation" errors come from Symantec Antivirus based on their
"reputation-based" threat assessments.  Essentially, 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.  It is
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.  And we can';t start
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.  Apache already
requires a detached signature.  But Symantec has no idea about these.
We need traditional Windows exe code signing.  This will help us with
Windows 8 as well.  So it is something we probably want to look into
at some point.

My recommendation:

Plan on doing 1.  Do 2. as soon as we have a release.  Look into 3. for AOO 4.0.

Regards,

-Rob