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 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 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 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/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.

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.