From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linutronix.de (146.0.238.70:993) by crypto-ml.lab.linutronix.de with IMAP4-SSL for ; 28 Feb 2019 18:22:27 -0000 Received: from mga04.intel.com ([192.55.52.120]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1gzQKA-0002mR-66 for speck@linutronix.de; Thu, 28 Feb 2019 19:22:26 +0100 Date: Thu, 28 Feb 2019 10:22:23 -0800 From: mark gross Subject: [MODERATED] test numer 2 Message-ID: <20190228182223.GB7752@mgross-MOBL.amr.corp.intel.com> Reply-To: mgross@linux.intel.com MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: [$] GMP and assert() [Security] Posted Feb 27, 2019 21:11 UTC (Wed) by jake A report of a potential security problem in the GNU Multiple Precision Arithmetic (GMP) library was met with a mixed reaction, from skepticism to responses verging on hostility, but the report ultimately raised a question worth pondering. What role should assertions (i.e. calls to the POSIX assert() macro) play in error handling? An assertion that fails leads to a process exit, which may not be what a developer calling into a library expects. Unexpected behavior is, of course, one step on a path that can lead to security holes. Full Story (comments: 14)