On 23 Jun 2026 14:12, Rainer Deyke via Boost wrote:
On 6/23/26 10:07, Andrey Semashev via Boost wrote:
I believe, it works in the same definition of "works" as for the other file types you mention. That is, the user B can download and use the archive, but he has no way of knowing whether the file he downloaded is the same as the one uploaded by user A. This includes possible tampering or unintentional corruption in transit. The user B also doesn't know whether the file he downloaded is safe to use. E.g. is the JavaScript safe to run? Does the image file have some embedded data that exploits a vulnerability in the image parsing library? etc.
Tampering is not an interesting threat. If Alice wants to download a file from Bob and instead receives a tampered file from Charlie, then that is only a problem if Alice trusts Bob more than Charlie. On the open internet, Alice shouldn't trust Bob at all, so a tampered file from Charlie is not more dangerous than the original file from Bob.
If the browser allows hostile Javascript to be dangerous to the user, then that is a serious security issue with the browser. If an image parsing library has an exploitable vulnerability, then that is a serious security issue with both the library and the browser that uses it. These are bugs, critical bugs, that must be fixed immediately.
There is no guarantee that an image downloaded from the internet is the particular image you wanted. However, there are only two possible valid responses a browser can have to a hostile image file. If it's a valid image file that can be displayed, then the browser must display it (even though it may not be the image the user wanted). If it's invalid or otherwise can't be displayed, the browser must cleanly handle the error without corrupting the process. The situation is analogous to the strong exception guarantee: the operation can succeed or fail, but either way it can't leave the system in an unspecified, much less a compromised, state.
Meanwhile, the attitude of Boost.Serialization is that passing invalid data in results in undefined behavior, which means that it leaves the system in a compromised state by default, and there's not even a way to validate the data beforehand. The only choice is to trust the data, which means trusting the data source.
Do you see the difference?
By the same logic as the browser, if the archive is valid, according to the archive format specification, Boost.Serialization has to parse it and present the result to the user. Otherwise, it must fail with an error. I'm not a Boost.Serialization user, but I'm assuming that this is currently the case (otherwise, this would be a bug in the library). In this sense, the library already does validate the data. Now, the parsed archive may not be valid from the user's application standpoint (i.e. if the parsed data does not describe a valid state of the application), but I don't think Boost.Serialization is in a position to validate it at that level. Or maybe I'm missing something about Boost.Serialization.