But honestly, I don't think we will ever see a 7-Zip with /GS or CFG. Not only would this cost about 1% in binary size, it would cost an additional 1% in runtime performance loss. Additionally, it would require compiling 7-Zip with a modern compiler like VS2017. You're just asking for too much.
I know it's not you saying this, but it's very strange given almost all files 7-zip will ever see are untrusted files downloaded from the internet
I'd rather have it be 1% slower than be compromised!
I still wonder if there's an ethical dilemma that lies underneath this - is it fair to prioritize needs of users who use your tool in a different way (for backup jobs) over users that use your tool only occasionally, perhaps not even out of their own initiative (they were sent 7z file from a ostensibly trusted source).
Ahhh, but does say VS2017 produce a smaller executable file, or a faster executable?
I am pleased Igor cares about individual 1% improvements - they stack up to significant savings. However I agree for our work usage security is more important.
If I recall correctly, Igor once said that he tested the new VS compiler and it produced neither smaller nor faster executables. I believe there was almost no difference.
Dunno, just as with FB/CA, users have agreed to what befell them. Relevant extract from LGPL 2.1: "THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE LIBRARY IS WITH YOU."
EDIT: /s, ...
I agree with others here on the security vs. performance and security vs. binary size trade-offs. As a thought experiment I wondered at what point it would become a hard decision if I were in his shoes. I think a 10% performance hit would make it a harder decision for me, but at that point I would probably still err on the side of caution and prioritize security.
Of course it's possible this is exactly one of the reasons Igor owns something like 7-Zip, and I don't :-)