You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by "Dennis E. Hamilton" <de...@acm.org> on 2012/03/04 20:52:01 UTC
Signing DLLs EXEs and Copyright Notices (was RE: Symantec WS.Reputation.1 Errors: What we can do)
Rob, I want to make sure that signature verification and AV scanning activities are not being confused together.
My AV scanned the OOo-Dev Windows x86 en-US .exe of the r1293550 developer preview checked the .exe and its interior components (all 51916 of them, if the count is to be believed) for the things that AVs check for. It did not remark on digital signatures at all and it found nothing objectionable.
An attempt to execute the preview binary provokes a Windows warning about the absence of a signature on the .exe (and, if it were distributed as a bare MSI, it would check that for a signature).
The comment about signing parts reminds me of something though. It is also possible and desirable to digitally sign DLLs and the *installed* (not installer) EXE files. It is not a requirement for installing OOo-dev 3.4: there is no objection from the Microsoft installer and none of the EXEs and DLLs are signed. This is not unlike signing each of the jar files in a combined, installable application.
- Dennis
PS: The OOo-dev 3.4 r1293550 installed DLLs and EXEs all carry an incorrect Copyright notice though. The .exe files have "Copyright © 2009-2010 by Apache Softw..." (too long for the Properties dialog) and Language German (Germany). The DLLs have "Copyright © 2010 by Apache Software F..." and Language German (Germany). This is a next-level of detail down from my QA of the deployment experience, <https://cwiki.apache.org/confluence/display/OOOUSERS/Win-en-x86-Setup>. I will concentrate on updating and expanding that material so someone can cherry-pick whatever seems worth fixing.
-----Original Message-----
From: Rob Weir [mailto:robweir@apache.org]
Sent: Friday, March 02, 2012 13:40
To: ooo-dev@incubator.apache.org; dennis.hamilton@acm.org
Subject: Re: Symantec WS.Reputation.1 Errors: What we can do
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: Signing DLLs EXEs and Copyright Notices (was RE: Symantec
WS.Reputation.1 Errors: What we can do)
Posted by Rob Weir <ro...@apache.org>.
On Sun, Mar 4, 2012 at 5:50 PM, Dennis E. Hamilton
<de...@acm.org> wrote:
> Gee Rob, my e-mail client shows a different, appropriate subject to the present thread.
>
> The branch had to do with understanding the difference between "reputational" warnings and actual malware detections (and false positives), and the variety of ways these things occur. It makes need for clarification of the specific situation rather important. The signed EXE case comes up in regard to warnings on attempt to execute using the Windows OS. I suspect that the non-Windows developers might want to appreciate that.
>
OK. If it clarifies things for you, then great. I, probably
erroneously, assumed the distinction would be obvious to everyone.
It is pretty standard these days for install instructions to tell the
user to ignore these Windows warnings. We can add it to the install
instructions. If there are special warnings that show up in less used
browsers like I.E. 9, we can add mention of those as well. But I'm
more interested in AV or OS behavior that is more severe, that would
-- perhaps in a managed desktop environment -- prevent someone from
installing AOO at all.
-Rob
> - Dennis
>
> -----Original Message-----
> From: Rob Weir [mailto:robweir@apache.org]
> Sent: Sunday, March 04, 2012 14:19
> To: ooo-dev@incubator.apache.org
> Subject: Re: Signing DLLs EXEs and Copyright Notices (was RE: Symantec WS.Reputation.1 Errors: What we can do)
>
> On Sun, Mar 4, 2012 at 4:18 PM, Dennis E. Hamilton
> <de...@acm.org> wrote:
>> Just to be clear, further, the reputation warning on my Windows configuration is neither from the Windows Installer nor the AV that I have installed. It is the file downloader that is part of Internet Explorer 9. Later, there is a Windows OS warning on attempted execution of the download. That is based on detection that the file to be executed is from an unknown source (not signed) and has been downloaded from the Internet. Neither of these are AV or installer behaviors, although the IE9 downloader does provide a "security scan" of downloads. I've never seen anything from it other than a reputation warning, though.
>>
>
> That's fine, Dennis. No one ever said your AV was an issue. The only
> thing I've been talking about in the Symantec errors that some testers
> were reporting. That problem does exist, for the reasons I've stated
> and with the solutions I've already given. I have no idea why you've
> hijacked the thread to give elaborate details about how you are *not*
> having a similar problem with an entirely different AV product. It is
> irrelevant. Let's all save time and list traffic by only reporting
> issues that exist, not ones that don't exist.
>
> -Rob
>
RE: Signing DLLs EXEs and Copyright Notices (was RE: Symantec WS.Reputation.1 Errors: What we can do)
Posted by "Dennis E. Hamilton" <de...@acm.org>.
Gee Rob, my e-mail client shows a different, appropriate subject to the present thread.
The branch had to do with understanding the difference between "reputational" warnings and actual malware detections (and false positives), and the variety of ways these things occur. It makes need for clarification of the specific situation rather important. The signed EXE case comes up in regard to warnings on attempt to execute using the Windows OS. I suspect that the non-Windows developers might want to appreciate that.
- Dennis
-----Original Message-----
From: Rob Weir [mailto:robweir@apache.org]
Sent: Sunday, March 04, 2012 14:19
To: ooo-dev@incubator.apache.org
Subject: Re: Signing DLLs EXEs and Copyright Notices (was RE: Symantec WS.Reputation.1 Errors: What we can do)
On Sun, Mar 4, 2012 at 4:18 PM, Dennis E. Hamilton
<de...@acm.org> wrote:
> Just to be clear, further, the reputation warning on my Windows configuration is neither from the Windows Installer nor the AV that I have installed. It is the file downloader that is part of Internet Explorer 9. Later, there is a Windows OS warning on attempted execution of the download. That is based on detection that the file to be executed is from an unknown source (not signed) and has been downloaded from the Internet. Neither of these are AV or installer behaviors, although the IE9 downloader does provide a "security scan" of downloads. I've never seen anything from it other than a reputation warning, though.
>
That's fine, Dennis. No one ever said your AV was an issue. The only
thing I've been talking about in the Symantec errors that some testers
were reporting. That problem does exist, for the reasons I've stated
and with the solutions I've already given. I have no idea why you've
hijacked the thread to give elaborate details about how you are *not*
having a similar problem with an entirely different AV product. It is
irrelevant. Let's all save time and list traffic by only reporting
issues that exist, not ones that don't exist.
-Rob
Re: Signing DLLs EXEs and Copyright Notices (was RE: Symantec
WS.Reputation.1 Errors: What we can do)
Posted by Rob Weir <ro...@apache.org>.
On Sun, Mar 4, 2012 at 4:18 PM, Dennis E. Hamilton
<de...@acm.org> wrote:
> Just to be clear, further, the reputation warning on my Windows configuration is neither from the Windows Installer nor the AV that I have installed. It is the file downloader that is part of Internet Explorer 9. Later, there is a Windows OS warning on attempted execution of the download. That is based on detection that the file to be executed is from an unknown source (not signed) and has been downloaded from the Internet. Neither of these are AV or installer behaviors, although the IE9 downloader does provide a "security scan" of downloads. I've never seen anything from it other than a reputation warning, though.
>
That's fine, Dennis. No one ever said your AV was an issue. The only
thing I've been talking about in the Symantec errors that some testers
were reporting. That problem does exist, for the reasons I've stated
and with the solutions I've already given. I have no idea why you've
hijacked the thread to give elaborate details about how you are *not*
having a similar problem with an entirely different AV product. It is
irrelevant. Let's all save time and list traffic by only reporting
issues that exist, not ones that don't exist.
-Rob
RE: Signing DLLs EXEs and Copyright Notices (was RE: Symantec WS.Reputation.1 Errors: What we can do)
Posted by "Dennis E. Hamilton" <de...@acm.org>.
Just to be clear, further, the reputation warning on my Windows configuration is neither from the Windows Installer nor the AV that I have installed. It is the file downloader that is part of Internet Explorer 9. Later, there is a Windows OS warning on attempted execution of the download. That is based on detection that the file to be executed is from an unknown source (not signed) and has been downloaded from the Internet. Neither of these are AV or installer behaviors, although the IE9 downloader does provide a "security scan" of downloads. I've never seen anything from it other than a reputation warning, though.
I completely agree that the full executable package should be digitally signed. A second-order signature would be on those .exe and .dll files that are installed. This is for provenance, not run-time checking (usually). Also, the ability to substitute a file in the folder of installed code is invariant. With signatures, there is an ability to at least check on these files. [That they need corrected properties, even unsigned, is a separate problem.]
Pondering this some more has me wonder about another problem: DLL side-loading interference. That's when a DLL with the same name is already dynamically loaded by another application, so it is used in place of the correct one with the same name. This may be a problem in running side-by-side executions of different releases. (The fact that all OOo-lineage distributions continue to use the same StarOffice filenames for their executables is a nuisance, but DLL collisions can cause more-serious problems.)
I am not clear how the DLL side-loading confusion is mitigated. I fear that it has something to do with SxS DLL installation and I may run away screaming. One can limit a specific DLL search to the directory from which the EXE is loaded, as I recall. It may be important to do that. For my homework (not very soon) I see that I need to find out what the guidance for having an application be Windows Version-mumble Ready requires.
- Dennis
-----Original Message-----
From: Rob Weir [mailto:robweir@apache.org]
Sent: Sunday, March 04, 2012 12:39
To: ooo-dev@incubator.apache.org
Subject: Re: Signing DLLs EXEs and Copyright Notices (was RE: Symantec WS.Reputation.1 Errors: What we can do)
On Sun, Mar 4, 2012 at 2:52 PM, Dennis E. Hamilton
<de...@acm.org> wrote:
> Rob, I want to make sure that signature verification and AV scanning activities are not being confused together.
>
I'm not confused.
> My AV scanned the OOo-Dev Windows x86 en-US .exe of the r1293550 developer preview checked the .exe and its interior components (all 51916 of them, if the count is to be believed) for the things that AVs check for. It did not remark on digital signatures at all and it found nothing objectionable.
>
That is your anti-virus. But not all anti-virus scanners work the
same way. Some of them have moved beyond looking for signatures in
files and looking for suspicious runtime activities (both techniques
around for over a decade) to using "wisdom of crowds" techniques to
estimate the reputation of an executable, based on how prevalent it
among other users of that vendor's anti virus software. They look at
other factors as well, including presence or absence of a digital
signature.
> An attempt to execute the preview binary provokes a Windows warning about the absence of a signature on the .exe (and, if it were distributed as a bare MSI, it would check that for a signature).
>
Right. And my guess is the MS scanner will complain no matter how
popular the program is or how long it has been around. It is doing a
much simpler test: signature, yes or no.
> The comment about signing parts reminds me of something though. It is also possible and desirable to digitally sign DLLs and the *installed* (not installer) EXE files. It is not a requirement for installing OOo-dev 3.4: there is no objection from the Microsoft installer and none of the EXEs and DLLs are signed. This is not unlike signing each of the jar files in a combined, installable application.
>
Better to put the signature on the outside. Otherwise you could take
old, unsafe signed DLL's from an earlier build and replace them into a
new build. Remember, the signature does not mean safety. It just
means known authorship. But it is possible to make an unsafe program
by mixing and matching known signed components.
In any case, my original observation still holds, that adding a
signature on our top-level installer will help with these AV warnings,
by boosting the "reputation" of our releases.
-Rob
> - Dennis
>
> PS: The OOo-dev 3.4 r1293550 installed DLLs and EXEs all carry an incorrect Copyright notice though. The .exe files have "Copyright © 2009-2010 by Apache Softw..." (too long for the Properties dialog) and Language German (Germany). The DLLs have "Copyright © 2010 by Apache Software F..." and Language German (Germany). This is a next-level of detail down from my QA of the deployment experience, <https://cwiki.apache.org/confluence/display/OOOUSERS/Win-en-x86-Setup>. I will concentrate on updating and expanding that material so someone can cherry-pick whatever seems worth fixing.
>
> -----Original Message-----
> From: Rob Weir [mailto:robweir@apache.org]
> Sent: Friday, March 02, 2012 13:40
> To: ooo-dev@incubator.apache.org; dennis.hamilton@acm.org
> Subject: Re: Symantec WS.Reputation.1 Errors: What we can do
>
> 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: Signing DLLs EXEs and Copyright Notices (was RE: Symantec
WS.Reputation.1 Errors: What we can do)
Posted by Rob Weir <ro...@apache.org>.
On Sun, Mar 4, 2012 at 2:52 PM, Dennis E. Hamilton
<de...@acm.org> wrote:
> Rob, I want to make sure that signature verification and AV scanning activities are not being confused together.
>
I'm not confused.
> My AV scanned the OOo-Dev Windows x86 en-US .exe of the r1293550 developer preview checked the .exe and its interior components (all 51916 of them, if the count is to be believed) for the things that AVs check for. It did not remark on digital signatures at all and it found nothing objectionable.
>
That is your anti-virus. But not all anti-virus scanners work the
same way. Some of them have moved beyond looking for signatures in
files and looking for suspicious runtime activities (both techniques
around for over a decade) to using "wisdom of crowds" techniques to
estimate the reputation of an executable, based on how prevalent it
among other users of that vendor's anti virus software. They look at
other factors as well, including presence or absence of a digital
signature.
> An attempt to execute the preview binary provokes a Windows warning about the absence of a signature on the .exe (and, if it were distributed as a bare MSI, it would check that for a signature).
>
Right. And my guess is the MS scanner will complain no matter how
popular the program is or how long it has been around. It is doing a
much simpler test: signature, yes or no.
> The comment about signing parts reminds me of something though. It is also possible and desirable to digitally sign DLLs and the *installed* (not installer) EXE files. It is not a requirement for installing OOo-dev 3.4: there is no objection from the Microsoft installer and none of the EXEs and DLLs are signed. This is not unlike signing each of the jar files in a combined, installable application.
>
Better to put the signature on the outside. Otherwise you could take
old, unsafe signed DLL's from an earlier build and replace them into a
new build. Remember, the signature does not mean safety. It just
means known authorship. But it is possible to make an unsafe program
by mixing and matching known signed components.
In any case, my original observation still holds, that adding a
signature on our top-level installer will help with these AV warnings,
by boosting the "reputation" of our releases.
-Rob
> - Dennis
>
> PS: The OOo-dev 3.4 r1293550 installed DLLs and EXEs all carry an incorrect Copyright notice though. The .exe files have "Copyright © 2009-2010 by Apache Softw..." (too long for the Properties dialog) and Language German (Germany). The DLLs have "Copyright © 2010 by Apache Software F..." and Language German (Germany). This is a next-level of detail down from my QA of the deployment experience, <https://cwiki.apache.org/confluence/display/OOOUSERS/Win-en-x86-Setup>. I will concentrate on updating and expanding that material so someone can cherry-pick whatever seems worth fixing.
>
> -----Original Message-----
> From: Rob Weir [mailto:robweir@apache.org]
> Sent: Friday, March 02, 2012 13:40
> To: ooo-dev@incubator.apache.org; dennis.hamilton@acm.org
> Subject: Re: Symantec WS.Reputation.1 Errors: What we can do
>
> 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
>>
>