From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.help Subject: Re: CVE-2017-14482 - Red Hat Customer Portal Date: Fri, 29 Sep 2017 15:43:08 +0300 Message-ID: <83a81d8ylf.fsf@gnu.org> References: <2e991bb7-c570-49ce-be94-3654945bb4b5@mousecar.com> <87d16jxjz6.fsf@eps142.cdf.udc.es> <861smzcgx3.fsf@zoho.com> <1b3bec6e-d4d5-37a7-ba54-49bd2d8281bd@yandex.com> <86k20qbcu9.fsf@zoho.com> <86o9q0a8zc.fsf@zoho.com> <87vak8rwcx.fsf@qcore> <87mv5is54g.fsf@qcore> <4d048ea0-5c54-f5ba-c903-78614480ac76@yandex.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1506689038 16952 195.159.176.226 (29 Sep 2017 12:43:58 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 29 Sep 2017 12:43:58 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri Sep 29 14:43:55 2017 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dxudz-0003qZ-RE for geh-help-gnu-emacs@m.gmane.org; Fri, 29 Sep 2017 14:43:51 +0200 Original-Received: from localhost ([::1]:35246 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dxue7-0007Qh-9W for geh-help-gnu-emacs@m.gmane.org; Fri, 29 Sep 2017 08:43:59 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44705) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dxudc-0007Qa-3E for help-gnu-emacs@gnu.org; Fri, 29 Sep 2017 08:43:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dxudY-0007G7-W6 for help-gnu-emacs@gnu.org; Fri, 29 Sep 2017 08:43:28 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:44096) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dxudY-0007G2-SE for help-gnu-emacs@gnu.org; Fri, 29 Sep 2017 08:43:24 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1203 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dxudW-0003UF-CJ for help-gnu-emacs@gnu.org; Fri, 29 Sep 2017 08:43:23 -0400 In-reply-to: <4d048ea0-5c54-f5ba-c903-78614480ac76@yandex.com> (message from Mario =?utf-8?Q?Castel=C3=A1n?= Castro on Tue, 26 Sep 2017 09:46:46 -0500) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.org gmane.emacs.help:114467 Archived-At: > From: Mario Castelán Castro > Date: Tue, 26 Sep 2017 09:46:46 -0500 > > > "correct" means that the client (the people who required the software) > > says that the program fulfills his requirements. Sometimes you need to > > wait an infinite amount of time for obtaining client's approbation :-) > > The same answer applies: If a client either provides himself or accepts > a formula in formal logic as a description of his requirements, then > yes, we can prove that a program is correct according to this concept. > > If the client can not provide an *absolutely accurate* description (this > is necessarily a specification in formal logic) of what his requirements > are, then we can not assure the client that the program meets his > requirements. This is not a fault of the programmer, but of the client > for being vague about what his requirements are. Good luck finding many clients that can provide such a set of requirements. Most of the projects I deal with in my daytime job have to do with clients that cannot even provide _in_formal requirements, and depend on me and my team to do that for them. > > […] We must provide what is requested from us, in > > terms of functionality, performance and cost […] > > Somebody has to take a decision between cheap software and reliable > software. Those are mutually exclusive. The world is not black-and-white, it's an infinite set of gray shades. If you are running a practical operation that needs to satisfy clients and be self-sustaining, you will have to choose one of those shades. You seem to be advocating the "reliable software" extreme, which, according to your definitions, is unreachable in any practical project of a large enough size. This is a kind of academic solution that does not translate well to any software engineering practices that lead to a delivery soon enough for clients to want to order your solutions. IOW, I'm firmly with Óscar here. > The predominating choice is cheap software. As evidence for this claim I > note the very high frequency of bug reports including security > vulnerabilities. I think you are misinterpreting the reasons for those bugs and vulnerabilities. The real reasons are the tremendous complexity of software we are required to produce nowadays, and the respectively inadequate level of formal-proof technologies that prevent their use in large-scale projects. IOW, we are simply trying to solve problems that are in principle insoluble with the current technology. So what we get are solutions that are 90% reliable, and the rest are bugs and vulnerabilities. > I have spent already enough time addressing your misconceptions. If you > reply to this message with even more misconceptions, I will not reply > because I am unwilling to spend even more time explaining what you > should already know. It is *YOUR* task to make sure you know what you > are talking about (and you have failed so far), not mine!. Please consider dropping your arrogant style and allow that others come into this discussion with some level of experience and knowledge, which should be respected as valid, instead of discarding it. If you disregard engineering practices, then your pure science is not interesting, at least not to those who have practical problems to solve every day.