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 0D6E83857838 for ; Tue, 7 Nov 2023 15:11:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0D6E83857838 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 0D6E83857838 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=1699369863; cv=none; b=AuzdEEzgNSVcZBnUYUHV+19L4ieW/tdlJ1pxw/r99AvnbQ3Us974+n+5wLtjInCtQ2UypCd33KDSgPgaWKRC5+bo5SpjvpFZLD3Uz8Ki3RiUDDVVsjc/8GIG+FNkMKUKRPetXKafHNq9tI15So8K+rIbm2n1F+gfBijkb+30VY4= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699369863; c=relaxed/simple; bh=Et6Qt1dvetR3eahn1Yg/MtGjquXP2Hi77eWsYdA3G9Y=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=N785/vJMQDb4wh1OdRrZKUb/HFE4x+FOlfX0+fDMb5rH5WZTcEiYuY8dAIWopzJ7wjnSBJEHLVUVOZQjUvCG533Caos+BZeMo9QSP+JCHciqKp2E7eTQzjGqy7aCsOxEZubVtHohb7/gJ+P22QVIKZ57yC0ubM9fSVPG4iJMql8= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1699369861; 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=lbennd4vT0fGjU7THs2ZpGRKrSUDsutEKzV+4xAZZI8=; b=QoUneA3kLUrjXOxWfj0pl6+Y/zQRbFCnQHGl+FJOGBuXkE/wmdqy8oc3rc1yeJgHFfJ7KI 2kRLyt6Rx8fsphch3MYtnVu28Gbr+bHLtBV7CzQnQoacXJMHGGMPGBGu1M08Q26rqZGHSX qRieyEmyZwpYEoiz6bg/5kuBiRszky0= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-553-4jAN-pSEP2aCp-GS3OTstg-1; Tue, 07 Nov 2023 10:10:57 -0500 X-MC-Unique: 4jAN-pSEP2aCp-GS3OTstg-1 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (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 1D7AA381A892; Tue, 7 Nov 2023 15:03:24 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.2.16.22]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 5EB99492BE0; Tue, 7 Nov 2023 15:03:23 +0000 (UTC) From: Florian Weimer To: Siddhesh Poyarekar Cc: GNU C Library , Carlos O'Donell , Adhemerval Zanella Subject: Re: [RFC] Publishing glibc advisories References: <3b60b07f-d1a3-c8f2-26cc-728ce1bfe338@gotplt.org> <87mswnq8bg.fsf@oldenburg.str.redhat.com> <430261b9-d932-5142-0cd2-2a47ec9a6c9f@gotplt.org> Date: Tue, 07 Nov 2023 16:03:21 +0100 In-Reply-To: <430261b9-d932-5142-0cd2-2a47ec9a6c9f@gotplt.org> (Siddhesh Poyarekar's message of "Fri, 13 Oct 2023 06:50:42 -0400") Message-ID: <87ttpxbo7a.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.3 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.9 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-4.8 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,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: * Siddhesh Poyarekar: > On 2023-10-13 03:40, Florian Weimer wrote: >> * Siddhesh Poyarekar: >> >>> I'm working on a way to publish glibc advisories and my first thought >>> was to host all advisories in the repository in a `advisories` >>> toplevel directory, but there's a bunch of information that is >>> typically shared, that will be cumbersome to maintain within the >>> repository. >> I think we should put it in the main repository. It's easier to >> integrate it with our current review prcedures. > > Hmm, I guess I'm mainly concerned about referring to commit fixes, > everything else may be easy enough to maintain in the same patchset as > the CVE fixed and could be trivially backported. It still feels > unsanitary to me, but fair enough, since that seems to be the > preference and I agree it integrates easily with our current review > procedures. We'll have to update the advisory anyway once people do more backports. The initial list of releases will likely grow over time. >>> As a result, I am thinking of requesting a separate repository, >>> e.g. glibc-advisories.git to host the advisory files along with >>> scripts to process them. I'm thinking of using the OSV[1] format for >>> the advisory files since that appears to be the growing standard for >>> maintaining and sharing CVE information. >> It's more important that we include information about impacted >> commit >> ranges, including backports to release branches. We should leave the >> format to others. I have not seen many folks publishing data in OSV >> format. > > Python uses the OSV format[1], I haven't looked hard to see who else > does, but there does seem to be a growing movement around it. I don't > feel too strongly about it though, we can leave the OSV format to > others or consider it later if we feel like it. In that case, we > could do a simple git-commit-like format with a subject line and free > text description along with tags to add specific data, > e.g. Affected-ref: , Reported-by: , Fixed-by: each ref>, etc. I think we should focus on content first, and once we know what we need, we can start formalizing it if we still feel like it. 8-) > Impacted commit ranges are the easy bit, refs for fixes are > not. However, I wonder if it would be acceptable to add git tags to > mark the fix refs, e.g. CVE-2023-4911_glibc-2.39_1, > CVE-2023-4911_glibc-2.38_1, CVE-2023-4806_glibc-2.34_1, > CVE-2023-4806_glibc-2.34_2, etc. That would eliminate the need for a > Fixed-by tag and a script could auto-generate that information for the > announcement text (or even to list commit refs for a specific branch) > from the git tags. In my experience, tags are rather cumbersome. What's worse, people will demand signed tags, and then we have to figure out key management for that. Tags can move, too, but these really shouldn't. I think we should just mention commit hashes. Thanks, Florian