From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by sourceware.org (Postfix) with ESMTPS id 8099D3858C53 for ; Wed, 7 Feb 2024 20:45:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8099D3858C53 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=owlfolio.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=owlfolio.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 8099D3858C53 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=66.111.4.26 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707338748; cv=none; b=qzPwgcukinfdrRjUrdsBZyTaGosTLtDQOdvX3qyMdal+elxX+2/1DkkZxZnEQv0K4rlVXFAsiOp1u0SX7XfzYK56x2wFt20qMb6NC5v9SfLCg5pGwW64FsuQrApEXXc0PqkuiXszAe9BEckw6WeEI7oLfEjrVgN1iNA/lvX+rT4= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707338748; c=relaxed/simple; bh=AMmELiJEz8QEQG0aeZdzQ9aW6hGJKwysE2q+46VGPzE=; h=DKIM-Signature:DKIM-Signature:MIME-Version:Message-Id:Date:From: To:Subject; b=HYCfOVF6lE1t7d2Ec+UG4ViGCY9NA1QDW17+Ku7BcMvEmicVUGr/9kBkdIC7PVM5t+UYbtehdPHYtd4o4xoEG/zD21303FO98ffCYGuqqTs6iuT8qX5GnhNEeB5rOulRDrzOKA2mOXlGyAeyvZ0stOcrFDDUau9mgMa7iPvXmP8= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 9E44C5C0158; Wed, 7 Feb 2024 15:45:44 -0500 (EST) Received: from imap45 ([10.202.2.95]) by compute5.internal (MEProxy); Wed, 07 Feb 2024 15:45:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=owlfolio.org; h= cc:cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm2; t=1707338744; x=1707425144; bh=crpycs312L KtcfKtK+L1s3aKiDOLbAfnf2QZ48BxOV0=; b=lnydRtADj0lkodekefWTIro6pD /qXMomqxTcLESaKFzq1ENrHN47phTOTJBPovsAMmfgoolKRvBXkgH1/Wa+lN4JRq GztjJafpI5ZTa+hE+fGxF3EmqR5QVQoyyYEpZydYF5jP3cHGrlINm0Nw96hiPzFI Cxb/Fa7B1pljbMuIHWueoRALhtAjgTsgP7vmeUsCc5dk0KiVXo/O+cBODhH8BWP3 Ke4YySmQC+DnJbpqefzqTww7lAF6XI8rCaVfSEbPOUY+t/e1MWYKO4WogvVOothO r0wq1qKmFOa+Np5aiwK/nWitlOQuGv6k58Zn9SPyM9bVhcX1bB2+ReFMHbjA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; t=1707338744; x=1707425144; bh=crpycs312LKtcfKtK+L1s3aKiDOL bAfnf2QZ48BxOV0=; b=siWOVx9dAQ/n/F6y9PaXfq4Jb50TnJZgUagPlI7j7F2q U1imI7kgiyUvdk4LdSayJNKqXgnaD2KaT7DVHQQ/DreO2aaoPwokJj9BE78yjNwO +BBUtX21/NOmD4f3C7q/kUkTchz1RJuCVATdcjyk+MOLh4hAQuG1ceIYFewXKSxl brOC8iEZq5FbwYQaQ6ytjG5iVg+BhW6RnJ7Eg1UvL3BWLVnY8/c2D9txKat3h1SY DBGdYrVb4axY5mW1d5hyG52KQHgj3lnrupUj7fp5h5TQlQXmlg5MCtUm8Aje8/8b CzjOwvTryVzkTEW2QfrKV8eywmT9NzMp+yE+J1ajKw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrtddvgddufeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtsehttdertderredtnecuhfhrohhmpedfkggr tghkucghvghinhgsvghrghdfuceoiigrtghksehofihlfhholhhiohdrohhrgheqnecugg ftrfgrthhtvghrnhephfelfeehudfhleegheegjeevheeuieehvdfgueeuteetleeiieet heefhfeludeinecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepiigrtghksehofihlfhholhhiohdrohhrgh X-ME-Proxy: Feedback-ID: i876146a2:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id E032D272007D; Wed, 7 Feb 2024 15:45:43 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.11.0-alpha0-144-ge5821d614e-fm-20240125.002-ge5821d61 MIME-Version: 1.0 Message-Id: <30c30ef6-7446-46f6-a502-d1c623762121@app.fastmail.com> In-Reply-To: <4963e3ae-b0d5-d1d7-a986-5709d7a30bbb@ispras.ru> References: <20240131145555.GB2102@cventin.lip.ens-lyon.fr> <96521764f4636c9ea3f3089f369975c12fa8be77.camel@xry111.site> <20240201005155.GF3044@qaa.vinc17.org> <20240201090721.GH3044@qaa.vinc17.org> <5ea9eabb-f047-490f-abe9-43630d79c395@cs.ucla.edu> <7234533a-c8dd-4114-aa64-d4af3b138a3a@gotplt.org> <4d94a528-fe3f-413d-afa0-91a41f8371ff@app.fastmail.com> <4963e3ae-b0d5-d1d7-a986-5709d7a30bbb@ispras.ru> Date: Wed, 07 Feb 2024 15:45:22 -0500 From: "Zack Weinberg" To: "Alexander Monakov" Cc: "Paul Eggert" , "Siddhesh Poyarekar" , "Vincent Lefevre" , "Xi Ruoyao" , "Adhemerval Zanella" , "Turritopsis Dohrnii Teo En Ming" , "GNU libc development" , "ceo@teo-en-ming-corp.com" Subject: Re: New GNU C Library (glibc) security flaw reported on 30 Jan 2024 Content-Type: text/plain X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,JMQ_SPF_NEUTRAL,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Wed, Feb 7, 2024, at 2:55 PM, Alexander Monakov wrote: > On Wed, 7 Feb 2024, Zack Weinberg wrote: >> Still, I think it is likely that some C libraries in >> the past have failed to implement this requirement (intentionally or not). >> In the attached patch I revised that suggestion again and I hope it satisfies >> everyone's expectations now. > > I don't understand how that is likely: was it common to use merge sort for > implementation of qsort? For in-place sorting algorithms that mistake is > pretty much impossible to make. It's a subtle requirement that conflicts with a textbook optimization to *any* sorting algorithm that isn't 100% in-place, and a supermajority of comparison functions in the wild won't care if it's violated. It would be *more* surprising to me if nobody could turn up a qsort implementation that breaks this rule and always has. > In any case it seems unnecessary (and even impolite maybe, towards the authors > of those other C libraries) to make such implication in the Glibc manual. > It's much nicer to stick to the facts about Glibc itself. I see where you're coming from but it is even more important that the manual be clear about what portable code can and cannot rely on. > (Glibc VCS briefly carried an implementation with such a mistake around 2002 > when Roger Sayle's "Towers of Hanoi merge sort" was applied and then reverted) Was it reverted because of this mistake? Do you happen to remember what broke? zw