From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id BEFEF385840D for ; Tue, 23 Apr 2024 18:26:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BEFEF385840D Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org BEFEF385840D Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1713896772; cv=none; b=JgVdHaQ7IWV4vAnAk7Lh3+XK3fPwHVuFHpLj8SvT+l17m7KJz2OunlA8SDuFZYiUTpeHCe6kx0wD7RypWW+iTB/tXhDadMm8V6ELcMrR5n0iKLW4/Kk39QfWkreo3iazX2hNF126edrjKaikFVoD+nJ8d9+sYWevJPaWHwM/jUM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1713896772; c=relaxed/simple; bh=bqKkY1sjvPiUa2GJ5s2GjktvMzGALNiNuVTz56NgW+0=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=tG9qQpAczusdcpIvLtycZ7tMj8sDtjVXG5CWOYpoqQhSILS5BaZHUnaQTtba6S8MrGuEVMG3299YKyiBT+UaVtzZWDiN32ebu/M1iHQS6qOVhX5tpMuohb2bgTMLrdRWyFBuHQb8aROu66sFvfcyXsIoVoUqmz6PeT4a9jYsD1Y= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1713896770; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ZGuvKzVtko/IHPEyR7nj0nWWkViUlNRA3thWbeSVOFY=; b=ShHY8erPjZBlcHCILvQT59renNs4EZlBnpDSuxTzJbURJmNh/3LJdsVtRcmIXhZxMFl+fo PxliSkilzn+pjc0lHYqDxbAoBq6ZKwCzScdDvcRWUX3m1Jo7w16htV5QcDUCbRhadbXr53 tcsuc97UANe+r2xMRIIG2AHTbzVlPxs= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-327-WTh6A-LYMNCxXI_Z25lhjw-1; Tue, 23 Apr 2024 14:26:07 -0400 X-MC-Unique: WTh6A-LYMNCxXI_Z25lhjw-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 5FB98834FB4; Tue, 23 Apr 2024 18:26:06 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.192.74]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 42CA043FAD; Tue, 23 Apr 2024 18:26:03 +0000 (UTC) From: Florian Weimer To: Paul Eggert Cc: Zack Weinberg , 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 In-Reply-To: <470fa772-d323-43b1-848f-038cc45992cb@cs.ucla.edu> (Paul Eggert's message of "Tue, 23 Apr 2024 11:09:49 -0700") 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> <1b2e16dd-4acf-45da-9285-7c6ce0e0fea6@cs.ucla.edu> <87bk6k1coe.fsf@oldenburg.str.redhat.com> <90ac2925-a833-4a2c-a7f7-9c28276b9222@app.fastmail.com> <470fa772-d323-43b1-848f-038cc45992cb@cs.ucla.edu> Date: Tue, 23 Apr 2024 20:26:02 +0200 Message-ID: <87h6fsaqbp.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.5 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP 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: * Paul Eggert: > On 2024-04-22 07:39, Zack Weinberg wrote: >> On Mon, Apr 8, 2024, at 4:28 AM, Florian Weimer wrote: >>> * Paul Eggert: >>>> the same array element should always compare the same way with >>>> the key. >>> >>> I don't think the requirement described in the last line actually >>> exists. Some applications likely reuse the same key object to search >>> for different values, and the requirement might prohibit that (but it >>> is ambiguous). >> I believe what Paul was trying to express here is that *during a >> single >> call to bsearch*, repeated calls to the comparison function with the >> same (key, element) pair should return the same result. > > Yes. I was mimicking POSIX, which says: > >> When the same objects ... are passed more than once to the comparison function, the results shall be consistent with one another. That is, the same object shall always compare the same way with the key. > > Perhaps we should simply remove the word "always" from the glibc > manual's phrasing? "Always" is not needed, and removing "always" > should help avoid the unwanted implication that the requirement > applies even to earlier or later bsearch invocations. Makes sense, thanks. Florian