all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Mario Castelán Castro" <marioxcc.MT@yandex.com>
To: help-gnu-emacs@gnu.org
Subject: Re: CVE-2017-14482 - Red Hat Customer Portal
Date: Mon, 25 Sep 2017 16:11:04 -0500	[thread overview]
Message-ID: <f05a5aa6-e494-f709-c3c2-ac726e5766e9@yandex.com> (raw)
In-Reply-To: <87vak8rwcx.fsf@qcore>

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

On 24/09/17 09:42, Óscar Fuentes wrote:
> It seems that you think that formal verification says that the software
> is correct. That's in theory. Practice is different, as usual.

This depends on what exactly is meant by “correct”.

If by “correctness” it is meant a formula in *formal logic*, then yes,
we can prove that the program behaves correctly.

If by “correct” it is meant an informal concept, then proving
correctness is in general not possible because a specification in formal
logic is required to prove anything. One may believe that one has
formalized correct behavior but later one finds that the formalization
does not accurately capture the informal concept.

The cases of the “bugs” mentioned in the paper you referenced are error
in formalizing “correct behavior”. That this is possible is not breaking
news, as you seem to think. This is a caveat well known to anybody
involved in formal verification.

Specifically, several of those “bugs” are errors in describing the
behavior of the environment in which the program is assumed to run. One
possible view in this circumstance is that the program *is* correct, but
it was run in an environment where the formal guarantees does not apply.
This is similar as how one can prove the implication that *if* ‘X’ is a
real number *then* ‘X^2≥0’. Suppose somebody applies the conclusion
where the antecedent fails; for example, in the complex numbers, then
the conclusion is false, but so is the antecedent, so there is no
contradiction here.

There is also the issue of having a fundamentally unsound logic. We can
reason about this risk as follows: The underlying logic of many proof
assistants is, or can, be proved sound (note that soundness implies
consistency) assuming that ZFC is consistent. In turn we have reasons to
believe that ZFC is consistent (I will not elaborate on that because it
deviates too much from the original topic of this conversation).

> Instead of writing a lengthy explanation about why formal verification
> can't be a guarantee about the correctness of a piece of sotware, I'll
> simply reference a study about failures on verified systems:
> 
> https://blog.acolyer.org/2017/05/29/an-empirical-study-on-the-correctness-of-formally-verified-distributed-systems/

The paper is of interest to me. Thanks for bringing it into my
attention. I only took a glance but maybe I will eventually read it with
detail. The blog post is just padding; you should have linked the paper
directly.

-- 
Do not eat animals; respect them as you respect people.
https://duckduckgo.com/?q=how+to+(become+OR+eat)+vegan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

  parent reply	other threads:[~2017-09-25 21:11 UTC|newest]

Thread overview: 68+ 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 [this message]
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
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
  -- strict thread matches above, loose matches on Subject: below --
2017-09-27 10:51 Richard Melville

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

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

  git send-email \
    --in-reply-to=f05a5aa6-e494-f709-c3c2-ac726e5766e9@yandex.com \
    --to=marioxcc.mt@yandex.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.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.