Christian Mazakas wrote:
On Tue, Jun 23, 2026 at 9:14 AM Robert Ramey via Boost < boost@lists.boost.org> wrote:
On 6/23/26 2:23 AM, Joaquin M López Muñoz via Boost wrote:
100% agree. The only security-related requirement we should put on Boost.Serialization, and we should put it, is that no UB be generated on archive loading time.
Joaquín M López Muñoz
I believe that there is no possible undefined for loading archives which have been saved in the same format as that loaded. The only scenario I could think of where this could occur would be:
a) There is an error in the usage of the library in that the user code implementing the "saving" of an archive is not consistent with the code implementing the "loading" of tthat archive.
b) The archive being loaded has been altered from the origainally saved one. (I called this tampering).
Yes, this is exactly the aforementioned precondition that shouldn't exist in a library such as Serialization.
We should have no preconditions. The library should exhibit no UB for all possible inputs.
I agree with Christian; deserialization should never be undefined behavior, regardless of input. How the "wrong" input has been produced, or has been brought into being, is immaterial. Bit flips happen. Transmission errors happen. It's not always malicious tampering, but it wouldn't matter even if it were.