4 ms·

I have previously read that for some reason the author disables most of the compiler options for things like ASLR and DEP I never managed to find out why edit

• landave 9y ago
  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.
  • leeter 9y ago
    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).
    • landave 9y ago
      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.
      • blibble 9y ago
        > 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!
        • HorizonXP 9y ago
          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.
        • RaleyField 9y ago
          For virtually everybody even 500% slower would be acceptable. 1% is 10 second, one-time cost, which is objectively a fool's bargain.
          • deleted 9y ago
            [deleted]
          • RaleyField 9y ago
            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.
            • user5994461 9y ago
              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.
  • staticassertion 9y ago
    Why is this such an uphill battle?
    • AnIdiotOnTheNet 9y ago
      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.
      • staticassertion 9y ago
        Comparing javascript to ASLR is nonsensical.