Earlier quoted context omitted.
Who said anything about reading a document?
The guidelines seem like a document to me: https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC...
You don't have to read them. The compiler will enforce them.
7-Zip: From Uninitialized Memory to Remote Code Execution
101–110 of 121 posts
Re: 7-Zip: From Uninitialized Memory to Remote Code Execution
#102Hi all,
In 18.01 Igor had fixed CVE-2018-5996 with adding some variable like _errorMode or m_TablesOK.
And in 18.05 I don't see this variables. Igor was replace it by _solidAllowed to fix CVE-2018-10115. Does it fix for both CVE-2018-5996 and CVE-2018-10115?
Thank you
Re: 7-Zip: From Uninitialized Memory to Remote Code Execution
#103Earlier quoted context omitted.
The guidelines seem like a document to me: https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC...
You don't have to read them. The compiler will enforce them.
Oh, ok, I didn't know that, thanks. Enforcing guidelines seems a bit like a contradiction in terms :)
Re: 7-Zip: From Uninitialized Memory to Remote Code Execution
#104Earlier quoted context omitted.
Interesting, I wasn’t aware of that. However, isn’t getting an EV certificate impossible for a natural person? You’d have to be some sort of legally recognized organization. Not exactly suitable for small-scale Open Source development.
>However, isn’t getting an EV certificate impossible for a natural person? You’d have to be some sort of legally recognized organization no? random example: https://sourceforge.net/projects/keepass/files/KeePass%202.x... signer is: "Open Source Developer, Dominik Reichl" edit: another example https://yarnpkg.com/latest.msi signer is: "Daniel Lo Nigro"
KeePass: This isn’t an EV certificate (has only OID 2.23.140.1.4). Certum also clearly states, topmost on the description of how to get an EV Code Signing certificate:
> We do not issue EV Code Signing certificates to natural persons!
Yarn: Not an EV certificate either: "Organizationally validated certificates used to sign standard objects." (2.16.840.1.114412.3.1 in addition to 2.23.140.1.4.1).
Re: 7-Zip: From Uninitialized Memory to Remote Code Execution
#105Earlier quoted context omitted.
I just checked and I was on v9 from 8 years ago on my work pc. Why bother fixing security bugs etc if you're not going to roll them out? With other Windows software I get told about updates when I load them (winscp, Virtualbox) or they check and update themselves (Firefox).
Because there are multiple conflicting priorities here. On the one hand, it is good to keep software updated, and therefore software should check for updates. On the other hand, software should restrict itself to solving one problem domain. Interacting with the internet is something wholly distinct from decompressing files, and so the software should not branch off into a new domain. Choosing between these priorities…
Assuming I agree with you, what's the reason for not telling me about updates when I run the app? What's the advantage of the decision they've taken which is to not announce this?
Re: 7-Zip: From Uninitialized Memory to Remote Code Execution
#106Earlier quoted context omitted.
Well, it says „official website“. If it isn‘t the author should send a C&D, this is really unfair.
Yeah, there is no question about it. This website clearly says that it's the legit source for 7zip. There is even a red box on the right side of the page. This needs to be taken down if this is not an official source. The left side has a navigation to different translations of the page. All but the English version link to the German page as well. I'm guessing it was once part of the build pipeline but has since been…
> So yeah, it is an official source. It's just outdated
`whois 7-zip.de` resolves to a private person in Germany. This does not look official to me. More like a crowdsourced effort of providing translated websites with a dangerous effect in case of security vulnerabilities.
The versions provided are (as of 2018-05-04T10:20:00Z): en 18.05, de 16.04, zh 16.04/18.05, eo 18.01, fr 18.01, ja 18.05, pt 18.01, es 18.01, th 18.05, vi 18.01
Re: 7-Zip: From Uninitialized Memory to Remote Code Execution
#107Earlier quoted context omitted.
The guidelines seem like a document to me: https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC...
You don't have to read them. The compiler will enforce them.
The C++ compiler can't enforce many of these rules (and many of the ones it does claim to enforce, it only does heuristically), and the document itself is not shy about admitting that. It also makes quite clear that it expects not just mechanical checking, but things like peer review, to take these guidelines into account--meaning yes, you are expected to know a large portion of the document. Also, a lot of the listed enforcement mechanisms are literally just flagging suspicious code--you would have to disable a tremendous number of such flags to execute many perfectly reasonable programs. Stop misleading people about the contents of this document actually being enforced by the compiler, please.
Re: 7-Zip: From Uninitialized Memory to Remote Code Execution
#108Re: 7-Zip: From Uninitialized Memory to Remote Code Execution
#109This is why Cuckoo Sandbox uses sflock (https://github.com/jbremer/sflock) :)
It sandboxes extraction.
Re: 7-Zip: From Uninitialized Memory to Remote Code Execution
#110Earlier quoted context omitted.
> 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.