Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.


> 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 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.


For virtually everybody even 500% slower would be acceptable. 1% is 10 second, one-time cost, which is objectively a fool's bargain.


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?


> Why is that asking too much?

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, ...


Interesting insight -- thanks!

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 :-)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: