unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
From: dekkzz78@gmail.com
To: help-gnu-emacs@gnu.org
Subject: Re: Re: CVE-2017-14482 - Red Hat Customer Portal
Date: Fri, 29 Sep 2017 15:59:21 +0100	[thread overview]
Message-ID: <20170929145921.GA5297@TP-x61s.localdomain> (raw)
In-Reply-To: <83a81d8ylf.fsf@gnu.org>

[-- Attachment #1: Type: text/plain, Size: 3610 bytes --]

On 09/29, Eli Zaretskii wrote:
>> From: Mario Castelán Castro <marioxcc.MT@yandex.com>
>> 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.

Ouch - there's a project doomed from the start.

>> > […] 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.

That's more to with poor teaching & understanding of how to code securely.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2017-09-29 14:59 UTC|newest]

Thread overview: 67+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-21 21:51 CVE-2017-14482 - Red Hat Customer Portal ken
2017-09-21 22:03 ` Kaushal Modi
2017-09-21 23:07   ` ken
2017-09-22  7:37     ` Alberto Luaces
2017-09-22  7:48       ` Emanuel Berg
2017-09-22 20:12         ` Mario Castelán Castro
2017-09-22 22:14           ` Emanuel Berg
2017-09-24  2:08             ` Mario Castelán Castro
     [not found]             ` <mailman.1063.1506218941.14750.help-gnu-emacs@gnu.org>
2017-09-24  6:47               ` Emanuel Berg
2017-09-24 13:38                 ` Mario Castelán Castro
2017-09-24 14:42                   ` Óscar Fuentes
2017-09-24 14:54                     ` tomas
2017-09-26 18:57                       ` Narendra Joshi
2017-09-24 23:06                     ` Emanuel Berg
2017-09-25 21:23                       ` Mario Castelán Castro
2017-09-25 21:49                         ` Emanuel Berg
2017-09-26  1:43                           ` Mario Castelán Castro
2017-09-26  2:17                             ` Emanuel Berg
2017-09-25 21:11                     ` Mario Castelán Castro
2017-09-25 23:58                       ` Óscar Fuentes
2017-09-26 14:46                         ` Mario Castelán Castro
2017-09-26 23:31                           ` Óscar Fuentes
2017-09-29 20:21                             ` Mario Castelán Castro
2017-09-29 12:43                           ` Eli Zaretskii
2017-09-29 14:59                             ` dekkzz78 [this message]
2017-09-29 16:51                               ` Óscar Fuentes
2017-09-29 17:20                                 ` Emanuel Berg
2017-09-29 18:27                                   ` Óscar Fuentes
2017-09-29 19:45                                     ` Emanuel Berg
2017-09-29 20:06                                       ` Óscar Fuentes
2017-09-29 23:24                                         ` Emanuel Berg
2017-09-29 18:03                               ` Eli Zaretskii
2017-09-24 23:07                   ` Emanuel Berg
2017-09-23 10:05           ` Charles A. Roelli
2017-09-23 12:53             ` Óscar Fuentes
2017-09-23 13:12               ` Eli Zaretskii
2017-09-23 17:18                 ` Glenn Morris
2017-09-23 17:34                   ` Eli Zaretskii
2017-09-23 20:50                     ` Yuri Khan
2017-09-24  2:53                       ` Eli Zaretskii
2017-09-24  7:13                         ` Philipp Stephani
2017-09-24 18:29                           ` Robert Thorpe
2017-09-29  8:17                             ` Eli Zaretskii
2017-09-29 20:28                             ` Stefan Monnier
2017-09-29 23:28                               ` Emanuel Berg
2017-10-03  0:52                                 ` Stefan Monnier
2017-10-03  1:04                                   ` Emanuel Berg
2017-09-29  7:11                           ` Eli Zaretskii
     [not found]                         ` <mailman.1068.1506237251.14750.help-gnu-emacs@gnu.org>
2017-09-24  7:48                           ` Emanuel Berg
2017-09-25 21:26                         ` Glenn Morris
2017-09-25 22:02                           ` Emanuel Berg
2017-09-25 22:08                           ` Ludwig, Mark
2017-09-26  5:50                             ` Emanuel Berg
2017-09-26 13:40                               ` Ludwig, Mark
2017-09-26 17:46                             ` Philipp Stephani
2017-09-26 19:00                               ` Ludwig, Mark
2017-09-29 13:23                               ` Eli Zaretskii
2017-09-29  9:48                           ` Eli Zaretskii
2017-09-26 18:44                   ` Narendra Joshi
2017-09-26 18:51                     ` Philipp Stephani
     [not found]           ` <mailman.988.1506161159.14750.help-gnu-emacs@gnu.org>
2017-09-24  6:31             ` Emanuel Berg
2017-09-22 16:40       ` ken
2017-09-22 19:07         ` Emanuel Berg
2017-09-23 20:27     ` Bob Proulx
     [not found]     ` <mailman.1053.1506198486.14750.help-gnu-emacs@gnu.org>
2017-09-24  6:38       ` Emanuel Berg
2017-09-24 17:17         ` Maxim Cournoyer
2017-09-24 22:38           ` Emanuel Berg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170929145921.GA5297@TP-x61s.localdomain \
    --to=dekkzz78@gmail.com \
    --cc=help-gnu-emacs@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).