Is it safe to download boost_1_67_0-msvc-14.1-64.exe?
From https://dl.bintray.com/boostorg/release/1.67.0/binaries/boost_1_67_0-msvc-14... I got windows defender warning on Trojan:Win32/Vigorf.A Total virus report the same on the same file. https://www.virustotal.com/#/file/402d07022fe9671e401efc4e90a1ff25e1bc9e1c23...
Just download the source and compile it yourself. Am 8. Juni 2018 23:33:56 MESZ schrieb Trung Tran via Boost-users <boost-users@lists.boost.org>:
From https://dl.bintray.com/boostorg/release/1.67.0/binaries/boost_1_67_0-msvc-14... I got windows defender warning on Trojan:Win32/Vigorf.A Total virus report the same on the same file. https://www.virustotal.com/#/file/402d07022fe9671e401efc4e90a1ff25e1bc9e1c23...
-- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
On 9 June 2018 at 00:33, Trung Tran via Boost-users < boost-users@lists.boost.org> wrote:
From https://dl.bintray.com/boostorg/release/1.67.0/ binaries/boost_1_67_0-msvc-14.1-64.exe I got windows defender warning on Trojan:Win32/Vigorf.A Total virus report the same on the same file. https://www.virustotal.com/#/file/402d07022fe9671e401efc4e90a1ff 25e1bc9e1c23b3d8b1c65e4a2e6799abfc/detection
This was posted on the list before (not so long ago). Defender probably simply just doesn't like that it's an unsigned (and unknown) executable (Vigorf.A is a very generic threat). Malwarebytes and DrWeb say it's clean (the ones I would trust). It is a shame that Kaspersky is no longer listed on VT for obviously political reasons. degski -- *"If something cannot go on forever, it will stop" - Herbert Stein*
On Fri, Jun 8, 2018 at 4:33 PM, Trung Tran via Boost-users < boost-users@lists.boost.org> wrote:
From https://dl.bintray.com/boostorg/release/1.67.0/ binaries/boost_1_67_0-msvc-14.1-64.exe I got windows defender warning on Trojan:Win32/Vigorf.A Total virus report the same on the same file. https://www.virustotal.com/#/file/402d07022fe9671e401efc4e90a1ff 25e1bc9e1c23b3d8b1c65e4a2e6799abfc/detection
If the hash that you download matches the one in the SHA256SUMS.asc file and the file signature with GPG is good, then you are fine. Tom
I just ran into this myself. Is there a specific reason that only the all-versions boost binary is distributed as an .7z and not the individual packages? If it's for beginners ease-of-use, then I'd expect it the other way around - because somebody would know the internal version number of visual studio but not how to decompress a 7z? Nick On Sat, Jun 9, 2018 at 11:37 AM, Tom Kent via Boost-users <boost-users@lists.boost.org> wrote:
On Fri, Jun 8, 2018 at 4:33 PM, Trung Tran via Boost-users <boost-users@lists.boost.org> wrote:
From https://dl.bintray.com/boostorg/release/1.67.0/binaries/boost_1_67_0-msvc-14... I got windows defender warning on Trojan:Win32/Vigorf.A Total virus report the same on the same file.
https://www.virustotal.com/#/file/402d07022fe9671e401efc4e90a1ff25e1bc9e1c23...
If the hash that you download matches the one in the SHA256SUMS.asc file and the file signature with GPG is good, then you are fine.
Tom
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users
On Wed, Jun 20, 2018 at 2:25 PM, Nicholas Devenish via Boost-users < boost-users@lists.boost.org> wrote:
I just ran into this myself. Is there a specific reason that only the all-versions boost binary is distributed as an .7z and not the individual packages?
If it's for beginners ease-of-use, then I'd expect it the other way around - because somebody would know the internal version number of visual studio but not how to decompress a 7z?
Nick
The reason for the installers is mostly historical...it seemed easier for users to run an installer than to unzip stuff. Not sure if this still holds true, I'd be curious what the user community thinks about this. The all-versions .7z was added later, because of its size it was somewhat impractical to get into an installer, so it was distributed as a compressed archive. Tom
On 21 June 2018 at 04:42, Tom Kent via Boost-users < boost-users@lists.boost.org> wrote:
The reason for the installers is mostly historical...it seemed easier for users to run an installer than to unzip stuff. Not sure if this still holds true, I'd be curious what the user community thinks about this.
My 2 cents is that a slightly savage user will be reluctant to run an executable (if they are already suspicious) and will take the .7z file. The less experienced user probably runs the executable. There ought to be a way where the person(s) putting this online can give assurances that no bad will come of running it, this is easier said than done.
The all-versions .7z was added later, because of its size it was somewhat impractical to get into an installer, so it was distributed as a compressed archive.
I don't know what the "installer" entails, but if it's just an auto run compressed file, then one can, with the command-line utility (7za.exe <https://www.7-zip.org/a/7z1805-extra.7z>), make a sfx archive using the command-line switch -sfx (in addition to any commands and other switches). degski -- *"If something cannot go on forever, it will stop" - Herbert Stein*
On Thu, Jun 21, 2018 at 11:03 PM, degski via Boost-users < boost-users@lists.boost.org> wrote:
On 21 June 2018 at 04:42, Tom Kent via Boost-users < boost-users@lists.boost.org> wrote:
The reason for the installers is mostly historical...it seemed easier for users to run an installer than to unzip stuff. Not sure if this still holds true, I'd be curious what the user community thinks about this.
My 2 cents is that a slightly savage user will be reluctant to run an executable (if they are already suspicious) and will take the .7z file. The less experienced user probably runs the executable. There ought to be a way where the person(s) putting this online can give assurances that no bad will come of running it, this is easier said than done.
The all-versions .7z was added later, because of its size it was somewhat impractical to get into an installer, so it was distributed as a compressed archive.
I don't know what the "installer" entails, but if it's just an auto run compressed file, then one can, with the command-line utility (7za.exe <https://www.7-zip.org/a/7z1805-extra.7z>), make a sfx archive using the command-line switch -sfx (in addition to any commands and other switches).
The installer is slightly more complex than a self-extracting archive. If I recall some years ago we were doing a sfx archive, but moved to an inno setup based installer to make the process a little more polished. Tom
On 23 June 2018 at 04:26, Tom Kent via Boost-users < boost-users@lists.boost.org> wrote:
The installer is slightly more complex than a self-extracting archive. If I recall some years ago we were doing a sfx archive, but moved to an inno setup based installer to make the process a little more polished.
I suspected as much. degski -- *"If something cannot go on forever, it will stop" - Herbert Stein*
On 08/06/2018 22:33, Trung Tran via Boost-users wrote:
From https://dl.bintray.com/boostorg/release/1.67.0/binaries/boost_1_67_0-msvc-14... I got windows defender warning on Trojan:Win32/Vigorf.A Total virus report the same on the same file. https://www.virustotal.com/#/file/402d07022fe9671e401efc4e90a1ff25e1bc9e1c23...
The link is provided on Boost's official download page <https://www.boost.org/users/download/> so you have to take it on trust. However, most people compile their own binaries selectively because Microsoft has got its own libraries and Boost libraries are added extra. Choose the ones you want to use and compile it yourself by putting it in your project. That's how I use these libraries.
On 22 June 2018 at 22:45, Good Guy via Boost-users < boost-users@lists.boost.org> wrote:
On 08/06/2018 22:33, Trung Tran via Boost-users wrote:
From https://dl.bintray.com/boostorg/release/1.67.0/binaries/ boost_1_67_0-msvc-14.1-64.exe I got windows defender warning on Trojan:Win32/Vigorf.A Total virus report the same on the same file. https://www.virustotal.com/#/file/402d07022fe9671e401efc4e90 a1ff25e1bc9e1c23b3d8b1c65e4a2e6799abfc/detection
The link is provided on Boost's official download page < https://www.boost.org/users/download/> so you have to take it on trust.
This is highly naive. I only need to refer to ccleaner <https://www.bleepingcomputer.com/how-to/security/ccleaner-malware-incident-what-you-need-to-know-and-how-to-remove/> to prove this. degski -- *"If something cannot go on forever, it will stop" - Herbert Stein*
On Fri, Jun 22, 2018 at 2:45 PM, Good Guy via Boost-users < boost-users@lists.boost.org> wrote:
On 08/06/2018 22:33, Trung Tran via Boost-users wrote:
From https://dl.bintray.com/boostorg/release/1.67.0/binaries/ boost_1_67_0-msvc-14.1-64.exe I got windows defender warning on Trojan:Win32/Vigorf.A Total virus report the same on the same file. https://www.virustotal.com/#/file/402d07022fe9671e401efc4e90 a1ff25e1bc9e1c23b3d8b1c65e4a2e6799abfc/detection
The link is provided on Boost's official download page < https://www.boost.org/users/download/> so you have to take it on trust.
Please don't take it on trust. If you get a warning for the binaries, check the hashes, then check the signature on the hashes! Boost (esp the binaries) would be an ideal target for a malicious actor to hack and make changes to that then get built into everybody's code. However, this type of attack definitely wouldn't trigger virus scanners, so I'm not worried about these reports (and since others previously in the thread have verified the checksums match). Tom
On 26 June 2018 at 01:05, Tom Kent via Boost-users < boost-users@lists.boost.org> wrote:
Please don't take it on trust. If you get a warning for the binaries, check the hashes, then check the signature on the hashes!
I don't think that hacker would be smart enough to change the boost code, hack into the web-site and replace the binary, while at the same time being so stupid as not to change the hashes as well. The hashes serve to verify that your download was correct, it's not a security. degski -- *"If something cannot go on forever, it will stop" - Herbert Stein*
On Tue, Jun 26, 2018 at 12:00 AM, degski via Boost-users < boost-users@lists.boost.org> wrote:
On 26 June 2018 at 01:05, Tom Kent via Boost-users < boost-users@lists.boost.org> wrote:
Please don't take it on trust. If you get a warning for the binaries, check the hashes, then check the signature on the hashes!
I don't think that hacker would be smart enough to change the boost code, hack into the web-site and replace the binary, while at the same time being so stupid as not to change the hashes as well. The hashes serve to verify that your download was correct, it's not a security.
The hashes (for the binaries) are signed with a PGP key as they are packaged up for each release. I agree it would be easy to change the hash in the SHA256SUMS. However, it would be impossible to create a copy of the SHA256SUMS.asc file that can be verified with GPG/PGP without hacking the private key that signs that file. This is a *much* higher bar, and does provide security. Tom
On 27 June 2018 at 00:20, Tom Kent via Boost-users < boost-users@lists.boost.org> wrote:
The hashes (for the binaries) are signed with a PGP key as they are packaged up for each release. I agree it would be easy to change the hash in the SHA256SUMS. However, it would be impossible to create a copy of the SHA256SUMS.asc file that can be verified with GPG/PGP without hacking the private key that signs that file. This is a *much* higher bar, and does provide security.
That is indeed much better [than I thought], but those people who download the .exe will not check that as this requires quite a bit of knowledge. Just a question of a lay-man in this matter. Can't the server make this check before serving the file, or does a setup like that actually weaken the security? degski
On 27/06/2018 16:48, degski wrote:
That is indeed much better [than I thought], but those people who download the .exe will not check that as this requires quite a bit of knowledge. Just a question of a lay-man in this matter. Can't the server make this check before serving the file, or does a setup like that actually weaken the security?
If the server is hacked to the point that it is serving a malicious file, how could you trust it to perform signature validation on an associated hashfile? The Right Way™ to handle this case for the layperson is to authenticode-sign the exe file, such that when you try to run it, Windows will verify the signature and tell you who it was signed by. Even this still requires that person to (a) know that it was supposed to be signed and (b) recognise the name of the person or organisation who signed it and (c) trust that no malicious party has been able to obtain a certificate with a sufficiently-plausible-sounding name from a certificate vendor trusted by their OS. I can't actually check whether the current files are signed or not (or who by) since apparently my Chrome hates the files and they forever sit in 100%-downloaded-but-trying-to-virus-scan limbo.
Mere moments ago, quoth I:
The Right Way™ to handle this case for the layperson is to authenticode-sign the exe file, such that when you try to run it, Windows will verify the signature and tell you who it was signed by.
Also note that Windows normally only does this when apps request admin permission. Which is common but not mandatory for installers; I'm not sure which way these ones happen to be set up (since I couldn't download them). You can verify certificates on non-admin exes as well but you have to think to do this yourself; it won't happen automatically on launch.
A little while earlier, quoth I:
Mere moments ago, quoth I:
The Right Way™ to handle this case for the layperson is to authenticode-sign the exe file, such that when you try to run it, Windows will verify the signature and tell you who it was signed by.
Also note that Windows normally only does this when apps request admin permission. Which is common but not mandatory for installers; I'm not sure which way these ones happen to be set up (since I couldn't download them).
You can verify certificates on non-admin exes as well but you have to think to do this yourself; it won't happen automatically on launch.
Chrome finally decided to finish scanning, so for the record, they appear to be non-signed and non-admin (so even if they were signed they wouldn't be automatically verified). Signing them anyway probably still wouldn't be a bad idea, although that depends whether whoever prepares these has access to a valid Authenticode key with a name that wouldn't pose additional confusion.
participants (3)
-
degski -
Gavin Lambert -
Georg Gast -
Good Guy -
Nicholas Devenish -
Tom Kent -
Trung Tran