DEP was previously disabled because Igor used to compile 7-Zip with VC6, which doesn't support the /NXCOMPAT flag. I convinced him back in January to enable it for 7-Zip 18.01. Note, however, that 64-bit versions of Windows enforce DEP even if the /NXCOMPAT flag is missing. Since Windows 10, the 32-bit version does this as well.
ASLR was primarily disabled because Igor wanted to strip the relocation from the binaries in order to save about 0.5-1% in file size. I have discussed this with him, and convinced him to enabled full ASLR for 7-Zip 18.05.
So now we have 7-Zip 18.05 with full ASLR and DEP. Stack canaries (/GS) are still disabled though.
If you can convince him to use Control Flow Guard, Stack Canaries, and HE-ALSR then you should be nominated for for whatever the security community has as an equivalent to a Nobel prize.
If you can convince him to get rid of his custom garbage Stdlib replacements and use ISO C++ then you're a hero to maintainability (and would probably improve the performance because the stdlib has move support).
HE-ASLR I am discussing with him right now, and I think we will get this.
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.
Like blibble says, this is an absurd tradeoff given that 7zip's primary use case is unarchiving files downloaded from the public internet. Between that, the willful ignorance and dismissiveness of security measures displayed https://sourceforge.net/p/sevenzip/feature-requests/1270/, and the apparent need for you to keep pressuring him to enable each countermeasure one-by-one, I question the prudence of using 7zip at all. He is clearly a great developer, and I have no reason to suspect ulterior motives, but his actions don't engender trust.
I know this probably isn't the answer you're looking for, but it might be worthwhile to maintain a parallel fork to enable these options for yourself/others. That way, folks that feel the same way you do can have their cake and eat it too. I realize that it's not an ideal solution though.
Why am I getting downvoted? I sincerely wonder what is so objectionable in my comment. Most uses of 7-zip are one-off events that last around a minute long. Most users aren't decompressing terabyte-range files. It makes no fracking difference to users if they have to wait 5 minutes or 1 minute. But it makes a difference if they receive 7z archive and get their bank account cleaned because the author prematurely optimized his program on a 20 year old compiler. If there was ever a reasonable situation where security flags could be disable then client-side decompression utilities aren't one. Anyone who needs that 5% performance improvement can compile the library themselves. This is what is wrong with this industry.
Consider that it was misplaced to suggest a 500% performance drop. It's used to extract large archives, backups, videos, documents. Folks don't want it to take half an hour instead of a few minutes.
Thanks for replying, this explains things. I guess I extrapolated from my needs too much, I didn't consider users who do daily 10+ GB compressed backups.
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).
> Additionally, it would require compiling 7-Zip with a modern compiler like VS2017
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.
> does say VS2017 produce a smaller executable file, or a faster executable?
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.
Given what I've seen of his code, I'm not surprised. When I mentioned the stdlib I wasn't joking. His code is unable to use modern compiler optimizations such as move, RVO, and constexpr because he's using idioms that prohibit it. It would be nice if he would at least release a solution that others can use to build with VS2017.
Why is that asking too much? I realize paying for software is not something everyone wants, but doesnt the free versions of VS work for compiling 7-zip?
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."
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 :-)
Developer cares about efficiency. It seems strange in today's world of Electron apps and text editors that take up a GB of ram and have hundreds of ms of latency, but that's clearly where his priorities lie and I, for one, can respect that.
If people are so up in arms about the security problems of 7-Zip, they're free to fork it.
ASLR was primarily disabled because Igor wanted to strip the relocation from the binaries in order to save about 0.5-1% in file size. I have discussed this with him, and convinced him to enabled full ASLR for 7-Zip 18.05.
So now we have 7-Zip 18.05 with full ASLR and DEP. Stack canaries (/GS) are still disabled though.